MAP 3.2 Potential costs of errors: requirements and evidence

What MAP 3.2 asks you to document about AI error costs

MAP 3.2 asks your organization to examine and document the potential costs of AI errors and of shortfalls in functionality and trustworthiness, including costs that have no price tag, and to tie those costs to your organizational risk tolerance. It sits in MAP 3 of the Map function in NIST AI 100-1, alongside the benefits, scope, proficiency and oversight topics. The NIST AI RMF is voluntary and has no certification, so nobody issues a MAP 3.2 pass. The evidence is your own documentation: a cost analysis for each system, the reasoning behind it, and the decision it informed. An independent assessor or a customer's due diligence team will read that record and ask whether it is specific, current and actually used at the go or no-go point.

The hard part is that much of the harm falls on people and communities, and it is difficult to put a dollar figure on a wrongful denial, a misdiagnosis or a biased ranking. The Playbook suggests starting with a map of who and what could be harmed, when and how. In practice, that means listing each affected group (applicants, patients, employees, customers, bystanders), each failure mode the system can produce, the point in the workflow where the error lands, and whether the harm is immediate or appears later. Some entries will be quantifiable, such as refund volume or rework hours. Others, such as loss of trust or reduced access to a service, will need qualitative descriptions and a stated severity scale. Ask your product owner and risk lead to agree on that scale before anyone scores it.

Once the harms are mapped, the Playbook suggests regularly evaluating both qualitative and quantitative costs of internal and external system failures to inform go or no-go decisions. Record who reviewed the analysis, which risk tolerance statement it was measured against, and what the decision was. Revisit the record when the system's data, users or scope change, because a cost estimate written for a pilot rarely holds for a national rollout. The Playbook is voluntary and its audit log shows its last content update in August 2023, so confirm current wording with the NIST AI RMF Playbook and your own legal and risk teams rather than treating its suggestions as a fixed checklist.

Which AI systems, teams and third parties fall under MAP 3.2 scope

MAP 3.2 asks for potential costs of errors to be examined and documented, so the first job is deciding what the analysis covers. The cards below set out the scoping decisions that determine which systems, users, third-party inputs and risk limits the cost analysis must reflect.

AI systems and components in scope

Decide which models, pipelines, prompts, retrieval indexes, decision rules and integrations count as part of the AI system whose errors you are costing. A model that looks minor on its own can drive a costly decision once it feeds a downstream workflow. Write the boundary down and confirm that each component has an owner, so no error path sits outside the analysis by accident.

Downstream users and decision makers

List the people who act on the system's output, including staff who override it, customers who receive its results and managers who rely on its summaries. Errors often cost the most where users trust output without checking it. Ask which users could be misled, how quickly they would notice a wrong answer, and what they would do next.

Affected groups and bystanders

Identify people who never use the system but still bear its errors, such as applicants, patients, account holders or members of the public. Their costs are often non-monetary, including loss of dignity, denial of service or harm that is hard to reverse. The Playbook suggestion to map who and what could be harmed, when and how applies directly to this group.

Third-party models and data sources

Record every external model, API, dataset and pre-trained component that feeds the system, along with the vendor responsible for it. An error that starts upstream may not be visible in your own logs, so the cost analysis must reflect failures you cannot directly test. Ask vendors what change notices, error reporting and service limits they provide, and confirm them in the contract.

Risk tolerance from GOVERN 1

The risk tolerance documented under GOVERN 1 sets the threshold against which error costs are judged. Confirm that the tolerance names acceptable error types, magnitudes and frequencies for this system, not only a general statement about trustworthy AI. Without it, the cost analysis has no benchmark for a go or no-go decision.

Teams owning the cost analysis

Name the people who examine and record error costs, usually spanning AI design, development, operations and monitoring, and impact assessment. Each group sees different failure modes, so a single team estimating costs tends to miss some. Confirm who signs off the documented costs and how that record is updated after an incident.

