Risk treatment.

The four treatment options

Risk treatment is the step where assessment turns into action. Once a risk has been identified, analysed and evaluated against your criteria, you have to decide what to do about it. The conventional vocabulary, shared by ISO 31000 and ISO/IEC 27005, gives you four families of response. They are not ranked from best to worst; the right choice depends on the risk, the cost of the control and the appetite the board has signed off.

• Avoid: stop the activity that creates the risk, or do it a different way. You decommission the exposed service, drop the feature, or exit the market that triggers the exposure.
• Reduce (modify): apply controls that lower the likelihood, the impact, or both. This is the most common path and the one that ties directly into your control set.
• Transfer (share): move some of the financial or operational consequence to a third party, typically through insurance or a contractual clause. Transfer rarely moves the whole risk; you keep the reputational and regulatory residue.
• Accept (retain): decide the residual risk is tolerable and live with it, on the record. Acceptance is a legitimate decision, not a failure to act, as long as the right authority signs it.

From decision to evidence: the chain that auditors follow

The hard part of risk treatment is not picking an option, it is keeping the paper trail coherent. Every decision should be justified by reference to the documented risk appetite, captured in a risk treatment plan, and then traced through to the controls that implement it and the evidence that they operate. In an ISO/IEC 27001 information security management system this is where the Statement of Applicability (SoA) lives: it records which Annex A controls apply, why, and where the evidence sits.

The single most common audit finding in this area is drift. The treatment plan said one thing, the SoA said another, and the operation on the ground had moved on from both. A control gets retired, a project changes scope, a supplier is swapped out, and nobody updates the documents. The decisions may all have been reasonable in isolation, but the chain no longer reconciles, and that inconsistency is what produces a non-conformity.

Residual risk and re-assessment

Treatment does not make a risk disappear. What is left after the controls are applied is the residual risk, and that is the figure the risk owner actually accepts. Good practice is to re-run the analysis on the treated risk so the residual level is explicit, then route it back through the same acceptance authority. ISO/IEC 27005, aligned since its 2022 revision with the principles of ISO 31000, frames this as an iterative loop rather than a one-off exercise: you treat, you measure what remains, you accept or treat again.

What practitioners actually do

In day-to-day GRC work, risk treatment is run as a living plan rather than a project deliverable. A workable rhythm looks like this:

1. Tie each treatment decision to a named risk in the register and to the appetite statement that justifies it, so the rationale survives staff turnover.
2. Assign a single accountable owner and a target date to every "reduce" action, and track them like any other commitment.
3. Keep the SoA, the treatment plan and the control evidence reconciled on a fixed cadence, not just before an audit.
4. Record residual risk and the acceptance signature for everything you do not fully mitigate, including the risks you transfer.

Done this way, the treatment plan stops being audit theatre and becomes the place where the organisation can honestly say what it is exposed to and who decided that was acceptable.