← Blog

GOVERN, MAP, MEASURE, MANAGE: The NIST AI RMF Functions in Plain English with Concrete Artifacts

NIST AI RMF organizes around four functions: GOVERN, MAP, MEASURE, MANAGE. Most teams encounter them as four-letter acronyms in vendor pitches and lose the thread. This article walks through each function in plain English, the concrete artifact a real organization produces under each, and where the four interlock with EU AI Act, ISO 42001, and federal procurement reviews. The artifact-first framing matters because GOVERN without artifacts is policy theater and MEASURE without artifacts is an audit gap.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Compliance & Regulationnistnist-ai-rmfai-governancecomplianceauditai-compliance
GOVERN, MAP, MEASURE, MANAGE: The NIST AI RMF Functions in Plain English with Concrete Artifacts

The NIST AI Risk Management Framework (AI RMF) organizes around four functions. GOVERN sets up the program. MAP defines the AI systems in scope. MEASURE tracks how those systems perform against risk. MANAGE closes the loop with corrective action. The four-letter naming is meant to make the framework memorable. The cost is that the names get repeated in vendor pitches as a four-letter incantation without the practitioner's understanding of what each function actually requires.

I want to walk through each function in plain English and pair it with the concrete artifact a real organization produces. The artifact-first framing matters because GOVERN without an artifact is policy theater, MAP without an artifact is a spreadsheet exercise, MEASURE without an artifact is an audit gap, and MANAGE without an artifact is an apology letter waiting to be written.

GOVERN

The GOVERN function establishes the program. The work is the program-level decisions about who owns AI risk, what the organization's risk appetite is, how the program connects to broader enterprise risk management, and how decisions get reviewed.

In plain English: GOVERN answers "who decides, and what are they accountable for?"

The artifact is the AI governance charter plus the related policy stack. The charter names the AI risk owner (often the CRO or a cross-functional committee), the cadence of review, the escalation path when a system enters or exits the high-risk tier, and the relationship between AI risk and enterprise risk management.

The charter is not enough on its own. It has to be paired with operational artifacts that demonstrate the charter is enforced. An AI risk committee that meets monthly with a documented agenda and recorded decisions is evidence the GOVERN function is active. A committee that exists on paper but has not met in six months fails the audit.

Where GOVERN maps to other regimes

EU AI Act Article 9 (risk management system) overlaps directly. ISO 42001's AIMS structure is built around the same governance scaffolding. Sector-specific regimes like Fannie Mae LL-2026-04 explicitly require named governance ownership at the lender.

Common GOVERN gap

The most common gap is the charter that exists without the operational cadence. A board-level AI policy adopted at the annual cycle, never operationalized, then surfaced during an audit. The fix is to set the cadence in the charter and write the cadence into a calendar with named owners.

MAP

The MAP function inventories the AI systems and their context. The work is to know what AI is running, where it is running, what data it touches, what decisions it makes, and what risk tier it sits in.

In plain English: MAP answers "what AI do we actually have, and what does it do?"

The artifact is the AI system inventory, the AI Bill of Materials (AIBOM) for each system, and the risk classification per system. The inventory has to cover every AI system in production use, including AI embedded in vendor SaaS tools the organization has purchased.

The inventory is also dynamic. A new AI system that comes online has to be added. A system that is decommissioned has to be removed. A system that changes its data classification or its risk tier has to have the change recorded.

Where the MAP inventory comes from

For the AI systems the organization deploys directly, the inventory can be sourced from the deployment layer. An inline enforcement layer that sees AI traffic produces a discovery side effect: every distinct model endpoint, every distinct caller, and every distinct policy version that traffic touches. That side effect is the operational form of the inventory.

For vendor-embedded AI, the inventory has to come from procurement-side disclosure. Updated vendor questionnaires that ask "does your product use AI inference on customer data" surface the dependencies. Many large vendors now publish their AI use as part of their SOC 2 reports.

Where MAP maps to other regimes

EU AI Act Article 11 (technical documentation) requires the equivalent of the AIBOM per high-risk system. NIST CSF asset management overlaps. DORA's ICT third-party register treats LLM providers as in-scope dependencies. The same inventory artifact feeds multiple regimes.

Common MAP gap

The most common gap is the inventory that covers only the AI systems the security team knows about. Shadow AI and vendor-embedded AI are the typical omissions. The fix is to source the inventory from a layer that sees traffic (the enforcement layer) rather than from the procurement record alone.

MEASURE

The MEASURE function tracks how the AI systems are actually performing against the risks identified in MAP. The work is metrics, evaluations, and ongoing assessment.

In plain English: MEASURE answers "how do we know our AI is doing what we said it would do, and not doing what we said it would not do?"

The artifact is the per-decision audit record at the AI request layer, the evaluation suite that runs against the deployed systems on a defined cadence, the model performance dashboard, and the bias and fairness assessment per system.

The per-decision audit record is the substrate. Without it, the dashboard and the evaluation suite produce numbers but cannot reconstruct a specific decision when asked. The record captures identity, prompt classification, model version, policy applied, and outcome per request.

What MEASURE evidence looks like in practice

A board asks "during the customer-support AI outage last month, what did the AI agent actually do during the affected window?" The MEASURE artifact is the audit record query that reconstructs the request-response sequences for the affected identities during the time window.