How an assessor tests MAP 3.2 evidence

This table sets out what a reviewer checks for each in-scope AI system when testing MAP 3.2, from the existence of the analysis to its link with risk tolerance and go or no-go decisions. Read each row as a test step, the evidence it expects, and the common finding that signals a gap. NIST does not certify or attest to this work, so the reviewer is an internal function, a customer, or an independent auditor.

Test step	What the reviewer expects to see	Common finding
Coverage per system	A documented cost-of-error analysis exists for every in-scope AI system, including systems bought from vendors	Analysis exists for flagship systems only; smaller or embedded AI features have none
Non-monetary harms	Analysis names who or what could be harmed, how, and when, including safety, rights, trust and service impacts	Costs documented only in financial terms, such as refunds or fines, with no harm to people recorded
Realized incidents	Incident records and near misses feed back into the analysis with updated cost estimates	Analysis written before launch and never refreshed after production errors
Qualitative and quantitative costs	Both kinds of cost are recorded for internal and external failure modes, with the basis for each estimate stated	Numbers appear without method, owner or assumptions, so they cannot be re-tested
Link to risk tolerance	Stated thresholds from the organization's risk tolerance (MAP 1 and GOVERN 1) are cited against each cost finding	Tolerance is defined in policy but never referenced in the cost analysis
Go or no-go decision	Minutes or sign-offs show the cost analysis informed deployment, continuation or shutdown decisions	Analysis is attached to the project file but no decision record cites it
Ownership and review	Named roles from the AI actor categories responsible for the analysis, with a review date and change log	No accountable owner; review happens only when an auditor asks
Third-party AI	Vendor failure costs and contingency assumptions are included where the system depends on third-party models or data	Vendor-supplied AI is excluded because the organization did not build it

How to build the cost-of-errors analysis step by step

This sequence turns MAP 3.2 from a general concern into a documented record that names who could be harmed, how much failures could cost, and whether the organization's risk tolerance accepts that exposure before the system goes live or continues in service.

Identify affected parties and harm pathways
Start by listing every group the system can touch: end users, customers, employees, affected communities, operators, and third parties such as data providers or model vendors. For each group, describe how harm could occur, when it could occur (during development, at deployment, or during later operation) and through which mechanism, such as a wrong output acted on by a person, an automated decision with no review, or a data exposure. The Playbook suggests mapping who and what could be harmed, when and how. The output is a harm pathway register with one row per party and mechanism, reviewed by the AI design and impact assessment owners. The step is complete when each pathway names a party, a trigger and a consequence.
Define expected and realized error scenarios
Turn each harm pathway into concrete error scenarios. Separate expected errors, which the team anticipates from testing and known limits, from realized errors, which come from incidents, production monitoring, or failures found in comparable systems. Include functionality and trustworthiness failures, such as drift, bias in outcomes, unavailable service, or insecure behavior, not only a single wrong answer. Ask development and operations staff to describe what they have seen. The output is a scenario list with a short description, a likelihood note based on available evidence, and a link to the harm pathway it tests. The step is complete when every high-impact pathway has at least one scenario.
Estimate qualitative and quantitative costs
For each scenario, record the costs that follow. Quantitative costs can include remediation effort, service credits, regulatory penalties, legal settlements, or lost revenue, and each figure needs a stated basis and source. Qualitative and non-monetary costs include harm to individuals, loss of trust, reputational damage, discrimination exposure, and effects on the communities served. Where a number cannot be supported, record the assumption and the owner who will confirm it rather than leaving the cell blank. The output is a cost table per scenario showing both kinds of cost, the assumptions behind them, and the reviewers who signed off. The step is complete when every scenario has a cost entry in each column.
Relate costs to documented risk tolerance
Compare each cost entry with the organization's risk tolerance statement, which should already exist under GOVERN 1 and MAP 1. Decide which scenarios fall within tolerance, which exceed it, and which need treatment before any further decision. Where tolerance is stated only in general terms, record the threshold that was applied so a reviewer can follow the reasoning. Governance leaders, not only the project team, should review scenarios that exceed tolerance on either monetary or harm grounds. The output is a tolerance comparison table with a within, exceeds, or unclear result for each scenario and the named approver. The step is complete when no scenario is left without a tolerance result.
Record the go or no-go decision and review date
Summarize the analysis into a decision record that states whether the system may proceed, proceed with conditions, or stop, with the scenarios and costs that drove the decision. List the treatments required for any exceeded scenario and the residual risk accepted by the accountable executive. Set a review date and name the triggers that would reopen the analysis, such as a material model change, a new incident, or a change in the intended use. The output is a signed decision record stored with the AI inventory entry, linked to the MANAGE 1 residual risk documentation. The step is complete when the decision, approver, and next review are recorded and visible to the teams that operate the system.

