NIST Risk Response: The Essential 2026 Guide to Accept, Avoid, Mitigate, Share or Transfer

NIST risk response is the stage of the NIST risk management approach where an organization decides what to do about risks it has already assessed: accept them, avoid them, mitigate them, share them or transfer them. It is the point where analysis turns into decisions, money and accountability, and it is where many programs stall, because a risk register full of ratings does not explain what the organization has actually chosen to do.

This guide explains the response options described in NIST SP 800-39, how to choose among them using risk tolerance, how to document decisions so they stand up to audit, and how to monitor whether responses work. It is written for security, risk and compliance teams, and it complements our guides to the NIST SP 800-30 risk assessment and the NIST risk management framework.

Where NIST risk response fits

NIST SP 800-39, Managing Information Security Risk, was published in March 2011 and is listed as final. It structures risk management around four components: framing risk, assessing risk, responding to risk and monitoring risk. Framing sets the context, including assumptions, constraints and risk tolerance. Assessment identifies threats, vulnerabilities, harm and likelihood. Response selects and implements actions. Monitoring checks that responses work and detects changes that affect risk. You can read the publication on the NIST Computer Security Resource Center.

NIST risk response is therefore the third of four connected activities, not a standalone step. Its quality depends on the framing before it, since the tolerance you set decides which risks need action, and on the monitoring after it, since responses that are never checked tend to decay.

The five NIST risk response options

SP 800-39 identifies five approaches to responding to risk. The table shows what each means in a cybersecurity setting.

Response	What it means	Cyber example
Accept	Take the risk as it is, knowingly, within tolerance	Living with a low-impact weakness in an internal test system
Avoid	Stop the activity or remove the exposure	Decommissioning a legacy application that cannot be secured
Mitigate	Reduce likelihood or impact with controls	Adding multi-factor authentication and monitoring
Share	Spread the risk with another party	Joint arrangements with a partner who also holds part of the risk
Transfer	Move the financial consequence to another party	Cyber insurance or contractual indemnities

In practice most risks are mitigated, and many need a combination: controls to reduce the likelihood, insurance to cover the residual loss and a formal acceptance of what remains. Transfer needs care: insurance may cover cost, but it does not remove the operational, legal or reputational consequences, and terms and exclusions vary. Read the policy and contract wording before you count on it.

How to choose a response using risk tolerance

SP 800-39 describes risk tolerance as the level of risk or degree of uncertainty that is acceptable to the organization, and stresses that there is no single correct level, since it reflects culture and leadership priorities. That is why the choice of response cannot be made by the security team alone. Leadership sets tolerance, and the response is chosen to bring residual risk within it. Our guide to risk appetite explains how to write it down.

The publication describes a response process in four parts: develop alternative courses of action, evaluate them, determine which fits the tolerance, and implement it. Applying that in a working procedure looks like this.

1. Start with the assessed risk. Use the rating, its rationale and the assets and processes affected.
2. Compare with tolerance. If the risk is already within tolerance, the decision may be to accept, with approval recorded.
3. List realistic options. For risks outside tolerance, describe at least two ways to respond and what each would achieve.
4. Evaluate cost, effect and side effects. Estimate effort, money, time, residual risk and effects on operations and other risks.
5. Choose. Decide who has the authority to select each response, based on the size of the risk.
6. Plan and assign. Give the chosen response an owner, a budget, a deadline and a measure of success.
7. Implement and verify. Complete the work, then check that it reduced the risk as intended.
8. Record residual risk. Re-rate the risk after the response, and confirm it now sits within tolerance, or escalate.

Documenting NIST risk response decisions

Auditors and regulators want to see decisions, not just ratings. For each risk that needs a response, the record should show the risk and its rating before response, the options considered, the option chosen and why, the owner and approver, the cost, the timeline, the expected and actual residual risk, and the review date. The record for an accepted risk needs particular care: it should show who accepted it, on what authority, for how long and under what conditions. Acceptance with no end date turns into permanent neglect. Record it in your cybersecurity risk register, and keep the reasoning short and specific.

A worked example

The following is a hypothetical illustration. A retailer’s assessment finds a high risk: a legacy inventory application runs on an unsupported operating system and holds supplier pricing data. The team lists options. Avoid: retire the application, which would take nine months and disrupt purchasing. Mitigate: isolate it on a restricted network segment, restrict administrator access and monitor it closely, at moderate cost within weeks. Transfer: cyber insurance already exists but excludes losses due to known unpatched systems. Accept: not possible for a high risk under the company’s tolerance. Leadership chooses to mitigate now and avoid later. The segmentation and monitoring go in first, reducing the rating to moderate, which is within tolerance for a limited period. Retirement is scheduled for the next fiscal year with a named owner, and the temporary acceptance of the residual risk expires on that date. If the date slips, the risk returns to the risk committee.

Monitoring responses

NIST treats monitoring as its own component because responses can fail quietly. Controls get switched off, projects slip, new vulnerabilities appear and the business changes. Monitor whether actions were completed on time, whether controls are operating, whether the risk rating has moved as expected and whether indicators are within their limits. For higher risks, schedule a check after completion and again after some months. Our guide to cyber risk quantification shows how to put numbers on the value of a response when you need to compare options.

Reporting response status to leadership

Leaders need to know which high risks have a response, how far along it is and whether it is working. A one-page summary works well: the top risks with their current and target ratings, the response chosen for each, the owner, the due date and a status of on track, at risk or late. Add a short list of accepted risks with expiry dates, and a list of decisions you need from the committee. When a response slips, say so plainly and show the effect on the risk rating, so the committee can decide whether to add resources, change the plan or accept the exposure for longer. Over time, the same summary gives you a record of how the organization handled risk, which is exactly what an auditor will ask to see.

Common mistakes in NIST risk response

• Every risk gets “mitigate”. Without considering avoid, share or transfer, the option set is narrow and costs rise.
• Acceptance by default. Risks left unaddressed because nobody made a decision.
• Acceptance without authority. A technical team accepting a risk that only executives should accept.
• Transfer treated as elimination. Buying insurance and assuming the risk is gone.
• No residual risk assessment. Actions completed but never re-rated, so nobody knows whether the risk changed.
• No owner or date. Responses that drift because nobody is accountable.
• Controls chosen without tailoring. Applying a generic baseline instead of selecting controls that address this risk. See our guide to NIST 800-53 tailoring.

Documenting your risk response program

A working program needs a risk response procedure, decision authority levels, a response options template, a risk acceptance form with expiry, a treatment plan tracker and a review schedule. The NIST Cyber Risk Management Toolkit supplies templates built on the NIST SP 800-30 methodology, which you can adapt to your organization. Keep the forms brief, and make sure that every response record links back to the assessment that triggered it.

NIST risk response FAQ

What are the NIST risk response options?

SP 800-39 identifies accepting, avoiding, mitigating, sharing and transferring risk. Organizations often combine them for a single risk.

Who can accept a risk?

A person with authority proportionate to the size of the risk, set out in your procedure. Higher risks need senior leaders or a risk committee.

What is the difference between sharing and transferring risk?

Sharing spreads a risk with another party who takes part of it, for example in a partnership. Transferring moves the financial consequence to a third party, for instance through insurance or contract terms.

Should accepted risks expire?

Yes. Set a review or expiry date so that acceptance is revisited as conditions change.

How do I know a response worked?

Verify implementation, then re-rate the residual risk and monitor relevant indicators. A response has not worked until the risk is within tolerance.