NIST AI RMF - the risk process

Where SAIF tells you which safeguards to build, NIST AI RMF tells you how to reason about and act on risk - the process that decides which safeguards you need, whether a gap blocks a launch, and how you prove you are managing it over time. This is the full working map of the framework and its Generative AI Profile.

The core idea

• The AI RMF is a risk process, not a control catalog and not a law. It is voluntary, non-certifiable, and use-case-agnostic. It is the board- and regulator-facing language for AI risk in the US line, and the one framework auditors, insurers, and procurement teams most often ask for.
• Its engine is four functions - GOVERN, MAP, MEASURE, MANAGE. GOVERN is cross-cutting; MAP -> MEASURE -> MANAGE run broadly in sequence but iterate.
• It is anchored to seven characteristics of trustworthy AI. Every measurement and control ultimately serves one of the seven.
• For generative AI, layer the Generative AI Profile (AI 600-1) on top - it adds twelve GenAI-specific risks and hundreds of suggested actions keyed to the Core.

Document identity

The Artificial Intelligence Risk Management Framework (AI RMF 1.0) is NIST AI 100-1 (DOI 10.6028/NIST.AI.100-1), released 26 January 2023 under the National AI Initiative Act of 2020. It is voluntary, non-sector-specific, and use-case-agnostic, with the stated purpose “to better manage risks to individuals, organizations, and society associated with AI” (NIST AI RMF landing; AI 100-1 PDF; AIRC Knowledge Base).

The framework defines risk as “a composite measure of an event’s probability of occurring and the magnitude … of the consequences,” and insists that harm be considered across three dimensions: people, organizations, and the ecosystem. It comes in two parts: Part 1 - Foundational Information (framing, trustworthiness, AI actors and lifecycle, including TEVV - test, evaluation, verification, and validation) and Part 2 - Core and Profiles (the four functions plus how to build Profiles).

The seven characteristics of trustworthy AI

Every function ultimately serves these seven characteristics (AIRC - Characteristics). They are not co-equal: Valid and Reliable is foundational (the others build on it), and Accountable and Transparent cuts across all the rest.

#	Characteristic	What it demands
1	Valid and Reliable (foundational)	The system does what it claims, repeatably, under real conditions
2	Safe	It does not, under defined conditions, endanger life, health, property, or environment
3	Secure and Resilient	It withstands adversarial attack and recovers - the security characteristic this book targets
4	Accountable and Transparent (cross-cutting)	Someone is answerable; the system’s behavior is disclosed and traceable
5	Explainable and Interpretable	Its mechanisms and outputs can be understood and reasoned about
6	Privacy-Enhanced	It safeguards autonomy, identity, and dignity in how it handles data
7	Fair - with Harmful Bias Managed	It manages the three bias types in SP 1270: systemic, computational/statistical, and human-cognitive

Security is characteristic #3 - but it touches all seven

