MAP 1.5 Organizational risk tolerances: requirements

What MAP 1.5 asks organizations to decide before an AI system goes live

MAP 1.5 is the NIST AI RMF outcome stating that organizational risk tolerances are determined and documented. NIST AI 100-1 places it in MAP 1 (context), alongside the work of defining intended purpose, the team that establishes context, the mission and business value, and system requirements. If you are the compliance lead or engineer who must show how your organization decides how much AI risk it accepts, this is the decision you have to be able to point to. The risk it addresses is simple to state: an AI system goes live with no agreed limit on what harm the organization will tolerate, so each team decides for itself and nobody can show a line was drawn. NIST does not certify, assess or endorse any organization against the framework, so the evidence you produce is for your own governance, your board, your customers and any regulator who asks.

The hard part is that tolerances are highly contextual and use-case specific. AI 100-1 says they can be shaped by policies and norms set by system owners, industries or policy makers, and that they are likely to change as systems, policies and norms evolve. A tolerance that suits an internal document summarizer will not suit a system that influences credit or clinical decisions. The Playbook suggests defining risk criteria across financial, operational, safety, reputational and model sources, with severity levels for each. Agreeing on thresholds across those five sources is where most programs stall, because the finance, operations, safety and model owners each measure harm in different units. Confirm with your risk function which existing regulatory and sector criteria already apply to the system, since the Playbook suggests starting there rather than inventing new scales.

Which AI systems, data, teams and third parties fall under MAP 1.5

Before an organization can set risk tolerances, it has to decide what they apply to. The cards below cover the scoping choices that determine which systems, use cases, models and sign-off paths sit inside MAP 1.5. Each decision should be written down so an assessor can trace every deployed system back to a documented tolerance.

Systems that affect people

Start with AI systems that touch people's rights, money, safety or regulated decisions, such as credit, hiring, clinical triage or access to public services. These are the systems where a tolerance has the most consequence. Check the AI inventory from GOVERN 1 for any system that makes or informs such decisions, and record why each one is in or out of scope. The NIST AI RMF does not set thresholds for these categories, so the organization must define them and explain the criteria.

Tolerance granularity

Decide whether tolerances apply per system, per use case or per business line. A single tolerance for a business line is simpler to govern, but one model may serve several use cases with very different impacts. Per-system tolerances give the most precise control but add review work. Whichever level is chosen, state it in the policy so that a new deployment cannot skip the tolerance step.

Pre-trained and third-party models

Decide which pre-trained, vendor-supplied and open-weight models fall under the tolerance. A third-party model inherits the risks of the deployment it supports, even when the organization did not train it. Confirm what the vendor documents about training data, known limits and updates, and map those gaps against the tolerance. Coordinate with the third-party controls in GOVERN 6 and MANAGE 3 so that vendor changes trigger a fresh review.

Off-label uses and drift

Bring within scope any system used outside its intended purpose and any system whose purpose has drifted over time. A tool approved for internal document search may later be used to rank job applicants. Set a check that compares actual use with the documented context of use, and reassess the tolerance when the two diverge. The playbook for MAP 1.5 specifically suggests reviewing off-label uses.

Data and inputs in scope

Decide whether the tolerance covers only the model or also the data pipelines, training sets, retrieval sources and prompts that shape its outputs. Risk criteria for data quality, privacy and intellectual property can change the acceptable level of error for the whole system. Document which data sources are included, who owns them, and how a change in a source affects the tolerance already set.

Who signs off the tolerance

Name the role that approves each tolerance and the role that can accept risk above it. Accountability for this decision is set under GOVERN 2, and the sign-off should sit with someone who has authority over the business value and the resources needed for oversight. Ask the approver to record the tolerance, the criteria used and the date of the next review. Confirm that the approver does not also own the system being assessed.

How risk tolerance levels, maximum limits and trustworthiness tradeoffs fit together

An assessor looking at MAP 1.5 expects three layers that connect to each other. The first is tolerance levels paired with oversight: the organization states how much risk it accepts for each class of AI use and attaches the people, review cadence and approval authority that match each level. The second is the risk criteria and severity levels that give those tolerances meaning. The Playbook suggests defining criteria across financial, operational, safety, reputational and model sources, so that a single finding can be rated the same way whether it came from a fairness test, a vendor incident or a data quality problem. The third is the maximum tolerance, a line above which the system is not deployed, or is decommissioned if it drifts past it. Your job is to confirm that each layer exists in writing, that the criteria are used in MAP and MEASURE records, and that someone with authority signed the limits. The values themselves are set by your organization, informed by its existing regulatory and sector criteria, and they are expected to change as systems and norms change.

