Risk mitigation strategies: the four treatment options and how to choose

The risk assessment is done, the register is scored, and the enterprise customer's security review wants to know what you are doing about the reds. Your ISO 27001 auditor will ask the same question at stage 2. A scored list is not an answer. A decision for each risk, with an owner, is.

This guide sets out the four risk mitigation strategies (avoid, reduce, transfer and accept) for founders, CTOs and security leads at UK B2B tech firms with 25 to 100 staff. It maps them to the UK "4 Ts", gives a method for choosing between them, and shows how each choice becomes the evidence an auditor and a buyer expect.

What are the four risk mitigation strategies?

The four risk mitigation strategies are to avoid the risk, reduce it with controls, transfer or share it, or accept it. Most risks get a mix, such as reducing then accepting. The choice depends on the risk's score against your acceptance criteria and on cost, and whatever is left must be accepted by a named owner.

Different sources use different words for the same four moves. UK public-sector teams often say "the 4 Ts": treat, tolerate, transfer and terminate, the terms HM Treasury used in its 2004 Orange Book. Information security standards use their own terms. The table lines them up, with an information security example of each.

The longer lists you will find elsewhere are mostly the same moves split more finely. The current Orange Book (May 2023), paragraph D6, lists avoiding the risk, taking or increasing it to pursue an opportunity, retaining it by informed decision, changing the likelihood, changing the consequences, and sharing it, for example through commercial contracts. Changing likelihood and consequences is what "reduce" means in practice, and taking on more risk to pursue an opportunity is the one real addition. For the wider standard behind that wording, see our page on ISO 31000.

Does ISO 27001 prescribe a fixed list of risk treatment options?

No. ISO/IEC 27001:2022 Clause 6.1.3 asks you to select appropriate risk treatment options, determine the controls they need, compare those controls with Annex A, produce a Statement of Applicability and a risk treatment plan, and obtain the risk owners' approval. The standard does not name the options or limit how many you use.

That matters because many guides say Clause 6.1.3 lists four options. It does not. ISO/IEC 27005, the guidance standard for information security risk, has its own vocabulary: earlier editions named the options risk modification, retention, avoidance and sharing. But ISO/IEC 27005 is guidance, not a requirement. An auditor checks that each risk has a reasoned, recorded decision, not that you used particular labels.

Our Clause 6.1 guide covers the clause in full. This page stays on the decision itself.

How do you choose between risk mitigation strategies?

Choose between risk mitigation strategies by testing each risk against three things in order: its score against your acceptance criteria, the cost of each option against the reduction it buys, and any regulatory or contractual constraint that rules an option in or out. The first test says whether to act, the second says how, and the third can overrule both.

Work through each risk above your acceptance line like this:

1. Score against acceptance criteria. Your risk methodology should define the score at which a risk is acceptable without further action. Anything at or below that line is a candidate to accept. Anything above it needs a treatment, and the gap between the current score and the line tells you how much reduction you need.
2. Ask whether the activity is worth keeping. If the activity that creates the risk adds little value, avoiding it is often the cheapest option. Retiring a system costs less than securing it for years.
3. Price the reduction. For each candidate control, estimate the cost to build and run it against the drop in score it delivers. The Orange Book (paragraph D7) frames the same trade-off: balance the benefits of an option against its costs, efforts or disadvantages, while weighing obligations and stakeholder views, not only money.
4. Check the constraints. A customer contract may require a specific control. UK GDPR requires appropriate security for personal data, so accepting a high risk to personal data is rarely defensible. A regulator's rules can remove "accept" from the menu altogether.
5. Decide what is left. After the chosen treatment, re-score the risk. If the expected residual score sits at or under the line, the owner can accept it. If not, add treatment or escalate.

Setting the acceptance line itself is a risk appetite decision, made once at leadership level rather than risk by risk. Where the line is unclear, every treatment decision becomes an argument.

How do you reduce a risk with controls?

Reduce a risk by adding or improving controls that lower its likelihood, its impact, or both. Use a mix of preventive controls that stop the event, detective controls that spot it quickly, and corrective controls that limit the damage and restore service. Then compare your chosen controls with ISO 27001 Annex A to check nothing obvious is missing.

A balanced set for one risk usually covers all three types. Take ransomware on the file estate:

• Preventive: multi-factor authentication, patching to a defined timescale, and restricting who can run executables.
• Detective: endpoint detection alerts that reach someone out of hours, and monitoring for unusual file changes.
• Corrective: immutable or offline backups, a tested restore, and an incident response plan people have rehearsed.

A risk treated only with preventive controls is a bet that prevention never fails.

Derive the controls from the risk first, then use Annex A as the completeness check. Starting from the catalogue tends to produce controls no risk asked for. Our Annex A controls guide lists all 93 controls and how they group. Record which risk each control answers, because that link is what turns a control list into a defensible Statement of Applicability.

What does risk transfer actually transfer?

Risk transfer moves some of the financial or operational consequence of a risk to another party, usually an insurer or a supplier. It does not move accountability. If a supplier loses your customers' data, your customers, auditor and regulator still look to you. Transfer is a way of funding or sharing a risk, not removing it.

