The risk treatment plan is one of the most scrutinised documents in a Stage 2 audit. It is also one of the most commonly confused. Many organisations conflate it with the risk register — or produce a risk register and assume they have covered both. They have not. The risk register identifies and scores your risks. The risk treatment plan is a separate document that records the decisions you have made about each of those risks and what actions will address them.
Clause 6.1.3 of ISO 27001 requires you to define and apply an information security risk treatment process. The output of that process is your risk treatment plan. Here is what it must contain and how to build it correctly.
The Four Risk Treatment Options
For every risk that exceeds your acceptance threshold, you must select one of four treatment options. Every entry in your treatment plan should clearly state which option applies and why.
Implement controls to lower likelihood or impact below the acceptance threshold. The most common treatment for high and medium risks. Requires specifying which Annex A controls you will implement.
Document management sign-off that the residual risk is within tolerance. Valid for low-scoring risks. Never leave an accepted risk undocumented — a verbal acceptance is not an acceptance.
Stop the activity that creates the risk. For example, stop processing a category of personal data that is not required for your product. Less common but entirely valid.
Shift financial consequence to a third party through cyber insurance or contractual indemnity. Transfer does not eliminate the risk — it manages the financial impact if the risk materialises.
What the Risk Treatment Plan Document Must Contain
The standard does not prescribe a specific format, but auditors expect to see the following fields for each treated risk:
| Field | What to document |
|---|---|
| Risk reference | Link back to the corresponding entry in your risk register (e.g., R-012) |
| Risk description | Brief summary of the risk scenario |
| Inherent risk score | The score before controls are applied |
| Treatment option | Mitigate / Accept / Avoid / Transfer |
| Controls selected | Annex A control references (e.g., A.8.2, A.5.15) or other measures |
| Residual risk score | The score after controls are implemented |
| Owner | Named individual responsible for implementing the treatment |
| Target date | When the control implementation is expected to complete |
| Status | Not started / In progress / Implemented |
How the Risk Treatment Plan Links to the SoA
The Statement of Applicability lists every Annex A control and states whether it is applicable to your ISMS, with a justification for each decision. The link between your risk treatment plan and your SoA is critical: every control you select in the treatment plan should appear as "applicable" in the SoA, with a justification that references the risks being treated. Conversely, if a control is marked applicable in the SoA but does not appear in any risk treatment decision, an auditor will ask why.
Document Flow
Each document feeds the next. Auditors trace this chain backwards from controls to risks.
Common Mistakes That Cause Audit Findings
Mistake 1: Residual risk scores are unchanged
If you apply controls but the residual risk score is the same as the inherent score, the logical implication is that your controls do nothing. Auditors will flag this.
Mistake 2: No owner assigned
A treatment plan with no named owner for each action is not actionable. It also signals that your ISMS lacks proper accountability structures.
Mistake 3: Treatment plan not approved by management
Clause 6.1.3 requires risk owners and top management to approve the risk treatment plan. An unsigned or undated document will not satisfy this requirement.
Mistake 4: Risks accepted without documented justification
Accepting a high risk without a written rationale and management sign-off is a major finding. Every acceptance decision must be explicit and documented.
A well-structured risk treatment plan is not a long document. For a typical 30–60 risk register, a single spreadsheet with the fields above — reviewed and approved by management — is entirely sufficient. The quality of the document is measured by its logical consistency with the risk register and the SoA, not its length.
If you want help building or reviewing your risk treatment plan, our ISO 27001 consulting service covers risk treatment as part of the full ISMS implementation.