How to characterize non-monetary costs without inventing numbers

Most of the harm an AI error causes does not arrive as an invoice. MAP 3.2 asks you to document potential costs, including non-monetary costs, so start by listing the harm categories that apply to this system: loss of trust among customers and staff, discriminatory outcomes for particular groups, safety impact on people or equipment, privacy harm from exposed or misused personal data, and reputational damage that outlasts the incident. For each category, record who could be harmed, how the harm would surface, and which stage of the lifecycle makes it most likely. The NIST AI RMF Playbook suggestions for this subcategory point the same way, asking organizations to map who and what could be harmed, when and how.

Once the harm categories are listed, rate each one on a shared qualitative scale, such as negligible, moderate, significant and severe, with written definitions that the risk owner signs off. Attach a short rationale to every rating so an assessor can see why a harm landed where it did. Where quantitative data already exists, such as incident counts from a pilot, support tickets, complaint volumes, downtime records or the cost of a past manual review, use it to anchor the scale, and say which ratings rest on measured data and which rest on judgment. Do not convert a severity rating into a currency value unless your own records support that conversion. Ask the business owner which internal figures they already track, because those are usually more defensible than any external benchmark.

The Playbook also asks you to evaluate the qualitative and quantitative costs of internal and external system failures on a regular basis, and to use that evaluation to inform go or no-go decisions. Put this on a recurring calendar item tied to MANAGE 1 decisions, and record the date of each review, the ratings that changed, and the evidence behind any change. Confirm with your legal and privacy teams which harms trigger notification duties under the laws that apply to you, since those duties will shape how severity is defined. The output should be a register that a non-specialist executive can read in a few minutes, with every number traceable to a source and every unmeasured harm clearly marked as judgment.

Evidence that satisfies MAP 3.2 and how to keep it current

MAP 3.2 is met by documents that show costs were examined, recorded and tied to risk tolerance, not by a single report. The five artifacts below connect one to another, so a change in one (an incident, a new tolerance) flows through the others. Each card names who keeps it current so the record stays accurate between assessments.

Error scenario register

This is the list of expected and realized AI errors for the system, with who or what could be harmed, when, and how. For MAP 3.2 it is the starting point, because every cost estimate traces back to a named scenario. Check that each entry names a system function and a affected party, that failures of third-party models and data are included, and that the register is dated. The product owner and the AI design lead draft it, and the risk function reviews it. Refresh it at each material change to the model, data or use case.

Cost characterization worksheet

This worksheet records the qualitative and quantitative costs of each scenario, covering financial loss, customer harm, legal exposure, safety impact and reputational damage. Ask for both internal failures and external failures, since the Playbook suggests evaluating both. Every cost line should state its basis, whether a measured figure, a sourced estimate or a judgment, so an assessor can see where numbers came from. The risk analyst owns it, with input from operations and legal.

Risk tolerance reference

This is the approved statement of how much harm the organization will accept from AI errors, set by executive leadership under the GOVERN policies. MAP 3.2 asks that costs be read against this tolerance, so the document must be specific enough to say whether a given cost is acceptable. Check that it has a version, an approver and a review date. The chief risk officer or equivalent owns it, and the board or risk committee approves changes.

