The NIST AI Risk Management Framework, explained in the order you would actually use it

The NIST AI Risk Management Framework, published as NIST AI 100-1 (AI RMF 1.0), organizes AI risk work into four functions: GOVERN, MAP, MEASURE and MANAGE. GOVERN runs once, organization-wide, and keeps running. The other three apply to each AI system, at each stage of its lifecycle. NIST itself describes the framework as voluntary, which matters when you compare it to binding law like the EU AI Act.

What the framework actually is

The heart of the document is the AI RMF Core. In NIST's words, the Core "provides outcomes and actions that enable dialogue, understanding, and activities to manage AI risks and responsibly develop trustworthy AI systems." Each of the four functions breaks down into categories, then subcategories, then specific actions and outcomes.

Read that structure correctly. It is a catalog of outcomes, not a procedure. NIST is explicit:

Actions do not constitute a checklist, nor are they necessarily an ordered set of steps.

So the framework does not tell you what to do on Monday. It tells you what a well-governed AI program produces, and leaves the sequencing largely to you. That said, NIST does suggest a practical order, and it starts with governance.

The four functions at a glance

Function	Scope	What it covers
GOVERN	The whole organization, continuously	Risk culture, policies, processes, accountability structures and documentation for managing AI risk
MAP	Each AI system, each lifecycle stage	Identifying the risks a specific system can pose in its context
MEASURE	Each AI system, each lifecycle stage	Assessing and tracking the risks that mapping surfaced
MANAGE	Each AI system, each lifecycle stage	Acting on measured risks: prioritizing and responding to them

The GOVERN row comes from the publication's own description. The other three rows paraphrase the plain meaning of the function names, which NIST uses as verbs: the functions exist "to govern, map, measure, and manage AI risks." The full category and subcategory text for each function sits in Part 2 of the publication, and the AIGP exam expects you to know the framework at that structural level, not to have memorized every subcategory.

Why GOVERN is different

The framework's own figure caption states the design principle directly:

Governance is designed to be a cross-cutting function to inform and be infused throughout the other three functions.

The body text repeats it. GOVERN "is a cross-cutting function that is infused throughout AI risk management and enables the other functions of the process." Aspects of GOVERN, "especially those related to compliance or evaluation, should be integrated into each of the other functions."

What does GOVERN contain? Per the publication, it cultivates a culture of risk management in organizations that design, develop, deploy, evaluate or acquire AI systems. It outlines the processes, documents and organizational schemes that anticipate, identify and manage the risks a system can pose, including to users and others across society. It incorporates processes to assess potential impacts. It connects the technical side of AI development to organizational values, and it addresses the full product lifecycle, including legal issues around third-party software, hardware and data.

Two points from the text are easy to miss. First, governance is top-down. Senior leadership "sets the tone for risk management within an organization, and with it, organizational culture." Second, GOVERN never finishes. NIST says it is "incumbent on Framework users to continue to execute the GOVERN function as knowledge, cultures, and needs or expectations from AI actors evolve over time."

The subcategories make it concrete. GOVERN 1.1 requires that legal and regulatory requirements involving AI are "understood, managed, and documented." GOVERN 1.3 requires processes to determine the needed level of risk management activity based on the organization's risk tolerance. These are organizational capabilities. You build them once and apply them to every system you touch.

The other three run per system, per lifecycle stage

MAP, MEASURE and MANAGE are where the per-system work happens. NIST frames the whole exercise as continuous: "Risk management should be continuous, timely, and performed throughout the AI system lifecycle dimensions." A system's risk profile is not fixed. What you mapped at design time changes at deployment, and changes again in operation. So you revisit the three applied functions at each lifecycle stage, for each system.

NIST also insists on who does this work. Core functions "should be carried out in a way that reflects diverse and multidisciplinary perspectives, potentially including the views of AI actors outside the organization." The stated reason is practical: a diverse team surfaces problems and identifies "existing and emergent risks" that a homogeneous team would miss.

The order you would actually use it

Here is the sequencing guidance in NIST's own words:

Assuming a governance structure is in place, functions may be performed in any order across the AI lifecycle as deemed to add value by a user of the framework. After instituting the outcomes in GOVERN, most users of the AI RMF would start with the MAP function and continue to MEASURE or MANAGE.

So the practical path is: stand up GOVERN first, then take each system through MAP, then MEASURE, then MANAGE. But note the qualifications. The order after GOVERN is a norm, not a rule. And NIST says the process "should be iterative, with cross-referencing between functions as necessary." Some categories apply to multiple functions, or logically precede decisions in another function. If you find yourself looping back from MANAGE to MAP because a mitigation changed the system's risk picture, you are using the framework as intended.

Voluntary, and what that means next to the EU AI Act

The AI RMF is voluntary, and NIST says so. Describing the companion Playbook, the publication states: "Like the AI RMF, the Playbook is voluntary." Users "may apply these functions as best suits their needs for managing AI risks based on their resources and capabilities," and some organizations "may choose to select from among the categories and subcategories" rather than apply all of them. The Playbook, part of the NIST Trustworthy and Responsible AI Resource Center, offers suggested tactical actions and lets users build tailored guidance.

The EU AI Act is different in kind. It is legislation. Where it applies to you, its obligations are mandatory, and choosing which parts to adopt is not on offer. The two are not competitors, though. The RMF assumes law exists and builds compliance into its structure: GOVERN 1.1 requires that legal and regulatory requirements involving AI are understood, managed and documented. In practice, an organization subject to the AI Act might use the RMF as the internal machinery that produces what the law demands, while the law itself defines what "compliant" means. The framework organizes the work. The statute sets the floor.

What the exam will do with this

The AIGP is a 3-hour exam of 100 multiple-choice items, each worth one point, with no essays. The AI RMF sits squarely in Domain II, where competency II.D, on industry standards and tools that apply to AI, carries 3 to 5 items, and the framework's lifecycle logic runs underneath Domains III and IV on governing development, deployment and use. You should be able to name the four functions, state that GOVERN is cross-cutting while the other three apply per system across the lifecycle, describe the GOVERN-then-MAP sequence NIST suggests, and explain what "voluntary" means when the framework sits next to a binding law. Learn the structure, not the subcategory numbers, and the framework will hold together when you need it.