MANAGE 1.3 Responses to high-priority risks: evidence guide

What MANAGE 1.3 requires for NIST AI RMF response planning

Your team has finished MAP and has a list of AI risks marked high priority. MANAGE 1.3 asks what happens next: responses to those risks must be developed, planned and documented. For each high-priority risk, the organization chooses among four options: mitigate it, transfer it, avoid it or accept it. The subcategory describes an outcome, not a form to fill in. NIST AI 100-1 is voluntary, and no certification, accreditation or conformity assessment exists for it. Nobody will issue a badge for meeting MANAGE 1.3. An independent assessor, customer or regulator will instead ask whether a named owner chose a response for each high-priority risk and can show the reasoning.

This step is often the hardest in the Manage function because it forces decisions that many teams have avoided. The first problem is ownership. MAP results often sit with the data science or engineering team, while the authority to accept a risk sits with a business owner or executive. If those roles are not documented under GOVERN 2, a response plan has no one to sign it. The second problem is tradeoffs. Mitigating a risk may reduce accuracy, slow a release or add cost, and those tradeoffs need a written record. NIST AI 600-1 suggests documenting tradeoffs and decision processes even for risks that do not exceed risk tolerance, such as in model release decisions.

A practical starting point is a response register with one row per high-priority risk. Each row should name the risk, the chosen response, the accountable owner, the resources and team assigned, the decision date and the monitoring that will show whether the response works. The Playbook suggests prioritizing risks involving physical safety, legal liability, regulatory compliance and harm to people, and storing this documentation in an organized, secure repository that relevant AI actors can reach. Teams that already run a wiki or GRC tool can keep the register there, provided version history and access controls are on. Confirm with your own assessor or customer which evidence format they expect, because NIST does not prescribe one.

Which AI systems, risks and teams fall under MANAGE 1.3 response planning

MANAGE 1.3 only works when the organization has settled what it is responding to and who answers for it. The decisions below set the systems, risk registers, priority thresholds, owners and generative AI actions that the response plans must cover before any treatment option is chosen.

Systems covered by the response plan

Start with the inventory of AI systems that are in development, deployed or relying on a third-party model. MANAGE 1.3 responses only apply to systems whose risks MAP has identified, so a system missing from the inventory has no documented response. Check that retired systems, shadow tools and embedded AI features in purchased software are either listed or explicitly excluded with a reason.

Risk registers in scope

Decide which registers feed MANAGE 1.3: a project-level AI risk log, an enterprise risk register, or both. Map outputs that sit only in a model team's notebook will not be visible to the people who approve responses. Confirm that each register records the risk, its source MAP subcategory and the owner, so that a response can be traced back to the finding that triggered it.

MAP outputs that count as high priority

Define the threshold that turns a MAP finding into a high-priority risk. The Playbook suggests weighting physical safety, legal liability, regulatory compliance and negative impacts on people. Write the threshold down, then apply it to the risk tolerance set under GOVERN 1, so that two teams do not classify the same finding differently.

Teams and owners of each response

Name the people who develop, approve and carry out each response. The Playbook tags MANAGE 1.3 to AI deployment, operation and monitoring and to AI impact assessment, so the plan usually needs engineers, operators and impact assessors together. Record who can accept a risk on the organization's behalf, since acceptance is one of the four response options and should not sit with the team that built the system.

Third parties with response duties

Identify which responses depend on a vendor, model provider or data supplier. A mitigation may require a contract change, a vendor patch or access to logs that only the third party holds. Check that each third-party dependency has a named contact, a notice period and a documented fallback, because a response plan that assumes vendor cooperation without evidence is incomplete.

Generative AI actions from NIST AI 600-1

Generative AI systems add two suggested MANAGE 1.3 actions in the Generative AI Profile, MG-1.3-001 and MG-1.3-002. The first covers documenting tradeoffs and decision processes for risks that fall below risk tolerance, such as model release decisions. The second covers monitoring the effectiveness of controls through red-teaming, field testing and user feedback. Add these to the plan for any generative system in scope, and confirm that the tests they require are funded and scheduled.

How an assessor tests MANAGE 1.3 responses to high-priority risks

