What an ATO actually is
An Authority to Operate is a decision, recorded in writing, by a senior government official that the risk of running a particular system — in a particular environment, handling particular information — is acceptable to their organization. That is the whole of it. The procedure that produces the decision is the NIST Risk Management Framework, documented in NIST SP 800-37 Rev. 2 (December 2018). Within the Department of Defense, DoD Instruction 8510.01 implements that framework for DoD systems, and the workflow typically lives in DISA's Enterprise Mission Assurance Support Service (eMASS).
The common mistake, when the system contains a model, is treating the ATO as a technical review of the model. It is not. It is a risk decision about a system, and the model is one component inside a boundary that somebody drew on a diagram. Almost everything that determines how long the process takes is a property of that boundary — what crosses it, what data sits inside it, what the hosting environment already provides — rather than a property of the model.
Who signs, and who cannot
The signature belongs to the Authorizing Official (AO): per SP 800-37 Rev. 2, a senior federal official or executive with authority to authorize operation of a system and to explicitly accept the residual risk. In DoD the AO sits in the mission owner's chain of command, not in yours. Around the AO are other roles the same publication names: the system owner, the information owner or steward, the Information System Security Manager and Officer (ISSM / ISSO), an AO Designated Representative, and a security control assessor.
No contractor signs. No vendor can grant an ATO to itself or to its software. SP 800-37 Rev. 2 lists the decisions the AO can render: an authorization to operate, a common control authorization, an authorization to use, or a denial of authorization to operate. DoD practice adds an Interim Authorization to Test, which permits a system to run in a live environment for testing only, under conditions the AO sets.
This matters commercially. When a vendor says their product "has an ATO," the accurate translation is either that some agency authorized a system that contained their product, or that a cloud service offering they operate holds a FedRAMP or DoD provisional authorization. Neither one transfers to a new customer automatically. The useful question to ask a vendor is not "do you have an ATO" but "which authorization, whose boundary, at what impact level, and what did the assessor test."
The seven steps, in plain language
SP 800-37 Rev. 2 defines seven steps. They are worth knowing by name because every conversation with a security office assumes them.
NIST SP 800-37 Rev. 2 — the seven RMF steps
Step names are verbatim from SP 800-37 Rev. 2. Role assignments are the primary responsibility in that publication; agencies distribute them differently in practice.
Categorize is where the schedule is set. Under FIPS 199, the system is rated low, moderate or high against confidentiality, integrity and availability, and the overall categorization takes the highest of the three. That rating drives the control baseline selected in step 3 from the SP 800-53 Rev. 5 catalog, using the baselines in SP 800-53B. Assess follows SP 800-53A; Monitor follows SP 800-137. Everything else is scheduling and paperwork discipline.
Why inheritance is the usual route
SP 800-37 Rev. 2 draws a distinction that is the single most useful idea in the whole framework: controls are common, hybrid, or system-specific. A common control is one provided to your system by somebody else — the hosting platform, the enclave, the agency — and inherited rather than re-implemented and re-tested. Physical security of the data center, network boundary protection, identity and access management, the logging infrastructure, host patching, container hardening baselines: on a mature platform, all of those are inherited.
For a component that changes the shape of the work entirely. You are not documenting several hundred controls; you are documenting the delta — what your component adds, changes, or owns outright — and referencing inheritance for the rest. The same pattern appears one level up in the DoD cloud path: DISA issues a Provisional Authorization to a cloud service offering at a given impact level, and each mission owner then issues their own ATO leveraging it.
So when a buyer asks for a component that can be dropped headless into any sandbox, the honest engineering answer is that the component cannot carry an authorization with it. What travels is the property of being cheap to assess. In practice that is a list of subtractions:
- No new inbound network paths — nothing for the boundary-protection controls to re-evaluate.
- No new data store — nothing that changes where the information at rest actually lives.
- No new identity system — authentication and authorization stay with the platform's existing provider.
- Logs to the existing pipeline — audit records land where the ISSO already looks for them.
- Deploys against the platform's hardening baseline — the container image inherits the applicable DISA STIG or SRG posture rather than asserting its own.
- No outbound calls to anything unauthorized — including model APIs outside the boundary, which is the one that most often kills an otherwise clean design.
Each subtraction removes controls an assessor would otherwise have to test against your component instead of inheriting from the platform. That is the actual mechanism behind "portable." It is unglamorous and it works.
The artifacts you will be asked for
SP 800-37 Rev. 2 defines the authorization package as an executive summary, the system security and privacy plan, the assessment report or reports, and the plan of action and milestones. Around that core, most programs also ask for privacy documentation (Privacy Impact Assessments are required by Section 208 of the E-Government Act of 2002), contingency and incident response plans, a configuration management plan, current vulnerability scan results, and a software bill of materials — whose minimum elements NTIA published in July 2021 under Executive Order 14028.
| Artifact | Who produces it | The question it answers |
|---|---|---|
| FIPS 199 categorization | System / information owner, approved by the AO | How bad is it if this information is disclosed, altered, or unavailable? |
| System Security Plan | System owner, with the builder | Where is the boundary, and which control is satisfied by whom? |
| Assessment plan and report | Security control assessor | Were the controls actually tested, and what failed? |
| Plan of Action & Milestones | System owner | What is still broken, who owns it, and by when? |
| Continuous monitoring strategy | System owner / ISSM | How will anyone notice when the system drifts? |
| SBOM and scan evidence | The builder | What is actually inside the software, and is any of it known-vulnerable? |
Only the last row is unambiguously ours to write. That division is worth stating plainly at the start of an engagement, because a component vendor who volunteers to draft the SSP is offering to write a document the government owns and signs.
Where the AI-specific questions come from
There is no artificial-intelligence control family in NIST SP 800-53 Rev. 5. That is good news for the schedule, because it means the questions land in families an assessor already knows how to test. In practice they cluster in five places:
Provenance of weights and training data. Rev. 5 added a Supply Chain Risk Management (SR) family, and that is where questions about where a model came from naturally sit, alongside developer testing under SA-11. "We fine-tuned an open-weights model" is an answerable statement; "we used a model from the internet" is not.
Change control on the model. If weights are updated in place, that update is a configuration change and takes the same approval path as any other under CM-3. A design that swaps weights automatically has put an unreviewed change into an authorized system without meaning to.
What gets logged. The Audit and Accountability (AU) family applies to model inputs and outputs, which may themselves be controlled unclassified information or higher. Logging everything is not automatically the safe answer; it can move sensitive content into a log store with a different categorization.
Input validation. Prompt injection, in control language, is an information-input-validation and information-flow problem — SI-10 and the boundary-protection controls, not a new category of risk needing a new framework.
Reproducibility of the assessment. If the same input produces a different output on a second run, an assessor cannot honestly write "tested and passed" against a specific behavior. Non-determinism is a legitimate engineering choice in many places; it is expensive in exactly this one.
Above the control catalog sits AI-specific policy that shapes the questions without granting or blocking anything: the NIST AI Risk Management Framework 1.0 (NIST AI 100-1, January 2023), voluntary and organized around four functions — Govern, Map, Measure, Manage — and its Generative AI Profile (NIST AI 600-1, July 2024). OMB's direction to agencies on AI use has been revised more than once, from M-24-10 in March 2024 to M-25-21 in April 2025. Ask the program which memorandum they currently operate under rather than assuming; it changes what they must inventory and document, not whether the RMF applies.
This is also where our own design bias comes from, and we would rather state it than have it discovered. We build small models that read through a body of records and produce a written conclusion in which every statement points back to the exact record it came from. That began as a product decision about usefulness. It happens to be the cheapest posture to assess: an assessor can check a claim against its source record without trusting us, and a deterministic path run twice produces the same artifact both times.
The DoD layer: IL4, IL5, IL6
The level belongs to the environment, not to your software
The DoD Cloud Computing Security Requirements Guide, published by DISA, defines the Impact Levels used across DoD cloud. IL4 and IL5 cover controlled unclassified information at differing levels of rigor; IL6 covers information classified up to SECRET. A component written to run at IL5 is not thereby authorized at IL5 — it is a component a mission owner can place inside an IL5-authorized environment without adding controls that environment does not already provide.
IL6 is a different kind of commitment from IL5, and the difference is mostly not software. It implies classified handling: cleared personnel, accredited facilities, and network and contractual arrangements that no amount of engineering substitutes for. A firm quoting IL6 work without those in place is quoting a schedule it cannot control.
Continuous authorization, briefly
The traditional pattern is a point-in-time authorization with a fixed term, followed by reauthorization. SP 800-37 Rev. 2 supports ongoing authorization instead, driven by continuous monitoring under SP 800-137. In DoD, the CIO's February 2022 memorandum on Continuous Authorization to Operate set conditions for that ongoing state, including continuous visibility of cybersecurity activity inside the boundary, an active cyber defense capability, and use of an approved DevSecOps reference design — the DoD Enterprise DevSecOps Reference Design being the published baseline.
The consequence for a component builder is narrow but real: evidence has to be produced by the pipeline, not assembled by a person the week before an audit. Scans, SBOMs, test results and provenance records need to fall out of the build automatically. If they do, a continuously authorized platform can absorb your component quickly. If they do not, you become the reason its posture slips.
What we will not do
Scope is easier to trust when the refusals are written down.
We will not tell you we can get you an ATO
Only the Authorizing Official signs, and the AO sits in the government's chain of command, not ours. Anyone promising you a signature is promising something they do not control. What a builder can honestly commit to is the quality and timeliness of the evidence, and a design that minimizes what the assessor has to test.
We will not assess a system we built
Independence is the assessor's entire value, and SP 800-37 Rev. 2 treats assessor independence as a factor the Authorizing Official weighs when deciding how much confidence to place in the results. If we built the component, we produce evidence for the assessor; we do not grade our own work.
We will not describe our software as "authorized"
FedRAMP authorization — codified in statute by the FedRAMP Authorization Act, enacted as part of the FY2023 National Defense Authorization Act (Pub. L. 117-263) — attaches to a specific cloud service offering listed on the FedRAMP Marketplace. A component is authorized only as part of a system, inside a boundary, by a named official. We will describe what a component inherits and what it adds, which is the useful information anyway.
We will not quote IL6 work without the prerequisites in place
IL6 involves classified handling and therefore cleared personnel, accredited facilities, and contract and network arrangements. Where those are not in place for a given engagement, we say so before the work starts. That conversation is uncomfortable once and expensive never.
We will not promise a date for someone else's decision
Assessment queues, AO calendars and reciprocity negotiations are outside a vendor's control, and published timelines vary widely by agency and by system. We will give you a dated plan for the artifacts we own and decline to attach a date to the signature we do not.
Bottom line
An ATO is a person accepting risk in writing. The framework that gets them there is public, stable, and older than the current wave of AI — and for a component, the fastest path through it is almost never a new argument about the model. It is a small boundary, a short delta of controls that are genuinely yours, evidence the build produces on its own, and a clear statement of what the component inherits from the platform underneath it. The AI-specific questions are real, but they land in control families that already exist. Answer them in that language and the conversation is short.
Frequently asked questions
Generally no. Authorization applies to a system operating in a specific environment with specific information, and the decision is rendered by an Authorizing Official for that organization. A component is authorized as part of a system. What a component can do is inherit common controls from an authorized platform and document only the controls it adds or changes.
The Authorizing Official — under NIST SP 800-37 Rev. 2, a senior federal official or executive with authority to authorize operation of the system and to explicitly accept the residual risk. Supporting roles include the system owner, the ISSM and ISSO, and an independent security control assessor. No contractor signs.
SP 800-37 Rev. 2 defines the core package as an executive summary, the system security and privacy plan, the security assessment report, and the plan of action and milestones. Most programs also ask for privacy documentation, contingency and incident response plans, a configuration management plan, current scan results, and a software bill of materials.
It does not add a control family — there is no AI family in NIST SP 800-53 Rev. 5. It concentrates attention on existing ones: supply chain (SR) for model and data provenance, configuration management (CM) for weight updates, audit (AU) for what inputs and outputs get logged, and system and information integrity (SI) for input validation. The NIST AI RMF and its Generative AI Profile shape the questions but are voluntary frameworks, not authorization gates.
Per the DoD Cloud Computing Security Requirements Guide published by DISA, IL4 and IL5 cover controlled unclassified information at different levels of rigor, while IL6 covers information classified up to SECRET. The practical difference for a vendor is that IL6 brings personnel clearance, facility accreditation, and network requirements that are organizational commitments rather than engineering ones.