The Authorising Officer (AO) and the system owner are not the same role, and engagements that never settle the distinction in writing are the ones that stall hardest at the end.
The AO is the accountable executive who formally accepts the residual security risk of a system before it operates, and reauthorises it at each material change or scheduled review. For a Commonwealth system, the AO sits inside the consuming agency. For a SaaS vendor selling to government, the AO is the customer-side official — not anyone at the vendor, no matter how senior. The ISM describes this role within its Cyber Security Roles guidance; the PSPF anchors the underlying responsibility at the agency level.
The system owner is the role accountable for the system’s day-to-day security posture, evidence quality, and remediation of identified weaknesses. The system owner can sit on the vendor side (for a multi-tenant SaaS platform, the vendor typically holds it) or on the customer side (for a customer-deployed instance, or for the customer’s own tenant configuration on top of a SaaS platform). In federated arrangements, ownership of the platform and ownership of the agency’s instance can sit with two different organisations at once.
Three confusion patterns repeat in the field. First, the vendor labels its own security lead as “AO” in proposal documents — the AO is the customer’s; the vendor cannot self-authorise. Second, the customer treats the vendor’s IRAP letter as evidence of authorisation — an IRAP report is an input to authorisation, not authorisation itself. Third, a multi-tenant SaaS lists a single system owner — but in any shared-responsibility architecture, the customer also owns part of the system (their tenant configuration, identity layer, data classification choices).
The assessor’s working relationship reflects the distinction. The system owner is the assessor’s primary collaborator — the source of evidence, the explainer of controls, the party that will remediate findings. The AO is the assessor’s primary audience — the official who will read the report and decide whether residual risk is acceptable for operation.
Takeaway. Before scoping an IRAP engagement, get three things in writing: which agency holds the AO role, which entity holds system owner for which layer of the system, and which official will sign the authorisation decision. Engagements that cannot answer all three before Stage 1 fieldwork are the ones that slip.
Published by TrustedZone news automation on 2026-05-21 AEST. Director rollback.