MANAGE 1.2 Prioritizing risk treatment: evidence

What MANAGE 1.2 asks organizations to prioritize

MANAGE 1.2 expects an organization to treat its documented AI risks in an order set by three inputs: impact, likelihood, and the resources or methods available to address each risk. If your team already has a risk register from the MAP and MEASURE work, this subcategory asks you to turn that list into a sequence of treatment decisions and to be able to explain why one risk is handled before another. The NIST AI RMF is voluntary and has no certification, so nobody will issue a MANAGE 1.2 certificate. Whether your ordering is sound is tested through internal review, a review by your own risk committee, or an independent assessment that you commission and scope yourself.

The hard part is making the order defensible rather than arbitrary. Impact and likelihood scores are often built from different evidence, and a high-impact risk with no practical mitigation may not belong at the top of the queue even though it looks severe on paper. The Playbook suggests assigning risk management resources according to established risk tolerance, giving systems with lower tolerances more oversight and mitigation. That means your register should record the tolerance that applies to each system, and the reasoning behind it, before the scores are compared. AI 100-1 also notes that systems trained on sensitive or protected data, or whose outputs directly or indirectly affect people, may warrant higher initial prioritization.

The order also has to change. MANAGE 1.2 expects tolerances to be recalibrated using monitoring results, so a risk that drifts upward in production should move up the queue without waiting for the next annual review. Before you rely on a prioritization method, confirm three things with your own governance owners: who can reorder the queue, which monitoring signals trigger a re-ranking, and where each decision is recorded so an assessor can trace it. The NIST Playbook is a companion resource, not a checklist, so these operating rules are yours to define and document.

Which AI systems, data and teams fall under MANAGE 1.2

MANAGE 1.2 asks for risk treatment to be prioritized by impact, likelihood and available resources. The decisions below determine which systems, data and teams feed that prioritization, and each one changes how much oversight and mitigation effort the organization must plan for. Settle them in writing before the first prioritization cycle starts.

AI systems and risk registers in scope

Decide which AI systems are listed in the risk register that MANAGE 1.2 prioritizes, and whether systems in pilot, internal-only or retired status are included. Each system carries its own risk tolerance and its own list of documented risks, so an incomplete inventory produces a priority order that leaves systems out. Check that every entry links to a named owner, an intended purpose and the MAP outputs that describe its risks. Treat the register as the input to prioritization, not as a separate document.

Systems trained on sensitive data

Systems trained on sensitive or protected data usually need a higher initial prioritization under AI 100-1 Section 1.2.3, so they should be identified early. Confirm which training datasets contain personal, health, financial or otherwise protected information, and where that data came from. Those systems typically require more documented mitigation and more frequent review than systems built on public or synthetic data. Ask the data owner to confirm the classification before the scoring starts.

Systems whose outputs affect people

Identify systems whose outputs directly or indirectly affect people, such as decisions about employment, credit, access to services or care. These carry the impact weighting that drives MANAGE 1.2 prioritization, and they often fall under stricter risk tolerances. Map each output to the people or groups it reaches, including people who never use the system but are affected by its decisions. Note which outputs feed downstream processes where a human may not review them.

Third-party and pre-trained models

Decide whether vendor AI services and pre-trained models sit in the same register as internally built systems. Their risks are often harder to measure, because the organization may lack access to training data, evaluation results or change logs. Confirm which controls the provider contractually supports, how updates are communicated, and who monitors the model after deployment. Where the organization cannot obtain this information, record the gap as a risk to prioritize, not as an assumption.

Generative AI and the Generative AI Profile

Confirm how generative AI systems are handled, because NIST AI 600-1 lists no suggested actions for MANAGE 1.2. Teams using the Generative AI Profile for other subcategories still need to define MANAGE 1.2 priorities from the organization's own risk register and tolerances. Decide whether generative AI tools are tracked as separate entries or grouped under their use cases. Ask whether the profile's other suggested actions will be mapped into the same prioritization record.

How impact, likelihood and risk tolerance set the order

MANAGE 1.2 asks organizations to order their treatment of documented AI risks by three inputs: the impact of each risk, its likelihood, and the resources or methods available to address it. Of these, risk tolerance is the anchor. The Playbook suggests assigning risk management resources relative to the established tolerance for each system, so that a system with a lower risk tolerance receives more oversight and more mitigation than one with a higher tolerance. Impact and likelihood tell you how large a risk is, but the tolerance tells you how much of it the organization is willing to carry. A credit-scoring model and an internal document summarizer can show the same likelihood of error and still belong in different positions in the queue, because the consequences for affected people and the organization's appetite for them differ.

