Understanding IRAP Report and Cloud Controls Matrix

An IRAP assessment produces two documents: the assessment report and the control matrix, a derivative of the System Security Plan annex. Together they give an authorising officer the system’s strengths and weaknesses, the implementation status of each applicable ISM control, and the residual risks needed to make a decision.

What are the two documents an IRAP assessment produces?

The IRAP report and the Cloud Controls Matrix are the two documents produced at the end of every cloud system assessment. Together they give an authorising officer everything needed to make an informed risk based decision about whether to authorise the system. Reading them well is the difference between an organisation that can act on its assessment and one that files it and waits to be told what to do next.

When the draft report arrived, James Hartley, the CISO at Stackform, spent an hour reading the executive summary and then stopped. The document was longer than he expected, structured in a way he had not seen before, and dense with control by control observations he did not know how to prioritise. He called Cybernion and asked where to start. The answer was to understand what the two documents are for before reading either in detail.

An IRAP assessment for a cloud system produces two deliverables. The Security Assessment Report, referred to in the cloud context as the Cloud Security Assessment Report, is written for authorising officers, system owners and risk owners. It describes the system, the assessment process, the findings and the recommendations in narrative form. The Cloud Controls Matrix, or CCM, is written for technical personnel and system administrators. It contains the row by row control assessment observations that the report summarises.

Neither document stands alone. The CCM is the evidence layer. The report is the interpretation layer. An authorising officer reads the report to understand the security posture of the system and uses the CCM to verify the detail behind any finding they want to examine more closely. Both are the output of the final stage of how the IRAP assessment process works.

Document	Written for	Role	What it contains
IRAP assessment report (for SaaS systems)
Cloud Security Assessment Report (for IaaS or PaaS systems)	Authorising officers, system owners, risk owners	Interpretation layer	System description, assessment process, strengths and weaknesses, findings, recommendations, limitations
Cloud Controls Matrix (CCM)	Technical personnel and system administrators	Evidence layer	Row by row outcome, implementation description, shared responsibility, assessment method and evidence for every applicable ISM control

What is in the IRAP assessment report?

The IRAP report follows a defined ASD template structure, the last deliverable in the IRAP assessment. The assessment boundary section is the first to read because it determines the validity of everything that follows. It documents exactly what was in scope and what was excluded, with justification for each exclusion. If the boundary was too narrow, the report’s coverage is limited, and that limitation needs to be understood before the findings are reviewed.

From there the report moves through the system, the governance around it, and the assessor’s verdict on the controls. The strengths and weaknesses section carries the headline picture. Strengths are areas where controls operate effectively. Weaknesses are areas where controls are ineffective, not implemented, have no visibility, or where the assessor has identified a vulnerability. Key vulnerabilities must be identified clearly and early so they are not buried.

Report section	What it documents
Assessment boundary	What was in scope and what was excluded, with justification for each exclusion. Read this first
System overview	The system function, environments assessed, architecture, data flows and the classification of information handled
Governance	Ownership, roles, responsibilities and the organisation’s risk management approach
Strengths and weaknesses	The headline assessment: where controls operate effectively and where they do not
Findings	The detailed observations behind each weakness, each tied to one or more ISM controls, with impact described but risk not rated
Recommendations	Descriptive remediation guidance: what to address and why, not the specific technical solution
Limitations	Constraints that affected the assessment, such as controls that could not be fully tested

For Stackform the system overview covered the production and pre production environments, the identity provider configuration and the privileged access workstation setup. Each finding tied back to one or more ISM controls and described what was observed, the gap and the potential impact. The assessor describes impact but does not rate risk, and recommendations stay descriptive rather than prescriptive. The organisation decides how to implement.

What is the Cloud Controls Matrix and how do you read it?

The CCM is a row by row record of every applicable ISM control assessed within the boundary. For each control it records the implementation outcome, a description of how the control is implemented in the system, the responsibilities between the organisation and any external service providers, the assessment method used, and the evidence gathered. It is the working document for the technical team and becomes the reference point for what is in place, which controls are gaps, and who is responsible for what across the shared responsibility model.

Read it by outcome, not top to bottom. Focus first on the controls rated Ineffective, Not Implemented and No Visibility. These are the gaps that need to be addressed or accepted. Controls rated Not Applicable should be reviewed to confirm the justification is sound. Controls rated Alternate Control should be examined to understand what the alternate mechanism is and whether it actually meets the intent of the ISM control.

