NIST AI RMF Guide

Many organisations say they "follow the NIST AI RMF", but few can show which of its 72 subcategories they meet, for which AI systems, and with what evidence. The NIST AI Risk Management Framework (AI RMF 1.0, published as NIST AI 100-1 on 26 January 2023) is a widely referenced voluntary framework for managing AI risk and a common starting point for US organisations and for anyone who needs a neutral risk vocabulary that sits alongside ISO/IEC 42001 and the EU AI Act. This guide explains the seven characteristics of trustworthy AI, the four functions and their categories, the Playbook, profiles including the Generative AI Profile (NIST AI 600-1), measurement, crosswalks and a phased way to implement it. It is written for AI risk owners, security and GRC teams, and platform engineers who have to turn the framework into controls and evidence. Facts on revision activity were checked on nist.gov in October 2026.

Key takeaways

• It is outcome-based and voluntary. NIST describes the framework as "voluntary, rights-preserving, non-sector-specific, and use-case agnostic"; it says what good looks like, not how to build it, and it does not prescribe risk tolerance.
• GOVERN is the foundation. NIST calls GOVERN "a cross-cutting function"; without the inventory (GOVERN 1.6), roles (GOVERN 2) and third-party policies (GOVERN 6), MAP, MEASURE and MANAGE have nothing to attach to.
• The Core is 19 categories and 72 subcategories. GOVERN has 19 subcategories, MAP 18, MEASURE 22 and MANAGE 13; the Playbook adds suggested actions for each one and is "neither a checklist nor set of steps to be followed in its entirety".
• Generative AI needs the profile. NIST AI 600-1 (July 2024) adds 12 generative AI risks and numbered actions such as MS-2.7-007 for red-teaming against prompt injection and data poisoning.
• Version 1.0 is being revised. As of October 2026 NIST states that "The AI RMF 1.0 is being revised as part of the White House AI Action Plan"; build your programme on the stable structure (functions, categories, characteristics) and track wording changes.

What the AI RMF is, and the documents around it

AI 100-1 has two parts. Part 1 frames AI risk, the AI lifecycle and its "AI actors", and the characteristics of trustworthy AI. Part 2 is the Core: four functions broken into categories and subcategories that describe outcomes. NIST calls it "a living document" and says "a review with formal input from the AI community is expected to take place no later than 2028". In practice the companion documents matter as much as the core text.

The seven characteristics of trustworthy AI

The characteristics are the "what" that the functions manage. NIST states that "Valid & Reliable is a necessary condition of trustworthiness", and that Accountable and Transparent "relates to all other characteristics". Each has a matching MEASURE 2 subcategory, which is the most practical way to turn them into tests.

MEASURE 2.12 adds environmental impact, and MEASURE 2.13 asks whether the TEVV (test, evaluation, verification and validation) metrics themselves are effective. The characteristics trade off against each other (privacy techniques can reduce accuracy), so record each trade-off and who approved it.

The Core: functions, categories and subcategories

GOVERN

• Legal and policy baseline: GOVERN 1.1 asks that "Legal and regulatory requirements involving AI are understood", and GOVERN 1.2 that the trustworthy characteristics are integrated into policies.
• Risk appetite drives effort: GOVERN 1.3 sets the level of risk management activity from risk tolerance; GOVERN 1.5 plans periodic review.
• Inventory and exit: GOVERN 1.6 requires "Mechanisms ... to inventory AI systems" and GOVERN 1.7 processes "for decommissioning and phasing out AI systems safely".
• Testing culture: GOVERN 4.3 asks for practices that "enable AI testing, identification of incidents, and information sharing".
• Suppliers: GOVERN 6.1 addresses "AI risks associated with third-party entities" and GOVERN 6.2 requires contingency processes for failures in high-risk third-party data or systems.

MAP

• Context first: MAP 1.1 records intended purpose, users and setting; MAP 1.5 states "Organizational risk tolerances are determined and documented".
• Operators and oversight: MAP 3.4 covers operator proficiency and MAP 3.5 human oversight processes.
• Components and legal risk: MAP 4.1 maps technology and legal risks of all components, including third-party data, software and intellectual property.
• Impact: MAP 5.1 documents the "Likelihood and magnitude of each identified impact", beneficial and harmful.

MEASURE

• Measure the biggest risks first: MEASURE 1.1 starts "with the most significant AI risks" and documents those that cannot be measured.
• Independence: MEASURE 1.3 brings in "Internal experts who did not serve as front-line developers" or independent assessors.
• Production, not just the lab: MEASURE 2.3 tests under conditions similar to deployment and MEASURE 2.4 monitors behaviour in production.
• Emergent risk and appeals: MEASURE 3.1 tracks "existing, unanticipated, and emergent AI risks"; MEASURE 3.3 gives end users and affected communities a route to report problems and appeal.