An assessor starts with the high-priority risks that MAP identified and follows each one forward to a documented response. The aim is to confirm that nothing deemed high priority was dropped between identification and treatment. The assessor then checks that each response records one of the four options named in MANAGE 1.3 (mitigate, transfer, avoid or accept) and that the choice has a rationale tied to the risk tolerance set under GOVERN 1. Because NIST's Playbook frames these as suggested actions rather than a checklist, the assessor judges whether the organization's own process is coherent, not whether it matches a template.

Trace the chain: Pick high-priority risks from the MAP outputs and follow each to its response record, owner and status.
Test the option choice: Confirm each response states whether the risk is mitigated, transferred, avoided or accepted, with the reasoning.
Sample for completeness: Select a sample of risks across systems and risk types, and confirm none lacks a response.
Check review: Verify that responses were reviewed by people with authority to accept residual exposure, and that reviews happened on a stated schedule or trigger.
Confirm scope: Ask which systems and third-party AI components the response register covers.

Before engaging an auditor, confirm with them the sample size, the period under review and which AI systems fall in scope.

Steps to plan and document responses to high-priority AI risks

This sequence turns the high-priority risks identified in MAP into owned, documented responses that a reviewer can trace from risk to treatment decision to monitoring result. It is a working order for MANAGE 1.3, not a checklist, and each step closes with an artifact that the next step depends on.

Confirm the high-priority risk list from MAP
Start by pulling the risks that MAP identified as high priority for the system, along with the impact and context records behind each ranking. Check that each entry names the affected people, the system component involved and the context of use. Confirm the list with the MAP owners and the system's business sponsor. The output is a signed-off register of high-priority risks with a reference to the MAP record that supports each one. Ask the reader to confirm that nothing was dropped between MAP and MANAGE, since later steps only cover what is on this list.
Assign a response owner and resources
For each high-priority risk, name one accountable owner who can make treatment decisions, and a response team with the skills the risk needs, such as security, legal, privacy, data science and operations. The Playbook suggests identifying response plans, resources and teams for MANAGE 1.3, so record the people and budget that are actually available, not those assumed. Escalate any risk without a named owner to the governance body that holds accountability for AI risk decisions. The output is an ownership table that shows who decides, who executes and who has been informed.
Prioritize by physical safety, legal and harm exposure
Order the risks so that those involving physical safety, legal liability, regulatory compliance and negative impacts on people are addressed first, as the Playbook suggests. Use the impact and likelihood information from MAP and the risk tolerance set under GOVERN 1 to decide where the response effort goes. Record the reasoning for the order so a reviewer can see why a lower-scored item was placed ahead of a higher-scored one. The output is a ranked list with a short rationale for each position.
Choose and record the treatment option with rationale
For each risk, select one of the four response options: mitigate, transfer, avoid or accept. Write down the option chosen, the controls or changes it requires, the residual risk that remains, and the reasoning that links the choice to the risk tolerance. Where a risk is accepted, record who accepted it and under what conditions, so that the decision can be revisited. Where a risk is transferred, such as through a contract or insurance, record what the transfer does and does not cover. The output is a treatment decision record per risk, signed by the owner.
Set response plans with actions and checkpoints
Turn each mitigation or avoidance decision into a response plan that lists the specific actions, the systems or teams involved, the dependencies and the conditions under which the plan is considered complete. Define checkpoints where the owner confirms progress and decides whether the plan still fits the risk. Confirm timelines with the owners rather than copying them from a template, since no timeline is fixed by the framework. The output is an approved response plan for each treated risk, with checkpoints the owner has agreed to.
Store responses in an organized, accessible repository
Place the risk register, treatment decisions, response plans and supporting system documentation in one repository that is organized by system and risk, secured with access controls, and readable by the AI actors who need it. Use version control so that every change shows what changed, when and by whom. A self-hosted wiki with page history or a documentation platform with role-based permissions can meet this need, but confirm the access model and retention settings in your own environment. The output is a repository with an index that links each high-priority risk to its decision, plan and evidence.
Review responses after monitoring results arrive
Once the response is in place, compare monitoring results and feedback against the expected effect of each control, and check whether the residual risk is still within tolerance. Update the treatment decision, the plan or the owner assignment where the evidence shows a gap, and record each change in the repository with its reason. Include any new or changed risks identified through monitoring so they re-enter MAP and MANAGE. The output is a dated review record per risk that shows the result, the decision taken and the next review point.

