NIST AI RMF Quick Reference
The voluntary federal framework for managing AI risk. Four functions. Use it to structure your write-up and your conversations.
The NIST AI Risk Management Framework (AI RMF 1.0) was published in January 2023. It is voluntary. OMB M-24-10 and most agency AI policies now reference it as the baseline. If you write AI requirements, run AI evals, or sit on a CAIO's bench, you need to read it in the original at least once. This page is the map.
The four functions
GOVERN
The culture and accountability layer. GOVERN asks who owns AI risk in your org, what your policies say, and how you train people. It produces a governance document, named accountable parties, a risk tolerance statement, and a training plan. In a real program it lands as a GOVERNANCE.md in the repo, a CAIO memo, and a recurring review cadence on the calendar.
MAP
The context layer. MAP asks what the system is, what it is not, who it affects, and where the data comes from. It produces a system card, a stakeholder map, a data provenance log, and a documented intended-use statement with explicit out-of-scope use. In a real program this is the artifact that survives ATO review when someone asks "what does this thing actually do."
MEASURE
The numbers layer. MEASURE asks how the system performs, how it fails, and how you would know. It produces eval sets, drift monitors, bias and fairness measurements where people are affected, and red-team results. In a real program this is the directory of CSVs and the monthly report that proves the system is still inside its risk envelope.
MANAGE
The response layer. MANAGE asks what you do when something breaks or changes. It produces a risk register, an incident runbook, an update policy, and a retirement plan. In a real program this is the page-of-the-week the on-call engineer reads when an alert fires.
The 18 categories
GOVERN (6 categories)
- GOVERN.1: Policies and procedures for AI risk are in place. Gotcha: most orgs have generic IT risk policy and call it done. AI risk needs its own named policy.
- GOVERN.2: Accountability structures are defined. Gotcha: "the AI team" is not a person. Name a human.
- GOVERN.3: Workforce is trained. Gotcha: a one-time slide deck is not training. Recurring is required.
- GOVERN.4: Organizational culture commits to risk management. Gotcha: this is often the weakest category on paper. Write down how leadership reinforces it.
- GOVERN.5: Engagement with affected communities is documented. Gotcha: "internal stakeholders only" is usually wrong for rights-impacting systems.
- GOVERN.6: Third-party and supply-chain risk is addressed. Gotcha: if you call a foundation model API, that vendor is in scope.
MAP (5 categories)
- MAP.1: Context is established. Gotcha: write down the operational environment, not just the technical stack.
- MAP.2: AI system categorization is documented. Gotcha: rights-impacting and safety-impacting designations drive the rest of M-24-10. Get this right.
- MAP.3: AI capabilities, targets, and assumptions are known. Gotcha: "chatbot" is not a capability statement. List the actual tasks.
- MAP.4: Risks and benefits are mapped. Gotcha: benefits need to be quantified the same way risks are.
- MAP.5: Impacts to individuals, groups, and society are characterized. Gotcha: this is where bias and disparate-impact analysis lives.
MEASURE (4 categories)
- MEASURE.1: Appropriate methods and metrics are identified. Gotcha: accuracy alone is not enough for anything that touches people.
- MEASURE.2: Systems are evaluated for trustworthy characteristics. Gotcha: this includes fairness, robustness, privacy, explainability, not just performance.
- MEASURE.3: Mechanisms for tracking risks are in place. Gotcha: a one-time eval is not a mechanism. You need continuous measurement.
- MEASURE.4: Feedback from end users and impacted communities is collected. Gotcha: a feedback button is not the same as actually reviewing the feedback.
MANAGE (4 categories)
- MANAGE.1: Risks are prioritized and resources allocated. Gotcha: if every risk is "medium," you have not prioritized.
- MANAGE.2: Strategies to maximize benefits and minimize risks are planned. Gotcha: "we'll monitor" is not a strategy.
- MANAGE.3: Third-party risks are managed. Gotcha: this is where your vendor's eval reports and SOC 2s land.
- MANAGE.4: Risk treatment, including response and recovery, is in place. Gotcha: the runbook needs to be tested, not just written.
When the RMF fits, and when it is overkill
Use the full RMF when the system is rights-impacting, safety-impacting, public-facing, or covers more than 100 users. Use it when you are heading toward an ATO. Use it when a vendor will be involved at any scale.
Do not use the full RMF for a small internal tool used by five people on non-sensitive data. A short system card and a named owner is enough. Citing the RMF on a tiny prototype is theater, and it slows everyone down. The Profile guidance in the RMF itself supports this scoping decision.
Five-step on-ramp for day one
- Pick the system. One AI system you actually own. Not the whole portfolio.
- Categorize it. Rights-impacting? Safety-impacting? Internal only? Write the answer in one paragraph.
- Write the system card. Intended use, out-of-scope use, users, data sources, dependencies, known limits. Two pages, not twenty.
- Stand up the risk register. Five risks, ranked. What you are doing about each. A markdown table is fine.
- Name the owner and the review cadence. Quarterly minimum. Put it on the calendar before you leave the meeting.
You now have GOVERN, MAP, MEASURE, and MANAGE in skeleton form. Iterate from there.