GOVERN gets the policy attention. MEASURE gets the data science attention. MAP and MANAGE, the functions that bracket the measurement work, are where AI risk management actually closes the loop, and they are the two most teams operationalize worst. MAP is where you establish what could go wrong, in context, before you have measured anything. MANAGE is where you decide what to do about the risks you measured and then actually do it. Skip the first and your measurements have no frame. Skip the second and your measurements have no consequence.
The result, in a lot of organizations, is a broken loop. Risks get identified in a workshop, metrics get computed in a notebook, and nothing connects the two to a recorded decision and a tracked action. The RMF is designed as a cycle. The back half is where the cycle either turns or stalls, and where a second-line reviewer learns whether your program is real.
What MAP and MANAGE Actually Require
The NIST AI RMF (AI 100-1) has four functions: GOVERN, MAP, MEASURE, and MANAGE. MAP comes after GOVERN; MANAGE comes after MEASURE. Together they bracket the measurement work.
MAP establishes context and frames risk. Its categories include:
- MAP 1. Context is established and understood: the intended purpose, deployment setting, the AI actors involved, and the system's place in the broader business and societal context.
- MAP 2. The AI system is categorized; its capabilities, the tasks it performs, and the methods it uses are documented.
- MAP 3. AI capabilities, targeted usage, goals, and expected benefits and costs are understood relative to appropriate benchmarks.
- MAP 4. Risks and benefits are mapped for all components, including third-party software and data.
- MAP 5. Impacts to individuals, groups, communities, organizations, and society are characterized (MAP 5.1 covers likelihood and magnitude of impact).
The thread through MAP is context before measurement. You cannot pick the right fairness metric in MEASURE until MAP has told you who the system affects and how. MAP is the function that keeps you from measuring the wrong things with great precision.
MANAGE acts on measured risk. Its categories include:
- MANAGE 1. AI risks based on MAP and MEASURE outputs are prioritized, responded to, and managed. This includes deciding which risks to treat and documenting the basis for the decision (MANAGE 1.3 covers responses to high-priority risks: mitigate, transfer, avoid, or accept).
- MANAGE 2. Strategies to maximize benefit and minimize negative impact are planned and resourced, including mechanisms to sustain value and to deactivate systems that exceed risk tolerance.
- MANAGE 3. AI risks from third-party resources are managed, monitored, and documented.
- MANAGE 4. Risk treatments, including responses to incidents, are documented, monitored, and improved over time, with mechanisms to track and respond to identified and emergent risks (MANAGE 4.1).
The thread through MANAGE is recorded decision and tracked action. Every risk that MEASURE quantified has to land somewhere: treated, transferred, avoided, or formally accepted, with a record of who decided and what they did.
Why This Is Hard in Practice
The back half of the RMF breaks in predictable places.
MAP gets done once and goes stale. Context is established at project kickoff, intended purpose, affected populations, third-party dependencies, and then the system evolves. A new data source is added. The model is repurposed for an adjacent use case. A vendor API gets swapped. The original MAP artifact still describes a system that no longer exists, and nobody re-mapped. MAP 4's requirement to account for third-party components is especially fragile here, because dependencies change quietly through pull requests, not through governance reviews.
The handoff between MEASURE and MANAGE is informal. A fairness metric breaches a threshold. Now what? In many organizations the answer is an email, a meeting, a verbal "let's keep an eye on it." The risk was measured but the response, the MANAGE 1.3 decision to mitigate or accept, was never recorded as a decision. When an auditor asks how you responded to the breach, you have the breach but not the response.
Risk acceptance has no owner and no expiry. Accepting residual risk is a legitimate, NIST-sanctioned response. But an acceptance with no named owner and no review date is just a way of making a risk disappear. The model that was "accepted as residual risk" two years ago is still running, against a context that has shifted, with nobody accountable for revisiting the decision. In a regulated firm, that orphaned acceptance is the finding examiners write up first.
Incidents don't feed back. MANAGE 4 is explicitly about documenting incidents and improving treatments over time. In practice, incidents get firefought and forgotten. The loop that should connect a real-world failure back to a revised MAP and a new measurement rarely closes, so the same class of incident recurs.
Each of these is a loop that didn't close. The risk was framed in MAP or measured in MEASURE, but the line to a recorded, owned, tracked response in MANAGE was never drawn.
What Good Evidence Looks Like
An auditor reviewing MAP and MANAGE is testing whether the loop actually turns. The evidence that shows it does:
A living context record. The MAP artifacts, intended purpose, affected groups, third-party components, impact characterization, are versioned and current, not frozen at kickoff. When the system changed, the MAP changed, and the change is dated. An auditor can see that context tracking is continuous, satisfying the spirit of MAP 1 through MAP 5.
Risk responses tied to specific risks. Each prioritized risk from MEASURE has a recorded response: mitigate, transfer, avoid, or accept (MANAGE 1.3). The response names the decision-maker and the rationale. The auditor can trace a line from "this metric breached this threshold" to "this person decided this treatment on this date."
Risk acceptances with owner and review date. Every accepted residual risk has a named accountable owner and a scheduled re-evaluation. An acceptance is a decision with a half-life, not a permanent exemption. The record shows when it will be revisited.
Deactivation criteria that exist before they're needed. MANAGE 2 calls for mechanisms to deactivate systems that exceed risk tolerance. Good evidence includes the predefined conditions under which a system gets pulled, written down in advance, so the call is policy rather than panic.
Incident records that close the loop. When something went wrong, the record shows the incident, the treatment, and the feedback into a revised MAP or a new measurement (MANAGE 4.1). The auditor can see the loop turning: failure, to learning, to changed control.
The unifying test: pick any risk and trace it end to end. Was it framed in context (MAP)? Quantified (MEASURE)? Responded to with a recorded, owned decision (MANAGE)? If you can walk that path for any risk an auditor names, the loop is closed.
A Runtime Approach to Closing the Loop
The handoff that breaks most often, MEASURE to MANAGE, closes most reliably when the response is enforced at the point of action and the enforcement is recorded. If a measured risk maps to a deterministic policy, then "we decided to restrict this" stops being an email and becomes a rule the system actually applies to every relevant action, with each application logged. The risk response and the evidence of the risk response are the same artifact.
This is the shape of the Cytra approach. The managed gateway evaluates every AI and agent action against deterministic policy, and the credential-brokering and sandboxed-execution layers mean a MANAGE decision, restrict this tool, scope down that permission, block that capability, is enforced at runtime with short-lived scoped tokens and deny-by-default execution, while each enforcement is written to a per-tenant, tamper-evident ledger. A risk acceptance, a restriction, an incident-driven control change: each becomes a recorded, queryable event rather than a decision that lives only in someone's memory. The gateway is in private beta. The principle behind it is durable. Compliance is a record of how your AI runs, not a document you assemble, and that principle is squarely aimed at the loop MANAGE asks you to close. For a Head of AI Governance or Model Risk, the payoff is being able to trace any risk from context through measurement to an enforced, recorded response without reconstructing the middle.
As always, the honest framing: this maps your MAP and MANAGE activities to NIST AI RMF control objectives so you can evidence them. It does not certify you and does not guarantee compliance. Whether your context is correctly framed and your responses are adequate remains your judgment. What the record gives you is proof the loop turned.
Takeaway: A MAP and MANAGE Checklist
To keep the back half of the RMF from stalling, confirm that for any AI system:
- Context is current. MAP artifacts, purpose, affected groups, third-party components, impacts, are versioned and updated when the system changes, not frozen at kickoff (MAP 1 through 5).
- Third-party dependencies are mapped and managed. Vendor models, data, and tools are accounted for in both MAP 4 and MANAGE 3, and re-checked when they change.
- Every measured risk has a recorded response. Mitigate, transfer, avoid, or accept, with decision-maker and rationale captured (MANAGE 1.3).
- Acceptances have owners and expiry. No residual risk is accepted without a named owner and a review date.
- Deactivation criteria exist in advance. You know, before you need it, what conditions pull a system from production (MANAGE 2).
- Incidents feed back. Documented incidents revise the MAP or trigger new measurement, closing the loop (MANAGE 4.1).
- Any risk traces end to end. You can walk a single risk from context to measurement to enforced, recorded response.
MAP frames the risk. MEASURE quantifies it. MANAGE acts on it. The RMF only works as a loop, and the loop only counts if you can show it turning.