Cyber insurance. The National Cyber Security Centre's cyber insurance guidance is clear that insurance can provide financial protection during an incident, but "it will not prevent a cyber breach/attack". The NCSC also says organisations "must continue to put measures in place to protect what they care about". It advises checking in detail what a policy excludes, and warns that an insurer may not have to pay a claim if the security measures you declared were not in place.

That last point turns insurance into a control obligation. The answers on your proposal form become commitments. If the form says multi-factor authentication is enforced everywhere, it needs to be, and you need evidence that it is.

Supplier contracts. Outsourcing a service to a supplier can share the operational risk, but only if the contract says what the supplier must do and how you will know they are doing it. ISO 27001 Annex A expects security requirements to be agreed with suppliers; our page on Annex A 5.20, supplier agreements, covers what those clauses should include. The 2004 Orange Book made the underlying point plainly: reputational risk generally cannot be transferred, even when a service is contracted out.

Record three things for each transferred risk:

• the policy or contract that carries it;
• its limits and exclusions;
• the person who monitors it.

If nobody can state the cover limit, the risk has not been transferred.

When is it right to accept a risk, and who can accept it?

Accepting a risk is right when its score sits within your acceptance criteria, or when further treatment would cost more than the harm it prevents and no law or contract forbids the exposure. Only a named risk owner with the authority and budget to act may accept it, and the acceptance must be recorded with a date and a reason.

Acceptance is a decision, not a default. A risk left untreated because nobody got to it has not been accepted; it has been ignored. The Orange Book's phrase is "retaining the risk by informed decision", and the important word is informed.

Set acceptance authority by score in your risk methodology. We recommend a simple structure, which is our suggestion and not a requirement of any standard:

ISO 27001 Clause 6.1.3 requires risk owners to approve the treatment plan and accept the residual risk. An IT contractor signing for the business is a finding waiting to happen.

When should you avoid a risk altogether?

Avoid a risk when the activity that creates it is worth less than the cost of making it safe, or when no affordable treatment brings the risk within your acceptance criteria. Avoiding means stopping or not starting the activity: retiring a system, declining a data type you do not need, or choosing not to enter a market.

Avoidance is the easiest of the four risk mitigation strategies to overlook, because it can feel like admitting defeat. It is often the cleanest. Data you never collect cannot be breached, and a server you have switched off needs no patching. Record the decision and the evidence that the activity has ended, such as a decommissioning ticket, so the risk can be closed in the register.

What goes in a risk treatment plan?

A risk treatment plan records, for each risk you are treating, the option chosen, the specific actions, a named owner, a deadline, the controls the actions link to, and the target residual score. It is the working list that turns treatment decisions into delivered controls, and ISO 27001 Clause 6.1.3 requires you to produce one.

We recommend these columns. They can sit in a separate plan or as extra columns in the risk register:

The Orange Book's paragraph D8 asks for much the same: the rationale for the option, the proposed actions, who is accountable, the resources, and when actions will start and finish.

"Improve security" is not a plan line.

How does the risk treatment plan connect to the Statement of Applicability?

The risk treatment plan and the Statement of Applicability are two views of the same decisions. The plan says what you will do about each risk and by when. The Statement of Applicability lists every Annex A control, whether it applies, why, and whether it is implemented. Each planned control should appear there with the same status.

Under ISO 27001, Clause 6.1.3 is where you plan the treatment and Clause 8.3 is where you carry it out and keep documented information about the results. Our Clause 8.3 guide covers what implementation evidence an auditor will look for.

The test is reconciliation. The register, the plan and the Statement of Applicability should tell one story: a risk scored high in the register, a plan line reducing it, and the matching controls marked as implemented or in progress. When they disagree, an auditor or a customer's reviewer usually finds it first.

When should you revisit a risk treatment?

Revisit a risk treatment when a planned action completes, when its deadline slips, when the business changes in a way that affects the risk, after a security incident or near miss, and at least at each planned risk review. ISO 27001 Clause 8.2 expects risk assessments at planned intervals and when significant changes are proposed or occur.

Practical triggers to build into your calendar and change process:

• Action complete: re-score the risk and confirm the owner accepts the actual residual risk, not the target.
• Deadline missed: the owner either re-plans with a new date or formally accepts the higher interim risk.
• Change: a new product, supplier, office, cloud service or acquisition can change the score of existing risks.
• Incident: a real event is the best evidence of whether a treatment works.
• Insurance renewal: check that the controls you declared are still true, and that cover still matches the risk.

What are the common mistakes with risk mitigation strategies?

The common mistakes are treating every risk the same way, assuming insurance or outsourcing makes a risk disappear, accepting risks by default rather than by decision, letting someone without authority sign acceptance, and building controls from the Annex A list instead of from the risks. Each produces a register that looks complete but does not stand up to questioning.

1. One option for everything. Reducing every risk spends money on low risks and starves the high ones. Use all four.
2. Transfer as wishful thinking. A policy nobody has read, or a supplier nobody monitors, transfers nothing.
3. Silent acceptance. An untreated risk with no sign-off is not accepted. An auditor will treat it as unmanaged.
4. The wrong signature. Acceptance by someone without budget or authority does not count.
5. Catalogue-first controls. Starting from Annex A rather than the risk leaves real gaps and builds controls nobody needs.

A treatment decision nobody owns is not a decision.

Frequently asked questions