What are the four functions of the NIST AI RMF?

GOVERN, MAP, MEASURE and MANAGE. GOVERN is the cross-cutting one: NIST designs it to inform and be infused throughout the other three rather than to sit before them in a sequence. MAP establishes context and identifies risks, MEASURE analyses and tracks them with methods and metrics, and MANAGE prioritises and acts on them, including response and recovery. The framework is voluntary and non-sector-specific, so the functions describe what has to be true rather than prescribing how an organisation achieves it.

How many categories and subcategories does the NIST AI RMF have?

Nineteen categories and 72 subcategories across the four functions. GOVERN has 6 categories and 19 subcategories, MAP has 5 and 18, MEASURE has 4 and 22, and MANAGE has 4 and 13. MEASURE 2 alone carries 13 subcategories, which is the largest single group in the framework and a fair signal of where NIST expects the work to be — evaluating a system against the trustworthiness characteristics is more detailed than governing or managing it.

What are the seven characteristics of trustworthy AI in the NIST framework?

Valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. NIST treats valid and reliable as the base condition — without it the others do not get you a trustworthy system — and accountable and transparent as cutting across all the rest. The framework is explicit that these have to be balanced against each other for a given system and context rather than maximised independently.

Is the NIST AI RMF mandatory?

No. It is a voluntary framework published by a US standards body, not a regulation, and nothing in it carries a penalty. That is a meaningful difference from the EU AI Act, which is binding law with dated obligations. What the AI RMF gives you is a shared vocabulary and a checklist structure that an internal audit function, a risk committee or a customer's due-diligence questionnaire will recognise — which is often exactly what is needed when the alternative is inventing your own categories.

How does the NIST AI RMF map to existing finance controls?

More closely than the vocabulary suggests. GOVERN 2 (accountability structures) is the named process owner and delegation of authority you already maintain. GOVERN 6 (third-party software and data) is vendor risk management. MAP 4 (risks across all components including third-party) is the interface inventory. MEASURE 3 (tracking risks over time) is a KRI on a risk register. MANAGE 4 (response, recovery and communication) is the incident process and the fallback in a cutover plan. Most of the framework is asking whether controls you already run have been extended to cover a probabilistic component.

NIST AI RMF: The Functions and Categories, Explained

The NIST AI Risk Management Framework has four functions — GOVERN, MAP, MEASURE and MANAGE — holding 19 categories and 72 subcategories between them, and GOVERN is cross-cutting rather than first in a sequence. It is voluntary, it is not a regulation, and most of what it asks is whether controls a finance function already runs have been extended to cover a component whose output varies.

This page is the structure, verified line by line against NIST AI 100-1, with the counts stated so you can tell at a glance where the weight sits. The commentary underneath each function is mine: eighteen years of controls work in SAP FI and treasury, pointed at the question the framework actually asks.

The shape of it

Function	Categories	Subcategories	What it asks
GOVERN	6	19	Is there a culture, an owner and a policy — across all three below
MAP	5	18	Do you understand the context, the system and the risks
MEASURE	4	22	Can you evaluate and track it, with methods and metrics
MANAGE	4	13	Do you act on what you found, including recovery
Total	19	72

Two things are worth reading off that table before anything else.

GOVERN is not step one. NIST is explicit that governance is a cross-cutting function designed to inform and be infused throughout the other three. Treating it as a gate you pass before the work starts produces the failure mode I described in where to start with enterprise AI: a control regime written against no concrete case, calibrated for the worst thing anyone imagined.

MEASURE 2 is the heaviest single category in the framework, with 13 of the 72 subcategories. It is the one about evaluating a system against the trustworthiness characteristics. If your programme's effort is not lopsided toward measurement, it is not following the shape of this framework — whatever the slide says.

The seven characteristics of trustworthy AI

The framework names these, and the ordering carries meaning. NIST treats valid and reliable as the base condition — the other characteristics do not add up to trustworthiness without it — and accountable and transparent as relating to all the others rather than sitting beside them.

Valid and reliable
Safe
Secure and resilient
Accountable and transparent
Explainable and interpretable
Privacy-enhanced
Fair, with harmful bias managed

The framework is explicit that these are balanced for a given system and context, not maximised independently — which is the honest position, because several of them trade against each other in any real design.

GOVERN — 6 categories, 19 subcategories

Category	In one line	The finance-control equivalent
GOVERN 1	Policies, processes and practices for mapping, measuring and managing AI risk are in place and implemented	The control framework document nobody reads until an audit
GOVERN 2	Accountability structures: teams empowered, responsible and trained	The named process owner and the delegation of authority
GOVERN 3	Workforce diversity, equity, inclusion and accessibility in the risk work	No direct equivalent — this one is genuinely additional
GOVERN 4	A culture that considers and communicates AI risk	Speak-up culture; the thing every incident review says was missing
GOVERN 5	Robust engagement with relevant AI actors	Stakeholder management, including the people the output lands on
GOVERN 6	Third-party software, data and supply-chain risk	Vendor risk management, extended to models and training data

