Why Your Cloud Migration Needs an IRAP Assessment — Not Just a Penetration Test

I see this pattern regularly: an organisation migrates government workloads to the cloud, commissions a penetration test, receives a report with a handful of medium-severity findings, remediates them, and considers the security question answered. Six months later, they discover that their agency customer requires an IRAP assessment — and that the penetration test, while useful, does not satisfy the requirement.

A penetration test and an IRAP assessment answer fundamentally different questions. A penetration test asks: “Can an attacker exploit this system?” An IRAP assessment asks: “Is this system fit for purpose at the required classification level, as measured against the Australian Government Information Security Manual?”

Both are valuable. Neither replaces the other. But if your cloud environment processes, stores, or communicates Australian Government data at OFFICIAL:Sensitive or above, the IRAP assessment is what your customer will require — and a penetration test alone will not satisfy that requirement.

Understanding the Difference

The confusion between penetration testing and IRAP assessments is understandable. Both involve security professionals examining your system. Both produce reports with findings. But the scope, methodology, and purpose are entirely different.

A penetration test simulates an adversary. The tester attempts to exploit technical vulnerabilities in your network, applications, and infrastructure. The output is a list of vulnerabilities ranked by severity. This is enormously useful for identifying technical weaknesses — but it tells you nothing about whether your governance is adequate, whether your documentation is current, whether your personnel hold appropriate clearances, or whether your data sovereignty obligations are met.

An IRAP assessment evaluates your system holistically against the ISM. It covers technical controls (which may include penetration testing as one input), but also governance, documentation, personnel security, physical security, and operational processes. The output is a Security Assessment Report that provides a recommendation on the system's suitability for processing government data at the target classification.

Why Cloud Migrations Specifically Need IRAP

Cloud introduces complexities that a penetration test is not designed to evaluate. These are the areas where an IRAP assessment provides assurance that a penetration test cannot:

The Shared Responsibility Model

In a cloud environment, security responsibilities are split between the cloud service provider (CSP) and the customer. The CSP is responsible for security of the cloud (physical infrastructure, hypervisor, network fabric). You are responsible for security in the cloud (data, identity, application configuration, encryption, access management). An IRAP assessment maps this shared responsibility to ISM controls and verifies that both sides are covered. A penetration test only tests what is technically accessible to the tester — it cannot validate the CSP's controls or verify that responsibility boundaries are correctly understood.

ISM Cloud-Specific Controls

The ISM contains specific controls for cloud computing that have no equivalent in penetration testing. These include:

• ISM-1037 — Cloud service providers must be certified or assessed to a level commensurate with the classification of the data being processed
• ISM-0872 — Data sovereignty requirements: government data must be stored in Australia or in approved locations
• ISM-1578 — Cloud tenancy isolation and multi-tenancy risks
• ISM-1074 — Contractual arrangements with the CSP regarding data handling, incident notification, and forensic investigation
• ISM-1579 — Cloud service provider personnel access controls and vetting

A penetration tester cannot evaluate whether your CSP contract meets ISM-1074 requirements. They cannot verify data residency. They cannot assess whether the CSP's personnel hold appropriate clearances. These are governance and contractual matters that sit squarely within the IRAP assessment scope.

The Certified Cloud Services List (CCSL) and IRAP Cloud Assessments

ASD maintains a list of cloud services that have been assessed through IRAP or equivalent processes. If your cloud platform has been IRAP-assessed by the CSP (for example, Microsoft Azure, AWS, or Google Cloud at specific classification levels), you can inherit the CSP's assessment for the controls they are responsible for. But you still need your own IRAP assessment for the controls you are responsible for — the customer-managed portion of the shared responsibility model. This inheritance model is something a penetration test has no visibility into.

Data Sovereignty and Residency

Australian Government policy requires that certain data classifications remain within Australian borders. For PROTECTED data, this typically means Australian data centres operated by Australian-vetted personnel. An IRAP assessment verifies these requirements. It examines your cloud configuration to confirm that data residency settings enforce Australian regions, that replication does not extend to offshore locations, and that backup and disaster recovery configurations maintain sovereignty requirements. A penetration test does not examine any of this.

When You Need Both

The answer, in most cases, is that you need both — but for different reasons and at different times.

A penetration test is valuable as an input to the IRAP assessment process. It provides technical evidence of vulnerability management effectiveness and identifies weaknesses that may not be visible through configuration review alone. Many IRAP assessors will recommend or require a current penetration test as part of the Stage 2 technical assessment.

The optimal sequence is:

1. Penetration test first — identify and remediate technical vulnerabilities before the IRAP assessment begins
2. IRAP assessment second — with a clean or mostly-clean penetration test in hand, the IRAP assessor can focus on the broader control landscape without being sidetracked by basic vulnerability findings
3. Ongoing penetration testing — after the IRAP assessment, regular penetration testing (annually or after significant changes) provides continuous assurance of technical security

How to Scope a Cloud IRAP Assessment

Scoping is the most critical pre-assessment decision for a cloud IRAP. Get it wrong and you will either over-scope (assessing controls the CSP is responsible for) or under-scope (missing controls that are your responsibility).

The scoping process should address:

• Cloud service model — IaaS, PaaS, or SaaS determines the boundary. IaaS gives you the most responsibility; SaaS the least. Your IRAP scope must cover everything on your side of the line.
• CSP IRAP status — Check whether your CSP has an IRAP assessment at the classification level you require. If yes, document which controls you are inheriting. If no, you may need to assess the CSP's controls as well.
• Data classification — The classification level of the data determines which ISM controls apply. PROTECTED data attracts significantly more controls than OFFICIAL:Sensitive.
• Interconnections — Every connection to and from your cloud environment is in scope: on-premises connections, third-party integrations, user access paths, management plane access, and backup/DR connections.
• Management and operational infrastructure — The systems you use to manage the cloud environment (CI/CD pipelines, monitoring tools, identity providers) are part of the assessment scope.