MANAGE

• Go or no-go: MANAGE 1.1 decides whether the system achieves its purpose and whether to proceed; MANAGE 1.3 chooses responses: "mitigating, transferring, avoiding, or accepting".
• Residual risk disclosure: MANAGE 1.4 documents negative residual risks for downstream acquirers and end users.
• Switch-off: MANAGE 2.4 assigns responsibility "to supersede, disengage, or deactivate" systems behaving outside intended use.
• Third parties: MANAGE 3.1 monitors third-party resources and MANAGE 3.2 pre-trained models.
• After deployment: MANAGE 4.1 implements monitoring plans including appeal and override, incident response and decommissioning; MANAGE 4.3 communicates incidents and errors to relevant actors.

For unacceptable risk NIST says "development and deployment should cease in a safe manner until risks can be sufficiently managed". Write that into the approval process.

Profiles and the Generative AI Profile

A profile tailors the Core to a context. NIST defines use-case profiles, temporal profiles (a Current Profile showing "how AI is currently being managed" and a Target Profile showing the outcomes needed) and cross-sectoral profiles for models or applications used across sectors. The gap between Current and Target is your roadmap.

NIST AI 600-1 is a cross-sectoral profile for generative AI. It identifies 12 risks "unique to or exacerbated by" generative AI and four primary considerations: Governance, Content Provenance, Pre-deployment Testing and Incident Disclosure. Its actions use function prefixes (GV, MP, MS, MG) plus the subcategory and a sequence number.

The others are Data Privacy, CBRN Information or Capabilities; Dangerous, Violent, or Hateful Content; Environmental Impacts; Harmful Bias and Homogenization; Intellectual Property; and Obscene, Degrading, and/or Abusive Content. GV-1.5-002 asks for after-action reviews of generative AI incidents. For prompt injection see the Prompt Injection Guide.

Measurement and TEVV

NIST treats TEVV as "a regular process within an AI lifecycle" that "allows for both mid-course remediation and post-hoc risk management". It also lists why AI risk is hard to measure: risks from third-party software, hardware and data; tracking emergent risks; availability of reliable metrics; risk at different lifecycle stages; risk in real-world settings; inscrutability; and the lack of a human baseline. Design the measurement plan around those gaps.

• Pre-deployment: document test sets, metrics and tools (MEASURE 2.1), test under deployment-like conditions (MEASURE 2.3) and record the threshold each characteristic must meet before release.
• Adversarial: red-team generative and agentic systems (MS-2.7-007) with agreed scope and containment. See Red Teaming AI Agents for Identity Abuse.
• In production: log inputs, outputs, tool calls and overrides (MEASURE 2.4); watch for drift against the pre-deployment baseline; route user complaints and appeals into the risk register (MEASURE 3.3).
• Meta-measurement: review yearly whether the metrics still predict real-world harm (MEASURE 2.13, MEASURE 4).

Metrics that show the programme is working:

• Inventory coverage: percentage of discovered AI systems registered with an owner and risk tier.
• Gate compliance: percentage of high-risk systems released with completed MAP 5.1 impact assessment and MEASURE 2 test evidence.
• Red-team closure: median days to fix high-severity red-team findings.
• Override and appeal rate: human overrides and upheld appeals per 1,000 decisions, trended per system.
• Kill switch drills: percentage of high-risk systems with a tested MANAGE 2.4 deactivation in the last 12 months.

Crosswalks and framework mapping

The Resource Center publishes crosswalks that "map concepts between the AI RMF and other guidelines, frameworks, and standards", with the caveat that inclusion "does not imply NIST endorsement" or that either document fully covers the other. The ISO/IEC 42001 crosswalk was drafted against the FDIS text, so confirm clause numbers against the published standard. Its mappings include:

NIST's only EU crosswalk (OECD, EU and EO 13960, January 2023) predates the final AI Act. The table below is NHI Mgmt Group's own mapping to Regulation (EU) 2024/1689 as amended by the Digital Omnibus on AI, and to NIST CSF 2.0. It shows where evidence can be reused, not that the AI RMF satisfies the Act.

For how these sit in an operating model see the AI Governance Guide, and for building one control set across frameworks the Control Mapping Guide.

Choosing how to use the AI RMF

