Last Updated on September 30, 2025 by Melissa Lazaro

Introduction

When I work with organizations on ISO/IEC 27001, one of the biggest sticking points is moving from the risk assessment stage to the risk treatment plan. Teams are usually comfortable identifying risks, but they stumble when it comes to documenting what they’ll actually do about them.

This gap matters because ISO/IEC 27001:2022 requires a formal, documented risk treatment plan under Clause 6.1.3. Without it, your ISMS looks incomplete, and auditors will flag it.

Here’s the way I explain it to clients: the risk assessment tells you what could go wrong, while the risk treatment plan records how you’ll handle it. Both are critical, but they serve different purposes.

In this article, I’ll walk you through the ISO/IEC 27001 requirements for a risk treatment plan, show you the treatment options with real examples, and give you a ready-to-use template you can adapt to your business. By the end, you’ll know exactly what to include, how to structure it, and how to keep it auditor-ready without overcomplicating things.

What is a Risk Treatment Plan in ISO/IEC 27001?

A risk treatment plan is the bridge between theory and action in your ISMS. The risk assessment identifies what could go wrong; the treatment plan shows what you’re actually going to do about it.

Think of it this way: the risk assessment might highlight that phishing is a major threat. The treatment plan then documents whether you’ll reduce the risk (by adding awareness training and email filtering), transfer it (by using a managed service), avoid it (by changing business practices), or accept it if it’s within your tolerance.

Here’s where many organizations get it wrong. They stop at the risk register and assume “everyone knows” how risks will be handled. During an audit, that’s not enough. Auditors want to see a formal, documented plan with owners, actions, and deadlines.

Quick Comparison

Real Example: I once worked with a logistics company that had a solid risk register—over 30 identified risks. But when the auditor asked, “Show me how you’re treating them,” they had nothing beyond verbal discussions. The result was a nonconformity. Once we built a treatment plan with owners, timelines, and linked controls, the ISMS passed easily in the next audit.

ISO/IEC 27001:2022 Requirements for Risk Treatment (Clause 6.1.3)

ISO/IEC 27001:2022 doesn’t just say “treat your risks.” It gives clear steps under Clause 6.1.3. The purpose is to ensure your risk assessment results lead to documented, accountable actions that link directly to your Statement of Applicability (SoA).

Here’s a breakdown of what the clause requires and what it means in practice:

Key Point

The clause is designed to create a traceable chain:

Risk Assessment → Treatment Decision → Control Selection → SoA → Risk Treatment Plan (with owners & deadlines).

If any link in this chain is missing, the ISMS will look incomplete to an auditor.

The Four Risk Treatment Options Explained

Once risks are identified and assessed, ISO/IEC 27001:2022 requires you to decide what to do with them. The standard recognizes four treatment options. Each one has its place—but you must document which option you chose and why.

1. Reduce the Risk

This means applying controls to bring the risk down to an acceptable level. It’s the most common option.

• Example: Your assessment shows a high risk of phishing attacks. To reduce the risk, you implement email filtering, multi-factor authentication, and staff training.

• Why it works: You can’t eliminate phishing completely, but you can make it far less likely to succeed.

• Pitfall to avoid: Listing controls without linking them to specific risks.

2. Avoid the Risk

Here you change or stop an activity to remove the risk entirely.

• Example: A company planned to store sensitive customer data on personal laptops. The risk was too high. They avoided it by banning local storage and moving to a secure cloud platform.

• Why it works: If an activity creates unacceptable risk, sometimes the best option is not to do it at all.

• Pitfall to avoid: Claiming you’ve “avoided” a risk but not actually changing the risky activity.

3. Transfer the Risk

This means shifting the risk to a third party, usually through insurance or outsourcing.

• Example: An e-commerce company worried about fraud liability took out cyber insurance and outsourced payment processing to a PCI-DSS compliant provider.

• Why it works: You reduce your direct exposure by relying on specialized providers or insurers.

• Pitfall to avoid: Thinking transfer means the risk disappears—you still retain responsibility under ISO 27001.

4. Accept the Risk

Sometimes, after analysis, you decide a risk is tolerable within your risk appetite.

• Example: A small consultancy identified the risk of temporary internet outages. They accepted it because the business impact was minor and the cost of full redundancy was too high.

• Why it works: Not all risks justify the expense of controls. As long as the rationale is documented and approved, acceptance is valid.

• Pitfall to avoid: Accepting high risks without justification or approval from the right owner.

Quick Recap Table

Key Point: Each identified risk must have one of these four treatment decisions recorded. The choice must be logical, justified, and approved by the risk owner.

Risk-Treatment Plan Template (Sample Format)

The best way to keep your risk treatment activities structured and auditable is to use a tabular template. Auditors like tables because they make it easy to see each risk, its treatment, the control applied, and who’s responsible.

Here’s a sample format you can adapt to your own organization:

Worked Example

Why This Works

• Traceable: Each risk links to controls and actions.

• Accountable: Every line has a risk owner and responsible person.

• Auditable: Progress can be tracked and shown to auditors.

Pro Tip: Keep your treatment plan and Statement of Applicability (SoA) aligned. If a risk treatment calls for a control, it should appear in your SoA too.

Linking the Plan with the Statement of Applicability (SoA)

One of the most common audit findings I see is this: the risk treatment plan and the Statement of Applicability (SoA) don’t match. The plan says a risk will be treated, but the SoA doesn’t list the corresponding control—or vice versa. That inconsistency immediately raises red flags with auditors.

The standard is clear: every treatment decision must flow through to the SoA, which is the central reference for all Annex A controls.

How the Link Works

1. Risk identified in assessment →

2. Treatment option chosen (reduce, avoid, transfer, accept) →

3. Control(s) selected from Annex A or elsewhere →

4. SoA updated with inclusion/exclusion rationale →

5. Treatment plan records actions, owners, and deadlines

Example Mapping

Key Point

The SoA and the risk treatment plan should tell the same story from two angles:

• The SoA lists controls and explains why they’re included or excluded.

• The treatment plan shows the actions, owners, and timelines behind those controls.

If they don’t align, auditors will assume the ISMS isn’t being managed consistently.

Maintaining and Reviewing the Risk Treatment Plan

A risk treatment plan isn’t a “write once and forget” document. Risks evolve—new systems are added, regulations change, suppliers come and go. If your plan doesn’t keep up, it quickly becomes outdated, and auditors will notice.

The standard expects you to treat the plan as a living document that is reviewed, updated, and monitored.

When to Review the Plan

At minimum, the plan should be reviewed annually, but certain events trigger earlier updates.

Assigning Ownership

Every risk treatment must have a risk owner who is accountable for deciding on the treatment option, and a responsible person for implementing the action.

• Risk Owner: Typically department heads, process owners, or senior managers.

• Responsible Person: The individual or team carrying out the control (IT staff, compliance team, HR, etc.).

Pro Tip: Keep ownership clear. If you assign risks to “IT” or “Management,” accountability gets lost. Auditors prefer named roles or individuals.

Monitoring Progress

• Use a status column in your plan (e.g., Open, In Progress, Completed, Overdue).

• Link progress updates to management reviews—this demonstrates continual improvement.

• Many organizations start with Excel or SharePoint trackers. Larger ones move to GRC tools (like Archer, OneTrust, or ServiceNow) once complexity grows.

Real Example: A SaaS company I worked with integrated its risk treatment actions into Jira. Each risk treatment became a ticket with an owner and deadline. This not only satisfied auditors but also made security tasks part of the team’s daily workflow.

Key Takeaway: Reviewing and maintaining the risk treatment plan is as important as creating it. With clear ownership, regular updates, and visible tracking, you’ll have a plan that works for the business and passes audit scrutiny.

FAQs (Strengthen Trust & Address User Intent)

Q1. Do I need a treatment plan for every risk?

Yes. Every risk identified during assessment must have a documented treatment decision—even if the decision is to accept it. Auditors expect to see a complete record showing that no risks were ignored.

Q2. Is Excel enough for managing the risk treatment plan?

Absolutely. Many organizations, including those I’ve helped through certification, use Excel or Google Sheets. As long as the plan is clear, updated, and linked to the Statement of Applicability (SoA), it’s perfectly acceptable to auditors. Larger organizations may eventually move to GRC tools, but Excel works fine for most.

Q3. How detailed should the treatment plan be?

It should be detailed enough to show:

• The chosen treatment option (reduce, avoid, transfer, accept).

• The Annex A control(s) selected.

• Who is responsible for implementation.

• Deadlines and progress tracking.

Overcomplicating it with unnecessary technical detail often makes the plan harder to maintain without adding audit value.

Conclusion (Reaffirm Authority & Prompt Action)

The risk treatment plan is where ISO/IEC 27001 moves from identifying risks to actually managing them. It’s not just paperwork—it’s the roadmap that proves your ISMS is active, accountable, and improving.

To recap:

• Every risk needs a treatment decision, documented and approved.

• The plan must link directly to Annex A controls and your Statement of Applicability.

• Ownership, deadlines, and progress tracking are critical to keeping it alive.

• A simple, structured template (even in Excel) is often more effective than a complex GRC system that no one uses.

In my experience, the organizations that treat the risk treatment plan as a living document—reviewed regularly, tied to business changes, and monitored in management reviews—not only pass audits smoothly but also strengthen their security posture in practice.

Next Step: Start by taking your current risk register and documenting treatment options for each risk. From there, use a template to track actions, assign owners, and link everything back to the SoA. If you want to accelerate the process, you can adapt a ready-to-use ISO/IEC 27001 risk treatment plan template and customize it to your environment.