Getting an AI System Through the ATO Process: A Practical Playbook

If you have read our posts on the ATO process and on the NIST AI RMF separately, you already have both halves of this picture. What neither post walked through is how they actually combine when the system going up for authorization is an LLM, a retrieval-augmented assistant, or an agentic tool. The RMF's seven steps do not change. What changes is what counts as evidence at each step, and where an assessor is going to probe harder than they would for a traditional system.

It is easy to forget the RMF's first step, because most conversations about authorization jump straight to Categorize. Prepare is where an organization sets its risk management roles, its risk tolerance, and its organization-wide control baselines, before any single system enters the pipeline. This is also where the AI RMF's Govern function does its real work: establishing the AI risk management policy, naming an accountable executive, and setting decision rights for AI deployments, well before you get anywhere near a specific system's SSPP.

Treating Govern as Prepare-level work, done once for the organization, changes the order of operations for the better. A team that skips this and tries to invent AI governance policy in the middle of a single system's authorization package ends up doing it under deadline pressure and with less credibility than a team that can point to an existing, organization-wide AI governance policy that this particular system simply operates under.

Categorization under the RMF asks what data the system touches and how sensitive it is. For an AI system, that question has an extra layer: what data does the model see during inference, not just what data the application formally stores. A retrieval-augmented system that pulls from a document store containing CUI is handling that CUI the moment it retrieves it into context, whether or not the model itself persists anything. Your System Security and Privacy Plan needs to describe the model's effective data access, not just the application's formal data stores, and this is exactly what the AI RMF's Map function is designed to force you to articulate: the system's purpose, its data sources, and what could go wrong.

Control selection follows the same logic. You are still picking your NIST SP 800-53 baseline based on impact level. The AI-specific work is extending that baseline's implementation statements to cover model behavior: which SR (Supply Chain Risk Management) controls apply to your model provider, which AC (Access Control) controls govern what the model itself is allowed to retrieve or act on, and which SI (System and Information Integrity) controls cover input validation and output filtering for a system whose behavior is probabilistic rather than deterministic.

This is where organizations most often underestimate the work. Implementing controls for an AI system means documenting things that do not exist for a traditional application: what the system prompt says and why, what tools or functions the model can call and under what authorization, what happens when the model refuses a request or produces a low-confidence output, and who is accountable for approving changes to any of that. The organization-wide accountability structure came out of Prepare and Govern; what gets built here is the system-specific extension of it, decision rights for this particular system's tools and prompts, written down as explicit policy rather than left implicit in the code, because the system's behavior is not fully determined by the code alone.

A traditional Security Assessment Report documents whether implemented controls work as specified. For an AI system, "works as specified" needs a testing methodology that does not exist in a standard penetration test. This is where adversarial AI testing earns its place in the authorization package: prompt injection testing against the system's actual deployment configuration (real system prompt, real retrieval sources, real tool permissions, not a sanitized lab setup), jailbreak resistance testing, and testing for unsafe tool use if the system has any agentic capability. Document the methodology and the results the same way you would document a penetration test, because that is functionally what CA-8 is asking for here. The AI RMF's Measure function and your SAR's adversarial testing section should be the same evidence, presented twice for two audiences.

Model cards, red-team results, and data provenance records deserve specific mention because they are new documentation categories a traditional ATO package never needed. A model card describing what the model is, what it was trained on at a general level, and its known limitations is evidence an assessor can use to evaluate whether the system's intended use matches its actual capability. Red-team results are your adversarial testing evidence in a form that is increasingly expected as a distinct artifact, not buried inside a generic SAR appendix. Data provenance, where training or fine-tuning data came from and under what license or agreement, is SR-family evidence that a traditional system's SSPP rarely needed to address at this level of specificity.

When an Authorizing Official signs off on an AI system, they are accepting a risk profile that includes probabilistic behavior, which is a genuinely different kind of risk acceptance than signing off on a deterministic system with a known, fixed set of failure modes. Make that explicit in the risk decision documentation rather than presenting the AI system as if it carries the same risk character as anything else in the portfolio. Continuous monitoring afterward needs to account for model drift and provider-side changes, since a model your organization does not control can change behavior when the provider ships an update, which is a contingency a traditional CP-2 contingency plan rarely had to consider.

Before you bring an AI system to an AO, make sure your package includes: a data flow description that covers what the model sees at inference time, not just what the application stores; extended 800-53 implementation statements covering model-specific AC, SI, and SR controls; written governance documentation for system prompts, tool permissions, and refusal handling; adversarial test results (prompt injection, jailbreak resistance, tool-abuse scenarios) run against the actual deployment configuration; a model card and data provenance summary; and a contingency plan that addresses model-provider changes, not just infrastructure failover.

None of this requires a separate AI authorization process. It requires treating the AI RMF's four functions as a lens on the RMF's seven steps, most of them run once at the organization level in Prepare and the rest run per system, and being deliberate about the evidence categories that are genuinely new. Organizations that try to force an AI system through an authorization package built for deterministic software usually get sent back with findings that a properly scoped package would have caught first. Organizations that build the AI-specific evidence in from the start get through the same process everyone else does, just with a more complete package.

This post draws on the NIST Risk Management Framework, NIST AI RMF 1.0, and NIST SP 800-53, consistent with our earlier posts on the ATO process, the NIST AI RMF, and the AI RMF to 800-53 crosswalk.