Patroklos PatroklouLast updated: 15 October 2026
Quick answer: An ISO 27001 risk treatment plan is the documented record of how you will handle each unacceptable information security risk: the treatment option chosen, the controls to implement, the owner, resources, deadline and how completion is checked. Clause 6.1.3 requires you to produce it, and risk owners must approve it and accept residual risk.
Most ISO 27001 projects spend weeks on the risk assessment and then rush the part auditors actually test: what you decided to do about each risk and whether you did it. The ISO 27001 risk treatment plan is where the risk register turns into work with names, dates and budgets attached.
This guide explains what the standard requires, what a good plan contains, how it connects to the Statement of Applicability, and how to keep it alive after certification.
What is an ISO 27001 risk treatment plan?
It is the action plan that sits between your risk assessment and your controls. For every risk that falls outside your acceptance criteria, it records the treatment decision, the controls you will add or strengthen, who is responsible, when it will be done and what residual risk you expect afterwards.
The requirement comes from clause 6.1.3 of ISO/IEC 27001:2022, the third edition of the standard, published in October 2022 and amended in 2024 to add climate action wording. Clause 6.1.3 sets out six steps. The organisation must:
- select appropriate risk treatment options, taking account of the risk assessment results;
- determine all controls needed to implement the chosen options;
- compare those controls with Annex A to check that no necessary control has been omitted;
- produce a Statement of Applicability (SoA);
- formulate an information security risk treatment plan;
- obtain risk owners’ approval of the plan and their acceptance of the residual risks.
Clause 8.3 then requires you to implement the plan and retain documented information of the results. In audit terms, 6.1.3 is the plan and 8.3 is the proof that you carried it out.
In practice: Auditors rarely ask whether a plan exists. They pick three or four high risks from the register and trace them: treatment decision, control, owner, due date, evidence of implementation and signed acceptance of what is left.
What are the four risk treatment options?
ISO 27001 does not list the options itself, but its guidance standard, ISO/IEC 27005:2022, describes four (our ISO 27005 risk assessment guide covers the method in depth): modify, retain, avoid and share. You can combine them for a single risk.
| Option | What it means | Typical example | Watch out for |
|---|---|---|---|
| Modify (reduce) | Add or improve controls to lower likelihood or impact | Enforce phishing-resistant MFA on remote access | Controls that exist on paper but have no evidence |
| Retain (accept) | Consciously accept the risk as it is | Accept the risk of a legacy kiosk PC with no sensitive data | Acceptance above criteria without the right owner signing |
| Avoid | Stop the activity that creates the risk | Retire an unsupported file transfer server | Business teams quietly restarting the activity |
| Share (transfer) | Move part of the risk to a third party | Cyber insurance, or a managed SOC under contract | Assuming accountability transfers; it does not |
Common mistake: Treating “share” as a way to make a risk disappear. Outsourcing or insurance changes who carries part of the impact, but your organisation still owns the risk and must assess the supplier. Our article on why vendor risk is now executive liability covers this in more depth.
What should a risk treatment plan include?
A usable plan answers who, what, when, how much and how you will know. ISO 27001 does not prescribe a format; a spreadsheet or GRC tool both work if controlled and current.
Risk treatment plan template: the fields that matter
| Field | What to record |
|---|---|
| Risk ID and description | Link back to the risk register entry, not a copy that drifts |
| Current risk level | Likelihood and impact scores from the assessment |
| Treatment option | Modify, retain, avoid, share, or a combination |
| Controls | New or improved controls, with Annex A or other control references |
| Actions | Concrete tasks, not “improve access control” |
| Action owner | The person doing the work |
| Risk owner | The person accountable for the risk, who approves the plan |
| Resources | Budget, people, tools or supplier effort needed |
| Target date | Realistic deadline, with milestones for long actions |
| Target residual risk | Expected score once the actions are complete |
| Verification method | How you will confirm effectiveness: test, audit, metric |
| Status and evidence | Progress and a link to the evidence that proves completion |
| Approval and acceptance | Risk owner sign-off on the plan and on residual risk, with date |
The “risk owner” and “action owner” distinction matters. Clause 6.1.2 requires you to identify risk owners, and those are the people who approve treatment and accept residual risk. The engineer patching servers is rarely the right person to accept a residual risk to customer data.
How does the risk treatment plan relate to the Statement of Applicability?
They come out of the same analysis but answer different questions (see our Statement of Applicability guide for the SoA side). The SoA says which controls apply to your ISMS, why, and whether they are implemented. The risk treatment plan says what you will do, by when, to deal with specific risks.
- Direction of travel: risks drive controls. You determine the controls you need first, then compare them with Annex A’s 93 controls as a completeness check, not a shopping list.
- Consistency: if the plan says a control will be implemented in Q3, the SoA should not show it as fully implemented today.
- Beyond Annex A: the standard notes that Annex A is not exhaustive. Controls from other frameworks, such as the NIST CSF or your own designs, are valid.
If you run several frameworks, the controls in your plan often satisfy more than one. Enactia’s Compliance Universe cross-maps controls across ISO 27001, NIS2, DORA, SOC 2 and 50+ other frameworks, so one treatment action can be tracked against every requirement it supports.
How do you build an ISO 27001 risk treatment plan step by step?
Start from an approved risk assessment and work on the risks outside your acceptance criteria, following the order of clause 6.1.3.
- Filter the register. Pull every risk above your acceptance threshold. Risks within the threshold can be retained, but record that decision.
- Choose an option per risk. Weigh cost, feasibility and business impact. Involve the risk owner now, not at sign-off.
- Determine controls. List the specific controls needed. Reference Annex A, your policies and any other frameworks you use.
- Check against Annex A. Run through Annex A to confirm no necessary control has been missed.
- Update the SoA. Reflect inclusions, exclusions, justifications and implementation status.
- Write actions with owners and dates. Break each control into tasks someone can finish.
- Estimate residual risk. Score each risk as it will be once treatment is complete.
- Get approval. Risk owners sign off the plan and accept residual risk. Keep the record.
- Implement and evidence. Under clause 8.3, track delivery and store evidence against each action.
- Review. Report the plan’s status to management review and re-assess risks when things change.
For the method behind the scores, the UK NCSC risk management guidance and NIST SP 800-30 Rev. 1 are both useful, free references.
If you would rather manage the register, plan, SoA and evidence in one place, you can start your 14-day free trial of Enactia’s risk management module and import your existing register.
Worked example: one risk from register to closure
Here is how a single entry might look. The scores use a simple 1-5 likelihood by 1-5 impact scale, with an acceptance threshold of 8.
| Field | Entry |
|---|---|
| Risk | R-014: Compromise of administrator accounts on the cloud tenant through credential phishing |
| Current level | Likelihood 4, impact 5, score 20 (high) |
| Option | Modify, plus share (cyber insurance covering incident response costs) |
| Controls | Annex A 5.17 authentication information, 8.2 privileged access rights, 8.5 secure authentication, 6.3 awareness training |
| Actions | Enforce phishing-resistant MFA for all admins; separate admin accounts from daily accounts; quarterly privileged access review; targeted phishing training for admins |
| Owners | Risk owner: Head of IT. Action owner: Cloud platform lead |
| Target date | MFA and account split by 30 June; first access review by 30 September |
| Target residual | Likelihood 2, impact 4, score 8 (within threshold) |
| Verification | Conditional access report showing 100% admin MFA coverage; access review sign-off |
| Approval | Plan and residual risk accepted by Head of IT, signed and dated |
In practice: Notice the verification line. “MFA enabled” is a claim. A dated report showing coverage is evidence. Define the verification method when you write the action.
Who approves the plan and accepts residual risk?
The risk owners do. Clause 6.1.3 f) requires their approval of the plan and acceptance of the residual risks, so the sign-off must come from the people accountable for each risk, not only the CISO.
A few governance habits make this defensible:
- Set acceptance authority levels in your risk methodology, for example medium risks accepted by department heads, high risks only by an executive.
- Record acceptance per risk, with date and name, rather than one blanket signature on a spreadsheet.
- Time-limit acceptance so retained risks are re-approved at each review.
- Report open treatment actions and overdue items to top management as part of clause 9.3 management review.
Writing these rules into your risk methodology and ISMS policies, and keeping them under version control, is easier with a dedicated policy management workflow.
What are the most common risk treatment plan mistakes?
- Generic actions. “Improve security awareness” cannot be completed or verified. Name the course, audience and date.
- No residual risk. Without a target score, nobody can say whether treatment worked.
- Wrong approver. The CISO signs everything, including risks owned by finance or HR.
- Frozen plan. Written for Stage 1 and never updated.
- SoA mismatch. Controls marked as implemented in the SoA are still open actions in the plan.
A periodic internal check against these points, for example through a structured compliance assessment, catches most of them before a certification body does.
Key takeaways
- Clause 6.1.3 of ISO 27001:2022 requires a risk treatment plan; clause 8.3 requires you to implement it and keep evidence of the results.
- Each unacceptable risk needs an option, controls, action owner, risk owner, deadline, target residual risk and verification method.
- Risks drive controls. Annex A is a completeness check, and the SoA must stay consistent with the plan.
- Risk owners, not only the CISO, approve the plan and accept residual risk.
- Keep the plan live: update it with the register and report it to management review.
Frequently asked questions
Is a risk treatment plan mandatory for ISO 27001 certification?
Yes. Clause 6.1.3 e) requires you to formulate an information security risk treatment plan, and clause 8.3 requires you to implement it and retain documented information of the results. A certification body will expect to see the plan, evidence of progress and risk owner approval during both Stage 1 and Stage 2 audits.
What is the difference between a risk register and a risk treatment plan?
The risk register lists identified risks with their analysis and scores. The risk treatment plan covers what you will do about the risks that exceed your acceptance criteria: chosen option, controls, owners, deadlines and expected residual risk. Many organisations keep both in one tool, linked by risk ID, so they never drift apart.
Does the plan have to use Annex A controls?
No. You determine the controls your risks require first, from any source, then compare them with Annex A to make sure nothing necessary is missing. The standard states Annex A is not exhaustive, so controls from NIST, CIS or your own design are acceptable, provided the SoA records them properly.
How often should the risk treatment plan be updated?
Update it whenever risks are re-assessed, which ISO 27001 requires at planned intervals and when significant changes occur. In practice, most organisations review progress monthly or quarterly, re-assess risks at least annually, and present the plan’s status at each management review so overdue actions are escalated.
Can a risk be accepted without any treatment?
Yes, retaining a risk is a valid option, even above your usual threshold, if the right risk owner makes an informed decision and records it. Document the reason, the approver and a review date. Auditors will challenge high risks accepted by someone without the authority your methodology requires.
Conclusion: make the plan the backbone of your ISMS
A strong ISO 27001 risk treatment plan is short on adjectives and long on owners, dates and evidence. Build it from the register, keep it consistent with the SoA, get the right people to sign, and review it as often as your risks change.
Want to run your ISO 27001 risk register, treatment plan, SoA and evidence in one platform? Enactia’s AI-powered GRC platform is built for exactly that, and our ISO 27001 page shows how. Contact us or book a demo or start your 14-day free trial.