Most of this book lives under “Secure and Resilient,” but the boundaries blur: a prompt injection that leaks training data is a privacy failure (#6); a jailbreak that produces hateful content is a safety failure (#2); a model that cannot explain a denied loan is an explainability failure (#5). The RMF’s discipline is to name which characteristic a finding threatens, because that determines who owns the fix.

The Core - four functions

The Core is where the work happens. Below is the full structure with every category and subcategory ID, verified against the AIRC Core (Section 5). Read GOVERN as the always-on culture layer, and MAP -> MEASURE -> MANAGE as the per-system loop that runs inside it.

GOVERN (6 categories / 19 subcategories) - cross-cutting

Cultivate a risk-management culture: policies, accountability, workforce, and third-party discipline. This is the operating system the other three functions run on.

Category	Subcategories (abbreviated)
GV-1 Policies & processes	1.1 legal/regulatory understood · 1.2 trustworthiness in policy · 1.3 risk-management level matched to risk tolerance · 1.4 transparent process · 1.5 monitoring & periodic review + roles · 1.6 AI system inventory · 1.7 safe decommissioning
GV-2 Accountability structures	2.1 roles/responsibilities documented · 2.2 AI risk training · 2.3 executive responsibility
GV-3 Workforce diversity & oversight	3.1 diverse team · 3.2 human-AI oversight roles defined
GV-4 Risk-aware culture	4.1 safety-first mindset · 4.2 document risks & impacts · 4.3 testing/incident/info-sharing
GV-5 Engagement with AI actors	5.1 collect external feedback · 5.2 integrate adjudicated feedback
GV-6 Third-party / supply-chain	6.1 third-party risk incl. IP · 6.2 high-risk contingency

MAP (5 categories / 18 subcategories)

Establish context and decide whether to proceed at all. The output of MAP is a documented, evidence-based decision to build (or not).

Category	Subcategories (abbreviated)
MP-1 Context established	1.1 intended purpose/laws/settings · 1.2 interdisciplinary actors · 1.3 mission/goals · 1.4 business value · 1.5 risk tolerances · 1.6 socio-technical requirements
MP-2 Categorization	2.1 tasks/methods (classifier/generative/recommender) · 2.2 knowledge limits & human oversight · 2.3 scientific integrity & TEVV
MP-3 Benefits & costs	3.1 benefits · 3.2 costs incl. non-monetary · 3.3 targeted scope · 3.4 operator proficiency · 3.5 human oversight
MP-4 Risks incl. third-party	4.1 legal/IP mapping · 4.2 internal risk controls
MP-5 Impacts characterized	5.1 likelihood x magnitude · 5.2 regular AI-actor engagement

MEASURE (4 categories / 22 subcategories)

Analyze, benchmark, and monitor - the TEVV function. This is the largest function by subcategory count, because “you cannot manage what you do not measure.”

Category	Subcategories (abbreviated)
MS-1 Methods & metrics	1.1 select for top risks + document what can’t be measured · 1.2 assess metric appropriateness · 1.3 independent assessors
MS-2 Evaluate trustworthy characteristics	2.1 TEVV test sets · 2.2 human-subject protection · 2.3 deployment-like conditions · 2.4 monitor in production · 2.5 valid & reliable · 2.6 safe incl. fail-safe · 2.7 security/resilience · 2.8 transparency/accountability · 2.9 explainability · 2.10 privacy · 2.11 fairness/bias · 2.12 environmental · 2.13 TEVV effectiveness
MS-3 Track risks over time	3.1 emergent risks · 3.2 hard-to-measure risks · 3.3 user/community feedback & appeal
MS-4 Feedback on measurement	4.1 connect to deployment context · 4.2 validate via domain experts · 4.3 measurable improvements/declines

MS-2 is the red-team hook

Subcategory MS-2.7 (“security and resilience are evaluated and documented”) is where an AI red-team engagement earns its RMF keep. When you scope an engagement (VI.4 · AI red-team playbook), map every test to the characteristic it exercises - MS-2.7 for security, MS-2.6 for safety, MS-2.11 for bias - so the report reads as MEASURE evidence, not just a list of findings.

MANAGE (4 categories / 13 subcategories)

Prioritize, respond, and monitor - act on what MEASURE found.

Category	Subcategories (abbreviated)
MG-1 Prioritize & respond	1.1 proceed/deploy decision · 1.2 prioritize treatments · 1.3 response = mitigate/transfer/avoid/accept · 1.4 document residual risk
MG-2 Maximize benefit / minimize harm	2.1 resources + non-AI alternatives · 2.2 sustain value · 2.3 recover from unknown risk · 2.4 supersede/deactivate (kill switch)
MG-3 Third-party management	3.1 monitor third-party resources · 3.2 monitor pre-trained models
MG-4 Risk treatment & communication	4.1 post-deployment monitoring / IR / change mgmt · 4.2 continual improvement · 4.3 communicate incidents to affected communities

On the counts

Enumerating the Core gives 4 functions, 19 categories, and 72 subcategories (GV 6/19, MAP 5/18, MEASURE 4/22, MANAGE 4/13). NIST does not publish this as a headline number - it is derived by counting the released Core - so present it as “as enumerated,” not as an official NIST figure.

The AI RMF Playbook

The Playbook is the companion that turns the Core’s outcomes into action. It offers “suggested actions for achieving the outcomes laid out in the AI RMF Core,” keyed to each subcategory with three things: Suggested Actions, Transparency & Documentation questions, and References.

Crucially, NIST states the Playbook is “neither a checklist nor set of steps to be followed in its entirety” - you select the actions that fit your context and risk tolerance. It ships in PDF, CSV, Excel, and JSON and is updated roughly twice a year. Related companions include the Roadmap, Crosswalks (to ISO 42001, SP 800-53, EU AI Act, and more), and Profiles.

The Generative AI Profile (AI 600-1)

For any generative-AI system, layer the AI RMF: Generative Artificial Intelligence Profile - NIST AI 600-1 (DOI 10.6028/NIST.AI.600-1), published 26 July 2024 as a deliverable under Executive Order 14110 (AI 600-1 PDF). It is a cross-sectoral use-case profile: it does not replace the Core, it specializes it for GenAI.

Its suggested actions each carry an Action ID keyed to a function+subcategory (for example GV-1.3-004, MS-2.7-009), an AI-Actor-Task tag, and the specific GenAI risk(s) addressed - so every recommendation traces back to a Core subcategory. The Profile is organized around four primary considerations: Governance, Content Provenance, Pre-deployment Testing, and Incident Disclosure.

The twelve GenAI risk categories (verbatim from the final July 2024 publication):

#	Risk	#	Risk
1	CBRN Information or Capabilities	7	Human-AI Configuration
2	Confabulation (hallucination)	8	Information Integrity
3	Dangerous, Violent, or Hateful Content	9	Information Security
4	Data Privacy	10	Intellectual Property
5	Environmental Impacts	11	Obscene, Degrading, and/or Abusive Content
6	Harmful Bias or Homogenization	12	Value Chain and Component Integration

Now run the screen. This is the artifact the gate block calls “run the 12-risk screen” - one row per risk. Mark each Y/N, then name the control or eval that owns every Y. An N is not free: log a one-line reason under MAP (MP-4.1). Route the security-flavored rows through the same garak + PyRIT run that files as MS-2.7 evidence.

#	GenAI risk	Applies to us? (Y/N)	Core-function hook (which control/eval owns it)
1	CBRN Information or Capabilities		garak dangerous-capability probes -> MS-2.6 (safe / fail-safe)
2	Confabulation (hallucination)		grounded-output eval set -> MS-2.5 (valid & reliable)
3	Dangerous, Violent, or Hateful Content		PyRIT content probes -> MS-2.6 (safe)
4	Data Privacy		garak leakreplay (PII leak) -> MS-2.10 (privacy)
5	Environmental Impacts		compute / energy accounting -> MS-2.12 (environmental)
6	Harmful Bias or Homogenization		bias eval (SP 1270 three types) -> MS-2.11 (fairness / bias)
7	Human-AI Configuration		oversight-role design -> GV-3.2 + MP-2.2 (human oversight)
8	Information Integrity		content-provenance / watermark controls -> MS-2.8 (transparency)
9	Information Security		garak + PyRIT -> MS-2.7 (security / resilience)
10	Intellectual Property		IP / license mapping -> MP-4.1 + GV-6.1 (third-party incl. IP)
11	Obscene, Degrading, and/or Abusive Content		PyRIT abuse probes -> MS-2.6 (safe)
12	Value Chain and Component Integration		model / SBOM provenance -> GV-6.1 + MG-3.2 (monitor pre-trained models)

Any Y with an empty hook is an open gap that MG-1.1 cannot clear - it holds the deploy decision until a control is attached or a signed MG-1.4 residual-risk acceptance names who owns it.

Cite the final labels, not the draft

The April 2024 draft used different labels (for example “Toxicity, Bias, and Homogenization”) and some secondary summaries report “13 risks” or “400+ actions.” The final publication has twelve risk categories, exactly as listed above. Re-count any action total from the released tables before quoting a figure.

How to operationalize each function

The framework is only useful if it changes what you do. Here is the working translation of each function into concrete practice.

The Core tables above are the full map. What you actually operate is a much shorter list of gates and one tooling hook - the decision-critical subcategories, not all 72:

NIST AI RMF - the gates you actually operate

# GOVERN gates (always on)
build risk-tiered AI inventory              # GV-1.6  <- can't govern what you can't see
set risk-tolerance go/no-go gates           # GV-1.3  <- the gate that blocks a launch

# MEASURE hook - where the red-team earns its keep
run garak + PyRIT against the target, then
file the results as MS-2.7 evidence         # MS-2.7  security/resilience evaluated & documented

# MANAGE gates - turn test results into a defensible decision
evidence-based deploy decision              # MG-1.1  <- proceed / hold
document residual risk (signed off)         # MG-1.4  <- what you accepted and who owns it
kill switch / deactivation path             # MG-2.4  <- can you pull it in production?

# FOR GENERATIVE AI: layer AI 600-1
run the 12-risk screen; apply actions under
Governance / Content Provenance / Pre-deployment Testing / Incident Disclosure
tracing every Action ID back to its Core subcategory

The three gates that matter most

If you remember only three subcategories, remember the gates: GV-1.3 (set risk tolerance), MG-1.1 (the evidence-based deploy decision), and MG-1.4 (document residual risk). Together they are the mechanism that turns a pile of test results into a defensible launch-or-hold decision - the thing a board, a regulator, and an incident post-mortem all want to see.

Where NIST RMF hands off

The RMF tells you how to reason about risk; it deliberately does not tell you which controls to build (that is SAIF) or give you an auditable certificate (that is ISO/IEC 42001, in VIII.4 · ISO/IEC 42001, verification & maturity). NIST publishes an official RMF -> ISO/IEC 42001 crosswalk precisely so the two stack. See the full one-finding-many-frameworks map in VIII.1 · Frameworks & standards.