NIST AI RMF: Govern, Map, Measure, Manage Explained
The NIST AI Risk Management Framework is the US government's recommendation for organizations seeking a structured approach to AI risk. It was published in January 2023, mandated by the National AI Initiative Act of 2020, and developed through a public consultation process that ran through early 2023.
The framework is voluntary and non-certifiable. Nobody can audit you against it, and you can self-claim alignment, which is where ISO 42001 comes in as the certifiable counterpart. What RMF gives you is a shared vocabulary.
NIST also publishes a companion document called the AI RMF Playbook. The framework itself is about 40 pages of principles. The Playbook runs over 140 pages of suggested actions, transparency questions, and reference resources for each piece of the framework. If you only read the framework, you get the abstractions, while most of the operational guidance is in the Playbook.
This article walks through the four functions at the heart of the framework, using Playbook content to sharpen what each function actually requires.
The four functions at a glance
The NIST AI RMF organizes everything around four functions: GOVERN, MAP, MEASURE, and MANAGE. They aren’t sequential steps. They’re roles in a system that runs continuously.
GOVERN sits across the whole framework. It’s the organizational foundation: policies, accountability, culture, and oversight that make the other three functions possible. MAP, MEASURE, and MANAGE, then run in a loop. MAP establishes the context for understanding a specific AI system. MEASURE tests it against the trustworthiness characteristics NIST defines. MANAGE turns those measurements into prioritization decisions, kill-switch procedures, and disclosures to affected parties. The outputs of all three feed back into GOVERN, which uses them to update policies, roles, and culture over time. The framework is iterative, not linear.
Here is what each function covers:
GOVERN (cross-cutting). Cultivates a risk-aware culture. Key elements: policies and processes, accountability, workforce diversity, organizational culture, engagement with AI actors, and third-party and supply-chain oversight.
MAP (framing). Establishes context and identifies risks before they can be measured. Key elements: context, system categorization, capabilities and goals, risk and benefit mapping, and impact characterization.
MEASURE (analysis). Analyzes and monitors AI risks. Key elements: methods and metrics, evaluation of trustworthy characteristics, risk tracking, and efficacy feedback.
MANAGE (response). Prioritizes and responds to what MAP and MEASURE surface. Key elements: prioritization and response, benefit and impact strategies, third-party management, and risk treatment and communication.
GOVERN
GOVERN is where the framework starts and where most organizations underinvest. It’s the function that establishes who’s responsible for what, what risks the organization is willing to take, how AI work fits into existing accountability structures, and how culture supports raising concerns rather than burying them.
Two concrete examples make GOVERN tangible. First, NIST requires you to maintain an inventory of your AI systems, with a named individual or team responsible for keeping it up to date. This is the AI equivalent of a CMDB (Configuration Management Database). Right now, most teams don’t have one, but I don’t think the reason is laziness. Employees are provisioning AI agents through personal accounts and unmonitored API integrations faster than any central registry can keep up. When you connect an AI agent to Google Drive or Slack via MCP, the OAuth prompt goes to the individual employee. The result is direct app-to-app access that bypasses the corporate identity provider entirely, leaving the security team with no visibility into what was authorized or by whom. You can’t manage what you haven’t cataloged, and you can’t catalog what was provisioned without you.
Second, NIST requires a written policy for the safe decommissioning of AI systems before you deploy them. The Playbook lists what those policies must address: user and community concerns; business continuity and financial risks; upstream and downstream system dependencies; regulatory requirements, such as data retention; future legal or forensic investigations; reputational risk; and migration to a replacement system. NIST treats decommissioning as a governance decision. Engineering executes the policy.
Governance gaps here invalidate downstream measurements. If you don’t know what you’re running, you can’t understand/measure/secure it.
MAP
MAP is about context. Before you measure an AI system’s performance or risk, you have to understand what it’s supposed to do, who’s affected by it, where it operates, and what the organization considers an acceptable level of risk for that deployment.
The most operationally important piece of MAP is risk tolerance. NIST requires you to determine and document organizational risk tolerances before deployment. The Playbook makes this concrete by requiring maximum allowable risk thresholds above which the system won’t be deployed (or will need to be decommissioned), with explicit criteria established in advance. Production AI deployments that don’t have this end up making risk decisions after the fact, when problems surface, rather than before, when the criteria can be set without pressure.
MAP also begins the stakeholder picture. NIST names “affected communities” (i.e., people who will be impacted by the system but don’t use it directly) as required participants in establishing system context (MAP 1.6) and in evaluating benefits and costs (MAP 3.1, MAP 3.2). The operational consultation work happens later, in MEASURE.
If GOVERN is the substrate, MAP is the framing. You can’t measure what you haven’t framed.
MEASURE
MEASURE is the largest function in the framework and the most technically detailed. It evaluates an AI system against seven trustworthiness characteristics: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed.
The seven sound abstract until you read what they require. Take “secure and resilient.” Traditional cybersecurity controls aren’t enough for AI. The Playbook names specific operational metrics such as “time-to-bypass” (how long it takes a determined attacker to defeat the system’s safeguards), red-team exercise frequency, and anomalous event rates. For per-vulnerability severity scoring, OWASP’s AIVSS extends CVSS v4.0 with an agentic uplift model that handles prompt injection and model jailbreaks. NIST’s contribution in MEASURE 2.7 is the operational test-and-measurement side, which AIVSS doesn’t cover.
MEASURE also distinguishes between transparency, explainability, and interpretability. They sound similar and get used interchangeably, but they mean different things. Transparency is what happened (visible outputs and audit trails). Explainability is how the model reached a decision. Interpretability is whether the explanation actually means something to the person reading it. A model can be technically explainable to a data scientist while being completely uninterpretable to the loan applicant whose application it just denied.
MEASURE is also where NIST widens the stakeholder picture from MAP. The Playbook is specific about where this shows up. Fairness metrics for MEASURE 2.11 are to be developed “in collaboration with affected communities.” MEASURE 3.3 requires feedback processes for impacted communities to report problems and unexpected behaviors. These are people affected by the system who don’t use it directly, such as loan applicants under an automated underwriting model or job candidates screened by a resume parser.
This is where most of the technical AI risk work lives.
MANAGE
MANAGE is where measurements become organizational action. Two requirements stand out.
First, NIST requires established procedures for superseding, disengaging, or deactivating AI systems that demonstrate performance or outcomes inconsistent with their intended use. This is the kill switch. The Playbook requires you to identify the incident thresholds that trigger deactivation, plan for redundant systems to ensure continuity when the AI is offline, and review the procedures regularly. This is likely another production AI deployment area that’s deficient for many companies.
Second, NIST requires a database of reported errors, near-misses, incidents, and negative impacts, with date reported, impact assessment, and responses. Plus a separate database of system changes, with rationale, test procedures, and version history. This is the AI equivalent of a vulnerability tracker and a change log. Industry references already exist for what these look like at scale: the AI Vulnerability Database catalogs failures across the AI ecosystem, and MITRE ATLAS maps the adversarial TTPs that incidents are likely to fall under.
MANAGE is where the framework meets production reality, and where the Playbook’s content gets the most operationally specific.
Is there a NIST AI RMF 2.0 or a 2026 version?
Short answer: no. As of 2026, AI RMF 1.0 (NIST AI 100-1, January 2023) is still the current core framework. NIST has said the framework is being revised, but no 2.0 has been released.
What confuses a search is that NIST extends the framework through Profiles, not new version numbers. The Generative AI Profile (NIST AI 600-1, July 2024) applies the four functions to generative AI risk, and that is the document most people mean when they ask about a “2024 version.” A Trustworthy AI in Critical Infrastructure Profile followed as a concept note in April 2026. So if you see “2023,” “2026,” or “1.0” attached to the same four functions, they all point back to the same core document, and the functions themselves have not changed.
How to use this if you’re leading an AI initiative
Read NIST AI RMF as an engineering spec, not a compliance document. Voluntary and non-certifiable looks like a weakness if you’re looking for something to audit against. It looks different if you’re looking for a complete public taxonomy of AI risk work, which is what RMF actually is. The depth is hard to recreate in private, which is why US financial regulators have built directly on it.
The Financial Services AI RMF, released by the Cyber Risk Institute in February 2026 and backed by the US Treasury and over 100 financial institutions, layers 230 control objectives onto NIST’s structure.
Practically, the framework is most useful as a structural vocabulary for cross-team conversations. It gives you a way to ask “what’s our documented risk tolerance for this deployment” or “do we have a decommissioning policy” without having to re-explain what an “AI risk” even means.
It’s not a checklist. The implementation tiers are directional rather than scored, and there is no audit procedure to certify which tier you’re at.
The Playbook is where value compounds, but you don’t have to read 140 pages cover to cover. Pull from it when you have a specific decision to make, like setting up an incident database or defining a kill-switch procedure. The framework points you at the question. The Playbook helps you build the answer.
One piece of practitioner advice worth ending on. The framework presents GOVERN first, but experienced implementers often suggest starting with MAP instead. Governance written without a current inventory governs imaginary systems. Run a discovery sprint first. Inventory the AI you’re already running, including the SaaS features that quietly added AI and the agents operating under employee credentials. Then write the GOVERN layer with specific reference to what you found. Your decision-rights matrix is a different document when “Slack now ships an AI summarizer that twelve of our teams use” is in the inventory.
Both documents are at nist.gov/itl/ai-risk-management-framework.
Frequently asked questions
What are the four functions of the NIST AI RMF?
Govern, Map, Measure, and Manage. Govern is cross-cutting, and the other three run in rough lifecycle order.
Is the NIST AI RMF mandatory?
No. It is voluntary, non-certifiable, and not sector-specific. It carries weight in US regulatory and procurement settings because of NIST’s authority, the same way the NIST Cybersecurity Framework became a de facto standard.
What is the difference between NIST AI RMF and ISO 42001?
NIST AI RMF is a voluntary framework for how to manage AI risk. ISO/IEC 42001 is a certifiable management system you can be audited against. Many teams use NIST for the risk taxonomy, then map to ISO 42001.
Does Govern come first?
It is listed first because it is cross-cutting, but many practitioners start with Map so governance reflects a real inventory of AI systems.
Is there a NIST AI RMF for generative AI?
Yes. The Generative AI Profile (NIST AI 600-1, July 2024) applies the four functions to generative AI risk.