Is a risk treatment plan the same as a Statement of Applicability in ISO 27001?

No, they are two separate but closely connected documents. The Statement of Applicability lists all 93 Annex A controls and states whether each one is applicable to your organisation, along with justification for inclusions and exclusions. The risk treatment plan describes the specific actions you are taking to address each identified risk, including which controls you are applying, who is responsible, and by when. Both documents must be consistent with each other, and auditors will check that the controls referenced in your treatment plan match what is declared in your SoA.

How often should a risk treatment plan be reviewed and updated?

ISO 27001 requires you to review your risk assessment and treatment plan at planned intervals and whenever significant changes occur in your organisation or its environment. In practice, most organisations conduct a formal review annually as part of their management review cycle, with ad hoc updates triggered by events such as new system deployments, security incidents, changes to business processes, or significant staff changes. A treatment plan that is only reviewed at certification time and left untouched for three years will not hold up at surveillance or recertification audits.

What happens if a control in the risk treatment plan has not been implemented by the time of the Stage 2 audit?

It depends on the significance of the gap. If a critical control addressing a high-rated risk has not been implemented, your auditor is likely to raise a major non-conformity, which means certification will be withheld until the issue is resolved. For lower-priority controls with a credible implementation plan and a reasonable timeline, an auditor may raise a minor non-conformity or an observation. The key is to be transparent with your auditor and to demonstrate that you have a realistic plan in place rather than trying to present a treatment plan as complete when it is not.

Do we need a separate risk treatment plan for each business unit or location?

Not necessarily. If your ISMS scope covers multiple locations or business units, you can have a single risk treatment plan that addresses risks across the entire scope, provided the plan clearly identifies which risks and controls relate to which parts of the organisation. In practice, larger organisations sometimes use a master treatment plan with annexes or sub-plans for specific sites or divisions. What matters is that every risk within your ISMS scope has been assessed and treated, and that the documentation makes this traceable.

Can we use a template for our ISO 27001 risk treatment plan?

Templates can be a useful starting point for structure and formatting, but they should never be used as a substitute for genuine risk analysis. A template that lists generic risks and pre-filled controls from Annex A is not a risk treatment plan for your organisation. It is a document that looks like one. Auditors are experienced at spotting templated content that has not been tailored to the actual business, and it will raise questions about the credibility of your entire ISMS. Use templates to understand the format, then populate them with your own risk data, your own controls, and your own evidence.

What is the difference between inherent risk and residual risk in the context of ISO 27001?

Inherent risk is the level of risk that exists before any controls are applied. It reflects the raw exposure your organisation faces from a particular threat. Residual risk is what remains after your controls have been implemented. ISO 27001 requires you to assess both. The purpose of your risk treatment plan is to reduce inherent risks to a residual level that falls within your organisation's risk acceptance criteria. If the residual risk is still above that threshold after applying controls, you need to either apply additional controls, escalate the decision to management for formal acceptance, or reconsider whether the risk treatment option you have chosen is appropriate.

How to Write a Risk Treatment Plan for ISO 27001

What Is a Risk Treatment Plan and Why Does ISO 27001 Require One?

If you have been through the early stages of an ISO 27001 implementation, you already know that risk assessment is a major part of the work. But identifying risks is only half the job. The risk treatment plan is where you actually decide what to do about them. It is the document that turns your risk register from a list of concerns into a programme of action.

On this page

ISO 27001 requires organisations to produce a risk treatment plan as part of Clause 6.1.3. This clause asks you to select appropriate controls, document your decisions, and produce a Statement of Applicability. The risk treatment plan sits alongside that Statement of Applicability and shows your auditor exactly how you intend to address each risk you have identified. Without it, you cannot demonstrate that your information security management system is actually managing anything.

This guide walks you through exactly how to write a risk treatment plan that meets the standard, satisfies auditors, and genuinely improves your security posture. If you are not yet familiar with the broader risk assessment process, it is worth reading our ISO 27001 risk assessment guide for non-technical business owners before continuing.

Understanding the Four Risk Treatment Options

Before you can write a risk treatment plan, you need to understand the four options the standard gives you for dealing with each risk. Every risk in your register must be assigned one of these treatment options, and your reasoning needs to be documented.

Modify the Risk

This is the most common option. You apply controls from Annex A of ISO 27001 to reduce either the likelihood of a risk occurring or the impact if it does. For example, if you have identified a risk around unauthorised access to customer data, you might implement multi-factor authentication, access controls, and regular access reviews. These controls modify the risk by making it less likely to materialise or less damaging if it does.

Accept the Risk

Some risks are too small, too expensive to treat, or simply unavoidable. You can choose to accept them, provided you document that decision and get sign-off from the appropriate level of management. Risk acceptance is legitimate, but it needs to be a conscious, documented choice rather than something that just falls through the cracks.

Avoid the Risk