Decision record with reviewer sign-off

Each go or no-go decision should record which costs were weighed, against which tolerance, and who approved the decision. Without this record, the cost analysis cannot be shown to have informed anything. Include the dissent or open risks that were accepted, with the name of the accepting role. The system owner prepares it and the accountable executive signs. Confirm with your auditor how they expect sign-off to be evidenced in your environment.

Incident-driven updates

Each AI incident, near miss or user complaint is a test of the scenario register. Record whether the realized cost matched the estimate and, if not, revise the worksheet and the register together. Track the incident log entries back to the scenario they confirm or contradict. The incident response lead owns the log, and the risk owner signs off on revisions. Schedule a review of the full set at least once a year and after any major model or use change, since NIST expects the framework itself to be formally reviewed no later than 2028.

What meeting MAP 3.2 costs in money and effort

This table breaks down who spends time or money on MAP 3.2 work, whether each cost is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to see where self-hosted tooling changes the spend. No prices or durations are stated because none were supplied.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Cost-of-error mapping workshops	Risk, legal, product and engineering staff, plus a facilitator	One-time to set up, then recurring at each review	Number of stakeholder groups and harm scenarios to cover
Harm and impact documentation	Product owner and risk lead writing who could be harmed, when and how	One-time per system, updated on change	Number of user groups and affected communities identified
Qualitative and quantitative failure cost estimates	Finance, engineering and risk staff estimating internal and external failure costs	Recurring, tied to go or no-go decisions	Incident history, data availability and number of third-party dependencies
Evidence upkeep	Compliance or GRC staff keeping records of cost assessments current	Recurring	Frequency of model, data or context changes that invalidate prior estimates
External review or red-team input	Independent reviewer or security testing firm, if used	Optional, usually per engagement	Scope of systems tested and the depth of harm scenarios examined
Reviewer and sign-off time	Senior risk owner or executive approving the documented costs	Recurring at each go or no-go decision	Number of systems, decision frequency and escalation paths
Self-hosted GRC tooling	Internal platform team to deploy and maintain; license spend reduced where open-source tools replace paid suites	Setup one-time, hosting and upkeep recurring	Number of frameworks tracked and the internal capacity to run the platform

Who owns MAP 3.2 and what an implementation partner can take

MAP 3.2 asks that potential costs of AI errors be examined and documented in relation to your organizational risk tolerance. That tolerance is a leadership decision. Your executives, risk owners and the business owner of the AI system decide how much harm is acceptable, which costs count (including non-monetary costs such as customer trust, safety, legal exposure and affected communities), and what happens when the analysis shows a cost above that line.

Risk tolerance: Setting the thresholds that the cost analysis is measured against.
Cost judgments: Deciding how to weigh financial loss, harm to people and reputational damage.
Go or no-go decisions: Recording who approves deployment and on what basis.
Harm mapping: Confirming who could be harmed, when and how, using knowledge of your users and operations.
Documentation ownership: Keeping the signed analysis current as the system changes.

Confirm internally that the named accountable executive has approved the tolerance statement before any outside party reviews the analysis.

Common gaps in AI error cost documentation

Most organizations can list the AI errors they worry about, but few document what those errors cost across the business. The gaps below are where MAP 3.2 documentation usually breaks down, and each one has a concrete check to run before the documentation is treated as complete.

Costs limited to revenue loss

Many cost estimates count only lost sales, refunds or fines and miss harm to people, reputational damage, loss of trust, regulatory scrutiny and workforce strain. MAP 3.2 asks for non-monetary costs as well, so a cost register built only on money leaves out the impacts most likely to change a go or no-go decision. Check whether each documented error type has at least one non-monetary cost entry, such as harm to a affected person, a community or a service user.

No link to risk tolerance

