Australia IRAP Guide: Assessments Against the ISM for Government Workloads

Australian government agencies will not put OFFICIAL: Sensitive or PROTECTED data on a system until someone independent has tested it against the Information Security Manual, and that someone is almost always an IRAP assessor. The Infosec Registered Assessors Program (IRAP), run by the Australian Signals Directorate (ASD), is how cloud providers, SaaS vendors, gateway operators and agencies themselves get evidence that a system's ISM controls are actually working. IRAP is often misread as a certification, and it is not: the assessor reports, the agency's authorising officer decides. This guide explains how the program works as of October 2026, what the 2025 IRAP Common Assessment Framework changed, where identity and non-human identity controls sit, and how to prepare evidence that survives a focused or comprehensive assessment. It is written for security practitioners at providers and agencies, and for executives budgeting for an assessment.

Key takeaways

• IRAP is an assessment, not a certificate. ASD states that assessors do not accredit, certify, endorse or register systems, and a completed assessment does not mean a system complies with every control it tested.
• The ASD certified list is gone. The Cloud Services Certification Program ceased on 2 March 2020 and the Certified Cloud Services List closed on 27 July 2020, voiding all earlier ASD cloud certifications.
• The ISM moves every quarter. Assessors must start on the latest ISM release and an assessment must never fall more than one version behind, so plan for control drift during long engagements.
• Evidence quality decides the outcome. The Common Assessment Framework grades evidence from Poor (policy restatements) to Excellent (direct testing), and a control without adequate assurance can be rated "No visibility".
• Identity is assessed everywhere. ISM principles PRO-12, PRO-13 and DET-04 put least privilege, credential management and baselining of privileged and remote access at the centre, including service accounts, API keys and, since June 2026, AI applications.

What it is and who it applies to

IRAP connects organisations with ASD-endorsed ICT professionals from the private and public sectors who provide independent security assessments. Endorsed assessors need security assessment and risk management experience and a detailed understanding of the ISM. ASD states that IRAP assessors can assess systems up to and including SECRET, covering ICT systems, cloud services, gateways and GovLink.

• Commonwealth entities: bound by the Protective Security Policy Framework (PSPF Release 2024 replaced the previous 16 PSPF policies) and expected to use the ISM to protect their systems. They use IRAP reports as input to authorisation decisions and remain accountable for their own assurance and risk management.
• Cloud and service providers: commission IRAP assessments so that agencies can consume a report rather than assess the provider themselves. Hyperscalers, SaaS vendors and managed service providers selling into government do this routinely.
• State and territory agencies and critical infrastructure: often ask for IRAP reports in procurement even where the PSPF does not bind them directly. Check the contract, not assumptions.
• Hosting: the Hosting Certification Framework, run by the Department of Home Affairs since 1 May 2023, requires that sensitive government data, whole-of-government systems and systems rated PROTECTED are hosted using certified services. It is a separate scheme from IRAP, and many PROTECTED procurements ask for both.

Classifications that drive scope

ASD's machine-readable ISM (OSCAL) publishes baselines for NON_CLASSIFIED, OFFICIAL_SENSITIVE, PROTECTED, SECRET and TOP_SECRET, plus Essential Eight Maturity Level One to Three profiles. Those baselines are the quickest way to see which controls apply to your target classification.

Structure and key requirements

An IRAP engagement has two documents underneath it: the ISM, which supplies the controls, and the IRAP Common Assessment Framework (April 2025, version 1.0), which tells assessors how to assess them. The framework replaced the earlier IRAP Assessment Process Guide and sets quality requirements numbered IRAP-AR-0001 to IRAP-AR-0046.

The ISM and its release cycle

• Cyber security principles: grouped as govern, identify, protect, detect and respond (for example PRO-05 secure administration, PRO-12 least privilege access, PRO-13 identity, credential and access management, DET-01 centralised event logging). Each principle carries applicability markings NC, OS, P, S and TS.
• Guidelines and controls: controls are numbered ISM-nnnn and grouped into guidelines such as system hardening, system management, system monitoring, software development, cryptography, gateways, enterprise mobility and personnel security.
• Quarterly releases: ASD releases the ISM roughly every quarter. The latest release we read in full for this guide is the June 2026 ISM (OSCAL release v2026.06.18). ASD's site also lists a September 2026 edition, which we could not retrieve; confirm the current release on cyber.gov.au before scoping.

What changed recently

The cloud assessment model

When ASD closed the Certified Cloud Services List, it and the Digital Transformation Agency published four resources on 27 July 2020: Anatomy of a Cloud Assessment and Authorisation, a frequently asked questions document, the Cloud Security Assessment Report Template and the Cloud Controls Matrix. Cloud assessments are now layered:

• Layer 1: the infrastructure provider (IaaS or PaaS) is assessed.
• Layer 2: the SaaS provider is assessed, inheriting what Layer 1 evidence supports.
• Layer 3: the consuming agency assesses its own responsibilities and draws on the earlier reports in one report for its authorising officer.

ASD's FAQ says a provider and its services should be reassessed at least once every 24 months, or sooner on trigger events. Older reports are not automatically invalid, but agencies should confirm the content is still accurate, and provider addendums are not independently verified until the next assessment.

Identity and NHI requirements

Identity controls are where assessors find the most ineffective ratings, because they are easy to describe in a policy and hard to prove in a live tenant. The ISM principles make the expectation explicit: PRO-13 asks for robust identity, credential and access management that also supports detection of credential misuse, PRO-12 limits users to the minimum access their duties need, PRO-05 asks for secure, accountable and auditable administration, and DET-04 asks for baselines of identity, privileged and remote access activity so anomalies can be detected.

• Privileged users: expect assessors to test multi-factor authentication for privileged and remote access, separate privileged accounts, privileged access workstations and just-in-time elevation, and to sample logs of privileged actions. The Essential Eight "restrict administrative privileges" and "multi-factor authentication" strategies overlap heavily here. See the Essential Eight Guide.
• Service accounts and workload identities: the framework requires every component in the boundary to be covered, so CI/CD pipelines, automation accounts, cloud IAM roles and integration credentials are in scope, not just human logins. Assessors will ask for an inventory, owners, scopes and rotation evidence. See the Service Account Security Guide.
• Secrets and keys: encryption controls now require ASD-approved cryptography, and key custody matters for sovereignty. Show where keys and API tokens are stored, who can read them and how they are rotated. See the Secrets Management Guide.
• Operator access from offshore: the framework tells assessors to consider offshore equipment and staff, metadata held outside Australia, and end-user devices used for privileged tasks. Support staff in other countries with standing admin access are a common finding; lockbox-style approval for provider access is one consumer recommendation the framework itself cites.
• AI agents: ISM-2112 to ISM-2114 apply to AI applications, and the software development guidelines now cover AI agents. An agent with its own credentials needs the same scoping, approval and logging as any other non-human identity. See the Zero Trust for AI Agents Guide.

Implementation steps

Duration depends mostly on how much live evidence already exists. A practical sequence:

1. Choose the classification and boundary first. Decide the target (OFFICIAL: Sensitive or PROTECTED) and write down every environment, region, admin path and supplier that touches the data. The assessment boundary must include production, pre-production, test and development where they are in scope of continuous monitoring, and exclusions must be justified.
2. Pull the right baseline. Use the ISM OSCAL baseline for the classification to build your controls matrix, and record the ISM release you start on.
3. Run a gap assessment. Self-assess every applicable control with the same ratings the assessor will use (Effective, Ineffective, Alternate control, Not applicable, Not implemented). Treat "we plan to" as Not implemented, because assessors may only rate what is in place.
4. Fix identity and logging first. These have the widest blast radius and the clearest evidence: MFA coverage, privileged account separation, service account inventory, central logging with protection from deletion.
5. Document the shared responsibility model and consumer recommendations. Agencies at Layer 3 rely on these, and the framework expects assessors to check the recommendations are effective (for example, a region lock that keeps data in Australia).
6. Engage an assessor. Use ASD's list of endorsed assessors. The assessor submits an engagement form and conflict of interest declaration to ASD at least 7 business days before starting.
7. Support the assessment. Give live read-only access, named contacts for interviews and a test window. The framework methods are examine, interview and test.
8. Remediate and maintain. Fix ineffective controls, then keep a change log so you can commission a delta report or addendum rather than a full reassessment when the service changes. Plan full reassessment at least every 24 months.

Rollback and change control: if a release breaks an assessed control (for example a login change that enables guest access), treat it as a trigger event: roll the change back or record it, notify consuming agencies and assess the delta.

Evidence and assessment

• Assessment degree: the framework combines depth (evidence quality) and coverage (scope and sample size) into basic, focused or comprehensive assessments, balanced against the assurance required.
• Sampling: allowed for things like patch history, log retention, central configuration, training and onboarding, but it supports rather than replaces direct assessment, and the method (random, stratified, risk-based or systematic) must be explained.
• Deliverables: an IRAP Security Assessment Report or Cloud Security Assessment Report for authorising officers and risk owners, and a Controls Matrix or Cloud Controls Matrix for technical staff. Assessors describe risks but do not assign risk ratings, and reports must avoid compliance, certification or marketing language.
• Authorisation: the authorising officer sets the authorisation boundary, which may be smaller than the assessment boundary but never larger, and accepts the residual risk.