Trustworthiness tradeoffs sit beside those limits. AI 100-1 describes seven characteristics: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful bias managed. Improving one often costs something in another, so the record should show which tradeoffs were accepted and why. Illustrative example (hypothetical): a credit-decision model is tuned for higher accuracy, which makes its outputs harder to explain to applicants, so the team documents the explanation method it will use, the accuracy floor it will not go below and the reviewer who accepted the change. A second common case is privacy-enhancing techniques that reduce the data available for fairness testing. Record who weighed each tradeoff, what evidence they used, and the condition under which the decision would be reopened.

Practically, build one table per system that links each identified risk to its tolerance level, its severity rating, its oversight owner, its maximum-tolerance check and any accepted tradeoff. Ask your team to confirm that the tolerance thresholds in that table match the go or no-go decision recorded under MANAGE 1, so the maximum limit is enforceable rather than descriptive. If you are preparing for an external review, ask your assessor which of your existing regulatory criteria they expect you to map to these levels, since that mapping is an organizational decision you will need to defend.

How an assessor tests MAP 1.5 without a NIST certificate

This table sets out how an internal auditor or external assessor would test MAP 1.5, what each test looks for, the evidence they request and the findings they commonly raise. NIST runs no conformity assessment, so the test measures the organization's own documented tolerance approach against the scope it stated. Use the rows to check your own file before a review.

Test area	What the assessor checks	Evidence requested	Common findings
Written risk tolerance	A documented statement of the tolerance levels the organization accepts for AI, by risk source and severity	The approved tolerance document, with version history and the criteria for financial, operational, safety, reputational and model risk	Tolerance statements that are undated or unversioned, or that exist only as informal guidance
Approval and ownership	Who set the tolerance, who approved it and whether that person had authority over the AI risks it covers	Approval records, meeting minutes or sign-off forms, and the named owner for each tolerance level	No named approver, or approval by a team that does not own the business risk
Maximum tolerance	Whether a ceiling exists above which a system will not be deployed or will be decommissioned	The written maximum, the rule that triggers it and examples of systems tested against it	No maximum defined, or a maximum stated without a rule that applies it to a go or no-go decision
Link to MAP 1.1	Whether tolerances reflect the intended purpose, deployment setting, users and known limitations of each system	Context-of-use records for sampled systems, cross-referenced to the tolerance that applies	Tolerances written generically, with no evidence they were applied to a specific context of use
Link to MAP 1.4	Whether tolerances were weighed against the business value and context of use for each system	Business case or value assessment for sampled systems, with the tolerance decision recorded beside it	Business value documented, but no record of how the risk tolerance affected the decision
Tradeoff decisions	Whether conflicts among trustworthiness characteristics, such as accuracy against explainability or privacy against fairness, were decided and recorded	Tradeoff records with the options considered, the decision, the decision maker and the rationale	Tradeoffs acknowledged in design notes but never resolved or signed off
Review after change	Whether tolerances were revisited when a system, its data, its users or applicable policies changed	Review log, change tickets linked to tolerance reviews and dated revisions after material changes	No review after a model update, a new use case or a change in external norms, which NIST notes are likely to shift over time
Decision traceability	Whether a deployment decision can be traced back to the tolerance it relied on	Go or no-go records for sampled systems that cite the tolerance level and the measured results	Deployment approved with no reference to any tolerance, so the tolerance has no visible effect

Sequence for setting and documenting risk tolerances

This sequence turns MAP 1.5 from a statement of intent into a documented decision record. It shows who sets each tolerance, what each step produces, and how the organization can show that a system was judged against limits it set in advance.

