An IRAP Report Travels. The Risk Decision Does Not.
The term "IRAP certified" is used regularly by suppliers, but it describes something that does not exist. An IRAP (Infosec Registered Assessors Program) assessment produces a report documenting the security controls and findings for a particular system, within a defined assessment scope. It does not confer accreditation or approval to operate.
ASD makes this distinction explicitly: IRAP assessors do not accredit, certify, endorse or register systems on behalf of ASD, the assessed entity or the consuming agency. The report is evidence for a security decision, not the decision itself. That distinction matters considerably when the same report is presented to multiple government customers, each with their own security requirements and acceptance processes.
In short, there is an assessment, there is a report, and there is a decision that somebody else still has to make.
That distinction drives procurement timelines, remediation cost and how much of the security work a supplier has to repeat for every new customer. We covered the wider Australian and US landscape in FedRAMP and IRAP. This piece is about a narrower and more practical question: what does an IRAP assessment actually establish, and what does the next customer still have to do?
What the assessment gives you
An IRAP assessment is an independent, evidence-based examination of a system's security posture by an ASD-endorsed assessor, normally against the controls in the Information Security Manual (ISM). It identifies what was examined, what the evidence showed, where the weaknesses are and what the assessor recommends.
That is genuinely valuable, but bounded evidence. The report describes a particular system, inside a particular boundary, at a particular point in time, against a particular set of controls operated by the Organisation. An assessment does not normally exercise every ISM control, and a control that was assessed is not the same thing as a control that was found to be effective. The person reading the report needs to know what was in scope, what was not, and what the findings actually say, before they treat it as an answer to their own question.
Why it is not a checklist
It is tempting to picture a security assessment as a spreadsheet: list the controls, tick the ones that are satisfied, print the result. ASD's IRAP Common Assessment Framework describes something quite different. It is structured around scope, boundary, evidence, control coverage and assessor judgement applied to a specific architecture.
That difference matters because the same control can be true on paper and false in production. A policy can exist without being enforced. A configuration can be correct in one environment and drift in the next. A cloud provider can implement the foundational controls while the customer remains responsible for identity, access, logging and the integrations they bolt on. The assessment has to establish what the evidence demonstrates about the actual system, not what the documentation claims about it.
The boundary is the whole argument
Take an ordinary SaaS product built on a public cloud platform. The cloud provider has its own assessment evidence for its infrastructure. The SaaS supplier has evidence for its application, operations and standard configuration. Then a government customer deploys it with their own identity provider, network controls, integrations, information classification and administrative arrangements.
Those are three related systems. They are not the same system. An assessment of the platform does not establish the posture of the application built on it, and an assessment of the supplier's standard environment does not establish the posture of a specific customer deployment.
So the useful question is never "was the original assessment legitimate?" It almost always was. The useful question is whether its scope and evidence still apply to the system now in front of you.
Assessment and authorisation are different jobs
The assessor evaluates the system within an agreed scope and reports findings. The organisation that will own the risk then decides whether that risk is acceptable for its information, its operating environment and its obligations. Under the ISM that decision belongs to the consuming organisation's authorising officer, not to the assessor and not to the supplier.
An assessment report informs that decision. It does not make it, and it certainly does not make it on behalf of every future customer. When a supplier sells the same product to several agencies, each of those agencies may handle different information, deploy differently and answer to different policy frameworks. Commonwealth entities work under the Protective Security Policy Framework; state and territory agencies generally operate under their own frameworks. Each one has to satisfy itself.
The distinction worth holding onto is between the quality of the evidence and the authority to accept the risk. The first can be shared. The second cannot.
Does a federal assessment carry over to a state customer?
There is no rule that says a federal assessment is useless to a state agency, and no rule that says a state agency must accept it. The honest answer is conditional, and it turns on five questions that apply in either direction:
- Is it the same service? A report for one product, version or service boundary may not cover another, even under the same product name.
- Is it the same deployment? Identity integration, network design, administrative access, logging, data handling and external connections can all differ from the assessed environment.
- Does the scope cover this customer's requirements? The controls examined, and the depth of examination, need to match the information and risk involved.
- Are the findings and their remediation understood? Open findings and residual risk need to be visible, not buried in an appendix.
- Who accepts the risk? The receiving organisation's own governance applies. Another agency's acceptance does not settle it.
What can actually be reused
Quite a lot, provided it is current and in scope:
- architecture and boundary documentation
- control implementation descriptions and evidence
- assessment findings and supporting artefacts
- the cloud provider's evidence relevant to the deployed service
- security policies and operating procedures
- vulnerability and remediation records
- incident response and continuous monitoring arrangements
- previous test results and technical validation
Reuse is not acceptance, though. A practical way to sort it:
| Evidence | Treatment |
|---|---|
| Applicable and current | Reuse it, subject to the recipient's own review. |
| Relevant but incomplete | Reuse it and identify the additional evidence or testing needed. |
| Outdated or out of scope | Reassess those areas rather than assume the old findings still hold. |
That avoids the two expensive mistakes: assuming one assessment settles every future decision, and throwing away all prior work every time a new customer turns up.
The commercial cost of getting this wrong
Suppliers often fund an assessment expecting it to carry them through several engagements. When the next customer has a different deployment or a different risk appetite, the extra work arrives late, usually during procurement, and usually as an open-ended security questionnaire. That shows up as slower contracts, larger evidence requests, unplanned remediation and configuration drift between customers who were meant to be on the same service.
Agencies feel the same problem from the other side: repeated reviews, repeated evidence requests and delays while everybody works out who owns which control.
Treat assessment evidence as a maintained asset
The fix is not to pretend assessments are portable. It is to manage the evidence so that the gap between "what has been shown" and "what this customer needs" is visible and small. In practice that means:
- A defined service boundary. A current description of the service, environments, integrations and shared responsibilities the evidence covers.
- Traceability to controls. Which controls were assessed, what evidence supports each conclusion, what was found and where coverage stops.
- Change tracking. Architecture, version, hosting, integration and process changes recorded against the evidence they affect.
- Shared evidence separated from deployment evidence. Reuse what genuinely applies and identify what each customer configuration still has to demonstrate.
- Explicit gaps. A clear list of what is evidenced, what needs validation and what is unresolved.
- A package built for the decision-maker. Evidence organised so the authorising officer can evaluate the system in its intended context.
None of that removes the need for independent assessment or customer-specific assurance. It makes that work targeted, faster and defensible, which is the same principle we apply to delivery evidence generally: the evidence should be produced and maintained by the work, not assembled about it after the fact. We made a related argument about deployment access in Why "Developer Everywhere" Access is a Governance Failure.
The short version
An IRAP assessment is important evidence. Its value depends on what was assessed, where the boundary sat, how current the evidence is and what decision it is being asked to support. The report can travel between organisations and can save a great deal of duplicated effort. The acceptance of risk does not travel with it.
Evidence can be reusable without the authorisation being portable. Build that into the assurance process from the start, and the second, third and tenth government customer become a matter of closing known gaps rather than starting again.
The next time you hear a supplier say "we're IRAP certified", ask which agency assessed and accepted the system, against which ISM controls, and within what system boundary. More accurately, they might say: "Our system has undergone an IRAP assessment against the ISM controls and has been accepted by [agency] for [specific purpose]." Those are very different claims.
The same applies to statements like "we have FedRAMP, so getting IRAP will be straightforward." It won't necessarily be. FedRAMP authorisation does not confer Australian government accreditation, nor does it demonstrate compliance with the Australian ISM. There may be reusable evidence, but there will still be an Australian assessment and an agency acceptance decision.
And if you're a supplier making these claims to win government business, be prepared to substantiate them. An inaccurate assurance claim isn't just a marketing problem. It can become a very expensive commercial and contractual problem. Bring your cheque book.