The NIST AI Risk Management Framework comes up in two ways. A US customer asks whether you follow it. Or your own team wants a structure for AI risk that is lighter than a certifiable management system. Either way, someone needs to know what the framework actually asks for and what adopting it means.
The short version: it is voluntary, it is not certifiable, and it is organized around four functions called Govern, Map, Measure, and Manage. It describes outcomes, not controls. You decide how to reach them.
This article explains its structure, what each function covers, the companion resources, and how it relates to ISO/IEC 42001.
What the framework is, and is not
NIST published the AI Risk Management Framework 1.0 in January 2023 as NIST AI 100-1. It was developed through public workshops and comment drafts. NIST describes it as voluntary, and as intended for any organization that designs, develops, deploys, or uses AI systems, in any sector.
It has two parts. Part 1 frames AI risk: how AI risks differ from traditional software risks, who the relevant actors are, and what makes an AI system trustworthy. Part 2 is the Core, the four functions, and a short discussion of profiles.
Three things it is not:
Not a certification scheme. There is no audit, no certificate, and no conformity assessment body. A claim of "alignment" is a self-assessment.
Not a control catalog. It does not list technical controls the way NIST SP 800-53 does. Its subcategories describe outcomes.
Not a risk tolerance. It says outright that it does not prescribe how much risk an organization should accept. That decision stays with you.
The characteristics of trustworthy AI
Part 1 names seven characteristics, and the rest of the framework refers back to them. A trustworthy AI system, in NIST's terms, is:
Valid and reliable
Safe
Secure and resilient
Accountable and transparent
Explainable and interpretable
Privacy-enhanced
Fair, with harmful bias managed
The framework treats validity and reliability as a foundation for the others, and accountability and transparency as relating to all of them. It is also candid that the characteristics trade off. Making a system more interpretable can cost accuracy. Privacy techniques can reduce the data available for checking bias. The framework does not resolve these tensions. It asks you to make the trade-offs deliberately and record them.
The four functions
The Core divides into four functions. Each breaks into categories, and each category into subcategories that describe a specific outcome.
Govern
Govern is cross-cutting. It applies across the other three rather than coming before or after them. Its categories cover policies and procedures for AI risk, accountability structures, workforce diversity and training, a culture that treats AI risk seriously, engagement with people affected by AI systems, and risks from third-party software, data, and suppliers.
In practice, Govern produces the artifacts an auditor of any framework would recognize: a policy, named owners, defined roles, training, and a process for managing suppliers.
Map
Map establishes context. For a given AI system, it asks what the system is for, who uses it, who it affects, what its limits are, and what could go wrong. It also asks you to categorize the system and map risks and benefits for its components, including those from third parties.
Map's output should inform a decision about whether to proceed with a system at all. Teams that skip that decision, and treat Map as paperwork after the system is built, lose most of its value.
Measure
Measure analyzes and tracks the risks Map identified. It covers choosing methods and metrics, evaluating systems against the trustworthiness characteristics, tracking risks over time, and gathering feedback on whether your measurements are working.
The framework accepts quantitative, qualitative, and mixed methods. It also acknowledges that some risks are hard to measure. Where that is true, record it, because an unmeasured risk still needs a treatment decision.
Manage
Manage decides what to do. Risks are prioritized and acted on, plans are made to maximize benefits and minimize harms, third-party risks are monitored, and response, recovery, and communication plans are documented.
If you already run likelihood and impact scoring for other risks, Manage is where AI risks join that process.
Profiles and the Playbook
Two companion resources make the framework usable.
The AI RMF Playbook is published by NIST alongside the framework. For each subcategory it offers suggested actions, references, and documentation ideas. It is the closest thing to implementation guidance the framework has. It is also explicitly not a checklist: you pick what fits.
Profiles apply the framework to a specific setting. A use-case profile tailors it to a particular application or sector. A current profile describes where you are, a target profile describes where you want to be, and the gap between them becomes a plan. NIST has published a Generative AI Profile, NIST AI 600-1, which applies the framework to risks specific to or made worse by generative AI.
If you have used the NIST Cybersecurity Framework, the idea of current and target profiles will be familiar.
How it relates to ISO/IEC 42001
Teams often ask whether to use one or the other. They do different jobs, and many organizations use both.
| NIST AI RMF 1.0 | ISO/IEC 42001:2023 | |
|---|---|---|
| Nature | Voluntary framework of outcomes | Management system standard with requirements |
| Certification | None | Third-party certification available |
| Structure | Four functions, categories, subcategories | Clauses 4 to 10, plus Annex A controls |
| Risk tolerance | Left to the organization | Organization sets criteria; must document them |
| Evidence expectation | Whatever you choose to keep | Documented information an auditor samples |
| Typical use | Structuring AI risk thinking, internal alignment | Demonstrating governance to customers and auditors |
The practical pattern: the AI RMF is a good way to think through risks for a specific system, especially in Map and Measure. ISO/IEC 42001 is the management system that makes that thinking repeatable and auditable. If customers ask for evidence, ISO/IEC 42001 certification gives you something third-party verified to show them. The AI RMF does not.
Answering "do you follow the AI RMF?"
Because there is no certificate, the honest answer is a description, not a yes. Say which systems you have applied it to, whether you keep current and target profiles, and who owns the Govern outcomes. Offer to share a summary.
Avoid claiming full alignment. Few organizations meet every subcategory for every system, and the framework does not expect them to. A customer's security reviewer will usually trust "we apply Map and Measure to every customer-facing AI feature, and here is the template" more than an unqualified claim. If the reviewer needs third-party assurance, the AI RMF cannot give it, and it is better to say so than to imply otherwise.
Where to start
If you are adopting the framework, a workable order:
Read Part 1 in full. It is short, and the rest assumes you have.
Pick one AI system. Ideally one with real users and real consequences.
Work through Map for that system. Record context, users, affected people, limits, and risks.
Write a current profile. For each subcategory, note what you do today. Be honest. "Nothing yet" is a valid entry.
Set a target profile. Choose the outcomes that matter for this system. Not all of them will.
Turn the gap into tasks with owners and dates, and put the risks in your existing register.
Repeat for the next system. By the third, you will have a Govern layer worth writing down. If you later pursue ISO/IEC 42001, that work feeds directly into building the management system.
How TrustLynce helps
TrustLynce's risk register holds AI risks with scoring and treatment plans next to the rest of your risks, so Manage decisions are recorded with owners and dates. For organizations also pursuing ISO/IEC 42001, the framework page shows how that standard is supported.