The NIST AI Risk Management Framework: A Practitioner's Field Guide

The NIST AI Risk Management Framework is the closest thing the United States has to a default reference for governing AI systems. It is voluntary, not a regulation — but it is increasingly the framework that procurement questionnaires, insurance reviews, and board-level AI-governance asks point to, and it is the scaffolding most enterprise AI governance programs are quietly built on. If you run security or risk for an organization deploying AI, you will be asked to map to it. This guide is what it actually requires, stripped of the consulting-deck gloss.

The goal here is operational. Plenty of summaries recite the four functions and stop. This one explains what each function asks you to do, where the Generative AI Profile adds teeth, and how a small team turns a deliberately flexible framework into a finite set of controls instead of an infinite documentation project. Where the framework intersects the threat material we cover elsewhere — adversarial ML, model supply chain, prompt injection — I have flagged the connection.

What the AI RMF is, and is not

The framework is published as NIST AI 100-1 ↗, released in January 2023. It is risk-based and outcome-oriented: it does not prescribe specific controls or technologies. Instead it defines characteristics of trustworthy AI — valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed — and a set of functions for managing risk against those characteristics across the AI lifecycle.

What it is not: a checklist you can pass, a certification, or a security standard in the ISO sense. It is a structured way to reason about and document AI risk. That flexibility is a feature for a fast-moving field and a trap for teams that want a finite to-do list. The discipline this guide pushes is to make it finite — to translate the open-ended functions into a bounded inventory of controls scoped to your actual systems.

The four functions

The framework’s core is four functions: GOVERN, MAP, MEASURE, MANAGE. They are not strictly sequential. GOVERN is cross-cutting and continuous; MAP, MEASURE, and MANAGE iterate over the lifecycle of each AI system. The full AI RMF Core ↗ breaks each into categories and subcategories, but the practitioner version is:

GOVERN — the standing program

GOVERN is the culture and structure that everything else hangs on, and it applies across all stages. In practice it is the answers to: Who owns AI risk? What policies exist? Is there an inventory of AI systems? How are third-party and supply-chain components tracked? How are decisions documented and who is accountable? Are the people doing this trained and resourced?

The single most valuable GOVERN artifact, and the one most organizations lack, is an AI system inventory. You cannot manage risk on systems you have not enumerated, and shadow AI — ungoverned tools and API keys deployed outside the inventory — is where most real exposure lives. If you do one GOVERN thing first, build and maintain the inventory.

MAP — establishing context

MAP is where you characterize a specific AI system before assessing it: what it does, the context it operates in, who is affected, what its capabilities and intended uses are, and where the risks come from — including third-party data, models, and components. The output of MAP is a clear-eyed description of the system and an initial enumeration of plausible harms.

The high-leverage MAP question for a security team is the supply-chain one: where did the model, the training data, and the dependencies come from, and what do you actually know about their provenance? This is the function that should surface that a “vendor model” is a fine-tune of an unknown base, or that a RAG corpus ingests user-controlled content. (Our coverage of unsafe model file formats and LLM supply chain poisoning is the threat detail behind these MAP questions.)

MEASURE — assessing and tracking

MEASURE is the analytic core: choose metrics and methods, evaluate the system against the trustworthiness characteristics, track risk over time, and — critically — assess whether your measurement is even effective. This is where security testing lives. Adversarial robustness, red-team results, evaluation of bias and reliability, and the ongoing monitoring that tells you when a measured property has degraded all belong here.

MEASURE is also where the framework is honest about its own limits: it explicitly asks you to evaluate whether your measurements are valid, because a metric that does not capture the real risk gives false assurance. For AI security specifically, MEASURE is where you commit to red-teaming as a recurring activity rather than a launch-day formality. (See our practical guide to AI red-teaming for what that engagement looks like.)

MANAGE — acting on what you found

MANAGE is the response: prioritize the risks MEASURE surfaced, decide treatments (mitigate, transfer, avoid, accept), plan incident response and recovery, handle residual risk explicitly, and keep monitoring third-party elements. It closes the loop — including the decision to accept a documented residual risk, which is a legitimate MANAGE outcome as long as it is a decision someone accountable made, not a gap nobody noticed.

The Generative AI Profile: where it gets specific

The base framework is intentionally model-agnostic. The teeth for anyone deploying LLMs are in the companion Generative AI Profile, published July 2024 as NIST AI 600-1 ↗. It was produced under Executive Order 14110 and identifies risks that are unique to or amplified by generative AI, then maps suggested actions back to the four functions.

