Risk Treatment Plans: Turning a Decision Into Action

Once you've identified and assessed a risk, you have to decide what to do about it — and document that decision in a way the organisation can stand behind. That's the job of the risk treatment plan: it defines how the organisation has come to an agreement on how to deal with an identified risk.

This isn't a complete guide to risk treatment — that would run far longer than anyone wants to read. These are the things that matter most when you're actually developing the plans.

It's a decision made together, not a form filled in alone

A risk treatment plan is the record of an agreement, which means it should come out of a conversation rather than being drafted in isolation. For most ISMS risks, that discussion involves the risk owner, the relevant control owner(s), and any impacted stakeholders — to name just the core group.

This matters because a treatment decision made by one person in a spreadsheet rarely sticks. The people who own the risk and operate the controls need to agree on the path, or the plan becomes something written about them rather than by them — and those plans tend to quietly die.

Analyse before you choose a treatment

The treatment option should fall out of analysis, not be decided up front. Before you land on an approach, work through:

• The cause — what is actually driving this risk? Treat the cause, not just the symptom.
• The inherent risk — likelihood × impact, before any treatment is applied.
• Existing compensating controls — what is already in place that reduces this risk, even partially?

Only once you understand those things can you make a defensible choice about how to treat it.

The four treatment options — and the 4 T's

There are generally four ways to treat a risk. They're commonly known by two names — the plain-language version and the "4 T's" — and they mean the same thing:

Each one carries its own requirements, and that's where most of the substance lives.

Mitigate (Treat): you need a real action plan

To mitigate is to reduce the risk — but "we'll improve this" is not a treatment plan. Mitigation requires a solid action plan with:

• Steps — the actual actions to be taken
• Ownership — who is responsible for each
• A timeframe — when it will be done
• A project attached, if the work warrants one
• Resources required — what it will take to deliver

A useful discipline here is to apply the SMART principles to your actions: Specific, Measurable, Achievable, Relevant and Time-bound. A mitigation action that fails any of those tests — vague, unmeasurable, or open-ended — is one that won't get delivered or won't be provable when you're asked to evidence it.

Avoid (Terminate): remove the cause entirely

To avoid a risk is to remove its cause altogether, so the risk simply no longer exists. This is the cleanest treatment when it's available.

In practice, if the risk is tied to a specific asset or application, avoidance might mean decommissioning or replacing it. You're not reducing the risk — you're eliminating the thing that generates it. Where it's viable, termination removes a risk from your register for good rather than committing you to managing it indefinitely.

Transfer: the option that catches organisations out

Transfer is the treatment most often misunderstood — and the misunderstanding is dangerous. Many organisations assume that once a risk is transferred, it's out of scope or no longer necessary to track. That is not true.

When you transfer or outsource a risk to a third party, you take on a new and necessary obligation: validating that the third party is actually doing what they've been contracted to do. The risk hasn't vanished — you've handed responsibility for a control to someone else, and you now have to assure yourself they're delivering.

Take outsourced backups as the classic example. Transferring backup responsibility to a provider doesn't end your involvement — it means you need to verify that:

• Backups are being completed against your agreed schedule
• They are periodically restored and tested (an untested backup is a hope, not a control)
• The RTO and RPO meet your organisation's business continuity and recovery needs

The failure mode is brutal: you wait for an incident, reach for the backups, and only then discover that the risk you thought you'd transferred was only masked — still present to the business the whole time. Transfer shifts the work, not the accountability. Build the validation into the plan, or you've simply moved the risk somewhere you can no longer see it.

Accept (Tolerate): a conscious, justified decision

Accepting a risk means that, based on your assessment, the risk sits within the organisation's risk appetite or tolerance. It's a legitimate, deliberate choice — not a default for risks you'd rather not deal with.

There may be other valid justifications for acceptance: technological limitations, resourcing availability, or an operational impact from mitigation that outweighs the benefit of implementing the control. What matters is that the reasoning is explicit and recorded. An accepted risk should be a documented, owned decision someone can point to later — not a gap that was quietly tolerated because no one got to it.

(One important caveat under RFFR: acceptance is a tool for risk-based controls. Contractual obligations — like data sovereignty — sit outside the risk-acceptance machinery and cannot simply be accepted.)

The plan is only as good as the process behind it

There are many options and nuances in risk treatment, but the through-line is this: how well risk treatment works as a tool depends entirely on the process being well understood, integrated, and taken seriously at every level of the organisation.

A beautifully written treatment plan means nothing if the action owners don't know it exists, the transfer never gets validated, or the accepted risk is forgotten the day after it's signed off. Treatment plans live or die on follow-through.

Again — this isn't the complete picture of risk treatment. But keep these things in mind as you develop your plans, and you'll avoid the failures that quietly undermine most risk registers: the mitigation that was never actionable, the transfer that only masked the risk, and the acceptance no one can justify.