What Is an ATO (Authority to Operate)?

What an ATO actually is

"ATO" stands for Authority to Operate, written in the standards as authorization to operate. It sounds like a certification and is not one. There is no ATO test you pass, and no company that can sell you one.

The definition, carried in NIST SP 800-53 Rev. 5 and published in the NIST glossary, is an "official management decision given by a senior Federal official or officials to authorize operation of an information system and to explicitly accept the risk to agency operations (including mission, functions, image, or reputation), agency assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security and privacy controls."

Three phrases do most of the work. Decision — testing produces evidence; the ATO is what a person does with it. Explicitly accept the risk — the official is not certifying the system is secure, only that the risk left over is acceptable for this mission. An information system — the authorization attaches to a particular system, in a particular configuration and environment, for a particular purpose.

Agencies do this because the Federal Information Security Modernization Act makes agency heads responsible for protecting their information and systems. As FedRAMP's guidance puts it, agencies "follow agency policy, OMB Circular A-130, and the NIST Risk Management Framework" when deciding whether to authorize a system.

Who signs it, and what else they can sign

The signer is the Authorizing Official (AO): a senior government official with authority to accept risk on the organization's behalf. Not the vendor. Not the assessor. Not the program manager who wants the system live. In the Department of Defense, AO designation and the RMF process are set out in DoD Instruction 8510.01, Risk Management Framework for DoD Systems.

An AO has more than a yes/no switch. NIST SP 800-37 Rev. 2 describes several distinct decisions: an authorization to operate; a common control authorization, covering controls one provider offers for other systems to inherit; an authorization to use, when an organization accepts the information in an existing package produced by another organization; and a denial of authorization, after which the system is not placed into operation, or is halted if already running.

An ATO can also arrive with strings attached. Under SP 800-37 Rev. 2 the authorization decision conveys the terms and conditions of the authorization, the system owner must "acknowledge, implement, and comply with" them, and the authorizing official "verifies on an ongoing basis, that the terms and conditions established as part of the authorization are being followed." DoD adds an Interim Authority to Test (IATT) for systems that must connect to a network before production.

The artifacts: SSP, SAR, POA&M

Task R-1 of SP 800-37 Rev. 2 names what the AO receives — the authorization package: the security and privacy plans, the assessment reports, the plan of action and milestones, and an executive summary.

• System Security Plan (SSP) — what the system is, where its boundary sits, and how each selected control is implemented. Usually the longest document, and the one that sets the schedule.
• Security Assessment Report (SAR) — what an assessor found when they independently tested those claims. Independence is the point; the person who built the control should not grade it.
• Plan of Action and Milestones (POA&M) — what is not fixed yet, with an owner and a date for each item. A POA&M is not an admission of failure; an empty one on a real production system usually means nobody looked very hard.
• Executive summary — the part the AO reads first, and sometimes the only part read closely.

Everything in that package describes a boundary. Deciding what sits inside it — which components, which data flows, which shared services — is the most consequential early decision, because every later cost prices off it.

How a system gets there

The path is the Risk Management Framework, NIST SP 800-37 Rev. 2 (December 2018). It has seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. Revision 2 added Prepare to the six that existed before it.

Categorize is where the size of the job is set. Under FIPS 199, Standards for Security Categorization of Federal Information and Information Systems (February 2004), a system is rated for potential impact — low, moderate, or high — against confidentiality, integrity, and availability. National security systems categorize under CNSSI 1253 instead. That rating drives the control baseline drawn from NIST SP 800-53 Rev. 5, which NIST continues to update — release 5.2.0 landed in August 2025.

Authorize is step six of seven, not the finish line. SP 800-37 Rev. 2 sets an authorization termination date for a conventional ATO, and describes ongoing authorization as an alternative in which "the authorization frequency is specified in lieu of an authorization termination date." An authorization can be initial, ongoing, or a reauthorization, and it can be rescinded.

Inheritance: why nobody starts from zero

If every system had to prove every control from scratch, nothing would ship. Inheritance prevents that: common controls authorized once and reused by many systems, an authorization to use, and — for cloud — FedRAMP.

The FedRAMP Authorization Act, enacted in December 2022 as part of the FY2023 National Defense Authorization Act, put the reuse rule into statute. 44 U.S.C. § 3613(e)(1) states: "The assessment of security controls and materials within the authorization package for a FedRAMP authorization shall be presumed adequate for use in an agency authorization to operate cloud computing products and services."

Read the next paragraph too, because it is the one people skip. Section 3613(e)(2) says that presumption "does not modify or alter" either the agency's responsibility to comply with federal information security law, or "the authority of the head of any agency to make a determination that there is a demonstrable need for additional security requirements beyond the security requirements included in a FedRAMP authorization for a particular control implementation."

FedRAMP's guidance is equally direct about what stays with the customer: categorize your own system, confirm the service supports what you need (identity integration, logging into your SIEM, administrative controls), configure it per the provider's secure configuration guide, and produce your own System Security Plan, assessment report, POA&M, and risk response. The resulting ATO "applies to the agency information system and its use of the cloud service." You inherit evidence; you do not inherit the decision.

The DoD path: impact levels and provisional authorizations

DoD layers its own structure on top of FedRAMP. The DoD Cloud Computing Security Requirements Guide (CC SRG), issued by DISA, sorts workloads into Information Impact Levels:

