ISO/IEC 27001 requires a risk treatment plan and says almost nothing about what it should contain. That gap is filled in practice by templates, and the templates vary widely. Some are a copy of the risk register with a "treatment" column. Others are a project plan with no link to any risk.
Neither works well under audit. The auditor wants to see that each risk you decided to treat has a specific, owned, dated plan, that the people who own the risks approved it, and that the plan is being carried out. Those are the things the plan has to show, whatever format you choose.
This article covers what the standard requires of the plan, how it relates to the risk register and the Statement of Applicability, the fields each entry needs, how approval and residual risk acceptance work, and how to keep the plan current.
What the standard requires
The requirements are short and spread across two clauses of ISO/IEC 27001:2022.
Clause 6.1.3 e) requires you to formulate an information security risk treatment plan.
Clause 6.1.3 f) requires you to obtain the risk owners' approval of the plan, and their acceptance of the residual information security risks.
Clause 6.1.3 also requires you to retain documented information about the risk treatment process.
Clause 8.3 requires you to implement the risk treatment plan, and to retain documented information of the results of risk treatment.
The standard does not prescribe fields, format, or tooling. ISO/IEC 27005 gives guidance on what a treatment plan can include, and it is worth reading, but it is guidance. You are audited on whether your plan does what clauses 6.1.3 and 8.3 require.
The clause 6 article covers the full risk assessment and treatment process. This one is about the plan document itself.
How the plan relates to the register and the SoA
Three documents come out of risk assessment and treatment. Each answers a different question.
| Document | Question it answers | Organized by |
|---|---|---|
| Risk register | What are our risks, who owns them, and how serious are they? | Risk |
| Statement of Applicability | Which controls are necessary, why, and are they implemented? | Control |
| Risk treatment plan | What are we doing about each risk we decided to treat, by when, and who is accountable? | Treatment action |
The three should agree with each other. A risk marked "treat" in the register needs an entry in the plan. A control marked "not yet implemented" in the Statement of Applicability should appear as an action in the plan. A plan action should trace back to at least one risk.
Some organizations keep the plan as additional columns in the register. That is acceptable if the result carries everything the plan needs. A separate document or tracker is often easier to manage once actions span several risks, or several actions treat one risk.
What each entry needs
The standard leaves the content to you, but an auditor will need to see enough to judge that the plan is real and being followed. A workable entry contains:
The risk or risks treated, by reference to the register.
The treatment option chosen. Modify the risk with controls, share it, avoid it, or retain it. The article on treatment options covers how to choose between them.
The actions. The specific controls or changes, described concretely enough that someone could check whether they were done.
The owner of each action. The person accountable for getting it done, who may differ from the risk owner.
Resources. What the action needs: budget, people, a tool, a vendor.
Target date. When the action is due.
Expected residual risk. The rating you expect once the action is complete, using the same scales as the register.
Status. Not started, in progress, complete, or overdue, with the date of the last update.
Approval. The risk owner's approval of the plan for that risk.
Fields 3, 4, 6, and 9 are the ones auditors most often find missing. An action written as "improve logging" with no owner and no date cannot be shown to be implemented, and clause 8.3 requires implementation.
A hypothetical entry:
R-14, unauthorized access to production through stale accounts. Option: modify. Actions: connect production access to the identity provider so leavers lose access when deprovisioned; add quarterly access review of production roles. Action owner: platform lead. Target: end of Q3. Expected residual: low. Risk owner approval: head of engineering, recorded.
Approval and residual risk acceptance
Clause 6.1.3 f) asks for two separate things from risk owners. Keep them distinct in your records.
Approval of the plan means the risk owner agrees the planned treatment is appropriate for their risk. It is a decision about the approach.
Acceptance of residual risk means the risk owner accepts the risk that remains after treatment. It is a decision about the outcome, and it should be compared with your risk acceptance criteria. If the residual risk is above the level your criteria allow, acceptance needs to come from whoever your method says can accept risks at that level, or further treatment is needed.
Both need evidence: who approved or accepted, what, and when. A signature, a recorded approval in your risk tool, or an email retained with the plan all work. A general statement in meeting minutes that "the risk treatment plan was approved" does not show that each risk owner approved their part. The risk appetite article covers how to set acceptance levels that make these decisions straightforward.
Keeping the plan live
A treatment plan written for the certification audit and not touched again is the most common failure. These habits keep it current.
Review it on a fixed cycle. Monthly or quarterly, depending on how many actions are open. Update status and dates at each review.
Revise it after every risk assessment. Clause 8.2 requires risk assessments at planned intervals and on significant change. Each one can add, remove, or re-rate risks, and the plan should follow.
Handle overdue actions explicitly. Either set a new date with a reason, or escalate. An overdue action with no note is a finding waiting to happen.
Record completion with evidence. When an action completes, link the evidence that it was done and update the register's residual rating. That is the documented information of results that clause 8.3 requires.
Report status to management. The status of the risk treatment plan is a required input to the management review. The management review article covers how to present it.
A check before your audit
- Not done:
Every risk marked for treatment has a plan entry
- Not done:
Every control not yet implemented in the SoA appears in the plan
- Not done:
Every action has an owner and a target date
- Not done:
Each risk owner's approval and residual risk acceptance is recorded
- Not done:
Overdue actions have a recorded reason or escalation
- Not done:
Completed actions link to evidence
- Not done:
The plan was updated after the most recent risk assessment
If you can tick each line, the plan will hold up. For the standard as a whole, see the ISO 27001 framework page.
How TrustLynce helps
TrustLynce keeps treatment plans in the risk register, linked to each risk, with owners, dates, and status. Risk owners' approvals and residual risk acceptances are recorded with a date, and continuous monitoring can confirm that a completed control is still operating.