Gather existing regulatory and sector risk criteria
Start by collecting the risk criteria your organization already applies. These usually sit in enterprise risk management frameworks, sector regulations, internal model risk policies and existing security or safety standards. Compliance, legal and the business owner of each AI use case typically do this together. The output is a register of source criteria, with each entry linked to the regulation or policy it comes from, so later tolerance decisions can be traced back to a requirement rather than to opinion.
Define risk criteria and severity levels
Using the source register, define the criteria your organization will use to rate AI risk across financial, operational, safety, reputational and model sources. For each source, write what a low, moderate and high impact looks like and define the severity levels used to describe them. Risk, compliance and the system owners should agree the wording. The output is a severity scale with written definitions for each source, approved as part of the risk policy so that two assessors rating the same harm reach the same level.
Set tolerance levels and matching oversight
For each severity level, set the tolerance the organization accepts and the oversight that must accompany it. A higher tolerance for a low-impact internal tool might require only periodic review, while a tolerance for a system that affects customers or safety might require named approvers, more frequent testing and documented escalation. Ask who has authority at each level and whether they have the staff and time to exercise it. The output is a tolerance matrix that pairs each level with its oversight resources and owner.
Set the maximum tolerance and the limit action
Define the maximum tolerance above which a system will not be deployed, or will be decommissioned if already running. Record the exact trigger, such as a severity rating that a risk assessment cannot bring below the limit through treatment, and the person who makes the call. Confirm that the limit applies to existing systems as well as new ones, and that business pressure does not override it without a documented, approved exception. The output is a written maximum tolerance with its action and decision owner.
Record tradeoffs among trustworthiness characteristics
Document where improving one trustworthiness characteristic may reduce another. Examples include accuracy against explainability, or privacy protection against fairness testing that needs sensitive attributes. For each tradeoff, record the option chosen, the reason, the risk that remains and the characteristics affected. Involve the teams who would feel the cost of each option, including model developers, privacy and business owners. The output is a tradeoff record attached to the system's risk file, which shows the decision was made deliberately.
Obtain approval from accountable leadership
Present the criteria, tolerance matrix, maximum tolerance and tradeoff record to the people accountable for AI risk decisions. Confirm that they understand the limits they are approving and who will act when a limit is reached. Record the approver, the date, the version approved and any conditions. The output is a signed or recorded approval that makes the tolerances an organizational decision rather than an analyst's draft, and that an internal or external reviewer can inspect later.
Schedule review and version the tolerances
Set a review cycle and triggers for early review, such as a material change to a system, a new regulation, an incident or a change in the business context. Risk tolerances are context specific and can change over time, so each review should compare current conditions with the approved record and version any change. The output is a dated review schedule and a change log for the tolerance documents. Note that the Playbook is a set of suggested actions, not a checklist, so use these steps as a structure to adapt to your own governance model.

Evidence that satisfies MAP 1.5 and how to keep it current

MAP 1.5 is met by documents that show tolerances were set, approved and enforced, not by a single policy statement. The six artifacts below connect to one another, so each should carry a version, an owner and a link to the system it governs. Keeping them current between assessments depends mostly on tying every update to a trigger the organization already tracks.

Approved risk tolerance statement

This is the organization's written statement of how much AI risk it will accept, dated and versioned, with the approver named. For MAP 1.5, the statement should reflect existing regulatory and sector risk criteria and state the tolerance per use case, since the AI RMF treats tolerances as highly contextual. Keep it current by requiring a new version whenever a policy, law or sector norm that it cites changes, and by linking each revision to the change ticket that prompted it. Confirm with your assessor which version was in force on any past date.

Severity and risk criteria definitions

These definitions set the scale used to rate risks, such as levels of severity and the categories of financial, operational, safety, reputational and model risk. Without them, a tolerance such as "medium" has no shared meaning across teams. Each definition should state the threshold that separates levels and who applies it. Review the definitions when the AI inventory shows new kinds of systems, and record each change so that past risk ratings can still be read against the criteria used at the time.

Maximum tolerance record and triggered decision

This record states the ceiling above which a system will not be deployed, or will be decommissioned, and names the decision that follows when a measured risk crosses it. It is the artifact an assessor is most likely to ask to see in action. Pair each system entry with its most recent measurement and the date of the go or no-go decision. Keep it current by re-checking the ceiling whenever monitoring results or incident records for that system change, and by logging any decommissioning step against the AI inventory entry.

Tradeoff log for each system

The AI RMF asks organizations to document tradeoffs among trustworthiness characteristics, such as accuracy against explainability or privacy against fairness testing. One log per system should record which tradeoff was chosen, the alternatives considered and the reason the chosen balance fits the tolerance. Tradeoffs change when models, data or deployment settings change, so the log should be updated through the same change process used for the system. Ask owners to state which trustworthiness characteristic lost priority and why.

