NIST AI RMF · 72 plays

NIST AI RMF Playbook: AI Risk Management

All 72 subcategories of the NIST AI Risk Management Framework, with the official suggested actions, documentation and references for each one.

  • Govern · 19

    Cultivate a culture of AI risk management through policies and procedures.

  • Map · 18

    Contextualise risks and establish AI risk profiles.

  • Measure · 22

    Analyse, assess, benchmark, and monitor AI risk and related impacts.

  • Manage · 13

    Allocate risk resources to mapped and measured risks on a regular basis.

About this page

The NIST AI Risk Management Framework organises the work of managing AI risk into four functions. Govern sets the policies, roles and accountability that everything else depends on, and it runs throughout rather than once at the start. Map establishes context: what the system is for, who it affects, and which risks are plausible. Measure tests those risks with methods and metrics, including the ones that are hard to quantify. Manage allocates resources to the risks that matter and decides what to treat, transfer or accept.

Each function contains categories, and each category contains subcategories. The subcategories are the practical unit: a short statement of an outcome to achieve. There are 72 of them. Use the filters to narrow to one function or category, or search to find a subcategory by its wording, its suggested actions or its topic. Open any play to read the official About text, suggested actions, the documentation worth keeping, and references. Every play has its own link, so a single subcategory can be shared directly.

Based on the NIST AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1) and the NIST AI RMF Playbook. Subcategory statements and suggested actions are NIST material, reproduced here for reference. This is an independent reference site and is not affiliated with, or endorsed by, NIST.

Shahzad Asghar

Why I built this playbook

Shahzad Asghar, CISSP, CISM · Written in a personal capacity

I have sat on both sides of an AI risk review: the team proposing the system and the committee deciding whether to allow it. The NIST AI Risk Management Framework gives both sides a shared structure, govern, map, measure and manage, but the framework text does not tell you what to put in the room on Monday. This playbook does, drawing on the governance work I did for AI systems serving refugees and public services.

I have spent more than twenty years building data and AI systems in international development and humanitarian organisations, including over a decade in United Nations agencies: leading a data analysis group whose systems served more than 700,000 refugees, then heading data and digital solutions for a regional commission, with earlier work at UNICEF, UNOCHA and CIDA. I hold the CISSP and CISM security certifications. What I publish here is what I wish someone had handed me before my first AI project. If you work through it and want to compare notes on your own situation, I am happy to connect and discuss.

Showing 72 of 72 plays

Govern

Cultivate a culture of AI risk management through policies and procedures.

GOVERN-1

7 plays

GOVERN-2

3 plays

GOVERN-3

2 plays

GOVERN-4

3 plays

GOVERN-5

2 plays

GOVERN-6

2 plays

Map

Contextualise risks and establish AI risk profiles.

MAP-1

6 plays

MAP-2

3 plays

MAP-3

5 plays

MAP-4

2 plays

MAP-5

2 plays

Measure

Analyse, assess, benchmark, and monitor AI risk and related impacts.

MEASURE-1

3 plays

MEASURE-2

13 plays

MEASURE-3

3 plays

MEASURE-4

3 plays

Manage

Allocate risk resources to mapped and measured risks on a regular basis.

MANAGE-1

4 plays

MANAGE-2

4 plays

MANAGE-3

2 plays

MANAGE-4

3 plays

Back to top

Pre-production controls for agentic AI

Eight checks that have to be satisfied before an agent is allowed to act, as distinct from the continuous controls that run afterwards. The NIST column links to the play on this page.

The NIST references are exact. The ISO/IEC 42001 and EU AI Act columns name the relevant control theme and obligation so you can find the right part of each text; check the current wording of both standards before citing a clause in an audit file.

Pre-production controls and their equivalents. Evidence is what a reviewer asks to see.
ControlRequired before productionNIST AI RMFISO/IEC 42001EU AI ActEvidence
Authority is written downThe actions the agent may take are listed, with the actions it may not take listed beside them, and a named person owns that list.AI policy; internal organisation and rolesArt. 9 risk management; Art. 26 deployer obligationsThe scope definition, and the approval that put it in place.
Irreversible actions are held backAnything that moves money, changes a record of consequence or leaves the organisation requires a human decision, and the system cannot be configured to skip it.Use of AI systems; AI system life cycleArt. 14 human oversightThe list of gated actions, and a test showing the gate cannot be bypassed.
Permission is enforced in codeThe boundary is enforced by the harness rather than described in a prompt, and a call outside scope is refused rather than discouraged.AI system life cycle; technical controlsArt. 15 accuracy, robustness and cybersecurityA refused call in a log, from a test that asked for something out of scope.
The data the agent can reach is boundedScope is drawn around what the task needs rather than what the system happens to hold, including fields inside records it may otherwise read.Data for AI systemsArt. 10 data and data governanceThe field-level scope, and a query showing out-of-scope fields are not returned.
Failure is defined before launchWhat counts as the system going wrong is written in advance, with the threshold that triggers a stop, rather than judged after an incident.AI system impact assessmentArt. 9 risk managementThe stopping condition, and who holds the authority to invoke it.
The run is reconstructableEvery tool call, refusal, approval and output can be replayed after the fact, attributed to a decision rather than only to an outcome.Information for interested parties; AI system life cycleArt. 12 record-keeping; Art. 11 technical documentationA complete trace for one real request, end to end.
The model and its suppliers are identifiedWhich model, which version and which hosting arrangement, with the contractual position on data use recorded.Third-party relationshipsArt. 11 technical documentation; Art. 26 deployer obligationsThe model record, and the supplier terms that cover it.
Someone is told it is an agentPeople on the receiving end know an automated system was involved, and how to reach a person instead.Information for interested partiesArt. 13 transparency; Art. 50 transparency for certain systemsThe wording shown to the recipient, and the route to a human.

Where to go next