No Visibility warrants particular attention. It means the assessor could not obtain adequate visibility of the control’s implementation. From a risk perspective, authorising officers may treat No Visibility as equivalent to Ineffective. Where it appears, the organisation needs to understand why the assessor could not see the control and whether the gap is an evidence problem or an implementation problem.

Outcome	What it means	What to do
Effective	The control operates as intended	Note as a strength
Ineffective	The control is in place but not operating effectively	Remediate or accept as a residual risk
Not implemented	The control is not in place	Remediate or document a business constraint
No visibility	The assessor could not obtain adequate evidence	Treat as equivalent to ineffective until proven; find out if it is an evidence or implementation gap
Not applicable	The control does not apply to the system	Confirm the justification is sound
Alternate control	A different mechanism is used in place of the ISM control	Check the mechanism meets the intent of the control

Does the assessor rate the risk or decide authorisation?

No. The assessor describes findings and their potential impact. They do not assign a risk rating. They do not say a finding is critical, high, medium or low. They do not recommend whether the system should be authorised. The risk rating and the authorisation decision belong to the organisation and the system authoriser. Under the Protective Security Policy Framework, the consuming agency’s authorising officer makes the risk based decision to operate (PSPF requirement 0086). The report gives them the information to make that decision. It does not make it for them.

James found this disorienting at first. He had expected a clear verdict. Instead the report gave a detailed picture of the system’s security posture and left the interpretation to the agency. That is by design. What the report does is surface the information an authorising officer needs to determine whether the residual risk is within the organisation’s risk appetite. It is also why IRAP is an assessment, not a certification: there is no pass mark and no approval inside the document itself.

Who can see the IRAP report once it is finished?

The assessed entity is expected to make the IRAP assessment report and CCM available to other organisations considering the use of their services. An assessment cover letter alone does not give a potential consumer enough information to understand the security risks involved. The full report and CCM need to be accessible.

For service providers like Stackform, the report is not a private document. It is evidence provided to consuming agencies to support their own risk based decisions. Marketing language that implies certification, approval or authorisation based on the report is not permitted under ASD’s guidelines.

What did Stackform do next?

James and the Cybernion team reviewed the CCM together, row by row, focusing on the non effective outcomes. Two controls rated No Visibility were addressed by producing the missing evidence. Three controls rated Ineffective had a remediation path. One control was Not Implemented with a documented business constraint that the agency would need to consider as a residual risk. With that understanding in place, the next task was assembling the IRAP authorisation package, where those residual risks are weighed against the organisation’s risk appetite. Cybernion runs IRAP assessments and readiness directly, end to end.

---

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

What is the difference between the assessment report and the Cloud Controls Matrix?

The assessment report is a narrative document for authorising officers and risk owners. It describes the system, the findings and the recommendations. The CCM is a technical document for system administrators. It records the outcome, implementation description, evidence and assessment method for every applicable ISM control. Both are produced at the end of the assessment and should be read together.

Where should we focus first when we receive the report?

Start with the boundary section to confirm scope, then the strengths and weaknesses section for the headline picture. In the CCM, focus on controls rated Ineffective, Not Implemented and No Visibility. These are the gaps that need to be addressed or formally accepted as residual risks.

Does the assessor tell us which findings are most serious?

The assessor describes the potential impact of each finding but does not assign a risk rating. The organisation and the system authoriser determine what level of risk is acceptable. Key vulnerabilities are identified prominently in the report, but the prioritisation is the organisation’s responsibility.

What does No Visibility mean in the CCM?

It means the assessor could not obtain adequate evidence of the control’s implementation. It may reflect an evidence gap rather than an implementation gap, but authorising officers may treat it as equivalent to Ineffective. Where it appears, the organisation needs to determine whether the control is actually in place and why it was not visible to the assessor.

Can we share the report with the agency before it is finalised?

The draft report is typically reviewed by the organisation and the assessor before finalisation. Once finalised, the report and CCM should be made available to consuming agencies considering the service. An assessment cover letter on its own is not sufficient for an agency to make an informed risk decision.

---

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:

1. ASD IRAP Consumer Guide, July 2025
2. IRAP Common Assessment Framework, April 2025
3. ASD Cloud assessment and authorisation, 2024
4. Protective Security Policy Framework, requirement 0086, 2024

Last updated: 21 June, 2026