Risk treatment and residual risk explained

Who this is for: risk owners, IT and security managers, and anyone who has to answer “so what are we doing about it?” once a risk has been scored. It assumes you already have a register with scored entries and want to turn the top of it into decisions you can defend.

Treatment is a decision, and the decision has to be recorded

Scoring tells you what to look at first. Treatment is what you decide to do. The four standard answers are to mitigate, transfer, avoid or accept. Any of the four can be correct; what makes a decision defensible is that it was made by someone with the authority to make it, for stated reasons, with a date on which it will be looked at again.

An auditor, insurer or board member reading your register is not usually judging whether you chose the “right” option. They are checking that a choice was made, deliberately, by the right person, and that the register shows what happened next.

The four options

Option	What it means	When it fits	What it does not do
Mitigate	Reduce likelihood, impact or both with controls	Most high and critical IT risks	Does not remove the risk; leaves a residual risk that must be scored
Transfer	Share the financial consequence through insurance or contract	High-impact, lower-likelihood events whose cost you cannot absorb	Does not prevent the event or move accountability; has exclusions and conditions
Avoid	Stop the activity, retire the system or decline the supplier	The risk is not worth the benefit and the activity is optional	Costs the benefit the activity gave you
Accept	Knowingly retain the risk	Residual risk is within appetite or treatment costs more than the exposure	Is not “do nothing and hope”; needs an owner, a rationale and a review date

Some frameworks use “retain” or “share” instead; the ideas are the same. Use the vocabulary your organisation already uses, and be consistent.

Mitigate

Mitigation means choosing specific controls and, importantly, choosing which factor they reduce. A control that reduces likelihood (multi-factor authentication makes a stolen password alone insufficient, for example) behaves differently from one that reduces impact (tested, offline backups limit how bad a ransomware event becomes). The tool looks at which factor is driving the score for exactly this reason: a risk dominated by impact usually calls for resilience, and one dominated by likelihood usually calls for fixing a root cause.

Select controls by asking three things: does it address the cause stated in the register entry, can it be operated reliably by the people you have, and how will you know it is working? The last question matters because an untested control cannot reduce a score in a defensible way.

Transfer

Insurance and contractual indemnities move financial consequences. They do not move the outage, the reputational damage or the legal duties you owe to customers and regulators. Before counting insurance as treatment, read the policy for conditions and exclusions. Policies commonly require specific controls to be in place, such as multi-factor authentication or offline backups, and may exclude losses arising from controls that were not maintained as described on the application. If the application said MFA was enforced everywhere and it was not, the cover may be disputed. That makes honest answers on the questionnaire part of the treatment, not a formality.

Contractual transfer has the same limits. A supplier indemnity is only as good as the supplier’s liability cap and balance sheet.

Avoid

Avoidance is the cleanest option and the least used, because it means giving something up. Examples: switching off a legacy service that cannot be patched instead of wrapping it in compensating controls, declining to store card data and using a hosted payment page instead, or not onboarding a supplier that will not agree to basic security terms. Include avoidance in every discussion of a critical risk, even if only to rule it out.

Accept

Acceptance is legitimate when the residual risk is within the organisation’s appetite, or when the cost of treating exceeds the exposure. It becomes illegitimate when it is the silent default. A proper acceptance record names who accepted, which score they accepted, why, which conditions would reopen it and when it expires.

Residual risk: what is left after treatment

Inherent risk is the exposure assuming no effective controls. Residual risk is the exposure after the controls that actually work are accounted for. Registers need both, because the gap between them is the value of your controls and the residual figure is what the owner is accepting.

Two rules prevent self-deception:

Residual moves only when a control changes. If the residual likelihood falls from 4 to 2, you should be able to point at the specific control, state when it went live and say how you know it operates.
Credit tested controls, not intended ones. A control that has been designed but not implemented reduces the *planned* residual, not the current one. Keep two columns if you need to: current residual and target residual.

A worked example, using the scale in the scoring guide:

risk:            R-014 Remote access to finance server uses passwords alone
inherent:        L4 x I4 = 16 CRITICAL
treatments:      1. MITIGATE: enforce MFA on VPN (cuts likelihood of credential misuse)
                 2. MITIGATE: restrict finance share to named group, segment the server (limits blast radius)
                 3. MITIGATE: documented restore of the server from offline copy (limits impact)
current_residual: L4 x I4 = 16  (no control live yet)
target_residual:  L2 x I3 = 6  MEDIUM  (after 1-3, assuming each operates)
transfer:        Cyber insurance reviewed; policy requires MFA on remote access -
                 treatment 1 is a precondition for the cover, not just a security improvement
accept:          Residual 6 accepted by Finance Director, review 2027-01-09

Notice that the example does not claim the risk is gone. A target of 6 means a medium risk remains and someone has agreed to carry it.

Writing the treatment plan so it gets done

A treatment is a project in miniature, and it fails like projects fail. Each one needs:

Specific actions, each small enough to finish. “Enforce MFA on the VPN gateway for all users, with documented exceptions” rather than “strengthen authentication”.
An owner for each action and a risk owner for the whole.
Dates, with milestones for anything longer than a quarter.
Success criteria that someone other than the implementer can check. “VPN login with password alone is rejected; test performed 2026-11-20 with two accounts.”
A cost, even a rough one, so acceptance of the remainder can be justified.
Dependencies, such as budget approval, change windows or a supplier’s delivery.

When the dates slip, record that. A register that shows a treatment overdue by two months is doing its job. One that quietly moves the date forward each quarter is hiding it.

Choosing between options

For a given risk, lay the options side by side and ask four questions. How much does each reduce the score, and how sure are you? What does it cost to implement and operate? What does it do to the business (friction, delay, lost capability)? What remains afterwards, and who owns it?

A short comparison for one risk can be enough:

Option	Effect on score	Rough cost	Business impact	What remains
Enforce MFA	Likelihood 4 to 2	Licences plus a few days of work	Small login friction	Phishing-resistant gaps; residual 8 on its own
MFA plus segmentation and restore test	16 to 6	Above plus a weekend of testing	Small	Residual 6; owner accepts
Accept as is	None	None	None	16, which exceeds appetite; not an available option without escalation
Avoid (remove remote access)	Eliminates this path	Alternative working arrangements	Large	Other access paths

The point of the table is not the specific numbers, which are illustrative, but that the third row is eliminated by the organisation’s own appetite and that the choice is visible.

Appetite and who may accept what

Acceptance authority should scale with the score. A common arrangement is that low risks are accepted by the service owner, medium by a department head, high by an executive, and critical only by the executive team or board. Whatever your arrangement, write it down once and reference it in the register so that “accepted” always carries an authority level.

Common mistakes

Treating the number instead of the risk. Lowering a likelihood on paper to fall below a threshold.
Counting insurance as a control. It pays for some consequences; it does not reduce the event.
Open-ended acceptance. No expiry, no conditions, no named person.
Risks with no treatment decision at all because the owner has never been asked.
Controls with no evidence. A treatment marked complete without a test or sample showing it operates.
Compensating controls that never end. A temporary workaround becomes permanent. Give each one an end date.
Forgetting new risks created by the treatment, such as the MFA recovery process becoming the new weak point.

What to do next

Take your top five scored entries and, for each, write one line per option (mitigate, transfer, avoid, accept) and say why you chose or rejected it. The risk matrix tool will suggest which treatment type to examine first for each score shape and flag entries still above your threshold after planned treatment; those suggestions are a starting point for discussion, not advice about your systems. Then take the decisions that need senior sign-off into your board reporting, expressed as requests.