This means stopping the activity that creates the risk altogether. If a particular business process creates an unacceptable information security risk and the process is not essential to your operations, you can simply stop doing it. This is less common but entirely valid.

Share the Risk

Risk sharing typically means transferring some or all of the financial consequence of a risk to a third party, usually through insurance or contractual arrangements. Cyber liability insurance is a common example. Risk sharing does not eliminate the risk, but it reduces your exposure to its consequences.

Get 3 ISO Quotes. 24 Hours Response

Tell us what you need and compare vetted ISO consultants or certification bodies within 24 hours. Free, no obligation.

Trusted by 400+ businesses like yours

What Your Risk Treatment Plan Actually Needs to Contain

A lot of businesses produce risk treatment plans that look impressive but fall apart under audit scrutiny. The reason is usually that they describe what they plan to do without specifying who is responsible, when it will be done, or how they will know it has worked. Here is what a solid risk treatment plan must include for each risk being treated.

Risk Reference and Description

Link each treatment action back to a specific risk in your risk register. Use consistent reference numbers so your auditor can trace the connection between the risk assessment, the risk treatment plan, and the Statement of Applicability without having to ask you to explain it. A risk described as “unauthorised access to the CRM system” in your register should appear with the same description and reference number in your treatment plan.

Selected Treatment Option

State clearly which of the four treatment options you have chosen for this risk. If you are modifying the risk, list the specific Annex A controls you are applying. If you are accepting it, say so explicitly and note who has approved that decision.

Control Reference

ISO 27001 Annex A contains 93 controls across four themes: organisational, people, physical, and technological. When you select a control to treat a risk, reference it by its Annex A number. For example, A.8.2 refers to privileged access rights. This linkage is critical because it connects your risk treatment plan to your Statement of Applicability, which lists all 93 controls and whether each one is applicable to your organisation.

Responsible Owner

Every action in your risk treatment plan needs a named owner. Not a department, not a role in the abstract, but a specific person who is accountable for implementing and maintaining that control. This is one of the most common gaps auditors find. When you write “IT team” as the owner, nobody is actually accountable.

Implementation Deadline

Set realistic target dates for each control. If you are in the process of building your ISMS for initial certification, your auditor will want to see that controls are either already implemented or have a credible timeline for implementation before the Stage 2 audit. Dates that have already passed with no evidence of completion are a red flag.

Current Status

Include a status field that shows whether each control is planned, in progress, implemented, or under review. This turns your risk treatment plan into a live working document rather than a static record. Update it regularly and make sure the version you present to your auditor reflects the actual state of play.

Evidence of Implementation

For controls that are already implemented, reference the evidence. This might be a policy document, a system configuration record, a training completion log, or a procedure. Your auditor will ask to see this evidence, so knowing where it lives before the audit saves a lot of stress.

Residual Risk Rating

After applying your controls, reassess the risk. The residual risk is what remains after treatment. If your residual risk is still above your organisation's risk acceptance threshold, you need to apply additional controls or escalate the decision to senior management. Document this reassessment clearly.

Step-by-Step Process for Writing the Plan

Here is a practical sequence for building your risk treatment plan from scratch. This assumes you have already completed your risk assessment and have a populated risk register.

Step 1: Pull Your Risk Register Into a Working Format

Start with your completed risk register. Each row should contain a risk description, the assets and threats involved, the likelihood and impact scores, and the overall risk rating. If you have not yet completed this step, you need to do so before you can write a treatment plan. The ISO 27001 standard itself makes clear that risk treatment follows from risk assessment, not the other way around.

Step 2: Sort Risks by Priority

Work through your highest-rated risks first. These are the ones your auditor will focus on, and they are the ones most likely to cause real damage if left unaddressed. For each high risk, you need a clear treatment decision. Do not spend the same amount of time on a low-rated risk as you do on a critical one.

Step 3: Map Each Risk to an Annex A Control

For risks you are treating by modification, go through the relevant Annex A controls and identify which ones apply. It is common for a single risk to be addressed by more than one control. For example, a risk around phishing attacks might be treated by A.6.3 (information security awareness, education and training), A.8.23 (web filtering), and A.5.14 (information transfer). Document all of them.

Step 4: Assign Owners and Deadlines

Go through every treatment action and assign a real person as the owner. Have a conversation with that person before finalising the plan. If they do not know they are responsible for implementing a control, the plan is fiction. Set deadlines that are achievable given your resources and timeline to certification.

Step 5: Update Your Statement of Applicability

Your Statement of Applicability must reflect the controls you have selected in your risk treatment plan. For every control you have included, mark it as applicable in the SoA and reference the risk that drove the decision. For controls you have excluded, document your justification. The SoA and the risk treatment plan must be consistent with each other. Auditors check this connection carefully.

Step 6: Get Management Sign-Off

