Creating a Risk Treatment Plan for ISO 27001 can look scary on paper.

In reality, it’s just a structured way of saying:

“We understand this risk, here’s what we’re going to do about it, who’s doing it, and when.”

In this guide, I’ll walk you through how to build a Risk Treatment Plan (RTP) step by step, using the same approach and templates I use in my ISO 27001 toolkit:

• RT 1 – Security Risk Assessment & Treatment Methodology (how we score and prioritise risks)
• RT 3 – Risk Treatment Plan template (the detailed plan for higher-risk items)

If you follow this process, you’ll end up with something that not only ticks the ISO 27001 boxes, but also actually helps your organisation manage risk in real life.

---

ISO 27001 Risk Management Overview

Risk management sits at the heart of ISO 27001. The standard isn’t prescriptive about which risks you face or what controls you must implement — instead it requires you to identify your own risks, assess them against your organisation’s context, and make conscious, documented decisions about how to treat them. That risk-based approach is what makes ISO 27001 scalable from a five-person startup to a 500-person enterprise.

The ISO 27001 risk management process runs across two key clauses. Clause 6 (Planning) is where you establish your risk assessment methodology, identify and evaluate risks, and decide how to treat them. Clause 8 (Operation) requires you to actually carry out those risk assessments at planned intervals and when significant changes occur — risk management under ISO 27001 is an ongoing activity, not a one-off exercise at implementation.

In practice, the process has four stages: identify risks to the confidentiality, integrity and availability of your information assets; assess each risk by scoring likelihood and impact against agreed criteria; treat each risk by choosing to mitigate, transfer, accept or avoid it; and monitor risks continuously, reviewing and updating your risk log as your organisation changes. Each stage produces documented evidence that auditors will expect to see.

How the Risk Treatment Plan Fits In

The risk treatment plan is the output of your risk assessment — the document that records what you’ve decided to do about each significant risk, which Annex A controls you’ve selected to treat it, who owns the treatment, and when it will be completed. The rest of this guide walks through how to build one.

What a Risk Treatment Plan Actually Is

In plain English:

• Your risk assessment answers:
  “What could go wrong, and how bad would it be?”
• Your Risk Treatment Plan answers:
  “So what are we going to do about it?”

An RTP is a document for a specific risk (or sometimes a cluster of closely related risks) that sets out:

• How you’ve decided to treat it (avoid, mitigate, transfer, or accept)
• What you’re going to do (actions)
• Who is responsible
• When it should be done
• How you’ll know if it has worked

Under ISO 27001, this all sits under Clause 6.1.3 – information security risk treatment, and links directly into your Annex A controls and your Statement of Applicability.

---

How This Fits With Your Risk Log and Methodology

In my toolkit, there are three key moving parts:

1. The Risk Log
   This is your single source of truth for information security risks: each risk, its likelihood, impact, overall score, and the high-level treatment decision.
2. RT 1 – Risk Assessment & Treatment Methodology
   This explains how you:
   • Identify risks (audits, incidents, context review, threat intel, staff feedback, etc.)
   • Score likelihood and impact on a 1–5 scale
   • Multiply them to get an overall risk score (1–25)
   • Decide what’s acceptable and what needs more work
3. RT 3 – Risk Treatment Plan Template
   This is the document you spin up for the higher-risk items where you need a clearer, more detailed plan.

I find it really helps to keep this simple rule in mind:

The Risk Log is for every risk.
The detailed Risk Treatment Plan is only for the big ones.

In my methodology, any risk with a combined score above 10 (using the 1–5 likelihood and 1–5 impact scales) deserves a full Risk Treatment Plan, while lower-scoring risks can be treated directly in the Risk Log with simpler notes.

---

How to Create a Risk Treatment Plan for ISO 27001

1. Start With a Sensible Risk Assessment

You can’t treat risks you haven’t identified, so everything starts from the risk assessment.

In RT 1, I outline a bunch of practical ways risks get identified, such as:

• Changes to your organisational context (new services, markets, regulations)
• Monitoring emerging threats (e.g. vendor alerts, NCSC updates, industry news)
• Security audits, penetration tests, and vulnerability scans
• Incident reports and helpdesk tickets
• SWOT analysis and management workshops
• Staff and stakeholder feedback
• Risk assessments of critical systems and services

Once a risk is identified, you:

1. Log it in the Risk Log
   • Give it a clear name
   • Describe it in simple terms
   • Assign an initial risk owner
2. Score it for Likelihood (1–5)
   • 1 = Remote
   • 5 = Highly probable
3. Score it for Impact (1–5)
   • 1 = Insignificant
   • 5 = Catastrophic
4. Calculate the Risk Score
   • Likelihood × Impact = overall score (1–25)
5. Categorise it (based on your acceptance criteria)
   • Low (1–4) – okay to accept and just monitor
   • Medium (5–10) – may be accepted with management approval
   • High (11–15) – must be treated, not just left
   • Critical (16–25) – urgent; requires immediate, serious action

I recommend getting your scoring method and acceptance criteria agreed by top management early on. It makes later conversations about “Can we accept this?” much easier.

---

2. Decide Which Risks Need a Full Risk Treatment Plan

Once you’ve scored your risks, you can decide which ones get a standalone RTP.

Using my methodology:

• Score 1–9:
  Treat directly in the Risk Log. Add a sensible treatment option and some clear actions and owners, but no need for a separate document.
• Score >10 (11–25):
  Create a dedicated Risk Treatment Plan (RT 3). These are the risks that are serious enough to deserve a bit of structure and visibility.

I find this “threshold approach” keeps the paperwork under control. You’re not creating big plans for every minor nuisance, but you are properly managing the things that could genuinely hurt the organisation.

---

