.svg){kind=icon}
Learn
The Risk Management Framework (RMF) is the seven-step process defined in NIST Special Publication 800-37 that federal and defense organizations follow to categorize a system, select and assess security and privacy controls, and make a risk-based decision to authorize it to operate and then monitor it continuously.
Last updated: October 19, 2026
Why it matters to your mission. A capability that cannot earn an authorization to operate never reaches the analyst who needs it, no matter how good the underlying reasoning is. The Risk Management Framework is the process that turns a system into an accredited one: categorize it, select and assess its controls, and let a senior official make a documented, risk-based decision. The outcome is a mission capability that is cleared to run on government networks and stays authorized as it changes.
The Risk Management Framework (RMF) is the seven-step process defined in NIST Special Publication 800-37 that federal and defense organizations follow to categorize a system, select and assess security and privacy controls, and make a risk-based decision to authorize it to operate and then monitor it continuously. In the Department of Defense and the intelligence community it is the path every information system walks before it is allowed on a network.
For any organization fielding software for the mission, including AI capabilities, the RMF is the gate, not paperwork around the edges. A model that cannot survive categorization, control assessment, and an authorizing official's review does not get deployed. A capability that treats accreditation as an afterthought ships late or not at all.
NIST SP 800-37 Revision 2 organizes the framework into seven steps, carried out in order and then revisited as a system evolves. Per NIST's own description, they are:
The order matters because each step depends on the one before it. You cannot assess controls you have not implemented, and no authorizing official signs off on a system whose controls were never assessed. Monitor, the last step, keeps the decision honest over time rather than treating the authorization as a one-time stamp.
The RMF exists to make a security decision defensible. NIST SP 800-37 describes the framework as providing "a disciplined, structured, and flexible process for managing security and privacy risk that includes information security categorization; control selection, implementation, and assessment; system and common control authorizations; and continuous monitoring." That is the whole arc: decide how sensitive the system is, pick controls proportional to that sensitivity, prove the controls work, and have an accountable official accept whatever risk remains.
The product of the process is an authorization to operate (ATO): the formal statement that a named senior official has reviewed the risk and permits the system to run in a specific environment for a specific purpose. An ATO is not a certificate that a system is perfectly secure. It is a record that the risk was understood, documented, and accepted by someone with the authority to accept it, which is exactly what an oversight body, an inspector, or a commander needs to see.
This is why the RMF is the backbone of accredited deployment. For defense and intelligence missions, tracing every control, every assessment result, and every accepted risk back to a source is the difference between a capability that can be briefed and defended and one that cannot clear the door.
These two frameworks share a name and a publisher, and they are routinely confused, but they answer different questions. The system RMF (SP 800-37) authorizes a system to operate. The AI RMF (NIST AI 100-1) governs whether an AI capability is trustworthy enough to field in the first place. They compose: you use the AI RMF to reason about AI-specific risk, and you still run the system RMF to get the resulting system authorized.
| Dimension | Risk Management Framework (NIST SP 800-37) | AI Risk Management Framework (NIST AI 100-1) |
|---|---|---|
| What it governs | A system's security and privacy risk | An AI system's trustworthiness risk (bias, explainability, robustness, and more) |
| Structure | Seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor | Four functions: Govern, Map, Measure, Manage |
| Output | An authorization to operate (ATO) signed by an authorizing official | Risk understanding and documentation; no authorization decision |
| Mandatory or voluntary | Required across federal and defense systems as the accreditation process | Released for voluntary use, per NIST |
| Controls | Draws on the NIST SP 800-53 control catalog | No control catalog; maps to characteristics of trustworthy AI |
NIST describes the AI RMF as "intended for voluntary use and to improve the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems." The AI RMF shapes how you build and evaluate an AI capability; the system RMF is the gate it still has to pass to go live. An AI capability headed for a government network has to satisfy both, and the artifacts from the AI RMF (how the model was mapped, measured, and managed) become evidence that strengthens the system RMF package.
An AI capability is a system, so it runs the same seven steps as any other: it gets categorized by impact, assessed against SP 800-53 controls, and authorized or not by an authorizing official. What AI adds is risk the framework's authors did not have in mind when a "system" meant a database or a web application. A model's behavior can drift as data changes. Its outputs can be hard to explain. A training pipeline is an attack surface. These are the concerns the AI RMF's Map and Measure functions exist to surface, and they feed straight into the system RMF's Assess and Monitor steps.
The Monitor step carries extra weight for AI. A traditional system changes when someone pushes new code; a model can change behavior with no code change at all. That makes continuous monitoring, and the ability to re-establish authorization as the capability evolves, central rather than optional. Independent oversight has made the same point: the U.S. Government Accountability Office's AI accountability framework (GAO-21-519SP, 2021) organizes responsible federal AI use around governance, data, performance, and continuous monitoring. A capability built so that every output traces to its inputs, every control is inspectable, and every change is logged is a capability whose RMF package stays current instead of going stale the day after the ATO is signed.
For accredited AI deployment, the RMF is the mechanism by which an AI capability becomes an authorized one, and the design choices that make a system auditable are the same choices that make its RMF package defensible.
There is no fixed duration; the RMF is scaled to the system's impact level and to how much of the work was done up front. A low-impact system reusing inherited common controls and a well-prepared security package can move quickly. A high-impact system in a classified environment, assessed against a large control set with little prior groundwork, can take many months. The two biggest levers are the Prepare step (doing the organizational and system groundwork before you start, which Revision 2 elevated for exactly this reason) and the amount of control inheritance available from the hosting environment.
The pattern that drags out an authorization is treating security as something to retrofit after the capability is built. The pattern that compresses it is building a capability whose controls, provenance, and documentation are inspectable from the start, so the Assess step confirms what is already true rather than discovering gaps. Designing for continuous monitoring from day one is also what makes ongoing authorization sustainable instead of a periodic fire drill.
Torch.AI builds government-owned reasoning infrastructure the customer can own, inspect, and govern, the same properties an RMF package has to demonstrate. Because the reasoning layer connects to mission data where it lives and complements existing systems of record rather than replacing them, the authoritative sources, and their existing authorizations, stay intact instead of being pulled into a new vendor platform that has to be accredited from scratch.
The products are designed so the evidence an authorizing official needs is a byproduct of how the system works, not an after-the-fact reconstruction. NEXUS makes data meaningful through semantic representation and Knowledge Domains, with the provenance a control assessment depends on. HALO fuses relationships into a graph an analyst, or an assessor, can trace back to source. Together they make outputs trace to inputs, log changes, and keep controls inspectable, which is what keeps a Monitor step current and an authorization defensible as the capability evolves. See how this is packaged as a capability on the Torch.AI software page.
For evaluators, software cannot issue its own ATO; a senior official does. But a capability built to be auditable and government-owned gives that official a package they can actually review, and gives the mission a system that stays authorized as it changes.
The checklist below is what to require of any system, AI or otherwise, that has to earn and keep an authorization to operate.
Scoping an accreditation path? Bring these seven requirements to a scoping call and we will walk each one against your environment and impact level: request a technical walkthrough.
Per NIST SP 800-37 Revision 2 they are Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor, carried out in order and revisited as the system changes. Prepare was the major addition in Revision 2.
It gives organizations a structured process to manage security and privacy risk, so that a senior official can make a documented, risk-based decision to authorize a system to operate and then monitor that decision over time.
The RMF (SP 800-37) is the seven-step process that authorizes a system to operate and produces an ATO; the AI RMF (NIST AI 100-1) is a voluntary four-function framework (Govern, Map, Measure, Manage) for AI trustworthiness. AI capabilities typically use both.
An AI capability runs the same seven steps as any system, with extra attention to model behavior, data lineage, and drift. The AI RMF's Map and Measure work feeds the system RMF's Assess and Monitor steps, and continuous monitoring matters more because a model can change behavior without a code change.
It depends on the system's impact level, the available control inheritance, and how much Prepare-step groundwork was done. Building a capability that is auditable and documented from the start is what compresses the Assess step and keeps ongoing authorization sustainable.
An ATO is the formal decision, signed by an authorizing official, that a named system may run in a specific environment with its residual risk understood and accepted. It records that the risk was reviewed and accepted, not that the system is risk-free.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