A regulator asks "for high-risk system X, can you produce a sample of decisions showing how the bias mitigation policy was applied?" The MEASURE artifact is the audit record filtered by system X and projected to show the policy decisions per request.

An auditor asks "what is the error rate of system Y against the eval set you committed to?" The MEASURE artifact is the eval suite results over the audit window, with the eval inputs and the model outputs preserved.

Where MEASURE maps to other regimes

EU AI Act Article 12 (record-keeping) and Article 19 (automatically generated logs) require the per-decision record. NIST CSF Detect function overlaps. ISO 42001 Annex A controls reference the evaluation evidence. The audit record is what makes the function operationally meaningful across all of them.

Common MEASURE gap

The most common gap is the dashboard without the underlying records. A high-level metric (95% accuracy on the eval set) without the ability to drill into specific decisions fails the auditor's drill-down questions. The fix is to write the per-decision record from the enforcement layer, not from the application.

MANAGE

The MANAGE function closes the loop. The work is to act on what MEASURE surfaced, prioritize the risks, implement corrective actions, and feed the lessons back into GOVERN.

In plain English: MANAGE answers "now that we know what's happening, what do we do about it?"

The artifact is the risk register entry per identified risk, the corrective action record per action, the post-incident review document per incident, and the GOVERN charter updates that result from major incidents.

The risk register is not a static document. Entries get added when MEASURE surfaces new risk. Entries get updated as corrective actions are taken. Entries get retired when the risk is mitigated or accepted.

What MANAGE looks like during an incident

An incident occurs: an AI system produced an inappropriate decision. The team responds. The post-incident review identifies the root cause. The corrective action is documented (a policy version update, a model swap, a process change). The risk register entry is updated. The GOVERN charter may be updated if the incident exposed a governance gap.

The full trail is the MANAGE evidence. A regulator examining the incident response asks for it. The board asks for it. The cyber insurance carrier asks for it.

Where MANAGE maps to other regimes

NIST CSF Respond and Recover functions overlap. EU AI Act Article 14 (human oversight) connects through the corrective action loop. ISO 42001 nonconformity and corrective action clauses overlap directly.

Common MANAGE gap

The most common gap is the incident response that does not feed back into governance. A post-incident review that documents what happened but does not update policy, controls, or the risk register fails the closed-loop test. The fix is to require the GOVERN charter and risk register update as a checkpoint at the end of every post-incident review.

How the four interlock

The four functions are not independent. GOVERN sets the rules. MAP populates the systems. MEASURE produces evidence. MANAGE closes the loop and updates the rules.

The interlocking is what makes the framework operational. A GOVERN charter without a MAP inventory has no scope. A MAP inventory without MEASURE has no observation. MEASURE without MANAGE has no corrective response. MANAGE without GOVERN has no decision authority.

The audit record at the AI request layer feeds all four. GOVERN consumes summary metrics from the record. MAP gets a real-time inventory side effect from the record. MEASURE is the record. MANAGE queries the record for incident reconstruction and corrective action evidence.

Implementation order

For an organization starting an AI RMF program, the order is:

GOVERN first, lightly. Adopt a minimal charter that names the owner, the committee, and the cadence. The charter expands as the program matures.

MAP next, starting from the AI traffic the security team can already see. Use the discovery side effect of any enforcement layer that is being deployed. Add procurement-side disclosure for vendor-embedded AI.

MEASURE immediately, in parallel with MAP. The per-decision record at the inference layer starts producing evidence from the first day the enforcement layer is in front of production traffic.

MANAGE follows naturally from the first incident. The post-incident review is the entry point.

The mistake to avoid is to do GOVERN exhaustively before MAP. The charter that is finalized over six months before any operational implementation begins typically does not survive contact with the operational reality.

DeepInspect

This is the architectural layer that produces MEASURE evidence and feeds MAP and MANAGE. DeepInspect sits inline between authenticated users and agents and any HTTP-based LLM endpoint. The per-decision audit record is what MEASURE asks for. The traffic discovery side effect populates the MAP inventory. The incident reconstruction query supports MANAGE.

The GOVERN function is not what a product produces. It is what the organization decides. But the operational evidence layer DeepInspect produces is what makes GOVERN decisions defensible.

If you are standing up an AI RMF program and want to see the operational layer that produces evidence for MAP, MEASURE, and MANAGE simultaneously, let's talk today.

Frequently asked questions

Is the AI RMF mandatory?

The framework itself is voluntary. The artifacts it asks for align with mandatory regimes (EU AI Act, ISO 42001, sector-specific rules). Most large enterprises that have not adopted the AI RMF still produce equivalent artifacts under other regimes.

What is the right size of risk committee?

Small enough to make decisions, large enough to cover the perspectives. A cross-functional group of five to nine, with named decision authority, meets the test.

How often should the inventory be refreshed?

Continuously, if the source is an operational layer. Quarterly at minimum if the source is manual. The inventory should never be more than one quarter stale.

Does the framework apply to internal-use AI like coding assistants?

Yes, in proportion to the risk. A coding assistant used by engineers on internal repositories sits at a lower risk tier than a customer-facing decision system but is in scope.

How does the AI RMF relate to ISO 42001?

ISO 42001 is a certifiable management system standard. The AI RMF is a framework. The two align on most of the same artifacts. An organization can implement the AI RMF as the substrate for ISO 42001 certification.