Lesson 1 of 7 · 7 min read
The NIST AI Risk Management Framework
In this lesson
TL;DR: The NIST AI RMF 1.0 (published January 2023) is a voluntary framework built on four functions. Govern: policies, accountability, roles, culture, applied across everything. Map: understand each system's context, intended use, stakeholders and risks. Measure: assess those risks with tests, metrics and evaluation, including security testing and red teaming. Manage: prioritise and treat risks, respond to incidents and monitor over time. It names characteristics of trustworthy AI, among them secure and resilient, valid and reliable, safe, privacy-enhanced and accountable and transparent. NIST AI 600-1 (July 2024) adds a Generative AI Profile. As of November 2026 the framework is still version 1.0; NIST is revising it following the July 2025 US AI Action Plan.
Before you read
Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.
1A company says it is 'NIST AI RMF certified'. What is wrong with that claim?
What it is for
AI systems create risks that traditional security and compliance processes were not designed for: probabilistic behaviour, data-driven failures, harms to people outside the organisation, and fast-changing capabilities. NIST released the AI RMF in January 2023, after public drafts and workshops, to give organisations a common structure for identifying and managing those risks. It is voluntary, sector-neutral and written for any organisation designing, developing, deploying or using AI.
The four functions
Govern
Policy, roles, accountability
Map
Context, use, risks
Measure
Test, evaluate, track
Manage
Prioritise, treat, respond
Govern underpins everything
Policies, roles, risk tolerance and accountability apply across the lifecycle and to every other function.
| Function | What it asks | Engineering examples |
|---|---|---|
| Govern | Who is accountable? What are our policies and risk tolerance? How do we oversee third parties? | AI policy, owners per system, review boards, training, vendor requirements |
| Map | What is this system for, who is affected, what could go wrong, in what context? | AI use-case register entry, intended use, data sources, threat model |
| Measure | How big are those risks, and how do we know? | Evaluations, red teaming, bias testing, security testing, monitoring metrics |
| Manage | What do we do about them, and what happens when things go wrong? | Controls, release gates, risk acceptance, incident response, decommissioning |
Each function breaks into categories and subcategories (outcomes), and NIST publishes a companion Playbook with suggested actions for each.
The Core's actual shape
The four functions break down into 19 categories and 72 subcategories, each an outcome with an identifier such as MEASURE 2.7. GOVERN has 6 categories and 19 subcategories, MAP 5 and 18, MEASURE 4 and 22 (MEASURE 2 alone runs from 2.1 to 2.13), and MANAGE 4 and 13. A handful of subcategories are the ones security engineers end up owning:
| Subcategory | Outcome (paraphrased) | What a security team produces |
|---|---|---|
| MAP 4.1 | Risks from third-party components, including data and models, are mapped | Vendor and model review, with contingency for supplier changes |
| MEASURE 1.3 | Assessments involve experts who were not the front-line developers, or independent assessors | A red team that is not the feature team |
| MEASURE 2.7 | AI system security and resilience are evaluated and documented | Prompt-injection, extraction and poisoning testing with results on file |
| MANAGE 1.3 | Responses to high-priority risks are chosen: mitigate, transfer, avoid or accept | A decision record per risk, with the control chosen |
| MANAGE 1.4 | Negative residual risks to downstream users are documented | A residual-risk statement with an owner |
| MANAGE 2.4 | Mechanisms exist to supersede, disengage or deactivate systems with inconsistent outcomes | Kill switches, per feature or per tool, with named people allowed to use them |
| MANAGE 4.3 | Incidents and errors are communicated, tracked and recovered from | The AI incident response playbook |
The Generative AI Profile, NIST AI 600-1 (July 2024), applies the Core to generative systems: 12 risks (including information security, data privacy, confabulation and harmful content) and over 200 suggested actions with identifiers like GV-1.5-002, organised around four primary considerations: governance, content provenance, pre-deployment testing and incident disclosure.
Trustworthy AI characteristics
The framework describes characteristics a trustworthy system should balance: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful bias managed. For security engineers, "secure and resilient" is the direct hook: it covers attacks such as data poisoning, evasion and model extraction, and the ability to withstand and recover from them.
Profiles
Profiles apply the framework to a context. NIST AI 600-1, the Generative AI Profile (July 2024), lists risks that are new or amplified by generative AI, including information security risks such as prompt injection and data poisoning, confabulation, data privacy and harmful content, with suggested actions mapped to the four functions. Organisations can write their own profiles for their sector or use cases.
How it relates to other frameworks
The AI RMF is not a regulation and not a certification scheme. It complements ISO/IEC 42001, which defines a certifiable AI management system, and helps with obligations under laws such as the EU AI Act, though aligning with one does not automatically satisfy the others. NIST also publishes crosswalks mapping the RMF to other standards.
Making it real
The RMF fails when it becomes a document exercise. It works when each subcategory points to something engineers do:
- Map produces an AI use-case register entry and a threat model for every system.
- Measure produces evaluation and red team results stored with the system's record.
- Manage produces release gates, risk acceptances with owners and dates, and incident playbooks.
- Govern produces named owners, review cadences and training records.
Worked example: one feature mapped to the Core
A support agent reads customer emails and can issue refunds of up to $200. Each subcategory ends in an artefact an auditor can open:
| Subcategory | Artefact |
|---|---|
| MAP 1.1, context and intended use | Register entry describing users, data and the refund capability |
| MAP 4.1, third-party components | Review of the model provider's terms, retention and change notices |
| GOVERN 1.3, risk tolerance | The decision that refunds above $50 need human approval |
| MEASURE 2.7, security and resilience | Injection red-team report: 4 hijacks in 300 attempts, about 1.3% (95% Wilson interval 0.5% to 3.4%) |
| MEASURE 1.3, independent assessment | The red team reports outside the feature team |
| MANAGE 1.3, risk response | Deterministic refund cap and approval threshold in the tool |
| MANAGE 1.4, residual risk | Statement: some injections will succeed; impact bounded to $50 per refund without approval |
| MANAGE 2.4, deactivation | A per-tool switch that disables refunds within minutes |
| MANAGE 4.3, incident communication | Playbook entry for refund abuse, including customer notification |
- 1
1 · GOVERN
6 categories, 19 subcategories
- Risk tolerance: approval above $50
- Who may pull the kill switch
Sets the rules everything else follows
frames - 2
2 · MAP
5 categories, 18 subcategories
- Intended use and users
- Third-party model review
Finds the risks in context
feeds - 3
3 · MEASURE
4 categories, 22 subcategories
- Independent injection red team
- 1.3% hijack rate, interval reported
Puts numbers and evidence on them
informs - 4
4 · MANAGE
4 categories, 13 subcategories
- Refund cap in code
- Kill switch and incident playbook
Treats, records and responds
Govern and map
Tolerance and context decide which risks matter for this feature.
The wider NIST family (checked November 2026)
AI RMF 1.0 (January 2023) is being revised under the White House AI Action Plan, with no revised draft published yet. Around it sit NIST AI 100-2 E2025, the adversarial machine-learning taxonomy; the draft NIST AI 800-1 on managing misuse risk for dual-use foundation models; a concept note (April 2026) for an AI RMF profile for critical infrastructure; and work from the Center for AI Standards and Innovation (CAISI, formerly the US AI Safety Institute), including a 2026 request for information on security for AI agents and a summary of the responses.
Misconceptions interviewers listen for
- "NIST certifies AI RMF compliance." It is voluntary and not certifiable; ISO/IEC 42001 is the certifiable management system.
- "AI 600-1 replaces the RMF." It is a profile applied on top of the Core.
- "The RMF is a control catalogue." It describes outcomes; controls come from elsewhere.
- "MEASURE means accuracy benchmarks." MEASURE 2.7 is security and resilience, and MEASURE 1.3 asks for independence.
- "There is an AI RMF 2.0." As of November 2026 it is version 1.0, under revision.
What if · interview follow-ups
Hold your answer as the constraints change
Your company has adopted the NIST AI RMF and asks you, the security lead, to show how your work on an AI support agent fits it. The interviewer probes the mapping.
Start here
What if someone asks which function your red-team work supports?
Where do testing results go next?
MEASURE, particularly 2.7 for security and resilience and 1.3 for independent assessment; its results feed MANAGE decisions such as caps and approvals (1.3) and residual-risk statements (1.4), and new findings flow back into MAP. GOVERN sets the tolerance the results are judged against.
Carry it forwardTesting is evidence in a loop, not a box at the end.
Weak answerPlacing red teaming only under GOVERN as a policy item.
Constraint changes
What if an auditor asks where the kill switch is?
Which subcategory covers deactivation, and who may use it?
MANAGE 2.4 calls for mechanisms to supersede, disengage or deactivate systems. Point to a concrete switch, such as disabling the refund tool within minutes, the people authorised to use it under GOVERN roles, and the last time it was tested.
Carry it forwardAnswer framework questions with a named, tested mechanism.
Weak answerDescribing the kill switch as a policy without a mechanism.
Constraint changes
What if your model vendor changes the model every few weeks?
Which outcomes depend on the third party?
MAP 4.1 and the GOVERN third-party categories require mapping and contingency for supplier risk, and MEASURE results go stale with each change. Pin model versions, re-run the security evaluation on each change before switching, and record the vendor's change notices.
Carry it forwardThird-party model changes are risk events; re-measure before you adopt them.
Weak answerTreating the vendor's model as a fixed component.
Constraint changes
What if the red team reports 4 hijacks in 300 attempts?
What should the report say beyond 1.3%?
Report the interval, roughly 0.5% to 3.4% at 95% confidence, the attack set and whether it was adaptive, and the consequence of each success. Then show the MANAGE response: the cap that bounds each success, and the residual-risk statement with an owner.
Carry it forwardProbabilistic findings need intervals and consequences, and a management response on file.
Weak answerReporting the point estimate as if it were exact.
Constraint changes
What if leadership asks whether following the RMF makes you compliant with the EU AI Act?
Is the RMF a legal standard?
No. The RMF is voluntary and gives no presumption of conformity; it is a good structure for the risk-management work the Act requires, and its artefacts become evidence. Map Act obligations to the artefacts explicitly, and use harmonised standards where they exist.
Carry it forwardFrameworks organise evidence; regulations define obligations. Map one onto the other.
Weak answerEquating framework adoption with legal compliance.
Now defend it
As the defender, how would you keep the RMF mapping alive rather than a one-off document?
Tie each subcategory to an artefact with an owner and a review date, regenerate MEASURE evidence on every model, prompt or tool change, track MANAGE decisions and residual risks in the risk register, test deactivation mechanisms on a schedule, and review the mapping when the RMF revision is published.
How this shows up in interviews
Expect "what are the four functions, and how do you use each?" in governance-adjacent roles and as a follow-up in security interviews at regulated companies. Strong answers name the functions with concrete engineering outputs, mention the Generative AI Profile, state clearly that it is voluntary and not certifiable, and note its current version status.
Say it in 30 seconds: "The NIST AI RMF 1.0 from January 2023 is voluntary and organises AI risk work into Govern, Map, Measure and Manage. Govern sets policy, owners and risk tolerance across everything. Map is understanding each system's use, context and risks, which for me is the register entry and threat model. Measure is evaluations and red teaming. Manage is controls, release gates, risk acceptance and incident response. NIST AI 600-1 adds a generative AI profile. It's not certifiable; ISO 42001 is."
Check yourself
Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.
1Which function would a red team engagement and its results primarily support, and how should results flow onward?
2Why is 'Govern' drawn as underpinning the other three functions rather than as a step in sequence?
3How many categories and subcategories does the AI RMF Core have?
4Which AI RMF subcategory covers kill switches, and which covers security testing?