NIST AI Risk Management Framework: A Plain-English Guide

Photo: Nataliya Vaitkevich / Pexels
Key takeaways
- The NIST AI RMF is voluntary, published by NIST in January 2023, and carries no legal force.
- Four functions structure it: GOVERN, MAP, MEASURE, MANAGE.
- GOVERN and MAP, a named owner, a written policy, a tool inventory, matter most for small teams starting out.
- Shadow AI is usually the biggest gap a MAP exercise uncovers.
- It overlaps heavily with ISO 42001 and the EU AI Act, so covering one framework does much of the work for the others.
The NIST AI Risk Management Framework is a voluntary set of guidelines published by the US National Institute of Standards and Technology in January 2023, built to help organisations identify, assess and manage the risks that come with using AI. It carries no legal force, unlike the EU AI Act, but it has become the reference point that US federal agencies, regulated industries and enterprise procurement teams reach for when they ask a blunt question: how do you actually manage AI risk? This guide translates its four functions into what a small team, with no risk department, can realistically do.
The four functions: GOVERN, MAP, MEASURE, MANAGE
NIST organises AI risk management into four functions rather than a checklist. GOVERN sets the culture and accountability: who owns AI risk, what the policy says, how decisions get made. MAP identifies which AI systems you actually use and what could go wrong with each. MEASURE evaluates those risks, sometimes with numbers, sometimes with judgement calls. MANAGE puts controls in place and checks they're still working. For a team without a dedicated risk function, GOVERN and MAP do most of the useful work; MEASURE and MANAGE matter more as your AI footprint grows. Our own NIST AI RMF hub breaks each function down further with SMB-specific actions.
The risk categories NIST asks you to think about
Underneath the four functions, NIST frames 'trustworthy AI' around a handful of characteristics worth knowing even if you never open the full document: valid and reliable, safe, secure and resilient, accountable and transparent, explainable, privacy-enhanced, and fair with harmful bias managed. You don't need to formally score a tool against all seven. In practice, most SMB risk questions collapse into three of them: is this tool secure with our data, is it transparent about what it does with our inputs, and could its output be biased or wrong in a way that affects someone. Keeping those three in mind when you rate a new tool covers most of what the fuller list is getting at.
GOVERN in practice for a small team
Governance at SMB scale doesn't need a committee. It needs a named owner for AI decisions, a written AI usage policy, and staff who actually know the rules exist. A one-page policy with a named owner and an annual review date is a credible GOVERN implementation for a team under 50 people, the goal is documented accountability, not process for its own sake. The annual review doesn't need to be exhaustive: check whether the approved tool list has changed, whether any new regulation now applies, and whether the named owner is still the right person for the job. Twenty minutes, once a year, keeps the policy honest instead of decorative. If you can't say who owns AI risk in your organisation right now, that's the gap to close first.
MAP: knowing what you're actually using
You can't manage a risk you haven't found. MAP starts with an honest inventory: which AI tools does your team use, who uses them, and what data goes in? This is the same tool register that also satisfies ISO 42001 and EU AI Act documentation. In most MAP exercises, the biggest surprise is shadow AI, tools people are already using that IT never approved or even heard of. Once you've found them, rating each by data sensitivity tells you where to focus.
MEASURE and MANAGE, with a worked example
MEASURE means putting some rigour behind your risk ratings, is this tool handling customer data, source code, or just meeting notes? MANAGE means acting on that: approving some tools, restricting others, and setting a process for what happens when someone requests a new one. Take three tools a support team might realistically use: ChatGPT Free on personal accounts, ChatGPT Team on a paid company subscription, and Microsoft 365 Copilot on the business tenant. ChatGPT Free trains on inputs by default and comes with no DPA, so it rates high-risk for anything beyond public information. ChatGPT Team doesn't train on business data and adds admin controls, so it rates medium, fine for internal drafting, still worth restricting for anything regulated. Microsoft 365 Copilot on the business tier, with its tenant boundary and included DPA, rates low-risk for most internal use. Same underlying task, three different risk levels, because the tier changes the answer every time. A workable MANAGE process is often just this: someone requests a tool, the named owner checks its tier and terms against the risk rating, and the decision, approved, approved with conditions, or declined, gets logged in the same register used for MAP.
Is the NIST AI RMF mandatory?
No. It's voluntary for private-sector organisations, though some US federal contracts and agencies reference it directly. Its real pull is reputational and commercial: enterprise customers and auditors increasingly use its language, GOVERN, MAP, MEASURE, MANAGE, as shorthand for 'do you actually manage this', so being able to answer in those terms smooths procurement conversations even where nothing legally requires it.
How does it relate to ISO 42001 and the EU AI Act?
The three are complementary rather than competing. The EU AI Act sets legal minimums for anyone it reaches. ISO 42001 provides a certifiable management system (see ISO/IEC 42001's standard page) for meeting and demonstrating them. NIST AI RMF offers a risk-management vocabulary, particularly useful for US organisations or anyone selling into US enterprise accounts. Because the underlying controls overlap heavily, a policy, a tool register and an attestation log built for one framework do most of the work for the other two as well.
What this looks like at a growing company
An IT lead at a 120-person healthtech company ran her first MAP exercise ahead of a customer's security review and found built-in AI features in three cloud tools nobody had flagged, one had been quietly summarising support tickets containing patient names for months. None of it was malicious. It was just that no one had ever asked 'what AI are we using?' out loud. The fix wasn't complicated: she rated each tool, restricted the ones handling health data to enterprise tiers with a signed BAA, and documented the decision. That's MAP and part of MANAGE, done in an afternoon, not a quarter, and it's the same pattern that shows up whenever a company runs its first honest inventory: the risk was already there, it just hadn't been written down.
Getting started without a risk team
Pick up GOVERN and MAP first: publish a policy, name an owner, build a register of approved and shadow tools. ModelCharter handles the first two out of the box. MEASURE and MANAGE add depth as your AI use grows, but you don't need them on day one. Read the official NIST AI RMF overview if you want the source document, or the full 1.0 text if you want the detail. A framework that exists on one page beats a perfect one still being drafted.
| Function | Core question | What it looks like for an SMB |
|---|---|---|
| GOVERN | Who owns AI risk, and what's the policy? | Named policy owner + written AI usage policy |
| MAP | What AI are we actually using, and what could go wrong? | Tool register covering every approved and shadow AI tool |
| MEASURE | How big are the risks we've mapped? | Risk rating per tool: data sensitivity, training defaults, vendor terms |
| MANAGE | What controls reduce the risk, and are they working? | Approval workflow, periodic review, incident process |
“A framework doesn't need a risk committee to be real. It needs an owner, a written policy, and an honest inventory of what's actually in use.”