3. Filling In the Risk Treatment Plan (RT 3)

Let’s walk through the RT 3 template from top to bottom.

3.1 Key Details

At the top of the RTP, you capture the basics:

• Name of the risk
• Classification (e.g. internal or confidential)
• Owner (usually the person accountable for the process or system at risk)
• Date identified
• Risk assessment score (before treatment)
• Score after treatment (what you expect once the plan is done)
• Risk treatment option (avoid, mitigate, transfer, accept)
• Reporting frequency (e.g. monthly, quarterly)
• Last update

I recommend filling this in straight from the Risk Log so you don’t end up with competing versions of the truth.

3.2 Summary of the Risk

Next, there’s a short summary section.

Keep it clean and non-technical. For example:

“Ransomware attack on the hosted customer platform could lead to loss of availability, data corruption, and breach of customer data, affecting contractual obligations and reputation.”

The idea is that anyone on the management team could read this and understand the problem in 20 seconds.

3.3 Description of Treatment & Rationale

This is where you explain your thinking:

• Which treatment option have you chosen?
  • Avoid, mitigate, transfer, accept
• Why that option?
  • Cost vs benefit
  • Practicality
  • Alignment with your risk appetite

For example:

“We will mitigate this risk by strengthening backup, hardening access, and improving monitoring, rather than attempting to avoid the risk entirely (which would mean withdrawing from the hosted service model).”

I find this section really helpful when auditors or senior managers ask: “Why did you choose to do it that way?” You’ve already written the answer.

---

4. Build a Practical Action Plan

The next part of the template is the Action Plan table.

The columns in RT 3 are:

• Action
• Responsible party
• Start date
• End date
• Status
• Comments / Notes

This is where your plan becomes real. Each action should be:

• Specific – someone could read it and know what to do
• Owned – tied to a named person or role
• Timed – with realistic start and end dates

For example, for a ransomware risk you might have:

Action	Responsible	Start	End	Status	Comments
Implement immutable offsite backups for customer platform	Head of Infrastructure	01/09	30/09	In progress	Using XYZ backup solution
Enforce MFA for admin access to platform	IT Security Lead	01/09	15/09	Complete	Verified in access review
Run phishing and ransomware awareness training for staff	HR / IT	15/09	30/10	Planned	Using existing training content

I recommend resisting the urge to create a huge list of micro-actions. Aim for a small number of meaningful actions that actually reduce the risk.

4.1 Resources Required

At the bottom of the template, there’s a Resources required section.

Use this to call out:

• Budget (licences, consultancy, new tools)
• Time (project work, internal resource)
• External support (penetration testers, MSPs, etc.)

This section is useful when you’re talking to management about funding and prioritisation; it makes the cost of risk reduction very visible.

---

5. Linking Your Plan to ISO 27001 Controls

ISO 27001 expects you to select controls based on your risk treatment and justify them in the Statement of Applicability (SoA).

I recommend doing this:

• In the Risk Log:
  Add a column for “Relevant Annex A controls” and list the key controls you’re using to treat the risk (e.g. A.5.x, A.8.x etc.).
• In the SoA:
  Make sure those same controls are marked as “Included”, with the rationale linked back to your risk treatment.

This creates a nice clear chain:

Risk → Risk Treatment Plan → Controls → Statement of Applicability

Auditors love this, and it also helps internally when people ask, “Why do we have to do this control?”

---

6. Monitoring, Reviewing, and Keeping It Alive

An RTP is not a one-off document you write for the audit and forget about. It should be a living part of how you manage security.

I recommend:

• Regular reviews – e.g. monthly for critical risks, quarterly for others
• Status updates – check progress on actions, refresh the “Score after treatment” if needed
• Incident feedback – if something goes wrong, revisit the relevant RTP and update it
• Escalation – for anything in the “major/critical” categories, escalate to your corporate risk register or board-level risk discussions as defined in your methodology.

And don’t forget to keep the RTP attached or linked back to the relevant entry in the Risk Log so everything stays joined up.

---

FAQs

What’s the main purpose of a Risk Treatment Plan?

To turn your list of scary risks into a structured, owned, and prioritised set of actions. It shows how each significant risk will be handled, who’s responsible, and when it will be dealt with.

How is it different from the Risk Assessment?

• Risk Assessment: “What are our risks and how serious are they?”
• Risk Treatment Plan: “What exactly are we going to do about this one?”

The assessment feeds the plan.

Do we have to treat every risk?

No. Under ISO 27001, you can accept risks if:

• They sit within your risk appetite
• The cost or effort of treatment outweighs the benefit

But risk acceptance should be conscious and documented – not just “we didn’t get round to it”.

How often should we update the RTP?

I recommend reviewing RTPs at least annually, and also when:

• You have a significant change (new system, new client, merger, etc.)
• A relevant incident or near-miss occurs
• A major project completes or a control changes

Do we need special software?

No. If you’re a small or medium organisation, a well-designed spreadsheet risk log plus Word-based RTP template (like RT 1 and RT 3 in my toolkit) is absolutely fine. The important thing is that it’s:

• Consistent
• Easy to maintain
• Easy to understand

---

Conclusion

A good Risk Treatment Plan is not about writing the most impressive document for an auditor. It’s about making sure:

• You understand your biggest risks
• You’ve agreed what you’re doing about them
• The right people are actually doing the work
• You can show that to anyone who asks – auditor, customer, or board member

If you’re using my ISO 27001 toolkit, you already have the risk methodology (RT 1) and the Risk Treatment Plan template (RT 3) set up to work together. Drop your risks into the Risk Log, pick out the ones above your threshold, and build targeted, practical plans for those.

That’s all an ISO 27001 Risk Treatment Plan really is:
a clear, realistic plan to stop the important things from going wrong.