Evidence that shows high-priority AI risk responses are planned and documented

MANAGE 1.3 asks for evidence that responses to high-priority AI risks were developed, planned and documented, not only that a team said it would act. The cards below cover the records an assessor or customer is likely to ask for, and each one needs an owner who keeps it current between reviews.

High-priority risk register

This is the list of AI risks that MAP identified as high priority, with the rationale for each ranking. For each entry, record the affected system, the risk category, the likelihood and impact reasoning, and the date of the last review. Check that every high-priority risk from MAP appears here, and that a risk is not quietly removed without a recorded decision.

Response plans with owners and resources

Each high-priority risk should have a response plan that names the accountable owner, the team, the budget or staff time allocated, and the steps and dates for action. The Playbook suggests prioritizing risks involving physical safety, legal liability, regulatory compliance and negative impacts on people, so plans for those risks should be easy to find and verify.

Treatment decision records

For each risk, document which option was chosen: mitigating, transferring, avoiding or accepting it. The record should state the tradeoffs considered and who approved the decision. For risks accepted within tolerance, NIST AI 600-1 expects documented tradeoffs and decision processes, such as those used in model release decisions.

Repository index and access control record

Store risk and system documentation in one organized, secure repository that relevant AI actors can reach. Keep an index that lists each artifact, its owner and its review date. Record who can read, edit and approve each space, so an assessor can confirm that access follows the roles people actually hold.

Version history of changes

Every change to a risk entry, response plan or decision record should be traceable to a date and a person. Version history shows that a response was planned before a deployment and updated after an incident, rather than rewritten to match the outcome. Ask the tool owner which page versions are retained and how far back a reviewer can compare them.

Review cadence between audits

Assign each artifact an owner and a review trigger, such as a model change, a new incident, a regulatory update or a scheduled date set by the organization. Run a short check before any assessment that confirms the register matches the current system inventory and that every decision still has an approver. Stale entries are the most common gap an assessor finds.

What meeting MANAGE 1.3 costs in money and effort

This table breaks down the cost components of meeting MANAGE 1.3 by who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to scope a quote, because no price or duration for MANAGE 1.3 has been published and every figure depends on your systems, risk tolerance and generative AI footprint. The main takeaway is that the largest recurring costs are people's time and evidence upkeep, while self-hosted open-source tooling mainly removes license spend.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it, and what to ask for in a quote
Internal time for risk owners	Your staff (risk owners, system owners, product leads)	Both: initial response planning, then recurring reviews	Number of high-priority risks from MAP and their complexity. Ask the partner to state which roles it assumes you staff internally.
Repository and tooling	Software licenses or self-hosting infrastructure	Recurring hosting, one-time setup	Self-hosted open-source options such as XWiki or BookStack carry no license fee, but you pay for hosting, backups and administration. Ask for hosting and support assumptions in writing.
External red-teaming or field testing	Specialist testers, paid under a written scope	Usually one-time per test cycle, repeated after major changes	Generative AI controls under MANAGE 1.3 call for red-teaming, field testing and user feedback. Ask for scope, number of test cycles and what counts as a retest.
Review by independent assessors	External auditors or assessors	Recurring, tied to your assessment cycle	NIST does not certify AI RMF use, so assessor fees depend on what you ask them to review. Ask whether the assessor reviews response plans, residual risk acceptance or both.
Response planning and resources	Your staff and any implementation partner preparing plans, teams and escalation paths	One-time for initial plans, recurring when risks change	Number of response options chosen (mitigate, transfer, avoid or accept) and how many teams must act. Ask for the deliverable list for each plan.
Evidence upkeep	Your staff keeping records current in the repository	Recurring	Version history, access rules and the volume of documentation kept per risk. Ask how the repository, retention and access control work after handover.

Who owns, implements and audits MANAGE 1.3 response work

Your organization owns the AI system, its risk tolerance and every response decision under MANAGE 1.3. The NIST AI RMF is voluntary and has no certification, so the accountability for choosing to mitigate, transfer, avoid or accept a high-priority risk sits with the people who run the system and carry its consequences. Your team decides what counts as high priority for each system, who signs off on residual exposure and when a response is complete.

