Maintaining IRAP Posture Between Assessments

An IRAP assessment is a point-in-time evaluation. The authorisation that follows it is not. The system continues to operate, the ISM continues to be updated, the system itself continues to change, and the threat environment does not pause while the organisation gets comfortable with its authorisation. Maintaining IRAP posture between assessments means treating the period between the current assessment and the next one as an active security obligation, not a quiet interval. This article covers what that obligation involves in practice.

Stackform’s journey

Twelve months after authorisation, James Hartley, CISO at Stockform, 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 questions. He had the records. Not every organisation in that position can.

Maintaining IRAP posture is not a complex discipline. It requires consistency, not sophistication. The organisations that struggle with it are rarely the ones that lack security capability. They are the ones that treated authorisation as a finish line.

The ISM quarterly release cycle

ASD publishes the ISM quarterly, typically in March, June, September, and December. Each release may add new controls, retire existing ones, update applicability flags, or change the intent of an existing control. The version used at the time of assessment is fixed in the report, but the system continues to operate against an ISM that keeps moving.

Between assessments, organisations should review each new ISM release against their CCM. The question to answer for each release is whether any new or changed control applies to the system and, if so, whether the system currently meets it.

Cybernion’s ISM Pulse – Free, Open-Sourced Tool

Cybernion’s ISM Pulse is a free, open-source browser-based tool built for exactly this purpose. Upload the SSP-A, the current-quarter CCM, and the ISM Changes PDF and it computes the delta and presents an interactive review dashboard with downloadable outputs. All processing happens in the browser, so nothing leaves the organisation’s environment. For most quarterly releases the review is a manageable exercise that should not take more than a couple of hours.

This is not a full reassessment. It is a gap analysis against the delta. Controls introduced since the assessment that the system does not yet meet represent new risk. That risk should be documented, assessed against the organisation’s risk appetite, and either remediated or formally accepted. It should not be ignored until the next assessment.

For Stackform, James assigned the ISM quarterly review as a standing task timed to each release. The first review after authorisation identified one new control relevant to the system. The gap was minor and addressed within the next sprint cycle. The second review identified no changes applicable to Stackform’s environment. The exercise took less than two hours each quarter and meant there were no surprises at the next assessment.

Maintaining IRAP Posture between Assessments

When the system changes

An IRAP assessment reflects the system as it was at the time it was conducted. When the system changes, the gap between what was assessed and what is currently running widens. How significant that matters depends on the nature of the change.

The CAF describes a process for assessing changes to a system that has already been IRAP-assessed. Where changes occur, the assessor identifies the delta against previously assessed controls, determines the impact of those changes on existing controls, and assesses the newly implemented changes or services. The output may be a delta report, an addendum to the original report, or in some cases a new IRAP report depending on the scope of the change.

Not every change triggers a formal reassessment. The threshold is whether the change materially affects the security posture of the system or introduces components, services, or data flows that were not within the original assessment boundary. Changes that do not cross that threshold should still be documented and tracked internally, so that the next assessment begins from a clear baseline rather than a reconstruction.

Changes that warrant consideration of a formal delta assessment or reassessment include adding a new environment or service to the system, integrating a new third-party provider that handles assessed data, changing the network architecture in a way that affects data sovereignty or segmentation, or altering access control mechanisms in a way that changes the shared responsibility model.

Changes that typically do not require reassessment, but should still be documented, include routine patching and configuration updates within the assessed baseline, staff changes in roles that were not individually assessed, and minor feature additions that do not alter the system’s security architecture.

The judgement call sits with the organisation and, where they are engaged, their security advisory support. When in doubt, the lower-cost option is to raise the change with an IRAP assessor for a scoping opinion before assuming it is out of scope. Discovering mid-assessment that a significant change was not disclosed is a poor position to be in.

The 24-month reassessment requirement for cloud service providers

For cloud service providers and managed service providers supplying services to government, the PSPF requirement is explicit. 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. That 24-month clock runs from the date of the assessment, not the date of authorisation.

For Stackform, this meant the next full assessment needed to be planned and initiated well before the 24-month mark. Leaving it to month 23 is not a credible approach. Assessment timelines vary, preparation takes time, and an assessor needs to be engaged and available. Building a reassessment into the forward plan from the first day after authorisation is how organisations avoid scrambling.

Keeping documents current

The authorisation package documents are not static artefacts. 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 operates. A document that was accurate at the time of assessment but has not been updated through eighteen months of system changes is not a useful reference for the next assessor, and it is not a credible foundation for ongoing authorisation.

A practical discipline is to tie document reviews to two triggers: scheduled periodic review, typically annually for the SSP-A and supporting documents, and event-based review whenever a material change is made to the system. A change log maintained against the SSP-A that records what changed and when is a low-effort habit that pays dividends at the next assessment.

The continuous monitoring plan in particular should be a live document. If monitoring activities have drifted from what the plan describes, either the plan needs updating or the monitoring needs to be reinstated. An authorising officer who receives an updated authorisation package and finds that the monitoring described in the plan has not been operating as written will have questions.

Preparing for the next IRAP assessment

The discipline of maintaining posture between assessments is, in effect, continuous preparation for the next one. An organisation that has tracked ISM changes, documented system changes, kept its POAM current, and maintained its documentation in line with the operating system will arrive at the next assessment in a substantially better position than one that has treated the intervening period as downtime.

The evidence that carries the most weight in an assessment is historical evidence: patching records stretching back months, access review records, log retention records, and training completion records. These cannot be manufactured at the start of an assessment. They have to accumulate over time. Maintaining posture is how that evidence base is built.

For Stackform, the second IRAP assessment was scheduled to commence at month 21. By that point, the ISM delta reviews were documented, the system change log was current, the POAM had three items closed with evidence and one remaining open with an updated rationale, and the SSP-A had been reviewed and updated twice. The assessor’s opening session took thirty minutes instead of a full day.

Frequently Asked Questions (FAQs)

How often is the ISM updated and what should we do when it is?

ASD publishes the ISM quarterly, typically in March, June, September, and December. After each release, review the delta against your CCM to identify any new or changed controls that apply to your system. Cybernion’s free tool ISM Pulse automates this process: upload your SSP-A, the current-quarter CCM, 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.

Do we need a new IRAP assessment every time the system changes?

Not necessarily. The CAF describes options including delta reports and addendums which address specific changes without requiring a full reassessment. The threshold is whether the change materially affects the security posture or introduces components outside the original assessment boundary. When in doubt, seek a scoping opinion from an IRAP assessor before deciding.

How long is an IRAP assessment valid for cloud service 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 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.

Which documents need to be kept current between assessments?

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 to the system. A change log maintained against the SSP-A helps track what has changed and when.

How does maintaining posture between assessments affect the next assessment?

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 maintained consistent records will have a shorter, smoother assessment than one that is reconstructing evidence from the weeks before the assessor arrives.

Maintaining IRAP Posture between Assessments