The Govern function tells you who’s accountable. The Map function tells you what you’re actually accountable for. Most organizations skip straight from a governance policy to a spreadsheet of tools and call it done. NIST’s Map function asks for something more specific: documented context, a risk category, a capability record, an impact assessment, and a named risk acceptance for every AI system you run or procure. Eighteen subcategories across five groups. Skip any of them and Measure has nothing to test against, and Manage has nothing to act on.
Breakdown of the 18 NIST AI RMF MAP Controls
The Map function splits into five categories containing 18 subcategories total.
MAP 1: Context Is Established and Understood
1.1 Intended Purpose and Deployment Setting - document the system’s intended use, beneficial uses, applicable laws, and the specific setting where it will run.
1.2 Interdisciplinary Input - the team establishing context reflects diverse technical, legal, and domain expertise, not just engineering.
1.3 Mission Alignment - the organization’s mission and goals for using AI are documented and connected to the specific system.
1.4 Business Value Justification - the business case or R&D justification for the system is clearly defined, including exit criteria if it doesn’t pan out.
1.5 Risk Tolerance Determination - organizational risk tolerance for this system is set and documented, not inferred after the fact.
1.6 System Requirements and Design - requirements are gathered from relevant stakeholders, and design decisions account for socio-technical consequences, not just technical performance.
MAP 2: Categorization of the AI System
2.1 Task and Method Definition - the specific tasks the system performs and the methods used to implement them are documented.
2.2 Knowledge Limits and Human Oversight - the system’s known limitations and how humans are meant to use and oversee its output are documented.
2.3 Scientific Integrity and TEVV - testing, evaluation, verification, and validation considerations, including data collection methods and construct validity, are identified and documented.
MAP 3: Capabilities, Usage, Goals, and Costs
3.1 Benefits Examination - expected benefits of the system’s functionality are examined and documented, not assumed.
3.2 Cost Examination - expected and realized costs, including non-monetary costs from errors, are documented against risk tolerance.
3.3 Application Scope - the targeted scope of use is specified based on the system’s actual capability and its Map 2 categorization, not marketing claims.
3.4 Operator Proficiency - processes exist to assess and document the proficiency required for people operating or relying on the system.
3.5 Human Oversight Design - human oversight processes are defined and documented in line with the policies set under Govern.
MAP 4: Risks and Benefits Mapped for All Components
4.1 Third-Party and Legal Risk Mapping - risk mapping covers third-party data and software components, including IP infringement exposure.
4.2 Internal Risk Controls for Components - controls covering every component, including third-party AI technologies embedded in the system, are identified and documented.
MAP 5: Impacts Are Characterized
5.1 Likelihood and Magnitude of Impact - impacts (beneficial and harmful) are assessed using expected use, prior incidents in similar contexts, and outside feedback, not internal assumption alone.
5.2 Stakeholder Engagement and Feedback - practices exist for ongoing engagement with affected parties and for feeding that input back into the system’s risk profile.
The Control That Breaks Most Organizations: Map 4
Map 1 through Map 3 are hard because they require discipline. Map 4 is hard because it requires visibility you often don’t have.
Picture a mid-size SaaS vendor selling contract review software to law firms. The product embeds a third-party LLM for clause summarization, disclosed in the vendor’s Map 1 documentation at launch. Eighteen months later, the LLM provider updates the underlying model and quietly changes its terms of service to permit using customer inputs for model improvement unless the customer opts out. Nobody at the SaaS vendor reviews third-party terms on a recurring basis. Nobody’s Map 4 control caught the change. The clause summaries their law firm customers relied on are now generated by a different model version with different failure modes, and client contract language may have been used for training without the firm’s knowledge. This is a composite scenario, not a single named incident, but it’s the shape of what shows up in breach notifications and client disputes across the industry every year.
That’s the gap Map 4 is built to close:
The vendor black box. Most AI systems in production today are not built in-house. They’re a foundation model API, a fine-tuned SaaS feature, or an open-source model with a license nobody read closely. Map 4.1 asks you to document the legal and technical risk of every one of those components. Vendors routinely decline to disclose training data composition or evaluation results, citing trade secrets. You’re being asked to map risk in a system you can’t see into.
Component-level controls, not system-level assumptions. Map 4.2 doesn’t let you write “we trust the vendor” as a control. It requires internal controls at the component level: what happens if the third-party model changes without notice, what happens if the vendor’s uptime fails, what your fallback is if the component gets deprecated. Most organizations have a vendor contract. Few have a component-level control for what happens when that vendor’s model silently updates.
Shadow AI inside the components you already approved. A platform you vetted eighteen months ago may have quietly added a generative AI feature to its product since then. That feature now touches your data under the same contract, with none of the Map 1 through Map 3 work ever done for it. Map 4 requires you to catch that drift, and most inventory processes have no trigger for “your vendor added an AI feature.”
Priority Controls for Audit Season
These five carry the most audit weight and the highest likelihood of a finding if left undocumented:
The remaining 13, checklist form:
1.1 Intended purpose and deployment setting documented per system
1.2 Interdisciplinary sign-off on context (legal, domain, technical)
1.3 Mission alignment tied to a stated organizational goal
1.4 Written business value case with exit criteria
1.6 System requirements capture socio-technical implications
2.1 Tasks and methods documented in plain language
2.3 Data collection and validation methods documented
3.1 Expected benefits quantified, not assumed
3.2 Error costs weighed against Map 1.5 risk tolerance
3.3 Use scope limited to what’s actually tested
3.4 Operator training requirements defined
5.1 Impact assessments grounded in incident data
5.2 Real feedback channel for affected users
Map as Operational Infrastructure
Working through all 18 subcategories moves Map from a one-time inventory exercise to a per-system discipline that gets revisited every time a vendor updates a model, a use case expands, or a system moves to a new population. Organizations that treat Map 4 and Map 5 as seriously as Map 1 build inventories that survive an actual audit instead of collapsing the moment a regulator asks who’s accountable for the third-party model buried three vendors deep in the stack.
I read and reply to every comment on this one.
When you last reviewed your AI vendor stack, did you find a feature that wasn’t there the last time you looked?