You’re a US cloud or SaaS provider and an Australian government agency wants your service, but its security team needs an IRAP assessment against the Information Security Manual before anyone can authorize it. The ISM is long, written for Australian systems and different from FedRAMP in ways that matter. Readiness shows you where your service stands against it, builds the documentation an IRAP assessor will expect, and gets you to the assessment with fewer surprises.
The Information Security Registered Assessors Program is run by the Australian Signals Directorate. ASD endorses individual security professionals as IRAP assessors, and those assessors evaluate systems against the Information Security Manual, ASD’s set of cyber security guidelines and controls for Australian government systems. Each assessment is made against a classification, typically OFFICIAL: Sensitive or PROTECTED for cloud services, and the applicable ISM controls change with that level.
An IRAP assessment produces a security assessment report on how well your controls are designed and how effectively they operate. It is not a certificate and it does not authorize anything. Since ASD retired its Certified Cloud Services List, there has been no central approval for cloud services: each agency’s authorizing officer reviews the IRAP report, the residual risks it records and your system documentation, then makes its own authorization decision.
Australian buyers also expect to see the Essential Eight, ASD’s prioritized mitigation strategies with maturity levels from Zero to Three, because agencies are directed under the Protective Security Policy Framework to implement them. Teams come to IRAP readiness to understand where a US-built cloud service diverges from the ISM, to produce a system security plan written to ASD’s guidelines, and to settle questions about data location, personnel and supply chain before the assessor starts.
An agency or a government panel wants your service, and its security team asks for a current IRAP report at OFFICIAL: Sensitive or PROTECTED. You need to know how your existing control set compares with the ISM before you commission an assessment.
You already hold a FedRAMP authorization and hope to reuse it. Much of your evidence carries over, but the ISM has its own controls, terminology and Australia-specific expectations, and an IRAP assessor will look at them directly.
An earlier IRAP report is ageing, your service has changed, or a buyer wants you assessed at PROTECTED instead of OFFICIAL: Sensitive. You want the new gaps understood before reassessment.
Your software runs in an Australian partner’s environment or on a hyperscaler region in Australia, and the boundary between their controls and yours needs to be clear before an assessor draws it for you.
An ASD-endorsed IRAP assessor you engage; each government buyer then decides on authorization
IRAP security assessment report for your system at a stated classification, used by each agency’s authorizing officer in its own authorization decision
The assessor’s report and the agency’s decision belong to them. Readiness happens before either, on your side of the table, so the system and documentation the assessor reviews already reflect the ISM.
Every applicable ISM control at your target classification marked implemented, partly implemented or not yet in place, with the evidence that exists and the work that remains.
Your current maturity level for each of the eight mitigation strategies, the target buyers expect, and what moves you from one to the other.
A system security plan and controls annex describing your system, its boundary and how each applicable ISM control is met, written so an IRAP assessor can test against it.
Incident response plan, continuous monitoring plan and the policies and procedures the ISM’s documentation guidelines call for, aligned to your actual operations.
Your FedRAMP, ISO 27001 or SOC 2 controls mapped to the ISM, showing where evidence carries over and where Australian requirements need something new.
The technical and documentation changes needed before assessment, prioritized by their effect on the risks an agency’s authorizing officer will weigh.
Architecture diagrams, data-flow diagrams, inheritance statements and an evidence index organized the way an IRAP assessment is conducted.
A plain description of your service’s classification, hosting and controls that Australian procurement and security teams can read before they request the full report.
Better found now, by people on your side, than by your assessor.
A system boundary that is unclear, so the assessor and you disagree on which components are in scope
Essential Eight maturity below the level buyers expect, often on application control or macro settings
ISM controls treated as satisfied by FedRAMP evidence that does not actually address them
A system security plan written generically, without control-by-control implementation detail
Data or backups that can leave Australia through support, logging or replication paths
Privileged access by offshore staff with no answer to the personnel security expectations at PROTECTED
Inherited controls claimed from the cloud provider without checking what its own IRAP report covers
Logs collected but not centrally monitored or retained to the ISM’s expectations
IRAP assessments of cloud services examine how your tenancy is configured, including identity, network controls, encryption and logging, so a configuration review shows where the ISM will not be met.
What the test coversAgencies weighing your report want confidence that the service itself resists attack, and the ISM’s software development guidelines expect applications to be security tested.
What the test coversYour internet-facing gateways and administrative interfaces are among the first things an assessor and an agency’s security team consider.
What the test coversThe ISM expects ongoing vulnerability scanning and patching, and the Essential Eight patching strategies depend on knowing what is unpatched.
What the test coversNo. An IRAP assessor produces a security assessment report describing how your system meets the ISM at a given classification and the risks that remain. Each government buyer’s authorizing officer then decides whether to authorize your service. No single body certifies a cloud service for all of government.
Only an individual the Australian Signals Directorate has endorsed for the program, whom you engage directly. Readiness is separate from that assessment, which keeps the preparation and the independent review apart.
Your FedRAMP evidence is a strong starting point, and many controls map across. The ISM is still its own framework, with Australia-specific requirements on cryptography, personnel security, data location and the Essential Eight, and an IRAP assessor tests your system against the ISM rather than accepting another authorization in its place.
It depends on the data your buyers will put in your service. Many agencies need PROTECTED for sensitive workloads, while others accept OFFICIAL: Sensitive. PROTECTED brings more ISM controls and stricter expectations on personnel and hosting, so the decision shapes the whole program and is best settled with your target buyers first.
The ISM and government hosting policies place strong weight on where data is stored and who can access it, and many buyers require Australian hosting for sensitive government data. Readiness traces your storage, backup, logging and support paths so you can describe accurately where data goes.
The Essential Eight is part of what agencies are directed to implement and what assessors and buyers look at. Your maturity against it is usually reported alongside your ISM results, so reaching the level your buyers expect is part of being ready.
One conversation with someone who does this work. You leave knowing where you likely stand and what readiness would involve for you.
Not sure where to start? One of our testers reviews your internet-facing footprint and sends you a short summary of what an attacker would see — free. Nothing you don’t own is ever touched, and there’s no sales sequence.
Free. No obligation.
