There is no annual IRAP requirement. Under PSPF requirement 0109, a cloud service provider’s IRAP assessment must be no more than 24 months old for an agency to rely on it. A material change to the system, or a new consuming agency, can force a reassessment sooner, and the next assessment is measured against whatever ISM is current then.
How often does an IRAP assessment need to be redone?
For cloud and SaaS providers, the working rule is every 24 months. The Protective Security Policy Framework (requirement 0109) says an agency should only rely on an assessment conducted within the previous 24 months, against the latest ISM at the time of assessment. There is no annual cycle and no expiry date printed on the report. The 24 months is the outer limit the consuming agency works to, not a promise the report stays accurate the whole time. ASD is blunt on this point: a report older than 24 months is not automatically invalid, but the longer it sits, the more likely it no longer describes the system. So “how often” has two answers, the 24 month ceiling and the moment something material changes. Whether you need one at all turns on the data you hold, covered in do you need an IRAP assessment.
What is the 24 month rule, exactly?
It is PSPF requirement 0109, and it applies to outsourced cloud and IT services that hold Australian Government information. The provider must have had an IRAP assessment within the previous 24 months, measured against the ISM that was current when the assessment ran. Two details decide how much margin you really have. The clock starts at the assessment, not when an agency picks up the report, so months can pass in procurement before anyone relies on it. And “latest ISM at the time” matters: an assessment run against an ISM that was already months old starts further behind the current baseline. The table below sets out what resets the clock and what does not. For the document itself and what it produces, see what an IRAP assessment is.
| Trigger | What it is | Effect on your assessment |
|---|---|---|
| 24 month limit reached | The PSPF requirement 0109 outer limit | An agency can no longer rely on the report; reassess before it lapses |
| Material change to the system | New region, new data flow, re-architecture, classification change | The old boundary no longer describes the system; reassess the changed scope |
| New ISM at the next assessment | The ISM is updated through the year | The next assessment is measured against the current ISM; new controls come into scope |
| Significant security incident | A breach or a major control failure | An agency may require a fresh assessment to confirm posture |
| A new consuming agency | A different agency wants to use the system | Its authorising officer may require a current assessment to its own satisfaction |
What forces a reassessment sooner than 24 months?
Material change. The 24 months is a ceiling, not a schedule, and the assessment is point in time against a defined boundary. A new cloud region, a new data flow, a re-architecture, a lift in classification, a merger or a significant incident can all push the system outside the boundary the assessor signed off. Change the boundary and the old report no longer describes what is running. This is where providers get caught: they treat the report as a two year pass, ship a major change in month six, then at the next assessment find the new component was never in scope. The fix is to test every significant change against the assessed boundary as you go. How that boundary is drawn is covered in defining the assessment boundary, and the ongoing discipline in maintaining posture between assessments.
Does the ISM changing reset the clock?
Not directly. A new ISM does not invalidate your current report, which stays good to its 24 month limit. What changes is the bar for the next one. The ISM is updated through the year: the June 2026 release added AI application controls and renamed data protection to cryptographic protection, and in March 2026 the cyber security principles were restructured into six functions, govern, identify, protect, detect, respond and recover, aligning the ISM with the NIST Cyber Security Framework. Your next assessment is measured against whatever ISM is current then, so controls that did not exist at your last one are suddenly in scope. Agencies increasingly expect a provider to track ISM releases between assessments rather than meet them cold at reassessment. What the ISM is and how it changes is set out in what is the ISM.
What should you do between assessments?
Treat the 24 months as continuous work, not a pause. Keep the System Security Plan and its annex current, update the control matrix as the system changes, track each ISM release, and run continuous monitoring so the next assessment confirms posture rather than discovers it. Providers that let documentation drift spend the first weeks of the next assessment reconstructing what changed and why. Start readiness well before the 24 months expires, because an agency cannot rely on a lapsed report and a gap in coverage can stall a live procurement. A practical preparation list is in the IRAP readiness checklist, and the cloud specific shared responsibility detail in IRAP for SaaS and cloud providers.
Frequently asked questions
No. There is no annual cycle. The working rule for cloud providers is the 24 month limit in PSPF requirement 0109, and a material change or a new consuming agency can require one sooner.
It carries no printed expiry, and ASD says a report is not automatically invalid at 24 months. But an agency should only rely on an assessment from the previous 24 months, so in practice that is the limit.
No. Your current report stays valid to its 24 month limit. The ISM current at your next assessment sets the controls then, so new controls come into scope at reassessment, not before.
ASD publishes no fixed duration. A reassessment of a stable, well documented system is usually faster than the first, but Cybernion’s indicative figure for a moderately complex system is 12 to 16 weeks. Start readiness before the 24 months lapse.
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.
Talk to us. We are not always chasing a transaction.
Sources:
- ASD IRAP Consumer Guide, July 2025
- Protective Security Policy Framework, requirement 0109, 2024 release
- ASD Cloud assessment and authorisation, cyber.gov.au, 2026
- The cyber security principles, cyber.gov.au, 17 March 2026
Last updated: 21 June, 2026