The profile names 12 risk categories specific to generative AI. They are the ones a security reviewer will recognize, including: CBRN information or capabilities; confabulation (the report’s term for hallucinated, confidently wrong output); dangerous, violent, or hateful content; data privacy; environmental impacts; harmful bias and homogenization; human-AI configuration; information integrity; information security; intellectual property; obscene and abusive content; and value chain and component integration.

For a security team, three of these are the load-bearing ones: information security (the model and its surrounding system as attack surface — prompt injection, data exfiltration, model and infrastructure vulnerabilities), data privacy (training-data leakage, sensitive inputs entering the model context), and value chain and component integration (the supply-chain risk of third-party models, data, and dependencies). The profile’s value is that it turns “secure your AI” into a finite set of named categories you can assign owners to and assess against, each with suggested actions tied to GOVERN/MAP/MEASURE/MANAGE.

Where the framework meets real threats

The AI RMF is a management framework, not a threat catalog — and that is the gap practitioners fill with NIST’s other publications and the community frameworks. The honest read is that the RMF tells you to manage AI security risk; it points elsewhere for what the attacks are.

The natural companions:

• NIST AI 100-2e2025 ↗, the Adversarial Machine Learning taxonomy, is the attack-side reference. Its 2025 edition covers evasion, poisoning, privacy, and misuse attacks across both predictive and generative AI, including LLM-, RAG-, and agent-specific attacks. When MEASURE asks “evaluate security and resilience,” this report is the menu of what to test against.
• MITRE ATLAS maps adversary tactics and techniques against AI systems, ATT&CK-style, and is the operational bridge between the RMF’s abstractions and concrete detection. (We cover the AI/ML CVE side of the supply-chain story in our ongoing CVE roundups.)
• The OWASP Top 10 for LLM Applications is the developer-facing risk list that overlaps heavily with the GenAI Profile’s information-security category. (See our breakdown of what changed in the 2025 OWASP LLM Top 10.)

The practical pattern: use the AI RMF for structure and accountability (the how do we manage this layer), and use ATLAS, AI 100-2, and OWASP for the what specifically can go wrong layer that fills MAP and MEASURE with real content.

How to actually adopt it without drowning

The framework’s flexibility is where adoption goes to die. Three moves keep it finite:

1. Scope to the inventory, not to “AI.” Run GOVERN once to build the system inventory, then run MAP/MEASURE/MANAGE per system, prioritized by impact. You are not assessing “our AI” — you are assessing eleven named systems, ranked. A high-impact customer-facing agent gets the full treatment; an internal summarization tool gets a lightweight pass.
2. Tier the depth. Not every system earns a full profile assessment. Define two or three tiers (e.g. high-impact / external-facing, internal / moderate, low-risk experiment) and a corresponding depth of MEASURE activity. This is the difference between a framework you run and a framework you describe in a slide.
3. Make residual-risk acceptance explicit and owned. The framework’s most underused feature is that accepting a risk is a valid MANAGE outcome — when an accountable owner decides it, in writing, with the residual risk named. That converts “we didn’t get to it” into “we decided, and here is who decided.” Auditors, insurers, and incident post-mortems all care about that distinction.

The AI RMF will not, by itself, make a system secure — no framework does. What it gives you is a defensible structure: an inventory, an owner per risk, a record of what you measured and decided, and a vocabulary that lines up with what regulators and customers are starting to ask for. Paired with a real threat catalog and a recurring red-team practice, that structure is worth building. On its own, recited but not operationalized, it is a slide. The difference is entirely in whether you make it finite and assign the owners.

Sources

• NIST AI 100-1 — AI Risk Management Framework (AI RMF 1.0) ↗ — the framework itself; the four functions and the trustworthiness characteristics.
• NIST — AI Risk Management Framework program page ↗ — the hub for the RMF, Playbook, and companion resources.
• NIST AI 600-1 — Generative AI Profile ↗ — the 12 generative-AI risk categories and suggested actions mapped to the functions.
• NIST AI RMF Core (AIRC) ↗ — the categories and subcategories under each function.
• NIST AI 100-2e2025 — Adversarial Machine Learning Taxonomy ↗ — the attack-side companion for filling MAP and MEASURE with real threat content.

See also

• AI security intelligence hub
• CISA AI security guidance 2026