The Playbook also suggests documenting each risk tolerance decision, including who made it and on what basis, and recalibrating tolerances using results from monitoring. This matters for the reader because a priority order is only as defensible as the record behind it. Ask your risk owners to show the tolerance statement for each in-scope system, the MAP and MEASURE evidence used to rate impact and likelihood, and the date the tolerance was last reviewed. If monitoring shows that a system behaves differently in production than its testing suggested, the tolerance and the treatment order should be revisited, not left as written. The Playbook is a voluntary companion with suggested actions, so the exact form of these records is the organization's choice, and it should be proportionate to the decisions being made.

AI 100-1 also cautions that trying to eliminate negative risk entirely can be counterproductive, so the goal is a sensible order of treatment rather than zero residual exposure. It notes that higher initial prioritization may be called for where a system is trained on sensitive or protected data, or where its outputs directly or indirectly affect people. In practice, confirm which systems in your inventory meet either condition and place them at the top of the treatment queue regardless of how the other inputs score. Then check that the resources you allocate reflect that order, since a high-priority risk with no funded owner is still unmanaged. Where a precise measure of impact or likelihood is not available for a system, record that gap as an open item rather than filling it with an assumed number.

How an assessor tests MANAGE 1.2 in practice

This table sets out four test steps an reviewer can apply to MANAGE 1.2, the evidence each step asks for, and the common findings that show up. Read it as a guide to what a review can establish, since no AI RMF certification exists and the reviewer's independence determines how far the conclusion carries.

Test step	What the reviewer samples or checks	Evidence requested and common findings
Trace documented risks to a priority	Select a sample of documented AI risks and follow each to its assigned priority, the impact and likelihood ratings behind it, and the resources or methods chosen	Risk register entries with ratings and rationale. Common finding: priorities are assigned without a stated impact or likelihood basis, or high-impact risks sit at low priority with no recorded reason.
Check tolerance decisions against system classification	Compare each system's documented risk tolerance with its classification, such as use affecting people, sensitive or protected data, or external outputs	Signed tolerance decisions, system inventory entries and classification records. Common finding: systems touching sensitive data have the same tolerance as internal tools, or tolerances were never documented.
Confirm resource allocation matches tolerance	Review oversight hours, monitoring coverage, review cadence and mitigation budget for lower-tolerance systems against higher-tolerance ones	Staffing or ownership records, monitoring configurations, review calendars and change tickets. Common finding: lower-tolerance systems receive the same oversight as others, so the stated tolerance has no operational effect.
Check recalibration after monitoring	Look for evidence that monitoring results led to changes in tolerance, priority or controls, and that the change was documented	Monitoring reports, meeting minutes, tolerance revision history and records of decisions. Common finding: monitoring runs but no output is ever fed back into priorities.
Confirm the reviewer's conclusion scope	Decide which party is reviewing and what its findings can support	Internal audit can test controls against the organization's own documented method. A customer's assessor can judge fit for their contract. An independent firm can give an opinion on its scope. None of them issues an AI RMF certificate, because NIST does not certify or endorse organizations.

How to implement MANAGE 1.2 in sequence

This sequence turns the risks documented in MAP and MEASURE into a ranked, resourced and revisited treatment plan, so that systems with lower risk tolerance receive more oversight and mitigation. Each step closes with a named artifact that someone inside the organization signs off.