Cost figures are only useful when they are compared with the level of harm the organization has agreed to accept. Without a documented risk tolerance, teams cannot tell whether a given error cost is acceptable, and the cost analysis stays a list of numbers with no decision attached. Confirm that each cost entry names the tolerance threshold it is measured against and the owner who approved that threshold.

Realized incidents never fed back

Cost estimates are often written once, before deployment, and never updated after the system produces real errors. The Playbook suggests regularly evaluating the costs of internal and external system failures, so a documented cost model that ignores incident tickets, user complaints and near misses describes the system as it was expected to behave, not as it behaves. Check that incident records have a defined path back into the cost model and a review date.

Third-party model failures ignored

Organizations that use pre-trained models, hosted AI services or vendor components often estimate costs only for their own code and data. When a supplier model changes behavior, degrades or becomes unavailable, the downstream harm still lands on the organization. Confirm that the cost analysis covers failures of each third-party component it depends on, and that the contract or service terms are reviewed for what the supplier will and will not cover.

No decision record

A cost analysis that does not show what was decided, by whom and on what evidence cannot support a go or no-go determination later. Auditors, regulators and internal reviewers look for the link between the documented costs and the deployment decision. Check that each cost analysis is stored with the decision it informed, the approver, the date and the conditions attached, so the reasoning can be reconstructed after an incident.

Questions buyers ask about MAP 3.2

How much effort does MAP 3.2 take to complete?

The effort depends mainly on how many AI systems are in scope, how many people and processes each system touches, and how much historical error data the organization already holds. No public source supplied here gives a duration or headcount for MAP 3.2, so treat any figure you hear with caution and ask for it to be built from your own inventory. Work usually splits into identifying who or what could be harmed and how, estimating the cost of internal and external failures in both monetary and non-monetary terms, and recording the results against your stated risk tolerance. Each system you add multiplies the work, while systems that share a documented method and template take less time to repeat. Ask any provider to show the list of systems, stakeholders and cost categories it will assess before agreeing to a number.

Can we do MAP 3.2 in-house without outside help?

Yes. NIST AI 100-1 is voluntary and does not require any outside party, so an organization can perform MAP 3.2 with its own staff. The NIST AI RMF Playbook offers suggested actions and documentation prompts for this subcategory, but it is not a checklist, so your team still has to decide what counts as a cost of error for each system. Internal teams usually need people from product, legal, security, operations and the business owner of the risk decision, because the cost analysis cannot be done by engineers alone. Outside help is most useful when the internal team lacks experience estimating harm, or when the same method must be repeated across many systems on a regular schedule.

What does an implementation partner handle for MAP 3.2?

An implementation partner can prepare the systems, records and evidence that support the analysis, but the organization owns the risk decisions. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside your own infrastructure, so it can help set up the registers, workflow records and evidence stores that hold your MAP 3.2 documentation. Typical written scope items include gathering system inventory data, structuring the cost-of-error register, linking entries to the relevant AI actor categories and preparing review records. DeployOpen does not set your risk tolerance, decide go or no-go outcomes, or issue any assessment report. Those remain with your accountable executives and, where needed, an independent assessor. Confirm the exact deliverables in a written scope before work starts.

Does NIST certify organizations for MAP 3.2?

No. NIST has no certification, accreditation or conformity assessment program for the AI RMF, and it does not validate or endorse any organization's use of the framework. A claim that an organization is "MAP 3.2 certified" has no basis in NIST's published materials. If a customer or regulator asks for evidence, provide your documented analysis, the risk tolerance it references, and the review records. Where an independent view is required, engage an auditor, assessor or other qualified party whose role is defined in your contract. Ask any firm offering a MAP 3.2 "certificate" to name the body that issues it and the standard it tests against.

How does MAP 3.2 relate to the Generative AI Profile?

