IRAP for SaaS and cloud providers is an independent assessment of a cloud service against the Information Security Manual, run by an ASD endorsed assessor. It checks the controls the provider owns under the shared responsibility model, not the hyperscaler infrastructure beneath it. It is an assessment, not a certification, and there is no pass mark.
Do SaaS and cloud providers need an IRAP assessment?
If your service stores, processes or communicates Australian Government information at OFFICIAL: Sensitive or above, an agency cannot use it until it has been IRAP assessed. The trigger is the data and the buyer, not your size. The Protective Security Policy Framework, in its Table 21, requires outsourced IT and cloud services that handle OFFICIAL: Sensitive, PROTECTED and SECRET information to be IRAP assessed before they hold government data. A startup with ten staff and a single hyperscaler tenancy sits in the same position as a large vendor. What changes is the boundary and the volume of evidence, not the obligation. Plenty of founders assume IRAP is only for the AWS and Azure tier. It is not. If you are still working out whether the requirement applies to you, start with whether you need an IRAP assessment and how the classification of the data is set.
What does an IRAP assessment cover in a cloud service?
It covers the controls you are responsible for under the ISM, captured in the Cloud Controls Matrix. ASD’s Cloud Controls Matrix records the implementation status of each applicable control and marks where the cloud consumer, not the provider, configures the service to meet the ISM. The output is the assessment report and that control matrix. In practice the assessment looks at your configuration, your application logic, your data handling, identity, access and logging, and the operational practices around them. It does not re-assess the physical data centre or the hypervisor your hyperscaler already had assessed. The point is to show an agency exactly which controls you implement and how, which is the same evidence base described in what an IRAP assessment is.
How does the shared responsibility model work for IRAP?
This is where most cloud IRAP work goes wrong. The hyperscaler’s IRAP assessment covers its infrastructure layer only. Everything you build on top of it is a separate scope. AWS or Azure being assessed at PROTECTED does not make your SaaS PROTECTED. You inherit the controls the provider implements, then you own and must evidence the rest, which is what your own IRAP assessment exists to check. ASD’s cloud guidance is explicit that the IRAP report sets out the shared responsibility model, and that a consuming agency must also have its own system, built on your service, assessed, with TOP SECRET the exception. The table below shows where the line sits.
| Layer | Who is responsible | Who assesses it |
|---|---|---|
| Physical data centre, hardware, hypervisor | Hyperscaler (infrastructure provider) | The hyperscaler’s own IRAP assessment |
| Platform and managed service configuration | Shared: provider defaults, your settings | Your IRAP assessment, via the Cloud Controls Matrix |
| Your application, data handling, identity, logging | You, the SaaS or cloud provider | Your IRAP assessment |
| The system the agency builds on your service | The consuming agency | The agency’s own IRAP assessment |
What classification should a cloud provider be assessed at?
The classification is set by the government information your service will hold, and the owning agency decides it, not you. The common levels are OFFICIAL: Sensitive, PROTECTED and SECRET. The ISM control set is the same at OFFICIAL: Sensitive and PROTECTED; what changes are the physical security, personnel clearance and network obligations, and those step up sharply at SECRET. Assess at the level your buyers actually need. Being assessed at PROTECTED when your customers only handle OFFICIAL: Sensitive adds cost and clearance overhead you may never recover. For the full picture across cost, process and timelines, see the IRAP assessment guide.
How often does a cloud provider need to be reassessed?
At least every 24 months, and sooner on material change. PSPF requirement 0109 expects cloud services to have had an IRAP assessment within the previous 24 months against the latest ISM at the time of assessment, and ASD’s cloud guidance says the same: reassess at least every two years, or when an event changes the security posture. An IRAP assessment is point in time. The authorisation that follows is not. Treat the gap between assessments as continuous work, because the ISM updates through the year and your platform does not stand still. The detail on how long an assessment takes and on maintaining posture between assessments both matter here.
What do SaaS providers get wrong about IRAP?
Three things, repeatedly. They call the result a certification. It is not; ASD ceased certifying systems in 2020 and there is no pass mark, so the “IRAP certified” label on a website is wrong, and assessors notice, which is why it helps to be clear on whether IRAP is a certification. They assume the hyperscaler’s assessment covers them. It covers the infrastructure, not their tenancy. And they scope the whole platform when only one product or environment touches government data, which inflates the control count and the bill. A tight boundary is the cheapest decision you make, and it is set early in how the assessment process works.
No. IRAP is an independent assessment against the Information Security Manual, not a certification, and there is no pass mark. ASD ceased certifying systems in 2020. The consuming agency’s authorising officer makes the decision to operate.
No. A hyperscaler’s IRAP assessment covers its own infrastructure layer. Your configuration, application, identity and data handling sit above that line and are a separate scope you must have assessed.
Yes. The obligation is driven by the government data you handle and the agency buying the service, not by your size. A tight assessment boundary keeps the control count and cost manageable for a smaller provider.
There is no formal expiry, but PSPF requirement 0109 expects cloud services to have been assessed within the previous 24 months against the latest ISM, so providers reassess at least every two years or on material change.
Written by Gaurav Vikash, an ASD endorsed IRAP assessor and senior cyber security leader with 18 years of experience across Australia, the UK and Asia, including CISO and senior security leadership roles. He holds CISSP, CISA, CISM and CRISC and is an ISO 27001 and ISO 42001 Lead Implementer, and speaks regularly at industry conferences.
Sources:
- ASD, Cloud assessment and authorisation, 2025
- ASD, IRAP cloud services and the Cloud Controls Matrix, 2025
- ASD, IRAP Consumer Guide, July 2025
- Protective Security Policy Framework, requirements 0086 and 0109 and Table 21, 2025
- ASD, Information Security Manual, June 2026
Last updated: 21 June, 2026