Confirm the risk register from MAP and MEASURE
Start by checking that every risk identified in MAP and measured in MEASURE appears in one register for the system, with its source, owner and current status. The AI risk owner (usually the system owner with the risk function) confirms that nothing from the mapping or testing work has been dropped or left unassigned. Done means the register is versioned, each entry links to its MAP or MEASURE evidence, and the owner has signed the register as complete for the review cycle.
Set and document risk tolerance per system
Record the risk tolerance for each AI system, stating how much residual risk the organization accepts and in which impact areas. Systems that touch sensitive or protected data, or whose outputs affect people directly or indirectly, usually need a lower tolerance, as AI 100-1 notes for higher initial prioritization. The accountable executive approves each tolerance statement, and the output is a signed tolerance record per system that the later steps can cite.
Score impact and likelihood with a stated method
Score each register entry for impact and likelihood using one written method, so that two reviewers would reach comparable results from the same evidence. Document the scale definitions, the scoring criteria and any assumptions, and record the reasoning for each score. The risk lead reviews a sample of scores against the tolerance record. Done means every entry has a score, a method reference and a second-reviewer note, approved by the risk function.
Compare scores against tolerance and rank treatment
Place each scored risk against the tolerance for its system and sort the register into a treatment order that reflects impact, likelihood and the methods available to address each risk. Confirm which risks exceed tolerance and which systems need the most oversight. The output is a ranked list per system, reviewed and signed by the system owner, with any exceptions explained in writing.
Allocate treatment resources by priority
Assign people, budget, tooling and time to the ranked risks, starting with the highest priority and the lowest tolerance. Where resources are limited, record which lower-ranked risks wait and why, and whether any are accepted for now. This step also identifies where an outside partner might prepare controls or testing, and the scope of that work should be agreed in writing. The output is a resource allocation record signed by the executive who owns the budget.
Record the ranked decisions
Write down each prioritization decision with its ranking, rationale, assigned owner and the treatment direction, linking back to the tolerance record and the scoring method. Responses to the highest priority risks are developed later under MANAGE 1.3, so this record should point to them rather than repeat them. The governance committee or accountable executive signs the decision log, and the signed log becomes the evidence an assessor or customer would ask to see.
Set recalibration triggers from monitoring
Define the monitoring signals and events that will reopen a ranking, such as a change in data, a shift in measured performance, a new incident or a change in the system's use. Set a review cadence that the organization can actually sustain and state which results would recalibrate tolerance. The AI RMF Playbook suggests recalibrating tolerances using monitoring results. The output is a trigger schedule approved by the risk owner, and the first recalibration review is recorded in the same register.

Evidence that shows risk treatment is prioritized

MANAGE 1.2 asks whether treatment of documented AI risks follows impact, likelihood and available resources, with more oversight for systems with lower risk tolerance. The artifacts below connect those decisions from the risk register through to the sign-offs that show they were made and revisited. Each one should be dated, versioned and tied to a named system so that an assessor can trace a priority to its reasoning.

Ranked risk register with rationale

The register lists each documented AI risk for a system, with the impact and likelihood scores, the scoring scale used, and a short written rationale for the rank it received. It shows that treatment order follows the stated factors rather than whoever raised the loudest concern. Check that each score can be traced to the MAP and MEASURE evidence behind it, and that the scale is the same across systems so rankings can be compared. Re-rank whenever a score changes and keep prior versions so the history of priority decisions remains visible.

Risk tolerance decisions per system

A dated record for each AI system states the risk tolerance the organization accepted, who approved it, and the conditions under which it applies. This is the reference point for deciding how much oversight a system receives, so a system with a lower tolerance should show a visibly stronger treatment plan. Confirm that each decision names the system's intended purpose and the people affected by its outputs, since those facts drive the tolerance. Revisit the record when the system's use changes.

Resource allocation records tied to priority

Budget, staff time and tooling assigned to each risk treatment show whether higher-priority risks actually receive more resources. Records should link each allocation to a register entry and note any resource limit that forced a lower-priority item to wait. Assessors often find the gap here, where priorities are documented but the spending does not follow them. Review allocations at each planning cycle and record the reason for any deviation from the ranking.

Oversight level assignments

Each system should have a written statement of the human review, approval and monitoring frequency it requires, matched to its risk tolerance and rank. This artifact answers the MANAGE 1.2 expectation that lower-tolerance systems receive more oversight and mitigation. Note which roles perform each review and what triggers escalation. Update the assignment when a system's risk rank changes so that the oversight never falls behind the risk.

Recalibration logs from monitoring

Recalibration logs record when monitoring results led to a change in a system's risk rank, tolerance or treatment priority, and what the change was. They show that the prioritization is a living process, which the Playbook suggests by recalibrating tolerances using monitoring results. Each entry should cite the metric or incident that triggered it and the decision that followed. Confirm that monitoring outputs are reviewed on a schedule and that entries exist even when the outcome is no change.

Meeting minutes and sign-offs

Minutes and signed approvals record who reviewed the priority decisions, what they decided and which open items remain. They establish accountability for treatment choices and show that a named owner accepted the residual exposure. Keep attendee lists, the version of the register reviewed, and the approver's authority to accept risk. Store them with the register so an assessor can follow a decision from discussion to outcome.

What meeting MANAGE 1.2 costs in money and effort

This table breaks down the cost components of prioritizing AI risk treatment under MANAGE 1.2, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a written scope and to compare quotes line by line. The main takeaway is that most of the recurring cost comes from keeping the ranked register current, not from producing it the first time.