• AI RMF alone: suits organisations that need a free, credible risk vocabulary and are not yet asked for certification or EU conformity.
• AI RMF plus ISO/IEC 42001: choose when customers ask for a certifiable management system. Use the AI RMF for risk content (what to assess and measure) and 42001 for the management system (scope, statement of applicability, internal audit, management review).
• AI RMF for the EU AI Act: the functions map well to provider and deployer obligations, but the Act's duties, deadlines and conformity assessment must still be met on their own terms.
• Small organisations: one accountable owner, a Current and Target Profile covering GOVERN 1, GOVERN 6, MAP 1, MEASURE 2.7 and MANAGE 2.4, and the Playbook as a reference rather than a checklist.
• Large organisations: use-case profiles per business line, an independent central MEASURE team (MEASURE 1.3), and Playbook actions imported from the JSON or CSV release into the GRC tool with owners per subcategory.

Implementing the AI RMF

1. Set the scope and appetite: agree which AI systems are in scope (built, bought, embedded in SaaS, agents) and document risk tolerances (GOVERN 1.3, MAP 1.5).
2. Build the inventory: register each system with owner, purpose, model and version, data sources, third parties and access (GOVERN 1.6). See the Shadow AI Discovery Guide.
3. Write the Current Profile: score each subcategory for a pilot set of three to five systems of different risk levels; note evidence or its absence.
4. Define the Target Profile by tier: high-risk systems need all MEASURE 2 subcategories evidenced; low-risk ones may need only GOVERN, MAP 1 and MANAGE 2.4.
5. Pilot the gates: run the MAP impact assessment and MEASURE test plan on the pilot systems before their next release, and fix the templates.
6. Roll out by tier: new high-risk systems first, then existing ones at their next significant change, then lower tiers.
7. Prove the exit: test MANAGE 2.4 deactivation for each high-risk system, including revoking its credentials and integrations, and document rollback to the previous model version or manual process.
8. Review and adapt: review the profile at least annually (GOVERN 1.5) and when NIST publishes the revised AI RMF or updated Playbook.

Where identity fits

An inventory entry (GOVERN 1.6) is incomplete without the service accounts, API keys and OAuth grants an AI system uses; deactivation (MANAGE 2.4) and decommissioning (GOVERN 1.7) only work if those credentials are revoked too; and MEASURE 2.7 testing should cover what an agent can reach, not just what the model says. Treat each agent as a non-human identity with an owner, least privilege and short-lived credentials. See the Agentic AI Identity Guide and the AI Agent Authorisation Guide.

Common failure patterns

• Policy without inventory: GOVERN 1 documents exist but GOVERN 1.6 does not, so nobody can prove the gates ran.
• Measuring the model, not the system: benchmarks pass while the deployed agent holds broad credentials. The PocketOS database deletion shows an AI coding agent using an over-privileged token to wipe production, a MAP 4 and MANAGE 2.4 failure as much as a model one.
• Uncontained testing: red-team and evaluation environments that can reach real targets turn MEASURE activity into an incident; the Anthropic Claude evaluation incidents involved misconfigured cyber tests that reached real organisations.
• Ignoring third-party AI: GOVERN 6 and MANAGE 3 skipped for SaaS AI features. The McHire default password flaw exposed applicant data through a supplier's AI hiring platform.
• No prompt injection testing: generative systems connected to untrusted content without MS-2.7-007 style testing, as in ForcedLeak.
• Treating the Playbook as a checklist: teams try to evidence every suggested action for every system and stall.

Practitioner checklist

• Record which AI RMF version and Playbook release your profile uses, and review it when NIST publishes the revision.
• Maintain an AI inventory with owner, tier, model version, third parties and the identities each system uses.
• Document risk tolerances and the rule that unacceptable risk stops development or deployment.
• Write a Current and Target Profile for each risk tier and track the gap as a roadmap.
• Map each MEASURE 2 characteristic to a named test, threshold and evidence location.
• Apply NIST AI 600-1 actions to generative AI, including red-teaming for prompt injection and data poisoning in a contained environment.
• Test deactivation and credential revocation for every high-risk system at least once a year.
• Review third-party models and AI SaaS under GOVERN 6 and MANAGE 3 before purchase and at renewal.

Standards and references

• NIST: AI 100-1 Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• NIST: AI Risk Management Framework
• NIST Trustworthy and Responsible AI Resource Center: AI RMF Playbook
• NIST: AI 600-1 Generative Artificial Intelligence Profile
• NIST Trustworthy and Responsible AI Resource Center: Crosswalks
• NIST AIRC: NIST AI RMF to ISO/IEC 42001 Crosswalk
• NIST: IR 8596 Cyber AI Profile (initial preliminary draft)
• The White House: America's AI Action Plan

Related NHI Mgmt Group resources: AI Governance Guide · AI Guardrails and AI Firewalls Guide · LLM Security Guide · Agentic AI Compliance Guide · Control Mapping Guide