The risk treatment plan is not a document that the IT manager produces and files away. ISO 27001 requires top management to be involved in information security governance. Get formal sign-off from a director or senior executive. This sign-off should be documented, either as a signature on the document itself or as a recorded management review decision. If you want to understand what auditors look for in management involvement, our article on ISO 27001 for beginners covers the governance requirements in plain language.

Step 7: Review and Maintain the Plan

Your risk treatment plan is a living document. Every time you conduct a risk assessment review, update the plan to reflect new risks, completed treatments, and changes to your residual risk ratings. ISO 27001 requires you to review your risk assessment and treatment plan at planned intervals and whenever significant changes occur. A plan that was written for your initial certification and never touched again will not survive a surveillance audit.

Common Mistakes That Will Get You a Non-Conformity

After auditing dozens of ISMS implementations, certain patterns come up again and again. Here are the mistakes that most commonly lead to non-conformities during ISO 27001 audits.

Generic Controls Not Linked to Specific Risks

Writing “implement access controls” as a treatment action without linking it to a specific risk and a specific Annex A control is not enough. Your auditor needs to see the thread from risk to treatment to control to evidence. Generic statements without that traceability will be flagged.

Risk Acceptance Without Documented Approval

Accepting a risk is fine. Accepting a risk without anyone senior signing off on that decision is a non-conformity waiting to happen. Every accepted risk needs a documented approval, ideally from someone with the authority to make that call on behalf of the organisation.

Residual Risk Not Assessed

A lot of organisations document their initial risk ratings but forget to reassess after applying controls. If your plan shows a high risk with a treatment action but no residual risk rating, your auditor cannot tell whether the treatment was effective. Always document the residual risk.

Owners Who Do Not Know They Are Owners

This is more common than it should be. A consultant or internal project manager writes the plan, assigns names to control ownership, and nobody tells those people. When the auditor asks the named owner about their control, they have no idea what is being discussed. Always confirm ownership with the individuals concerned.

The Plan Is Not Connected to the SoA

Your risk treatment plan and Statement of Applicability must be consistent. If a control appears in your treatment plan but is marked as not applicable in the SoA, or vice versa, that is a problem. Cross-check these two documents before your audit. This is one of the first things an experienced auditor will look at.

A Practical Example: Risk Treatment for a Small Software Company

Consider a small Australian software company with fifteen employees seeking ISO 27001 certification. During their risk assessment, they identify the following risk: a disgruntled or departing employee could exfiltrate customer data via personal email or USB storage.

The risk is rated high due to the sensitivity of the customer data involved and the realistic likelihood of the scenario. Their treatment plan entry might look like this:

Risk reference: R-014
Risk description: Insider threat, data exfiltration by current or departing employee
Treatment option: Modify
Controls applied: A.5.18 (access rights), A.8.12 (data leakage prevention), A.6.5 (responsibilities after termination or change of employment)
Owner: Head of Engineering (named individual)
Deadline: 30 days prior to Stage 2 audit
Status: In progress
Evidence: Access revocation procedure, DLP configuration record, offboarding checklist
Residual risk: Medium, within accepted threshold
Management approval: Signed off by CEO at management review dated [date]

This level of detail gives the auditor everything they need to verify the treatment decision. It is traceable, specific, and honest about the residual risk that remains.

How Long Does It Take to Write a Risk Treatment Plan?

For a small to medium business going through ISO 27001 for the first time, writing a thorough risk treatment plan typically takes two to four weeks of focused effort. This includes the time needed to map risks to controls, assign owners, gather evidence references, and get management sign-off. If your risk assessment is already complete and well-documented, the treatment plan builds on that work and the timeline is shorter.

Organisations with complex IT environments, multiple business units, or large numbers of high-rated risks will need more time. It is not unusual for the risk treatment planning phase to be the longest single piece of work in an ISO 27001 implementation. If you are working with a consultant, make sure they are helping you build a plan that reflects your actual environment rather than copying a template that was written for a different business. Our guide on how to compare ISO 27001 consultants can help you evaluate whether the support you are getting is genuinely tailored to your situation.

If you are approaching your Stage 2 audit, it is also worth reviewing our checklist on 10 things to do before an ISO Stage 2 certification audit to make sure your risk treatment plan is in order alongside your other documentation.

Getting Help With Your ISO 27001 Risk Treatment Plan

Writing a risk treatment plan that genuinely satisfies ISO 27001 requirements is not a simple task. It requires a clear understanding of the standard, a realistic assessment of your information security risks, and the discipline to maintain the document over time. Many businesses find that working with an experienced ISO 27001 consultant significantly reduces the time and rework involved, particularly for the risk assessment and treatment phases.

If you are looking for qualified ISO 27001 consultants or accredited certification bodies in Australia or globally, CertBetter makes it straightforward. Submit one form and receive up to three competing quotes from vetted providers, completely free of charge. The platform was built by someone who has spent years on the audit side of ISO 27001, so the matching process is designed to connect you with providers who have real experience with information security management systems, not just generalist consultants who have ticked a box.