Cost component	Who is paid or who spends time	One-time or recurring, and what drives it	How to keep it down
Ranked risk register build	Internal risk or engineering staff, optionally an implementation partner	One-time. Driven by the number of AI systems in the inventory and how many documented risks each one carries	Start with systems that process sensitive or protected data or affect people directly, and rank the rest later
Risk tolerance documentation	Governance, risk and business owners	One-time setup, then recurring review. Driven by how many systems have distinct tolerance levels	Use a small set of tolerance tiers so each system maps to one tier with a written rationale
Tooling and licenses for register and workflow	Software vendors, if commercial tools are chosen	Recurring license fees where proprietary tools are used. Driven by user count and modules	Self-hosted open-source GRC tools can remove license spend, though hosting and administration still cost staff time; confirm the license terms before deployment
Recalibration using monitoring results	Monitoring, operations and risk staff	Recurring. Driven by monitoring volume, incident frequency and how often tolerances change	Automate feeds from monitoring into the register and set fixed review triggers instead of ad hoc reviews
External review or independent testing	Independent assessors or security testing providers	Periodic and scope-dependent. Driven by system criticality, number of systems tested and test depth	Scope testing to the highest-priority systems in the ranked register and retest only what changed
Auditor or reviewer time	Independent auditors or internal audit, if an assurance review is requested	Periodic. NIST AI RMF has no certification, so cost depends on the scope the requesting customer or regulator sets	Agree the evidence set and sampling approach in writing before fieldwork begins

Who owns, who prepares and who reviews MANAGE 1.2

Your organization owns MANAGE 1.2. Only your leadership can decide how much risk each AI system may carry, which risks rank above others and how scarce people and budget are assigned to treatment. The NIST AI RMF is voluntary and does not certify anyone, so the decisions and the documents that record them are yours to make and keep. Most of the work sits with AI risk owners, the security function and whoever signs off on deployment.

Risk tolerance decisions: Set and approve tolerance levels for each system, including who signs them and when they are reviewed.
Prioritization rules: Agree how impact, likelihood and available resources or methods combine into a ranking, and who can override it.
Resource allocation: Assign oversight and mitigation effort so systems with lower tolerance receive more of it.
Recalibration: Decide when monitoring results justify changing a tolerance or a priority.
Accountability records: Name the owner of each decision and keep the minutes or approvals that show it was made.

Before any outside work starts, confirm that your leadership has approved the tolerance levels and that a named owner can defend each priority to an assessor.

Where organizations usually fall short on MANAGE 1.2

MANAGE 1.2 asks whether documented AI risks are treated in an order that reflects impact, likelihood and the resources or methods available. Most shortfalls come from priorities that were never tied to a stated risk tolerance, or from a register that no longer matches what MAP and MEASURE found. The cards below describe each gap and the check that exposes it.

Priorities set without documented tolerance

Teams often rank risks by gut feel because no one wrote down how much risk each system may carry. Without a documented tolerance, two reviewers can rank the same risk in opposite orders and both can defend it. Check whether each system's risk tolerance is recorded, approved by an accountable owner, and cited in every priority decision. The Playbook suggests documenting tolerance decisions so that treatment order can be explained later.

Tolerance set once, never recalibrated

A tolerance approved at launch can go stale as the system's users, data and outputs change. The Playbook suggests recalibrating tolerances using monitoring results, so a drop in accuracy or a rise in complaints should prompt a review. Ask when each tolerance was last reviewed, which monitoring signals trigger a review, and whether the change was recorded with its reason.

Resources not linked to rank

Budget and staff often go to the loudest project rather than the highest-priority risk. MANAGE 1.2 expects oversight and mitigation to follow established tolerance, so systems with lower tolerance should receive more review and控制 effort. Check whether the staffing plan and remediation budget name the ranked risks they serve, and whether the lowest-tolerance systems get the most review hours.

Sensitive and human-affecting risks ranked low

AI 100-1 notes that higher initial prioritization may be called for where a system is trained on sensitive or protected data, or where its outputs affect people directly or indirectly. Teams sometimes score these risks like ordinary technical defects because the likelihood looks small. Check whether the scoring method adds a rule for sensitive data and for decisions that touch individuals, and whether a reviewer outside the build team confirms those scores.

Scores without written rationale

A register that lists a score of high, medium or low without the reasons behind it cannot be tested or challenged. Assessors and auditors will ask how impact and likelihood were judged and what methods or resources limited the response. Require each score to record the impact evidence, the likelihood basis, the treatment options considered and the name of the person who accepted the rating.

Registers that do not trace to MAP and MEASURE

Risk registers sometimes list items that cannot be traced back to any MAP context, impact characterization or MEASURE result, and some findings from testing never reach the register. MANAGE 1.2 assumes that documented risks come from earlier work. Pick several register entries and trace each to its MAP record and its MEASURE evidence. Also pick several test findings and confirm each appears in the register with a priority.