• IL2 — non-controlled unclassified information. Data cleared for public release, plus some low-confidentiality unclassified information not designated CUI that still needs minimal access control.
• IL4 — controlled unclassified information. CUI and other mission-critical data, including data used in direct support of military or contingency operations. (Earlier SRG revisions retired Levels 1 and 3, merging them into Levels 2 and 4.)
• IL5 — CUI requiring higher protection. CUI that the information owner, public law, or other regulation determines needs more protection than IL4. IL5 also carries unclassified National Security Systems; the SRG states that "unclassified NSS must be instantiated at Level 5 if a CSO is used."
• IL6 — classified information up to SECRET. Because the infrastructure must be dedicated and separate, the SRG notes IL6 offerings may only come from providers under contract to DoD or a federal agency — in that sense, it says, the offering "is not considered 'commercial.'"

DISA issues a Provisional Authorization (PA) to a cloud service offering that meets a given impact level. A PA is not a mission system's ATO. The SRG is explicit: "The PA and supporting documentation must then be leveraged by the mission owner's AO in granting the required ATO for the mission system operating within the cloud."

How much you inherit varies by service model. Per the SRG, "the Mission Owner inherits compliance from the CSO for the security controls (or portions thereof) that the CSP meets and maintains" — a SaaS customer inherits the bulk; a team building on IaaS or PaaS still owns many controls inside its own code.

DISA's DoD Cloud Authorization Process briefing (June 2024) describes the commercial route as "based on FISMA and NIST RMF processes leveraging FedRAMP, supplemented with DoD considerations." DoDI 8510.01 separately directs cybersecurity reciprocity to reduce redundant testing — a policy preference an AO exercises, not an entitlement a vendor can claim.

Continuous authorization

A point-in-time authorization ages badly for software that ships every week. DoD's answer is continuous ATO (cATO), the subject of a February 2022 DoD CIO memorandum. As reported by ExecutiveGov, the memo describes three competencies an authorizing official should see first: "adoption of an approved DevSecOps reference design"; the capacity to conduct active cyber defense and respond to cyber threats in real time; and "ongoing visibility of cyber activities within the system boundary and continuous monitoring of risk management framework controls."

That maps onto ongoing authorization in SP 800-37 Rev. 2: trade the termination date for a documented frequency and a monitoring program strong enough that the AO can keep accepting the risk with open eyes. cATO is not a shortcut. It converts a one-time push into a permanent standard of evidence.

What an ATO does not mean

Two limits are worth stating plainly, because they are where expensive misunderstandings live.

It is not proof a system is secure, and it does not last forever. It is a documented judgment that the risk left over is acceptable for a stated mission; termination dates, ongoing-authorization frequencies, reauthorization, and rescission are all part of the framework.

It does not travel. A component running inside an accredited enclave at one impact level is not automatically authorized somewhere else. What travels is evidence — the assessment, the control implementation detail, the monitoring record — plus whatever reciprocity the receiving AO grants. A promise that a model or service "drops in anywhere with the ATO included" describes a wish, not the process in SP 800-37 or the CC SRG.

Honest scope beats claimed breadth, so here is where Precision Federal draws its lines. We do not issue ATOs and will not tell you a system "comes with" one — no contractor can. We do not act as the independent assessor for systems we build; the SAR should come from someone with nothing riding on the answer. We do not claim accreditation we have not earned — if we have not operated at a given impact level, we say so in writing. And we do not treat a POA&M as a document to be cosmetically shortened; its whole value to an AO is that it is candid.

What we build is narrower: small models that read through a body of data and produce a written conclusion, with every statement traced back to the exact record it came from — traceability designed as an artifact an assessor and an authorizing official can read, not a demo feature. That shortens nobody's RMF timeline. It does make the system legible when someone asks how a conclusion was reached.

Sources: NIST SP 800-37 Rev. 2 — Risk Management Framework for Information Systems and Organizations; NIST CSRC Glossary — authorization to operate; FIPS 199 — Standards for Security Categorization; NIST SP 800-53 Rev. 5; 44 U.S.C. § 3613 — FedRAMP agency responsibilities and presumption of adequacy; FedRAMP — Initial Agency Authorization; DoD Cyber Exchange — DoD Cloud Computing Security (CC SRG); DISA — DoD Cloud Authorization Process (June 2024); DoD Instruction 8510.01; ExecutiveGov — Pentagon memo on continuous authorization to operate. Analysis and framing by Precision AI Academy.

Common questions

What is an ATO (Authority to Operate)? NIST defines an authorization to operate as the official management decision given by a senior Federal official to authorize operation of an information system and to explicitly accept the risk to agency operations, agency assets, individuals, other organizations, and the Nation, based on the implementation of an agreed-upon set of security and privacy controls. It is a risk-acceptance decision about a specific system, not a test result or a certificate.

Who issues an ATO? A government Authorizing Official — a senior federal official with authority to accept risk on the organization's behalf. Vendors, assessors, and integrators cannot issue one. In DoD, AO roles and the RMF process are set out in DoD Instruction 8510.01, Risk Management Framework for DoD Systems.

What documents make up an authorization package? Per NIST SP 800-37 Rev. 2: the security and privacy plans (the System Security Plan), the security and privacy assessment reports (the SAR), the plan of action and milestones (POA&M), and an executive summary for the authorizing official.

Does FedRAMP or a DoD Provisional Authorization give you an ATO? No — both are reusable evidence. Under 44 U.S.C. § 3613(e), a FedRAMP authorization package is presumed adequate for use in an agency ATO, but the presumption does not change the agency's own security responsibilities or an agency head's authority to require more. In DoD, DISA issues a Provisional Authorization to a cloud service offering, which the Mission Owner's Authorizing Official then leverages in granting the ATO for the mission system.