Risk decisions: Executives and system owners choose the response option for each high-priority risk and record the reason, including any decision to accept a risk.
Response plans and resources: Named owners, budgets and teams are assigned to each response, with dates set by your own change and governance process.
Physical safety, legal and people impacts: Your legal, safety and affected-business owners judge liability, regulatory exposure and harm to people, which MANAGE 1.3 suggests prioritizing.
Documentation repository: Your staff decide where risk and system documentation lives, who can access it and how long it is retained.
Contract terms: Your procurement and legal teams set the transfer terms, such as vendor obligations, that appear in agreements.

Before engaging anyone, confirm that each response has a named decision owner who is not also the person building the control.

Common gaps in AI risk response documentation and how to close them

Most MANAGE 1.3 gaps are not missing intent. They are responses that nobody owns, decisions without a written basis, and records spread across tools that no one reviews after something goes wrong. Each card below names one gap, why it weakens the evidence an assessor or regulator will ask for, and the action that closes it.

Responses with no named owner

A response plan that says "the team will mitigate" gives an assessor nothing to test. MANAGE 1.3 expects responses to be developed, planned and documented, and each one needs a named accountable person, a delivery team and a budget or resource line. Close it by recording one owner per high-priority risk in the risk register, with the owner's name, role and deadline for each planned action. Check that the owner has authority to pause the system if the response requires it.

Accept decisions without rationale

Accepting a risk is a valid response option, but an accepted risk with no written reasoning looks like an oversight. The Generative AI Profile asks organizations to document tradeoffs and decision processes for risks that do not surpass risk tolerance, such as model release decisions. Close it by requiring each acceptance to state the risk, the tolerance it falls within, the evidence used, who approved it and when it will be reviewed.

Generative AI risks missing from plans

Response plans often cover classic model risks but skip the generative AI risks defined in NIST AI 600-1, such as those tied to human-AI configuration and information security. The profile lists two suggested MANAGE 1.3 actions, MG-1.3-001 and MG-1.3-002. Close it by mapping each generative AI risk in your inventory to a response option and an owner, then confirming that the plan covers prompt injection, data exposure and misuse paths for every deployed model or tool.

Documentation scattered across tools

When the risk register sits in a spreadsheet, the response plan in a ticket system and the approvals in email, no one can show a complete trail. The Playbook suggests storing risk and system documentation in an organized, secure repository accessible to relevant AI actors. Close it by choosing one controlled system of record, linking every response to its evidence there, and restricting edit rights so approvers cannot change the record they signed.

Version history missing from records

A response plan that is overwritten each quarter cannot show what was decided, when, or by whom. Assessors and incident reviewers need that history to test whether responses were followed. Close it by keeping the wiki or document platform under version control, so each change records what changed, when and by whom, and by confirming that earlier versions of approved responses can be compared and restored.

No review after incidents

Responses are often written before deployment and never revisited. When an incident or a monitoring finding shows a response did not work, the plan should change and the change should be recorded. Close it by setting a trigger for review after each incident and each material monitoring result, then logging the response's outcome, the revised treatment and the owner who approved the change.

What buyers ask about MANAGE 1.3 cost, effort and outside help

Is the NIST AI RMF certified, and can we get a MANAGE 1.3 certificate?

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. NIST describes the framework as voluntary, so no regulator or body issues a MANAGE 1.3 certificate. What you can produce is documented evidence that your organization planned and recorded responses to high-priority AI risks. If a customer or contract asks for proof, ask them what form of evidence they expect, such as an internal assessment, an independent review or a report from an auditor that they name in writing. Independent auditors and assessors can test your evidence, but they do not certify the framework itself.

How much effort does MANAGE 1.3 take, and what drives it?

NIST does not publish an effort estimate for MANAGE 1.3, so the reliable answer depends on your environment. The main drivers are the number of AI systems that MAP rated as high priority, how many risks each system carries, whether responses already exist in your incident or change processes, and how many teams must agree on each decision. Systems that touch physical safety, legal liability, regulatory compliance or people affected by decisions usually need more documented detail. Ask any provider to break the effort into inventory and prioritization review, response planning, documentation setup and periodic updates, and to tie each part to the systems in scope.

Can our own team handle MANAGE 1.3 without outside help?

