Authority to Operate (ATO)

When it applies

An ATO applies at the transition from system-build to production-operation. For government health systems, an ATO package is typically assembled alongside Privacy Impact Assessment (PIA) and Security Risk Assessment (SRA) artefacts, and is reviewed by a named accrediting authority before go-live. In iterative programmes, the ATO is refreshed at phase boundaries rather than being a one-off artefact.

How it differs across Australia, New Zealand, and the United States

In Australia, an ATO is typically issued by an agency-level accreditor after IRAP assessment (for systems holding Commonwealth information) and internal security review; the language of "Authority to Operate" is widely used but not uniformly codified. In New Zealand, equivalent practice centres on certification and accreditation against NZISM, with CEs or accrediting authorities making the go-live decision; the term "ATO" is used in some agencies but is not statutory. In the United States, ATO has a precise federal meaning under NIST RMF / FedRAMP — it is a formal authorisation by a named Authorising Official with a defined assessment package (System Security Plan, Security Assessment Report, Plan of Action and Milestones).

Common misconceptions

An ATO is not a compliance tick-box — it is a decision that accepts residual risk on behalf of the organisation and assigns ongoing monitoring obligations. An ATO does not transfer — a change of environment, vendor, or material architecture typically requires a fresh or refreshed authorisation. ATO artefacts should be written during design, not assembled retrospectively — otherwise the security story and the implementation diverge.

Related terms

• Privacy Impact Assessment (PIA)
• Security Risk Assessment (SRA)
• Health IT governance