Accept vs Transfer vs Mitigate vs Avoid: How to Choose and Document a Risk Treatment

Most risk registers record a treatment for every risk, but few record why that treatment was chosen over the other three, so the same kind of risk is mitigated in one team, accepted in another and assumed to be insured in a third. Accept, transfer, mitigate and avoid are not a menu to pick from by instinct. Each has a cost, a residual risk, a decision owner and a failure mode, and most real treatments combine two or more. This guide sets out the decision criteria, who may choose each option at which level, how cyber insurance and contracts really transfer risk, where avoidance blocks the business, and how to document and review the decision. It is written for risk managers, CISOs, GRC analysts and the business owners who sign off risk. The operating process for individual security exceptions is covered in the Security Exceptions and Risk Acceptance Guide and is not repeated here.

Key takeaways

• The choice follows appetite and cost, not preference. Compare each option's residual risk with your stated tolerance and its cost with the loss it prevents; accept only what sits inside tolerance.
• Transfer moves money, not accountability. NIST SP 800-39 is clear that senior leaders remain responsible for risk decisions; insurance and contracts compensate for some losses and leave the operational and reputational impact with you.
• Avoidance is the strongest and most expensive answer. Not doing the activity removes the risk and the value; use it where the activity is outside appetite at any reasonable cost of control.
• Most treatments are combinations. Mitigate to reduce likelihood, transfer the remaining financial tail, and formally accept what is left; record each part separately.
• Every decision needs an owner, an expiry and a trigger. Acceptances without review dates and insurance assumptions nobody has checked against the policy wording are the two most common failures.

The four options in one table

NIST SP 800-39 lists the responses as accepting, avoiding, mitigating, sharing or transferring risk; ISO 31000 and ISO/IEC 27005 use broader treatment wording, but the same four decisions sit underneath. Sharing is treated here as partial transfer.

Decision criteria

Use the same questions for every risk, in this order, so that decisions are comparable across teams.

1. Is the inherent risk inside appetite? If yes, acceptance is a legitimate first answer and spending on controls may be waste. NIST SP 800-39 Appendix H states that a decision to accept risk must be consistent with the stated organisational tolerance for risk. If you have no tolerance statement, build one first; see the Risk Appetite and Tolerance for Cyber Guide.
2. Is the activity worth its exposure at all? If the value is low and the exposure high, avoid. If the activity is core to the business, avoidance is usually not a real option and should be recorded as rejected, with the reason.
3. What does mitigation cost against the loss it prevents? SP 800-39 notes that mitigation uses limited resources and may quickly become cost-ineffective. A quantified estimate, even a rough range, makes this comparison honest; see the Cyber Risk Quantification Guide.
4. What is left after mitigation, and can its financial tail be transferred? Low-frequency, high-severity losses suit insurance; frequent small losses usually cost less to retain than to insure.
5. Is the final residual inside tolerance? If yes, a named owner accepts it formally. If no, go back to step 2 or 3, or escalate.

Accept: when it is legitimate

Threat model: the risk was assessed, it sits inside tolerance, and the organisation is choosing not to spend more. The danger is not acceptance itself but implicit acceptance: a remediation date slips, nobody decides, and the organisation carries the risk without anyone having signed for it. SP 800-39 notes that some risk acceptance will likely be necessary, which is why the process must make it explicit.

• Good acceptance: named risk owner with budget authority, documented rationale, residual rating, conditions that would invalidate the decision, and an expiry date.
• Bad acceptance: approved by the person who requested it, no expiry, accepted because the fix was "too hard" with no estimate of what it would cost.
• Not acceptable to accept: legal obligations and controls the board has made non-negotiable.

Transfer: what insurance and contracts really cover

Threat model: the organisation believes a loss is covered and discovers at claim time that it is not, or that cover pays for only part of the impact. SP 800-39 describes transfer as making another entity wholly responsible for a risk and sharing as making it partly responsible, and it stresses that the local impact must still be addressed. Insurance pays money after a loss; it does not restore customer trust, regulatory standing or the hours of an outage.

• Exclusions: policies exclude defined events. Lloyd's Market Bulletin Y5381 (17 August 2022) required Lloyd's managing agents to include, in standalone cyber-attack policies incepting or renewing from 31 March 2023, a clause excluding war and state backed cyber-attacks that significantly impair a state's ability to function or its security capabilities, with a robust basis for attribution. Read your own wording for similar exclusions and for any conditions tied to controls you declared at application.
• Declared controls: application questionnaires ask about MFA, backups, endpoint detection and privileged access. A control declared but not operating can put cover at risk. See the Identity Controls for Cyber Insurance Questionnaires Guide.
• Retentions and sublimits: a retention you cannot absorb, or a ransomware or business interruption sublimit far below the modelled loss, leaves the tail with you.
• Contractual transfer: indemnities and service credits from suppliers are capped and depend on the supplier's ability to pay. A liability cap equal to annual fees rarely matches a data breach loss.

Whether to insure or retain the financial risk on the balance sheet is covered in Cyber Insurance vs Self-Insurance, and policy structure in the Cyber Insurance Guide.

Mitigate: reducing to a target, not to zero