Often yes, if the team has the authority to make risk decisions and the time to maintain records. The work is mostly organizational: naming who decides each response, writing plans for mitigating, transferring, avoiding or accepting each high-priority risk, and keeping that record current. Outside help makes the most sense when your team lacks AI risk expertise, when several systems must be documented at once, or when your records live across tools that do not connect. Whatever you choose, the accountable owner of each response must stay inside your organization.

What does an implementation partner prepare, and what does the auditor test?

An implementation partner prepares the systems and evidence: the response plans, the decision records, the repository structure, and the workflows that route risks to the right people. DeployOpen works this way. It plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and it prepares evidence for assessments. It does not issue audit reports or attestations. An independent auditor or assessor tests whether the responses exist, were approved by the right people, and are followed in practice. Confirm in writing which deliverables the partner owns and which items your assessor will sample.

What do we need to provide before an outside team can start?

A partner needs access to the outputs of your MAP and MEASURE work, the list of AI systems in scope, the current risk register, and the people who approve risk decisions. You should also name an internal owner who can answer questions and sign off on scope. Expect to provide the existing policies on risk tolerance and incident handling, because MANAGE 1.3 responses must fit them. Ask the provider to list these inputs in the written scope before work begins, so that gaps surface early and do not extend the schedule.

What recurring work follows the first set of MANAGE 1.3 responses?

The main recurring work is keeping responses current as systems change, risks shift and new high-priority findings appear. Plan for periodic review of each response, updates when a system is retrained or its use changes, and records of decisions to accept residual risk. Some teams also use the NIST AI RMF Playbook as a reference when reviewing responses, but NIST notes that it is not a checklist, and the Playbook's audit log shows its last content update in August 2023. Ask any provider whether ongoing support, upgrades or continuous testing are included, or whether they would be sold separately as a retainer.

How do we find out what MANAGE 1.3 will cost us?

DeployOpen does not publish a price list. Its engagements are fixed-scope, and a quote follows from the written scope, which covers the systems, deliverables and timeline agreed before work starts. The cost components are the internal time of your risk owners, any external partner work on preparing systems and evidence, and any fees for an independent assessment, which an auditor sets. Ask each provider to separate one-time setup from recurring work, to state what is excluded, and to name the assumptions behind the estimate.

Does the NIST revision in progress change what we should do for MANAGE 1.3?

Confirm the current position before you commit. NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan and has not yet published a revised version. The July 2025 AI Action Plan recommends removing references to misinformation, diversity, equity and inclusion, and climate change. The MANAGE 1.3 outcome about responding to high-priority risks is not tied to those topics, so its core work is unlikely to change, but the wording and Playbook guidance may. Build your records so that they can be re-mapped to a revised version, and ask your partner how they will handle that update within the agreed scope.

How DeployOpen prepares MANAGE 1.3 response records

DeployOpen's part of MANAGE 1.3 is the preparation work around the response decisions, not the decisions themselves. Before work starts, the scope is agreed in writing, including which high-priority risks from MAP are in scope, which self-hosted tools will hold the response records, and who on the client side reviews each record. The organization owns its risk decisions: choosing to mitigate, transfer, avoid or accept each risk, and signing off the response plan, stays with named accountable people. DeployOpen does not issue audit reports, attestations or certifications, and nothing it prepares should be presented as one. Independent auditors and certification bodies are the only parties that issue those.

Once the scope is set, DeployOpen deploys and hardens the tools in the client's own cloud accounts, data centers or air-gapped networks. For response records, this typically means a documentation wiki such as XWiki, where each response plan is a versioned page that records what changed, when and by whom, and a role-based content platform such as BookStack, where permissions can be set per shelf, book, chapter or page so that only relevant AI actors can edit or view response plans. Compliance tooling such as CISO Assistant can hold the risk register and link each response to its framework references. Whether a given tool supports a specific capability should be confirmed against its current documentation before it is relied on in a design.

The evidence that results is a set of response plans with owners, resources, teams and decision dates, plus the repository structure that keeps them retrievable. Ask for a written list of the artifacts each deliverable will contain, the review cadence the client must sustain after handover, and which items remain the client's responsibility, such as the risk tolerance itself and any residual risk acceptance. Ask the auditor or assessor, before work starts, which response evidence they will request, so the records are built to be tested rather than rebuilt later.

MANAGE 1.3 Responses to high-priority risks