Executive approval records

Approval records show that accountable executives accepted the tolerances and any residual risk above the standard level. They should identify the approver's role, the date, the systems covered and any conditions attached. Approvals made by a committee or a delegate should name the delegation instrument. Keep these current by setting a re-approval trigger whenever the tolerance statement changes or when a system's risk rating moves to a higher level, and by keeping signed copies in the same repository as the statement they approve.

Review log of changes after updates

The review log records each time tolerances were examined after a system change, a policy update or a new incident, along with what changed and who reviewed it. Assessors use it to test whether tolerances are living controls or one-time paperwork. Link each entry to the change ticket, the AI inventory record and any updated Playbook-based documentation. Confirm the review cadence with your own governance policy, since the framework does not set one, and make sure the log records reviews that found no change as well.

What setting AI risk tolerances costs in people, tooling and external review

This table compares the cost components of setting and documenting AI risk tolerances under MAP 1.5, showing who does the work, whether the cost is one-time or recurring, and what pushes it up or down. Read it to scope internal effort and to frame what to ask a partner for in a fixed-scope quote.

Cost component	Who does the work	One-time or recurring	What drives it up or down
Internal policy and risk staff time	Risk, compliance and AI governance staff who draft tolerance levels and approve them	Both: initial drafting is one-time, periodic review is recurring	Number of systems in scope, number of approval levels, and how often tolerances are revisited
Cross-functional workshops	Legal, security, product and domain experts who agree on severity levels and criteria	Mostly one-time, with recurring sessions when systems or rules change	Number of business lines, regulatory overlap, and how much disagreement exists on impact severity
Risk register tooling or licenses	Organization IT or a partner that configures the register	Setup is one-time, hosting and upkeep recur	Choice between commercial and self-hosted tools, and how many people need access
Engineering time to instrument measurements	Engineers who connect metrics to the criteria, such as monitoring thresholds for each tolerance	Initial build is one-time, monitoring upkeep recurs	Quality of the AI inventory, number of deployed models, and whether logging already exists
External review or advisory time	Independent advisers or assessors who challenge the tolerance logic (NIST does not validate or endorse individual organizations)	Usually periodic, tied to a review cycle or a customer or regulator request	Scope of the review, the number of sectors involved, and whether findings need re-testing
Evidence upkeep	Document owners who keep tolerance records, approvals and tradeoff notes current	Recurring	Frequency of model changes, off-label use reviews, and the number of audit requests received

Who owns tolerance decisions, what a partner prepares and what the auditor tests

The organization owns its risk tolerances. The AI RMF is voluntary and has no certification, so no outside party can set the threshold on your behalf. MAP 1.5 is about determining and documenting the level of risk your organization will accept for AI, and the decision needs named people who carry the consequences of it. Accountable executives set the tolerance and the maximum level above which a system will not be deployed. Risk owners apply those tolerances to specific systems and decide what happens when a system approaches a limit. Engineers record the metrics that show where a system sits against the criteria.

Accountable executives: approve the risk criteria, the severity levels and the maximum tolerance, and record the reasons for each choice.
Risk owners: apply the tolerances to each AI system, document the oversight resources that match each level, and escalate exceptions.
Engineers and data owners: capture measurements for the agreed criteria and keep them current as systems change.
Legal and compliance staff: map existing regulatory and sector criteria into the tolerance record.
Governance owners: schedule reviews, since tolerances are likely to change as systems, policies and norms evolve.

Confirm internally who signs the tolerance record and who can override it. Those names should appear in the record itself, not only in a policy.

Questions buyers ask about MAP 1.5 cost, effort and outside help

Can MAP 1.5 be certified?

No. MAP 1.5 is an outcome in the NIST AI Risk Management Framework, and NIST runs no certification, accreditation or conformity assessment program for the framework. NIST also states that it does not validate or endorse any individual organization's use of the AI RMF. What an organization can show is documented risk tolerances, the rationale behind them and evidence that decisions follow them. If a customer or regulator asks for a certificate, ask which independent body issues it and what it actually tests, because no such certificate exists for the AI RMF itself.

How long does setting AI risk tolerances take, and what drives that?

