IRAP is Australia’s Information Security Registered Assessors Program, used to evaluate whether a technology provider meets government security expectations for handling sensitive data. It aligns assessment work to the Australian Government Information Security Manual and is commonly used for public sector cloud and software procurement.
Expanded Definition
An IRAP assessment is an Australian government security review performed by an Information Security Registered Assessor to judge whether a provider can safely handle government information and workloads. In NHI and cloud governance, the practical concern is not just whether controls exist, but whether the service can sustain them across deployment, access, logging, and change management. IRAP is therefore less a product label than an evidence-based assurance process that maps provider claims to the Australian Government Information Security Manual and related procurement expectations.
Definitions vary across vendors when they describe IRAP as a simple certification, but no single standard governs it that way. It is better understood as an assessment against documented security controls, with scope shaped by the system boundary, data sensitivity, and hosting model. That makes it adjacent to, but distinct from, internal risk reviews, penetration tests, and general compliance attestations. The NIST Cybersecurity Framework 2.0 provides a useful external reference for thinking about governance, protection, detection, and recovery outcomes, even though it is not an Australian assurance scheme. The most common misapplication is treating IRAP as a one-time checkbox, which occurs when organisations ignore post-assessment configuration drift and shared-responsibility gaps.
Examples and Use Cases
Implementing IRAP rigorously often introduces evidence-collection overhead, requiring organisations to weigh procurement velocity against the cost of producing and maintaining trustworthy assurance artifacts.
- A government agency requires IRAP assessment before onboarding a SaaS platform that will store citizen records, because the vendor must demonstrate controls for access, logging, encryption, and incident handling.
- A cloud provider uses IRAP findings to narrow its shared-responsibility documentation, making clear which controls are inherited and which remain the customer’s responsibility.
- An NHI-heavy platform supports service accounts, API keys, and automation tokens in a public sector deployment, so assessors review secrets handling, rotation, and privilege scope alongside the hosting stack. The Ultimate Guide to NHIs is useful context for why those controls matter.
- A vendor preparing for procurement maps its operational controls to a recognised framework such as the NIST Cybersecurity Framework 2.0 before the formal IRAP review, reducing surprises during assessor interviews.
- A SaaS product used by multiple agencies undergoes reassessment after a major architecture change, since a previously accepted control design may no longer fit the new trust boundary.
Why It Matters in NHI Security
IRAP matters in NHI security because many public-sector compromises begin where machine identities, secrets, and service-to-service permissions are weakly governed. NHI programs often fail when access looks acceptable at design time but drifts in production through unmanaged keys, excessive privilege, or forgotten automation credentials. That is one reason the Ultimate Guide to NHIs reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and why 97% of NHIs carry excessive privileges. Those patterns are directly relevant to IRAP because assessors are looking for evidence that sensitive government workloads will not inherit hidden identity risk.
For procurement teams, IRAP becomes a forcing function for governance: inventorying secrets, proving rotation, constraining third-party exposure, and documenting who can administer what. It also helps separate security claims from operational reality, which matters when a vendor’s controls depend on manual discipline rather than enforceable policy. Organisations typically encounter IRAP as a hard requirement only after a procurement delay, a failed assurance review, or a security incident, at which point the assessment becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the technical controls, and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | IRAP is an assurance review that maps directly to governance and outcome-based risk oversight. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | IRAP commonly evaluates trust boundaries and least-privilege enforcement in zero-trust architectures. |
| OWASP Non-Human Identity Top 10 | NHI-02 | IRAP evidence often hinges on secret handling, rotation, and privilege control for NHIs. |
| NIST SP 800-63 | AAL2 | Although human-focused, its assurance concepts inform strong authentication expectations for privileged access. |
| NIS2 | IRAP-style assurance supports regulated governance, incident readiness, and supply-chain security expectations. |
Maintain auditable controls and supplier evidence so assessment artifacts remain current and defensible.
