The IRAP authorisation package is the suite of documents provided to the authorising officer so they can make a risk-based decision about whether to approve the system for operation. The IRAP assessment report is a central component but it is not the whole package. The authorising officer reviews the package, weighs the residual risks against their organisation’s risk appetite, and makes the authorisation decision. A completed IRAP assessment does not guarantee that decision will go in the system’s favour. Understanding what the package must contain, who makes the decision, and what the decision means in practice is what this article covers.
Stackform’s journey
James Hartley, the CISO at Stockform, had the finalised IRAP assessment report and the CCM. He understood the findings. Two controls were remediated before the package was submitted. One finding remained open with a documented business constraint. Three recommendations were acknowledged and scheduled for a future uplift cycle. The next task was assembling everything the agency’s authorising officer would need to make their decision.
This was not simply a matter of forwarding the report.
What the Authorisation Package contains
The authorisation package is the complete set of documents submitted to the authorising officer. The IRAP Consumer Guide specifies the following minimum artefacts.
- System security plan: The SSP describes the system, its architecture, its data flows, and the security controls in place. For cloud systems, this is the SSP-A. It must reflect the system as it is at the time of authorisation, not as it was at the start of the assessment.
- Cyber security incident response plan: This document describes how the organisation will detect, respond to, and recover from a security incident affecting the system. The authorising officer needs confidence that the organisation has a functional response capability, not just a theoretical one.
- Continuous monitoring plan: This document describes how the organisation will monitor the security posture of the system on an ongoing basis after authorisation. It covers what is being monitored, how frequently, and what triggers a review or reassessment. An authorising officer authorising a system expects that posture to be maintained, not left unattended until the next assessment.
- The IRAP report and cloud controls matrix: These are the outputs of the assessment process. The report provides the narrative picture of the system’s security posture. The CCM provides the control-by-control detail.
- Plan of action and milestones, where applicable: The POAM documents the open findings from the assessment, the planned remediation activities, ownership, and target completion dates. Where findings remain unresolved at the time of authorisation, the POAM gives the authorising officer visibility of what the organisation intends to do and when. Its inclusion is not mandatory in all cases but is expected where material findings are open.
These are the minimum documents. In practice, authorising officers commonly expect additional supporting material beyond this set. The Consumer Guide’s preparation guidance identifies documents that agencies will frequently want access to when reviewing a package, including a risk management plan covering the system’s identified risks and treatment decisions, design and architectural documents sufficient to understand how the system is built and how data flows through it, and organisational security policies and standard operating procedures relevant to the system’s operation.
The specific requirements of the consuming agency’s authorising officer should be confirmed before the package is submitted. Some agencies have internal templates or submission requirements that go beyond the ASD minimum. Finding that out after the package is assembled wastes time on both sides.
For Stackform, Cybernion confirmed the agency’s expectations before assembly began. The package included the minimum artefacts plus the risk management plan and architectural diagrams. The POAM was included because findings remained open. Submitting without it would have left the authorising officer with questions that had no formal answers.
Who the Authorising Officer is
For OFFICIAL: Sensitive and PROTECTED outsourced IT systems and cloud services, the authorising officer is the Accountable Authority or Chief Information Security Officer of the entity that owns the system, or their delegate. For Stackform’s situation, that was the agency’s CISO, acting as the delegate of the agency’s accountable authority.
The authorising officer is responsible for authorising the system to operate based on acceptance of the residual security risks. That acceptance must happen before the system processes, stores, or communicates government information or data. The PSPF is explicit on this. Operating the system before authorisation is granted is not a grey area.
The authorising officer does not assess the system. They review the assessment package, consider the residual risks in the context of their organisation’s objectives, culture, and risk tolerance, and make a decision. An authorising officer reviewing a package with unresolved material findings will want to understand what those findings mean for their organisation specifically, not just what the assessor observed in general terms.
What the Authorising Officer considers
The authorisation decision is a risk-based judgement, not a pass or fail test. A system with findings can be authorised. A system with no findings can still be declined if the authorising officer has concerns the assessment did not address. The framework gives the authorising officer discretion, which means the quality of the package and the organisation’s ability to explain the residual risks in plain terms both matter.
The authorising officer will look at the gap between what the assessment found and what the organisation has done or committed to do about it. They will consider whether the continuous monitoring plan gives them reasonable ongoing assurance. They will assess whether the incident response capability is credible. They will review the POAM for realistic timelines and clear ownership. A POAM that lists every finding as resolved within thirty days with the system owner as the responsible party for all of them will not inspire confidence.
The authorising officer seeks a balance between system functionality and residual risk. They are not looking for a perfect system. They are looking for a system they can authorise with a clear picture of the risks they are accepting and the controls they are relying on.
The system Authorisation Boundary
The system authorisation boundary may match the system assessment boundary exactly, or it may be a subset of it. An authorising officer can choose to authorise a portion of what was assessed. The authorisation boundary cannot be larger than the assessment boundary. The agency cannot authorise components that were not assessed.
For Stackform, the agency authorised the production environment and the identity provider configuration. The pre-production environment, which had been assessed, was noted as out of the authorisation boundary with the expectation that it would not process real government data until a separate authorisation decision was made.
What Authorisation means
Authorisation is the formal decision by the authorising officer to accept the residual security risks associated with the system and permit it to operate. It is not a declaration that the system is secure. It is not an endorsement by ASD or the Australian Government. It is the agency taking accountability for the risk decision.
For Stackform, the authorisation letter from the agency’s CISO was the commercial trigger that allowed the platform to go live for government data processing. Without it, the platform could not be used for that purpose regardless of how complete the assessment was.
The authorisation is point-in-time. If the system changes materially after authorisation, the organisation has an obligation to consider whether the existing authorisation still holds, and whether reassessment or a new authorisation decision is required.
Frequently Asked Questions (FAQs)
What documents must be in the IRAP authorisation package?
The ASD minimum set is: the system security plan, the cyber security incident response plan, the continuous monitoring plan, the IRAP assessment report, the assessment controls matrix, and a plan of action and milestones where findings remain open. In practice, authorising officers frequently expect additional material including a risk management plan, architectural diagrams, and relevant security policies. Confirm the specific requirements with the consuming agency before assembling the package.
Who is the authorising officer for an OFFICIAL: Sensitive cloud service?
For OFFICIAL: Sensitive and PROTECTED outsourced IT and cloud services, the authorising officer is the Accountable Authority or CISO of the entity that owns the system, or their delegate. For government agencies this is typically the agency’s CISO acting under delegation.
Does a completed IRAP assessment mean our system will be authorised?
No. The assessment gives the authorising officer the information to make the decision. Agencies have declined to authorise systems that have completed IRAP assessments. The decision rests entirely with the authorising officer based on their risk appetite and the content of the full package.
What is the POAM and does it need to be included?
The plan of action and milestones documents open findings from the assessment, planned remediation activities, ownership, and target dates. Its inclusion is expected where material findings remain unresolved. It gives the authorising officer visibility of how and when the organisation intends to address the gaps they are being asked to accept.
Can the authorising officer authorise part of the assessed system?
Yes. The authorisation boundary may be smaller than the assessment boundary. An authorising officer can choose to authorise specific services or environments that were assessed, and exclude others. The authorisation boundary cannot exceed the assessment boundary.
Read Next: IRAP POAM and Risk Management
Sources:
- ASD IRAP Consumer Guide, July 2025
- IRAP Common Assessment Framework, April 2025
- Australian Government Security Classification System and Requirement 0109, PSPF 2025
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.
Last updated: 05 June, 2026
Cybernion has helped multiple organisations with IRAP readiness and assessments.
Talk to us. We aren’t always chasing a transaction.