The duration depends on how many AI systems are in scope, how many business units and regulators shape the criteria, and how much existing risk material can be reused. NIST's Playbook suggests defining risk criteria across financial, operational, safety, reputational and model sources, plus severity levels and a maximum tolerance, so each added source adds review work. No researched duration is available for this work, so ask any partner to state the timeline in a written scope that lists the systems, stakeholders and deliverables covered.

Can an in-house team set MAP 1.5 risk tolerances without outside help?

Yes, an in-house team can do this, because the organization owns its risk tolerances and NIST describes the framework as voluntary. The work usually requires people from risk management, legal, security, the business owner and the AI product team, and someone must keep the criteria and their rationale current. Outside help is most useful when the team lacks time, has no shared risk vocabulary, or needs the criteria mapped to existing enterprise risk tooling. A partner prepares systems and documentation, but the organization makes the decisions and an independent assessor reviews the result if one is required.

What do executives need to contribute to risk tolerance decisions?

Executives must decide how much risk the organization accepts, which system must never be deployed above a given level, and who signs off on exceptions. NIST's Playbook links tolerance levels to matching oversight resources, so leaders must also fund the monitoring, review and staffing that each tolerance level requires. Expect executives to approve the maximum tolerance, confirm the severity scale and accept the tradeoffs among trustworthiness characteristics in writing. Without that sign-off, the tolerances tend to remain technical settings that no one is accountable for enforcing.

What should a quote for MAP 1.5 work include?

A useful quote lists the scope before the price: which AI systems, business units, regulations and risk sources are covered, and which deliverables are produced. Ask for the following in writing:

The systems and use cases included, with any off-label uses to be reviewed
The risk criteria sources, severity levels and maximum tolerance to be documented
Who participates from the client side and how many review rounds are included
What is one-time work and what recurs, such as annual review or retainer support
Exclusions, assumptions and the acceptance criteria for each deliverable

DeployOpen works from a written scope and does not publish a price list, so compare quotes on these items rather than on headline figures.

Must risk tolerances change when NIST revises the AI RMF?

Not automatically, but organizations should plan to review them. As of October 2026, NIST says AI RMF 1.0 is being revised under the White House AI Action Plan and has not published a revised version. NIST's own guidance notes that risk tolerances are contextual and likely to change over time as systems, policies and norms evolve. Keep the tolerance rationale and its sources recorded so that a later review can show what changed and why. Check any state law or customer contract that cites a specific version of the framework, since those references may need updating.

Does the Generative AI Profile add suggested actions for MAP 1.5?

No. NIST AI 600-1, the Generative AI Profile published in July 2024, lists no suggested actions for MAP 1.5. The profile states that not every AI RMF subcategory is included and that subcategories it does not address may be added later. Generative AI systems still need documented tolerances under the core framework, so organizations should set them using the base Playbook suggestions and their own generative AI risk criteria, then record that the profile did not address this outcome.

How DeployOpen scopes and prepares MAP 1.5 evidence

DeployOpen helps organizations prepare the systems, records and documentation behind their MAP 1.5 risk tolerances, working inside the client's own infrastructure. The organization sets its own tolerances and owns the decisions, while DeployOpen builds the supporting evidence trail on self-hosted open-source platforms.

How we scope

Agree in writing which AI systems, business units and risk sources the MAP 1.5 work covers before any work starts.
Confirm which existing regulatory and sector risk criteria the organization already uses and must map its tolerances to.
Define the deliverables, owners and review dates for documented tolerances, agreed as a fixed-scope engagement.

How we build

Set up a register that records tolerance levels, severity levels and the oversight resources attached to each level.
Configure risk criteria across financial, operational, safety, reputational and model sources in the chosen platform.
Document the maximum tolerance above which a system will not be deployed or will be decommissioned, with its approval record.

How we hand over

Deliver a documented tolerance set with the tradeoffs recorded among trustworthiness characteristics for each system.
Provide review records showing when tolerances were revisited as systems, policies and norms changed.
Give the organization's owners a written handover so they can maintain the evidence without DeployOpen involvement.

How we support

Offer ongoing support as a retainer for updating tolerances when the planned NIST revision of AI RMF 1.0 is published.
Help prepare the organization's evidence package for review by an independent auditor or assessor, who issues any report.
Confirm with the organization which assessor requirements, customer contracts or regulators apply before finalizing evidence.

MAP 1.5 Organizational risk tolerances