Threat model: the control is chosen, funded and deployed, but residual risk is never measured, so nobody knows whether the target level was reached. Mitigation decisions should state the target residual rating up front, the controls expected to reach it, and how effectiveness will be tested. A plan of action and milestones (NIST SP 800-53 CA-5) tracks the work; a risk response record (RA-7) ties it to the risk. Combine with acceptance for the residual, rather than leaving the residual unowned.

• Preventive controls reduce likelihood: MFA, least privilege, patching, allowlisting.
• Detective and responsive controls reduce impact: logging, detection, incident response, immutable backups.
• Compensating controls stand in where the preferred control cannot be applied; they need testing like any other control.

Avoid: when stopping is the right call, and when it blocks the business

Threat model: security proposes avoidance for a risk the business needs to take, the business works around the decision, and the organisation ends up with the activity and none of the controls. SP 800-39 notes that avoiding risk may require selective reengineering of mission and business processes, which is a business decision, not a security one.

• Good avoidance: not collecting a data field nobody uses; retiring an internet-facing legacy portal; declining a market whose regulatory exposure exceeds appetite.
• Avoidance that backfires: banning a widely wanted tool without an approved alternative, which pushes use out of sight. Offer a mitigated route alongside the prohibition.
• Who decides: the business owner of the activity, with security advising on exposure. Security should not have a unilateral veto over business activities.

Who may decide at which level

Authority should follow the residual rating and the option chosen. Transfer and avoidance often need different authorities from acceptance: transfer commits budget and contract terms, and avoidance changes business strategy.

In US federal systems, the authorising official accepts system-level risk at authorisation under the NIST Risk Management Framework; see the NIST Risk Management Framework (SP 800-37) Guide. For how treatment decisions roll up into enterprise risk, see the NIST IR 8286 Cybersecurity and ERM Integration Guide; NISTIR 8286B (updated February 2025) covers recording risk priority and response in the cybersecurity risk register.

Worked scenario

A retailer's payment page relies on third-party scripts loaded from several providers. Assessment rates the risk of a malicious script injection as high: likely enough given the number of external scripts, with severe impact through card data theft and regulatory consequences.

• Avoid: considered for two analytics scripts that add little value on the payment page; they are removed. Avoidance of the payment provider's own script is rejected because it is required for checkout.
• Mitigate: a script inventory, integrity checks and a content security policy on the payment page, with change detection alerting. Target residual: medium.
• Transfer: the cyber policy's breach response and payment card costs cover are checked against the modelled loss; the retention and any sublimit for card brand assessments are recorded. Contracts with remaining script providers are reviewed for notification duties.
• Accept: the remaining medium residual is accepted by the e-commerce director for six months, with the trigger that any new script on the payment page reopens the decision.

Documentation and review cadence

Record the decision so that a reviewer a year later can see why it was made. The register entry should hold: risk ID and description; inherent rating; options considered, including those rejected and why; chosen treatment or combination; target and actual residual rating; decision owner and date; cost of treatment; for transfer, the policy or contract reference and the exclusions checked; for acceptance, expiry and invalidating triggers. The Risk Treatment Plan Template and Risk Register Template give usable formats.

Framework mapping

Measuring it

• Explicit decisions: percentage of high and critical risks with a documented treatment decision and named owner.
• Expired acceptances: number of acceptances past expiry without renewal or closure, which should trend to zero.
• Residual achieved: percentage of mitigation plans that reached their target residual rating by the planned date.
• Transfer validation: percentage of risks marked as transferred where policy or contract wording, limits and exclusions were checked at the last renewal.
• Appetite breaches: number of risks with residual outside tolerance and no escalation record.

Common failure patterns

• Acceptances that never expire: approved once, never reviewed, still active after the asset, owner and threat have all changed.
• Insurance as a control: a risk marked "transferred" because a policy exists, without checking that the scenario is covered, that exclusions do not apply and that declared controls are true.
• Avoidance that drives workarounds: a ban with no alternative, so the activity continues unseen and unmanaged.
• Mitigation without a target: controls funded with no residual rating defined, so nobody can say when the risk is treated.
• Self-approval: the team that owns the fix also accepts the risk, so acceptance becomes a way to avoid work.
• Single-option thinking: recording only one treatment when the real decision was a combination, which hides the accepted residual.

Practitioner checklist

• Publish an appetite and tolerance statement that acceptance decisions can be tested against.
• Record the options considered and rejected for every high and critical risk, not only the one chosen.
• Set a target residual rating before funding any mitigation.
• Check insurance wording, retentions, sublimits and exclusions before marking a risk as transferred.
• Confirm that controls declared on insurance applications are operating.
• Give avoidance decisions to the business owner and offer a mitigated alternative where possible.
• Route each decision through the authority table by residual rating and option.
• Set an expiry and invalidating triggers for every acceptance.
• Review transfers at every policy and contract renewal.

Standards and references

• NIST: SP 800-39 Managing Information Security Risk
• NIST: IR 8286B Prioritizing Cybersecurity Risk for Enterprise Risk Management
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: SP 800-37 Rev. 2 Risk Management Framework
• ISO: ISO 31000 Risk management
• Lloyd's: Market Bulletin Y5381 State backed cyber-attack exclusions

Related NHI Mgmt Group resources: Security Exceptions and Risk Acceptance Guide, ISO 31000 Risk Management Guide, FAIR Model and Open FAIR Standard Guide, Cyber Risk Appetite Statement Template.