Cloud Security for Government: ISM and IRAP Considerations

Cloud adoption across Australian government is now mainstream, but the security obligations attached to it are frequently misunderstood. Agencies sometimes treat an IRAP assessment as a tick-box that transfers responsibility to the provider, when in reality the agency remains accountable for the risk decision and for everything it builds on top of the platform. Getting cloud security right means understanding the Information Security Manual (ISM), the role of the Infosec Registered Assessors Program (IRAP), and the wider guidance published by the Australian Cyber Security Centre (ACSC).

The ISM is the baseline, not the ceiling

The ISM, maintained by the Australian Signals Directorate (ASD), is the foundational control framework for Australian government systems. It is risk-based rather than prescriptive: instead of mandating a fixed checklist, it sets out controls that agencies select and apply according to the sensitivity of their data and the consequences of compromise. For cloud, this means the controls you implement for an OFFICIAL workload look very different to those required for a PROTECTED system.

A common mistake is to read the ISM as a one-time gate. It is updated regularly, and the threat environment it responds to shifts constantly. Treat ISM alignment as an ongoing program of work tied to your system’s authorisation lifecycle, not a document you consult once during procurement.

What an IRAP assessment actually delivers

IRAP is the mechanism ASD uses to enable independent assessment of systems and cloud services against the ISM. An IRAP-endorsed assessor examines the security controls of a service and produces a report describing how well those controls are implemented and where residual risk sits. Crucially, this is an assessment, not an accreditation or government endorsement.

The practical implications for agencies are:

• The authorising officer still decides. An IRAP report is an input to your authority to operate. Your agency’s authorising authority must weigh the residual risks and decide whether to accept them for your specific use case and data classification.
• Scope is everything. A provider may have an IRAP assessment for certain services and regions but not others. Confirm that the specific services, configurations and data centre regions you intend to use fall within the assessed scope.
• Currency matters. Cloud platforms change rapidly. Check the date of the assessment and the ISM version it was conducted against, and understand the provider’s cadence for reassessment.

Data classification drives everything

Before any cloud design decision, classify the information. The Australian Government’s protective marking scheme (OFFICIAL, OFFICIAL: Sensitive, PROTECTED and above) determines the controls you need, the assessment rigour, and often where the data may physically reside. Misclassification is one of the most damaging early errors: under-classify and you under-protect; over-classify and you incur cost and friction that pushes staff toward shadow IT.

Build a clear mapping of which workloads carry which classifications, then align each to an appropriately assessed service. For PROTECTED workloads in particular, expect tighter requirements around encryption, key management, personnel access, and onshore storage and support.

Get the shared responsibility model in writing

The single most consequential concept in cloud security is shared responsibility. The provider secures the platform; the agency secures what it puts on the platform. But the boundary moves depending on the service model:

• Infrastructure as a Service (IaaS) leaves the agency responsible for operating systems, patching, network configuration, identity and data.
• Platform as a Service (PaaS) shifts more to the provider, but application security, identity and data protection remain with the agency.
• Software as a Service (SaaS) hands most operational control to the provider, yet the agency still owns data classification, access management and configuration of the tenant.

Document the split for every service you consume. The majority of publicised cloud breaches stem not from provider failures but from customer-side misconfiguration: exposed storage, over-permissioned identities, and disabled logging. These are firmly in the agency’s column of the responsibility matrix.

The controls that matter most in cloud

While the ISM is comprehensive, a handful of areas deliver disproportionate risk reduction in cloud environments:

• Identity and access management. Enforce phishing-resistant multi-factor authentication, least-privilege roles, and just-in-time elevation for administrators. Cloud identity is the new perimeter.
• Configuration and posture management. Use automated tooling to detect drift from a hardened baseline. Insecure defaults are a leading cause of exposure.
• Logging and monitoring. Centralise logs, retain them appropriately, and ensure you can detect and investigate incidents. You cannot respond to what you cannot see.
• Encryption and key management. Encrypt data in transit and at rest, and understand who controls the keys. For sensitive workloads, customer-managed keys may be required.
• Backup and recovery. Maintain tested, isolated backups resilient to ransomware, and rehearse recovery rather than assuming it works.

Many of these map directly onto the Essential Eight, which remains an effective baseline for cloud-hosted systems just as it is on-premises. The Essential Eight mitigation strategies are a sensible starting point even where the ISM is your formal benchmark.

Sovereignty, jurisdiction and supply chain

For government, data sovereignty is rarely optional. Confirm where data is stored, processed, replicated and backed up, who can access it for support purposes, and which legal jurisdictions could compel disclosure. Many agencies require onshore data residency and Australian-based, citizen-screened support for sensitive workloads. Extend this scrutiny to the supply chain: subprocessors, third-party integrations and managed service providers can all introduce exposure that sits outside your IRAP scope.

This is also where cyber due diligence on providers pays off. Assess the vendor’s own security posture, breach history, incident response commitments and contractual security obligations before signing.

Common pitfalls in government cloud adoption

Across federal, state and local government, the same avoidable mistakes recur. Recognising them early saves rework and reduces risk:

• Treating IRAP as a transfer of accountability. An assessed service does not absolve the agency of its obligations. The authorising officer still owns the residual risk, and the agency still owns its configuration, data and identities.
• Assuming the whole product is in scope. Providers often have assessments covering specific services, tiers and regions. New features ship continuously, frequently ahead of any assessment. Using an unassessed feature with sensitive data quietly takes you outside your authorisation.
• Lift-and-shift without re-architecting. Moving a legacy application to IaaS unchanged often carries its weaknesses with it while adding new cloud-specific exposures. Cloud security benefits come from using managed services, automation and identity-centric design, not from relocating old patterns.
• Forgetting non-production environments. Test and development environments frequently hold copies of real data with weaker controls. They are a favourite target and must be governed to the same standard as production or stripped of sensitive data.
• Logging configured but never reviewed. Enabling logs is not the same as monitoring them. Without analysis and alerting, logs only help after the fact during forensics.

A further trap is cost-driven shadow IT. When the approved path to cloud is slow or restrictive, business units procure SaaS independently, often with a credit card and no security review. The remedy is to make the sanctioned route efficient enough that nobody is tempted to bypass it, and to maintain visibility of cloud spend and usage so unsanctioned services surface quickly.

Building a sustainable authorisation process

Authorisation to operate is not a finish line. Establish continuous monitoring against your ISM control set, schedule periodic reassessment aligned with provider changes and new ISM releases, and maintain a living risk register that the authorising officer reviews. Tie cloud security into your broader governance so that new services cannot be spun up outside the assessment process.

For agencies without a permanent security executive, a virtual CISO can own this lifecycle, translate ISM and IRAP requirements into practical engineering work, and represent risk to decision-makers. CISO Advisory works with federal, state and local government organisations to authorise cloud workloads with confidence. For a discussion about your environment, call 07 2112 8502 or get in touch via our contact page.

The bottom line

Cloud can be more secure than legacy on-premises infrastructure, but only when agencies engage with the ISM as a living framework, treat IRAP assessments as informed inputs rather than guarantees, classify their data accurately, and own their side of the shared responsibility model. The platform is the easy part; the discipline around it is what protects citizens’ information.