Metrics that show the program is working

• Percentage of applicable controls rated Effective, and the count of "No visibility" ratings (target zero).
• MFA coverage for privileged and remote access, including break-glass accounts, as a percentage of accounts.
• Service accounts and API credentials with a named owner and a rotation date inside policy.
• Age of the current report against the 24-month reassessment expectation, and number of unassessed changes since sign-off.
• ISM release gap: versions between the release assessed and the current release.
• Mean time to close ineffective controls from the last report.

Mapping to other frameworks

• Essential Eight: the eight strategies are a subset of ISM controls, and ASD publishes them as ML1 to ML3 profiles in the ISM OSCAL. An Essential Eight maturity assessment is narrower than IRAP; the two share evidence for patching, MFA, admin privileges, application control and backups.
• FedRAMP: the closest US analogue, but FedRAMP grants an authorisation and IRAP does not. Evidence such as an SSP and control implementation statements can be reused. See the FedRAMP Guide.
• ISO 27001 and SOC 2: agencies may read them, but they do not substitute for an ISM-based assessment at OFFICIAL: Sensitive or PROTECTED.
• Privacy and sector rules: the Privacy Act, SOCI and APRA CPS 234 sit alongside IRAP. See the Australian Privacy and Cyber Rules Guide.

Small providers versus large

• Small SaaS provider: inherit as much as possible from an IRAP-assessed Layer 1 platform, keep the boundary tight (one region, one production account) and target OFFICIAL: Sensitive first if agencies accept it.
• Large or multi-service provider: assess at PROTECTED, publish consumer recommendations per service, and run delta assessments quarterly or half-yearly so the report never ages past the 24-month mark.
• Agency: do not stop at the provider report. The Layer 3 assessment of your own configuration (tenant settings, admin roles, integrations) is where most residual risk sits.

Common pitfalls

• Calling it IRAP certified: the framework forbids certification language in reports, and ASD has not certified cloud services since 2020. Marketing claims of "IRAP certified" invite scrutiny from agency buyers.
• Policy-only evidence: statements that repeat the ISM control are graded Poor. Without live configuration or testing, identity controls drift to "No visibility" or Ineffective.
• A boundary that skips the admin path: excluding support tooling, offshore operations or the CI/CD pipeline that deploys to production leaves the most privileged identities outside the report.
• Unassessed changes after sign-off: a release that changes authentication is a trigger event. The OpenAI agent Medicare portal incident was linked by reporting to an upgrade that added a login page but also enabled automatic guest access to a production endpoint, the kind of change a delta assessment should catch.
• Forgetting non-human identities: service accounts, long-lived API keys and integration tokens with tenant-wide scope are routinely missed in the controls matrix.
• Running on a stale ISM: starting on an old release, or letting a long engagement fall more than one version behind, breaks a framework requirement and forces rework.

Practitioner checklist

• Confirm the current ISM release on cyber.gov.au and record the version you assess against.
• Fix the target classification and write a boundary that includes every environment, region, admin path and supplier.
• Build the controls matrix from the ISM OSCAL baseline for that classification.
• Self-assess with CAF ratings and evidence grades, treating planned work as Not implemented.
• Prove MFA, privileged account separation and admin logging with live configuration, not documents.
• Inventory service accounts, API keys and AI agents in scope, with owners, scopes and rotation evidence.
• Publish a shared responsibility model and tested consumer recommendations.
• Track changes since sign-off and commission a delta report or addendum when authentication or hosting changes.
• Schedule full reassessment inside 24 months, and check Hosting Certification Framework needs for PROTECTED.

Standards and references

• Australian Signals Directorate: Infosec Registered Assessors Program (IRAP)
• Australian Signals Directorate: IRAP Common Assessment Framework
• Australian Cyber Security Centre: Information Security Manual in OSCAL (releases and change notes)
• Australian Cyber Security Centre: Cloud Assessment and Authorisation FAQ
• Australian Cyber Security Centre: IRAP cloud services and the end of the CCSL
• Department of Home Affairs: Protective Security Policy Framework
• Department of Home Affairs: Hosting Certification Framework
• Microsoft Learn: PSPF required sensitivity labels

This guide summarises the Infosec Registered Assessors Program and related Australian Government requirements as published in October 2026 and is not legal advice. Related NHI Mgmt Group resources: Essential Eight Guide · Australian Privacy and Cyber Rules Guide · FedRAMP Guide · Global Cybersecurity Regulatory Map · Service Account Security Guide