Risk assessment tells you what your risks are. Risk treatment is what you decide to do about them. For many organisations going through ISO 27001 implementation, the assessment itself gets the most attention — identifying assets, threats, vulnerabilities, and likelihood ratings. But the treatment decisions are where the real work happens, and where auditors spend significant time reviewing the quality of your thinking.
Clause 6.1.3 of ISO 27001 requires you to select appropriate risk treatment options and determine the controls necessary to implement them. That sentence contains two important ideas: the options are a choice, and the controls you select must be appropriate to the option you have chosen. This guide explains what each option means, when to use it, and how to document your decisions so they stand up to scrutiny.
The Four Risk Treatment Options
ISO 27001 recognises four options for treating an identified information security risk. They are not a hierarchy — none is inherently better than another. The right option depends on the nature of the risk, your organisation’s risk appetite, the cost of alternative treatments, and practical feasibility.
The Four ISO 27001 Risk Treatment Options
Clause 6.1.3 requires you to select appropriate options — none is inherently better than another
1. Mitigate (Risk Modification)
Mitigating a risk means applying controls that reduce either the likelihood of the risk occurring, the impact if it does occur, or both. This is the most commonly selected option and corresponds to the majority of Annex A controls.
A risk of unauthorised access to customer data might be mitigated through access controls, multi-factor authentication, encryption at rest, and regular access reviews. None of those controls eliminates the risk entirely — some residual risk will remain — but together they reduce it to a level that is acceptable.
When selecting this option, you need to identify which specific controls you will implement and confirm that the residual risk after those controls are applied is within your defined risk acceptance criteria. The gap between inherent risk (before controls) and residual risk (after controls) is the measurable effect of your treatment.
2. Avoid (Risk Elimination)
Avoiding a risk means deciding not to engage in the activity that creates the risk in the first place. If processing a certain category of personal data creates a risk you cannot adequately mitigate, you might decide not to process that data at all. If hosting a particular type of system exposes you to risks beyond your risk appetite, you might discontinue that system.
Risk avoidance is a legitimate treatment option but it is often underused — organisations assume they must mitigate rather than considering whether the activity creating the risk is necessary at all. It is also sometimes misapplied: labelling a decision to stop an activity as “risk avoidance” when the activity simply isn’t planned is not meaningful risk treatment.
The key test for risk avoidance is whether the decision is deliberate and documented. If you are not processing certain data categories specifically because the risk is unacceptable, say so. That documented decision is evidence of risk-based thinking.
3. Transfer (Risk Sharing)
Transferring a risk means shifting some or all of the financial or operational consequences to a third party. Cyber insurance is the clearest example: the insurer accepts the financial consequences of certain incidents in exchange for a premium. Outsourcing a function to a cloud service provider may also represent partial risk transfer, though it does not remove your accountability for the data or process.
There are two important limitations to understand about risk transfer:
Transfer reduces financial exposure but not likelihood. Taking out cyber insurance does not make a breach less likely. If you transfer a risk without also mitigating the likelihood, you still have a control gap — the insurer will pay out, but you will still have suffered an incident.
Transfer cannot shift accountability. Under GDPR and most data protection frameworks, you remain accountable as a data controller even if the breach occurs at a processor or third party. Insurance can cover costs; it cannot transfer regulatory accountability.
For risk transfer to be meaningful in an ISMS context, document what is being transferred (financial loss, operational recovery, etc.), to whom, under what conditions, and what residual risk remains after the transfer.
4. Accept (Risk Retention)
Accepting a risk means making a deliberate, documented decision to live with it — neither mitigating, avoiding, nor transferring it. This is appropriate when the risk falls within your defined risk acceptance criteria, when the cost of treatment exceeds the potential impact, or when no practical treatment option is available.
Acceptance is not the same as ignoring. An ignored risk has no decision recorded against it. An accepted risk has been identified, assessed, reviewed against your risk acceptance criteria, and formally signed off by someone with appropriate authority — typically the risk owner or senior management, depending on the risk level.
Unilateral acceptance of high risks by the ISMS lead without management sign-off is a common audit finding. The standard requires that “risk owners” accept residual risks (Clause 6.1.3(e)), which implies the person accepting the risk must have the authority to do so.
Residual Risk: What Remains After Treatment
For every risk where you have selected mitigate, transfer, or avoid, you need to assess the residual risk — the level of risk that remains after your treatment controls are in place. Residual risk should then be compared against your risk acceptance criteria.
If residual risk exceeds your acceptance threshold, further treatment is required. If it falls within the threshold, it can be formally accepted.
This creates a closed loop: identify risk → assess inherent risk → select treatment option → apply controls → assess residual risk → accept or treat further. Your risk treatment plan should show this logic for each risk.
Combining Options
Treatment options are not mutually exclusive. A single risk will often benefit from a combination — partial mitigation to reduce likelihood, partial transfer through insurance of the financial consequences, with a deliberate acceptance of the residual.
For example, a risk of ransomware encrypting business-critical systems might be treated with technical controls (backups, endpoint detection, network segmentation) to reduce the likelihood and impact, cyber insurance to cover recovery costs and incident response fees, and an accepted residual risk that a sufficiently sophisticated attack may still succeed.
Documenting this combination clearly shows that your treatment is proportionate and considered, which is exactly what an auditor is looking for.
The Risk Treatment Plan
Clause 6.1.3 requires you to produce a risk treatment plan. This is the document that links each identified risk to its selected treatment option and the controls that will be implemented. It is one of the mandatory documented information items under the standard.
Your risk treatment plan should capture for each risk:
- The risk identifier and description
- The selected treatment option (mitigate, avoid, transfer, accept)
- The specific controls or actions to be implemented
- The responsible owner for each control
- The target completion date for implementation
- The residual risk level after treatment
- Whether the residual risk has been accepted, and by whom
This document becomes the management tool for driving implementation forward and the audit trail for demonstrating that treatment decisions were deliberate, proportionate, and properly authorised.
Risk Treatment Plan: What to Capture
A mandatory document under ISO 27001 — linking each risk to its treatment option, controls, owner, and residual risk
Linking to Annex A
When you select the mitigate option, you will typically draw on controls from Annex A of ISO 27001 to address specific risks. The connection between a risk and the Annex A controls you have selected to treat it should be traceable.
This traceability also matters for your Statement of Applicability (SoA). The SoA must document whether each Annex A control is applicable and, if so, link it to either a risk treatment decision or another business requirement. Controls included in your risk treatment plan should appear as applicable in your SoA with a reference to the relevant risk.
If your risk treatment plan identifies a need for a control that does not appear in Annex A, you can implement additional controls — the standard does not limit you to the Annex A list.
What Auditors Look For
When reviewing your risk treatment, auditors are assessing whether your decisions are documented, proportionate, and properly authorised.
Treatment options are not just formalities. Auditors look for evidence that treatment options were genuinely considered, not just assigned mechanically. A register where every high risk is “mitigate” and every low risk is “accept” with no further analysis does not demonstrate risk-based thinking.
Residual risk is assessed, not assumed. The residual risk after controls should be explicitly assessed and recorded. Stating that a risk is “mitigated” without assessing the residual level provides no assurance that treatment is adequate.
Acceptance decisions are authorised. Accepted risks — particularly medium and high risks — should be formally signed off by someone with appropriate authority. ISMS leads do not typically have authority to accept significant risks on behalf of the organisation.
The risk treatment plan is current. A risk treatment plan prepared at implementation and never revisited does not reflect the current state of your risk landscape. Auditors will check whether it has been updated following risk assessment reviews and after significant changes.
Controls are actually implemented. A risk treatment plan that lists controls to be implemented is not evidence of implementation. Auditors will test whether selected controls exist in practice.
Common Mistakes
Treating acceptance as the default for risks with no obvious solution. Acceptance should be a positive decision, not the fallback when you cannot think of a control. If a risk is high and the acceptance rationale is “we have not implemented any controls yet”, that is an implementation gap, not a treatment decision.
Selecting transfer as a treatment without understanding its limits. Organisations that treat insurance as a substitute for controls may find that claims are denied due to lack of basic security hygiene, or that coverage does not apply in the circumstances of an actual incident.
Documenting options without documenting reasoning. “Option: mitigate. Controls: access controls” is not a treatment plan. The reasoning for why those controls were selected, what residual risk they leave, and who has accepted that residual should all be captured.
Letting the risk treatment plan age. A risk treatment plan that does not reflect control implementation progress, updated risk scores, or new risks identified since implementation gives an auditor no confidence in your ongoing risk management.
FAQs
Do we have to use all four options?
No. The standard requires that you select appropriate options — there is no requirement to use all four. You may even just use your own options. Most organisations will use a combination of mitigate and accept, with transfer applied selectively and avoidance used in specific circumstances. What matters is that the option selected is appropriate to the risk and documented with a rationale.
Who decides which treatment option to apply?
The risk owner — the person accountable for the risk and the business process it relates to — should make or confirm treatment decisions, particularly acceptance decisions. The ISMS lead typically facilitates the process and provides input on available controls, but should not be the sole decision-maker for risks owned by other parts of the business.
How detailed does the risk treatment plan need to be?
Detailed enough to demonstrate that decisions are traceable, authorised, and actionable. The standard does not prescribe a format, but the plan should show the link from each risk to its treatment option, the controls selected, ownership, and the residual risk assessment. A one-line entry per risk with no supporting rationale is unlikely to satisfy an auditor.
What is the Statement of Applicability and how does it relate to the risk treatment plan?
The Statement of Applicability (SoA) is a separate mandatory document that lists all 93 Annex A controls and states whether each is applicable to your organisation and, if applicable, whether it is implemented. For controls selected through risk treatment, the SoA and risk treatment plan should align — a control in your risk treatment plan should be applicable in your SoA. The SoA may also include controls justified by legal, regulatory, or contractual requirements that are not specifically risk-driven.
Can we accept a risk that is rated high?
Yes, but the bar for authorisation is correspondingly higher. A high-rated risk accepted without a clear rationale, explicit acknowledgement of what that acceptance means, and sign-off at senior management level is a common audit finding. The standard does not prohibit acceptance of any risk level — it requires that acceptance decisions are made by risk owners with appropriate authority and that residual risks are formally accepted (Clause 6.1.3(e)).
