NIST AI RMF MAP Function: Deep Dive for CISOs (2026)

MAP 1 requires that the organisation documents and understands the context in which the AI system is being developed, deployed, or procured. The outcome is a written record of intended purpose, deployment setting, users, affected populations, data inputs, decision outputs, regulatory regimes that apply, and the operating environment.

A concrete example: a regional health insurer brings in a vendor AI tool that summarises prior authorisation requests for clinical reviewers. The MAP 1 record names the use case (clinical summarisation), the user population (utilisation management nurses), the affected population (members whose requests are summarised), the data inputs (clinical notes, ICD-10 codes, prior auth submissions), the decision outputs (summary text only - the human reviewer still adjudicates), the regulatory regimes (HIPAA, state insurance commissioner rules, the Colorado AI Act if Colorado members are in scope), and the operating environment (BAA in place, data residency US, vendor model is OpenAI GPT-4 class via Azure with no training on submissions).

The trap to avoid: treating context as a one-line use-case description. NIST AI 100-1 contemplates a multi-page artefact that is reviewed when the system, vendor, or scope materially changes. The Areebi platform inventory stores this context record alongside the live system so that it is impossible to add a model in production without a current MAP 1 entry.

MAP 2 requires that the AI system is categorised according to risk and other relevant factors, so that the appropriate level of oversight and controls can be applied. The outcome is a documented risk tier (with a rationale) that drives downstream MEASURE and MANAGE decisions.

A concrete example: the same insurer rates the prior authorisation summariser as "high impact" because errors could plausibly affect benefit decisions, even though the human reviewer is the formal decision-maker. That high-impact rating triggers stricter requirements: monthly accuracy spot-checks, mandatory pre-deployment red teaming, a published model card to clinical leadership, and the right to disable the tool on 24-hour notice if accuracy degrades. By contrast, an internal marketing copy assistant that affects no external party and produces no decision artefact is rated "limited impact" and runs on lighter-touch monthly review.

The trap to avoid: treating risk categorisation as static. NIST AI 100-1 expects re-categorisation when the model is retrained, repurposed, or moved to a new population. The EU AI Act uses parallel categories (prohibited, high-risk, limited, minimal) and ISO/IEC 42001 expects risk classification to be reviewed at least annually as part of the management system. CISOs should align internal risk tiers with EU AI Act categories where the organisation has EU exposure, because that mapping cuts downstream documentation effort substantially.

MAP 3 requires that the AI capabilities, targeted usage, goals, expected benefits, and costs of the AI system are understood, documented, and communicated. The outcome is a model and use-case card that records what the system can do, what it cannot do, the assumptions behind it, and the expected benefits net of costs.

A concrete example: a financial services CISO documents the targeted usage of a fraud-triage model: "rank inbound transactions by fraud likelihood for queueing to human reviewers; the model does not make automated decline decisions". The capabilities record includes the model architecture (gradient boosting on tabular features), the training data window (rolling 24 months of confirmed fraud and legitimate transactions), the known limitations (poor calibration on transactions from countries representing less than 0.5 percent of training volume), the expected benefit (review queue reduced by 40 percent in pilot), and the costs (vendor licence, internal MLOps support, model risk management overhead). This artefact is the source of truth used by every other function downstream.

The trap to avoid: copying vendor marketing as the capability record. NIST is clear that MAP 3 expects the deploying organisation to characterise capabilities in its own terms, with its own assumptions and its own evidence. Vendor claims are evidence inputs, not the artefact. Areebi audit logs attach the model and policy version to every interaction, which makes it straightforward to challenge vendor-supplied capability claims against actual behaviour in production.

MAP 4 requires that risks and benefits of the AI system are mapped to specific outcomes, with attention to both intended and unintended impacts on affected populations. The outcome is a structured impact assessment that goes beyond "could the model be wrong" to consider second-order effects on individuals and groups.

A concrete example: a public sector CISO running a benefits-eligibility triage model documents impacts across the lifecycle. Intended impacts: faster eligibility determinations, reduced backlog. Unintended impacts considered: disparate false-rejection rates across language groups, automation bias by caseworkers (over-reliance on model output), loss of caseworker judgment over time, model drift as eligibility rules change, vendor lock-in if vendor exits the market. Each impact is rated by likelihood and severity. Mitigations are assigned by impact, with named owners. The impact assessment is updated quarterly and after any material model change.

The trap to avoid: writing impact assessments that read like risk theatre. NIST AI 100-1 and NIST AI 600-1 (the Generative AI Profile, published 2024-07-26) both emphasise that the assessment must inform actual decisions about deployment, control selection, and ongoing monitoring. If your impact assessment never causes a control to be added, removed, or strengthened, it is not doing its job. OMB M-24-10 makes this explicit for US federal agencies: high-impact AI requires a pre-deployment impact assessment that materially shapes the deployment.

MAP 5 requires that the organisation characterises the magnitude of impact across affected stakeholders and reconciles those impacts against the organisation's risk tolerance. The outcome is a documented risk acceptance decision: who accepted the residual risk, on what basis, for what duration, and under what conditions the acceptance is revoked.

A concrete example: the CISO and the AI Governance Committee review the impact assessment for an HR screening assistant. The residual risk is documented (small but non-zero risk of disparate impact in initial CV ranking; mitigated by mandatory recruiter review of all model outputs and quarterly disparate impact testing). The risk owner (the VP of HR) formally accepts the residual risk in writing, with the acceptance valid for 12 months or until the next material model change, whichever comes first. The risk acceptance is logged in the governance committee minutes and surfaced on the executive risk dashboard. If quarterly disparate impact testing exceeds a documented threshold, the acceptance is automatically revoked and the system is paused pending review.

The trap to avoid: implicit risk acceptance. NIST expects an explicit, named, time-bound acceptance with documented revocation conditions. This is also where most internal audit findings cluster - auditors look for the named individual, the written rationale, and the link between the residual risk and the organisation's stated risk tolerance. The ISO/IEC 42001 management system clause on risk treatment is built on this same expectation.