NIST AI 600-1, the Generative AI Profile published July 26, 2024, lists no suggested actions for MAP 3.2. The profile states that not every AI RMF subcategory is included and that unaddressed subcategories may be added later. For a generative AI system, you still need to complete MAP 3.2 using the base framework and the Playbook. Use the profile's twelve generative AI risks as inputs when you identify what could go wrong, such as harms from confabulated or misleading output, so that those risks feed into your cost-of-error analysis. Document that you used the profile as context rather than as a source of MAP 3.2 actions, because a reviewer may ask why no profile guidance exists for this subcategory.

How often should we refresh the MAP 3.2 analysis?

Refresh the analysis whenever something changes that could alter the cost of errors, and review it on a fixed schedule set by your governance policy. NIST's framework is built around continuous review, so triggers usually include a change in the system's purpose or user base, a new third-party model or data source, a significant incident, or a change in the regulatory environment. NIST says the framework itself is being revised as part of the White House AI Action Plan, and it expects a formal review with community input no later than 2028, so your documented version should note which edition of AI 100-1 it follows. Ask your provider to define the trigger list and review cadence in the written scope so the schedule is contractual rather than informal.

Where open-source compliance tooling helps with MAP 3.2

CISO Assistant is an open-source governance, risk and compliance platform that you can host yourself. Its community edition ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and it supports running audits and compliance assessments against them with automatic mapping between frameworks. For MAP 3.2, its value is as a system of record: a place to register the AI system, link its risks, store the cost-of-error analysis and track the decisions that follow from it. The tool does not perform the NIST AI RMF cost analysis for you, and you should confirm its current NIST AI RMF coverage directly in the project's documentation before you build a workflow around it.

Register the AI system: Record the system, its owner and its intended purpose so the error-cost analysis has a defined subject.
Store error-cost records: Keep the documented costs of expected and realized errors, including non-monetary harms, linked to the relevant risks.
Track assessments: Assign assessment tasks, record responses and keep dated versions for review.
Link to other frameworks: Use automatic mapping where the tool provides it, and verify each mapping before relying on it.
Export records: Produce documents for internal review, assessors or customers.

Confirm the AI RMF content, mapping coverage and version in the README before you plan your MAP 3.2 workflow.

How DeployOpen prepares MAP 3.2 evidence

DeployOpen starts with a written scope that names the AI systems covered, the business units and decision-makers involved, the cost categories to be examined, and the deliverables the client will receive. Before any analysis begins, the client confirms which risk tolerance statement applies, because MAP 3.2 asks that potential costs be documented in relation to that tolerance. DeployOpen then facilitates the cost analysis workshops with the people who own the system, the people who operate it and the people who would absorb the consequences of a failure. The output of those sessions is the cost-of-error register, which records who or what could be harmed, when and how, and the qualitative and quantitative costs of internal and external failures. Any monetary figures in the register come from the client's own finance and operational data, and the client decides how to value non-monetary costs such as customer trust or regulatory exposure.

DeployOpen builds the register, its templates and the review cadence inside the client's own environment, such as its document repository, ticketing system or self-hosted GRC tooling, so the records remain under the client's control. Templates typically include fields for the AI actor category responsible (the Playbook ties MAP 3.2 to AI Design, AI Development, Operation and Monitoring, and AI Impact Assessment), the go or no-go criteria, the review trigger and the named risk owner. Where a generative AI system is in scope, the team also checks the NIST AI 600-1 Generative AI Profile, which lists no suggested actions for MAP 3.2, so the register should be built from the core Playbook guidance instead. Confirm with your own assessors which additional evidence they expect for that case.

DeployOpen then prepares the evidence package for the client's internal reviewers, internal audit or an external assessor: the dated register, meeting records, sign-off history and the link between each cost entry and the risk tolerance it was measured against. DeployOpen does not issue reports, attestations or certificates. Those come from the client's own governance functions, from independent auditors or from other assessors the client engages, and no AI RMF certification exists to be issued. Ask any implementation partner to state this boundary in the written scope, and ask who will hold the final version of each artifact after the engagement closes.

MAP 3.2 Potential costs of errors