GOVERN 2 is the one I would put first in practice. Accountability is where AI governance most often fails and it fails the same way every time: the accountable party is "the AI team", which is the same as nobody. The rule that holds is the one every control already follows — a named person who can change the system, see the exception queue, and stop it. That is the ownership question, and no framework can answer it for you.

GOVERN 6 deserves more weight than it usually gets in enterprise programmes, because for most organisations the model is third-party, the training data is third-party, and the agent platform is third-party. Vendor risk management is not a formality here; it is most of the attack surface, and the questions worth asking are the ones a vendor's accuracy claim cannot survive. The security list names the same gap in almost the same words — LLM04 Supply Chain in the 2026 OWASP LLM Top 10.

MAP — 5 categories, 18 subcategories

Category	In one line	The finance-control equivalent
MAP 1	Context is established and understood	The scoping workshop, done honestly
MAP 2	Categorization of the AI system is performed	System classification on the application inventory
MAP 3	Capabilities, usage, goals, benefits and costs against benchmarks	The business case, with a baseline
MAP 4	Risks and benefits mapped across all components, including third-party	The interface inventory and the dependency map
MAP 5	Impacts to individuals, groups, organizations and society characterized	Impact assessment — the half of a risk register nobody fills in

MAP 3 is where I would put the most pressure, because "expected benefits and costs compared with appropriate benchmarks" is precisely the step that gets skipped. A benefit stated without a baseline cannot be checked afterwards, which is the whole argument for measuring the work rather than the tool.

MAP 4 is the one an enterprise architect will recognise immediately. It is the interface estate, and the reason it matters here is that an AI component's risk is mostly inherited from what it can reach — an architecture problem, not a model problem.

MEASURE — 4 categories, 22 subcategories

Category	In one line	The finance-control equivalent
MEASURE 1	Appropriate methods and metrics are identified and applied	Test strategy: deciding what "correct" means before testing
MEASURE 2	Systems are evaluated for trustworthy characteristics (13 subcategories)	UAT, regression testing, and the evidence pack
MEASURE 3	Mechanisms for tracking identified risks over time	KRIs on the risk register; monitoring and alerting
MEASURE 4	Feedback about the efficacy of measurement is gathered and assessed	The post-implementation review that asks whether the tests were the right tests

MEASURE 1 contains the step teams reliably skip: deciding the method and the metric before measuring. In systems delivery that is a test strategy, and the AI version has one extra obligation — the output varies, so a single pass tells you nothing without a defined sample and a defined threshold. That is regression testing for a probabilistic component.

MEASURE 3 is the one that ages worst if you leave it. Tracking risk over time means noticing that behaviour drifted, and if the detection mechanism is "a customer told us", there is no mechanism — which is what production observability exists to fix.

MEASURE 4 — assessing whether your measurement was any good — is unusual, and it is the most self-aware thing in the framework. Very few control environments ask it about anything.

MANAGE — 4 categories, 13 subcategories

Category	In one line	The finance-control equivalent
MANAGE 1	Risks from MAP and MEASURE are prioritized, responded to and managed	Risk treatment decisions on a RAID log
MANAGE 2	Strategies to maximize benefits and minimize negative impacts	The design decisions themselves — where the human sits, what is automated
MANAGE 3	Risks and benefits from third-party entities are managed	Ongoing vendor management, not just onboarding
MANAGE 4	Risk treatments, response, recovery and communication documented and monitored	Incident management and the cutover fallback

MANAGE 4 is the gate I would refuse to waive. Response and recovery for an AI step means a tested way to undo a wrong output and a defined route for who is called when it misbehaves out of hours — which is exactly what a pilot has to prove before production, and it is the gate most often assumed rather than exercised.

What the framework does not do

Worth stating plainly, because the gap is where the disappointment comes from.

It is voluntary, and it is not law. Nothing in it carries a penalty. If your obligation is regulatory, the binding instrument in Europe is the AI Act, with dated requirements — which apply on a schedule the framework says nothing about.

It will not tell you whether to build the thing. The framework assumes a system exists or is planned. The prior question — whether this workflow should be redesigned with AI at all — is not in scope, and an assessment that can answer "don't" is a separate exercise.

It does not size your exception queue, set your thresholds or design your control path. Those are engineering and operating decisions. The framework tells you they must exist and be documented; it deliberately does not tell you what good looks like for your volume, which is correct for a non-sector-specific framework and unhelpful on the Monday you have to decide.

What I would decide

Use it as a checklist and a vocabulary, not as a programme plan. Run your existing control inventory against the 19 categories and mark the ones an existing control already covers — for most finance functions that is the majority, and the exercise takes an afternoon rather than a workstream. Put the real effort into the three that are genuinely different for a probabilistic component: GOVERN 6 because the supply chain is the model, MEASURE 2 because it is a third of the framework by weight, and MANAGE 4 because a recovery path nobody has exercised does not exist.

And do not let the framework substitute for the decision underneath it. Naming a risk in a register is not a control. Something deterministic in the path is.