An IRAP assessment is point in time; the authorisation that follows is not. The ISM updates quarterly, systems change, and cloud providers must be reassessed within 24 months under PSPF requirement 0109. Maintaining posture between assessments means treating that period as continuous work, not a pause.
The organisations that struggle to maintain IRAP posture are rarely the ones short on security capability. They are the ones that treated authorisation as a finish line. An IRAP assessment is a point in time evaluation. The authorisation that follows it is not. The system keeps operating, the ISM keeps moving, the system itself keeps changing, and the threat environment does not pause while an organisation gets comfortable with its authorisation. Maintaining posture is the closing discipline in the IRAP assessment lifecycle, and it means treating the gap between this assessment and the next as an active obligation, not a quiet interval.
What does maintaining IRAP posture actually involve?
Consistency, not sophistication. Twelve months after authorisation, James Hartley, CISO at Stackform, received an email from the agency. A routine query, asking for confirmation that Stackform’s IRAP assessment remained current and that no material changes had been made to the assessed system without notification. James could answer both. He had the records. Not every organisation in that position can. The discipline is not complex; it is the organisations that treated authorisation as a finish line that come unstuck, not the ones short on capability.
How often is the ISM updated, and what should you do each release?
ASD publishes the ISM quarterly, typically in March, June, September and December. Each release may add controls, retire others, change applicability flags, or shift the intent of an existing control. The version used at assessment is fixed in the report; the system keeps operating against an ISM that does not stand still. Between assessments, review each new release against your control matrix and answer one question per release: does any new or changed control apply to the system, and if so does the system meet it?
Cybernion’s ISM Pulse, a free open source browser based tool, was built for this. Upload the SSP-A, the current quarter control matrix and the ISM Changes PDF and it computes the delta and presents an interactive review with downloadable outputs. All processing happens in the browser, so nothing leaves your environment. This is not a reassessment. It is a gap analysis against the delta. A control introduced since the assessment that the system does not yet meet is new risk: document it, weigh it against your risk appetite, and either remediate or formally accept it. Do not leave it until the next assessment.
James set the ISM quarterly review as a standing task tied to each release. The first review found one new relevant control; the gap was minor and closed within the next sprint. The second found nothing applicable to Stackform’s environment. Each review took under two hours, and there were no surprises at the next assessment.
When does a system change trigger a reassessment?
Not every change does. An IRAP assessment reflects the system as it was when it was conducted, so as the system changes the gap between what was assessed and what is running widens. The Common Assessment Framework sets out how to assess changes to an already assessed system: the assessor identifies the delta against previously assessed controls, determines the impact on existing controls, and assesses the new changes or services. The output may be a delta report, an addendum, or a new IRAP report depending on scope.
The threshold is whether the change materially affects the security posture or introduces components, services or data flows outside the original boundary. Changes below that line should still be documented and tracked, so the next assessment starts from a clear baseline rather than a reconstruction. The judgement call sits with the organisation and, where engaged, its security advisory support. When in doubt, raise the change with an assessor for a scoping opinion. Discovering mid assessment that a significant change went undisclosed is a poor position to be in.
| Changes that warrant a delta assessment or reassessment | Changes to document and track, but not reassess |
|---|---|
| Adding a new environment or service to the system | Routine patching and configuration updates within the assessed baseline |
| Integrating a new third party provider that handles assessed data | Staff changes in roles that were not individually assessed |
| Changing network architecture in a way that affects data sovereignty or segmentation | Minor feature additions that do not alter the security architecture |
| Altering access control in a way that changes the shared responsibility model | Internal process tweaks that leave the assessed controls intact |
How long is an IRAP assessment valid for cloud providers?
Under PSPF Requirement 0109, cloud service providers must have had an IRAP assessment within the previous 24 months against the latest ISM at the time of assessment. The 24 month clock runs from the assessment date, not the authorisation date. A report is not automatically invalid the day it turns 24 months old, but as it ages the chance it no longer reflects the system grows, so agencies treat 24 months as the outer limit, not a comfortable target. Plan and initiate the next full assessment well before the mark. Leaving it to month 23 is not credible: timelines vary, preparation takes time, and an assessor has to be engaged and available. Building reassessment into the forward plan from the first day after authorisation is how organisations avoid scrambling.
Which documents must you keep current between assessments?
The authorisation package documents are not static. The SSP-A, the incident response plan, the continuous monitoring plan and the organisational security policies all need to reflect the system as it currently runs. A document that was accurate at assessment but has drifted through eighteen months of change is not a useful reference for the next assessor, nor a credible basis for ongoing authorisation. Tie reviews to two triggers: scheduled periodic review, typically annual for the SSP-A and supporting documents, and event based review on any material change. A change log against the SSP-A recording what changed and when is a low effort habit that pays off at the next assessment.
The continuous monitoring plan in particular should be a live document. If monitoring activity has drifted from what the plan describes, either update the plan or reinstate the monitoring. An authorising officer who reads a monitoring plan that has not been operating as written will have questions.
How does maintaining posture shape the next assessment?
Directly. Maintaining posture is, in effect, continuous preparation for the next assessment. An organisation that has tracked ISM changes, documented system changes, kept its POAM current and maintained its documentation will arrive in a far better position than one that treated the gap as downtime. The evidence that carries the most weight is historical: patching records going back months, access review records, log retention records, training completion records. None of it can be manufactured at the start of an assessment; it accumulates over time.
For Stackform, the second assessment commenced at month 21. By then the ISM delta reviews were documented, the system change log was current, the POAM had three items closed with evidence and one open with an updated rationale, and the SSP-A had been reviewed and updated twice. The assessor’s opening session ran thirty minutes instead of a full day.
The names of the organisations and individuals have been changed to protect their privacy. The situations described are based on real patterns observed across Australian government and enterprise environments.
Frequently asked questions
ASD publishes the ISM quarterly, typically in March, June, September and December. After each release, review the delta against your control matrix to find any new or changed control that applies to your system. Cybernion’s free tool ISM Pulse automates this: upload your SSP-A, the current quarter control matrix and the ISM Changes PDF and it produces an interactive delta review with downloadable outputs. New gaps should be documented and either remediated or formally accepted.
Not necessarily. The Common Assessment Framework allows for delta reports and addendums that address specific changes without a full reassessment. The threshold is whether the change materially affects the security posture or introduces components outside the original boundary. When in doubt, seek a scoping opinion from an IRAP assessor before deciding.
Under PSPF Requirement 0109, cloud service providers must have had an IRAP assessment within the previous 24 months against the latest ISM at the time of assessment. The clock runs from the assessment date, not the authorisation date. Reassessment planning should begin well before month 24 to allow time for preparation and assessor engagement.
At minimum the SSP-A, the incident response plan, the continuous monitoring plan and the organisational security policies relevant to the system. These should be reviewed on a scheduled basis and updated whenever a material change is made. A change log maintained against the SSP-A helps track what changed and when.
Directly. The quality of historical evidence available to the assessor determines how confidently controls can be rated. Patching records, access reviews, monitoring outputs and training records all need to accumulate over time. An organisation that has kept consistent records will have a shorter, smoother assessment than one reconstructing evidence in the weeks before the assessor arrives.
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 aren’t always chasing a transaction.
Sources:
- ASD IRAP Consumer Guide, July 2025
- IRAP Common Assessment Framework, April 2025
- Cloud assessment and authorisation, including PSPF Requirement 0109, cyber.gov.au, 2026
- Protective Security Policy Framework, 2025
Last updated: 21 June, 2026