Questions buyers ask about MANAGE 1.2

How much effort does prioritizing AI risk treatment take, and can we do it in-house?

Yes, most organizations can do this work in-house, because MANAGE 1.2 is an outcome about how you rank documented risks, not a technical test. The effort depends on how many AI systems you run, how many risks your mapping and measurement work has already recorded, and whether those risks are scored consistently by impact, likelihood and available resources. Cost is mainly internal staff time from risk, product, legal and security owners, plus any tooling you adopt. An outside partner can be paid to prepare the risk register, scoring method and evidence, but the organization still owns the risk decisions. Ask any partner for a written scope that lists the systems, deliverables and review cycles covered before work starts.

How long does it take to prioritize AI risk treatment?

The duration depends on the drivers rather than a fixed figure, and NIST does not publish one for MANAGE 1.2. The main drivers are the number of AI systems in scope, whether MAP and MEASURE outputs already exist as documented risks, how mature your risk tolerance statements are, and how many approvers must sign off on priorities. A team that already has a current AI inventory and documented risk tolerances will move faster than one starting from scratch. Ask any provider to break the timeline into phases with the dependencies named, and to state which inputs you must supply and when.

What does the work need from our team?

It needs people who can speak for impact, likelihood and resources in terms the business understands. NIST's Playbook tags MANAGE 1.2 with the AI Deployment, Operation and Monitoring and AI Impact Assessment actor categories, which means operators, monitoring owners and impact assessors should contribute. You will also need someone who owns risk tolerance decisions, so that higher oversight can be assigned to systems with lower tolerance. Appendix A of AI 100-1 describes the tasks of each actor category, which is a useful starting point for assigning roles. Confirm named owners before the first prioritization review.

Is there an AI RMF certificate for MANAGE 1.2?

No. The NIST AI RMF has no certification, accreditation or conformity assessment program, and NIST does not validate or endorse any organization's use of it. Any vendor or consultant offering an AI RMF certificate is selling something NIST does not recognize. What you can show is evidence: a documented prioritization method, the risk tolerance decisions behind it, and records of how oversight was assigned. If a customer or regulator asks for proof, provide that evidence and, where they require independent assurance, ask a qualified assessor to test it against the standard you have chosen.

How does MANAGE 1.2 differ from the Playbook suggestions?

MANAGE 1.2 is the outcome: treatment of documented AI risks is prioritized by impact, likelihood and available resources or methods. The Playbook offers suggested actions, documentation prompts and references for reaching that outcome. Its suggestions include assigning resources relative to risk tolerance, giving lower-tolerance systems more oversight and mitigation, documenting tolerance decisions, and recalibrating tolerances from monitoring results. The Playbook states that it is neither a checklist nor a set of steps, so you decide which suggestions fit your context and record why you chose or skipped them. Its audit log shows the last content update in August 2023.

How could the pending NIST revision change MANAGE 1.2?

NIST says AI RMF 1.0 is being revised under the White House AI Action Plan and has not published a revised version as of October 2026. The July 2025 Action Plan recommends removing references to misinformation, diversity, equity and inclusion, and climate change, so wording in the framework may change. NIST also expects a formal review with community input no later than 2028, and AIRC says the Playbook will be updated after the revision. For MANAGE 1.2, the core prioritization outcome is likely to remain relevant, but you should track the revised text, record which version your program was built against, and plan a review when it is published.

How DeployOpen prepares MANAGE 1.2 evidence

DeployOpen works on MANAGE 1.2 by helping organizations turn their documented AI risks into a written treatment order that reflects impact, likelihood and available resources. We prepare the systems, records and evidence inside your own infrastructure, while your organization keeps ownership of its risk tolerances and treatment decisions.

How we scope

The written scope names the AI systems, risk register entries and risk tolerance records covered by MANAGE 1.2.
Scope defines how impact, likelihood and resource constraints are recorded for each documented risk.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure risk registers and tolerance fields so that lower-tolerance systems are flagged for more oversight.
We set up monitoring feeds that capture results used to recalibrate tolerances and priorities over time.
We test that prioritization records link each treatment decision to its supporting monitoring data.

How we hand over

You receive documented prioritization criteria, risk tolerance decisions and the recalibration log.
Handover covers the evidence an independent assessor would request, mapped to the MANAGE 1.2 outcome and Playbook suggestions.
Your team receives runbooks for reviewing priorities and updating records after each monitoring cycle.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for systems that change over time.
Retainers can cover periodic review of priority records when new AI systems or risks enter scope.
Confirm with DeployOpen which support level fits your environment before the written scope is signed.