ISO 27001 risk treatment plan
One row per risk, an owner with a name, a date that has not already passed, and a signature from the person who carries the risk rather than the person who wrote the document. That is the whole requirement, and most plans fail on the signature.
The risk treatment plan is required by clause 6.1.3 e) of ISO/IEC 27001:2022, and clause 6.1.3 f) requires risk owners to approve it and to accept the residual risk that remains after treatment. It is one row per risk, not one row per control, which is the structural difference between it and the Statement of Applicability. For a Canadian company of 25 to 100 staff a first plan usually carries 30 to 60 risks and $2,000 to $15,000 CAD of remediation spend, with the occasional line for single sign-on licensing or a logging tool pushing it higher.
30 to 60 Risks in a realistic first plan
6.1.3 f) The clause that requires a risk owner's signature
How is this different from the risk register and the Statement of Applicability
Three documents come out of clause 6.1, they are produced in a fixed order, and swapping them around is the single most common reason a first attempt takes twice as long. Each answers a different question and none of them substitutes for another.
| Document | Clause | One row per | Question it answers |
|---|---|---|---|
| Risk assessment and register | 6.1.2 | Risk | What could go wrong, how likely, how bad, who owns it |
| Risk treatment plan | 6.1.3 e) | Risk | What we are doing about it, by when, at what cost, and what is left over |
| Statement of Applicability | 6.1.3 d) | Annex A control | Which of the 93 controls apply, why, and whether they are running |
The method behind the first document, including scoring scales and the register columns auditors check, is on the risk assessment page. The four columns required in the third, with worked good and bad justification rows, is on the Statement of Applicability page. This page is the middle document, and its content is what makes the other two consistent with each other.
What are the four risk treatment options
Clause 6.1.3 a) asks you to select treatment options before you name any controls. The vocabulary is old and settled, and an auditor will use it precisely.
- Modify
- Apply controls to reduce likelihood or impact. This is what the large majority of rows say, and it is where Annex A gets used. Every modify row should name the control or controls it relies on.
- Avoid
- Stop doing the thing that creates the risk. Retire the legacy service, drop the on-premise deployment option, stop storing the data class entirely. Cheap, under-used, and the only option that reduces a risk to nothing.
- Share
- Move part of the consequence to somebody else, through insurance, a contractual liability cap or an outsourcing arrangement. Sharing moves money, not obligation. Under Canadian privacy law you remain accountable for personal information transferred to a processor, so a supplier contract never makes a privacy risk somebody else's problem.
- Retain
- Accept it as it stands, with a named person accepting it. Legitimate, and an auditor is not hostile to it. What draws a finding is a retained risk with no acceptance recorded, or a retained high risk accepted by the security lead rather than by the executive who carries the consequence.
What columns does the plan need
The standard does not specify a format. It specifies content, and the content implies a shape. These are the columns an auditor reads, in the order they read them.
| Column | What it carries | What an auditor is checking |
|---|---|---|
| Risk identifier | The same reference used in the register, for example R-14 | That every risk in the register appears here, and nothing appears here that is not in the register |
| Treatment option | Modify, avoid, share or retain | That the option matches what the actions actually do |
| Controls relied on | Annex A references and any control of your own | That these controls are marked applicable and implemented in the Statement of Applicability |
| Actions | What has to be built, bought or changed | That actions are specific enough to be verifiable |
| Owner | A named person, not a team | That the person named knows they own it, because the auditor may ask them |
| Target date | A real date | Whether dates have slipped and whether anything was done about the slippage |
| Cost | Budgeted spend in CAD, or internal effort | That the plan was resourced rather than aspirational |
| Residual risk | The rating that remains after treatment | That it was assessed after treatment rather than copied from before |
| Acceptance | Risk owner, date, signature or an equivalent record | Clause 6.1.3 f). This is the column most often empty |
What do good rows look like
These rows are illustrative rather than taken from a client document, and the costs are the CAD ranges Canadian companies of this size actually see.
| Risk | Option | Action and control | Owner | Cost (CAD) | Residual |
|---|---|---|---|---|---|
| R-03 Shared administrator credentials on the production cloud account | Modify | Single sign-on with enforced multi-factor authentication, individual named accounts, quarterly review. A.5.16, A.5.17, A.8.2 | Head of Engineering | $4,000 to $9,000 a year | Low |
| R-07 A subprocessor holds customer personal information under no reviewed agreement | Modify | Supplier register, security terms into the contract at renewal, annual review. A.5.19, A.5.20, A.5.22 | General Counsel | Internal time only | Medium |
| R-11 Backups have never been restored | Modify | Documented restore test each quarter with a recorded result. A.8.13 | Head of Infrastructure | Internal time only | Low |
| R-14 Exploitation of a known vulnerability in an internet-facing service | Modify | Advisory monitoring, monthly scanning, annual independent penetration test, remediation timelines in policy. A.5.7, A.8.8 | Head of Engineering | $10,000 to $20,000 a year | Medium |
| R-19 On-premise deployment option for two legacy customers | Avoid | Migrate both to the hosted product at renewal and withdraw the deployment option. No control needed once retired | VP Customer | Internal time only | None once complete |
| R-22 Loss of the single founder-engineer who understands the deployment pipeline | Retain | Documented runbooks reduce it, and the concentration remains until the team grows. A.5.29, A.8.32 | Chief Executive | Nil | High, accepted |
| Budgeted remediation, year one | Excludes internal time and the certification audit itself | $14,000 to $29,000 | |||
Two things about the last row are worth copying. The residual rating is High, stated plainly, and the acceptance sits with the Chief Executive rather than with the person who wrote the plan. Auditors do not object to a high residual risk. They object to a high residual risk that nobody senior has looked at.
Internal time is a cost, and leaving it blank costs you credibility
A plan whose cost column reads nil on every row tells an auditor the plan was never resourced. Where a row is genuinely internal effort, say so and put a rough number of days against it. At a loaded rate of $80 to $150 CAD an hour, ten days of engineering is $6,000 to $12,000 CAD of company money, and writing that down is how the plan survives contact with a budget conversation.
Who has to sign off the residual risk
The risk owner, which clause 6.1.2 required you to identify when you built the register. That is the person with the authority and accountability to manage the risk, and it is almost never the security lead. If a risk is about supplier contracts, the owner is whoever signs contracts. If it is about staffing concentration, the owner is an executive. The security lead's job is to run the process, not to absorb everyone else's risk on their behalf.
The signature is not ceremonial. It is the mechanism by which the standard forces a business decision to be made by the business. A plan approved only by the person who wrote it is the most common clause 6.1.3 f) finding, and it is also the reason the plan then sits unfunded, because nobody who controls a budget was ever asked to agree to it. If you cannot get a risk owner to sign, you have learned something important about whether that risk is really accepted.
How the plan gets sampled at stage 2
The auditor works backwards from it. They pick four or five rows, usually including the highest residual risks and anything with a date in the past, and follow each one into reality: is the control named in the row marked implemented in the Statement of Applicability, does the person named as owner recognise the risk when asked, does the evidence for the action exist, and did the residual rating get reassessed after the action completed. A row that survives all four is a good row.
The failure they find fastest is the plan that stopped being maintained. Target dates from eighteen months ago, all still open, with no record of a review is a clause 10 finding as much as a clause 6 one, because the management system is supposed to notice its own slippage. Reviewing the plan is a standing input to the management review and a standing item for the internal audit, and doing both is what keeps this document alive between audits.
When the plan is the wrong tool
The honest counter-case is that risk treatment plans get over-built, and the over-building is usually sold rather than needed. A 20-person company does not have 200 distinct information security risks. It has perhaps 25, and a plan with 200 rows means the risk assessment was run at the level of individual assets rather than at the level of things that could actually go wrong. Long plans are not audited more favourably. They are audited the same way, sampled at random, and every extra row is another chance to be caught with an owner who has left.
Two other cases where the plan is not the answer. A finding that has already happened belongs in the corrective action process under clause 10, not in the risk treatment plan, and mixing them makes both harder to read. And a control you have decided to implement for a customer contract rather than for a risk belongs in the Statement of Applicability with a contractual justification. It does not need a manufactured risk written backwards to justify it, which is a habit that produces registers full of fiction.
Get the plan reviewed before the auditor reads it
Tell us your scope and where the risk work has got to, and we will match you with Canadian firms that do ISO 27001 readiness.
Get matchedCommon questions
Is the risk treatment plan the same as the Statement of Applicability?
No. The risk treatment plan has one row per risk and records what you are doing about each. The Statement of Applicability has one row per Annex A control and records whether the control applies and why. They are produced from the same work and clause 6.1.3 requires both, and they have to agree with each other: a control named in the plan that is marked not applicable in the Statement of Applicability is a contradiction an auditor will find.
How many risks should be in the plan?
Every risk in your register that you decided to treat, which for a Canadian company of 25 to 100 staff is typically 30 to 60. There is no minimum or maximum in the standard. A plan much shorter than the register means risks were dropped without a decision, and a plan of several hundred rows usually means the assessment was done per asset rather than per risk.
Can we accept a high risk?
Yes, provided the risk owner accepts it explicitly and the acceptance is recorded with a date. Clause 6.1.3 f) asks for exactly that. What draws a finding is a high residual risk with an empty acceptance column, or one accepted by somebody without the authority to carry the consequence. Record the reasoning too, because the next auditor will ask why it is still accepted a year later.
Does cyber insurance count as risk treatment?
It counts as sharing, and it is a legitimate option for financial consequence. It does not reduce likelihood, it does not satisfy a control, and it does not move accountability for personal information under PIPEDA or the provincial statutes. Insurance rows in a treatment plan should sit beside modify actions rather than instead of them, and the auditor will ask what the policy actually excludes.
How often does the plan need updating?
Whenever a risk changes, an action completes or the scope moves, and at minimum as part of the annual cycle before each surveillance audit. The practical rhythm is a quarterly pass through open rows and a full review ahead of the management review, so that leadership sees current dates rather than a document written for the last audit.
Do we need a tool for this?
No. A spreadsheet with the columns above satisfies clause 6.1.3 completely and is what most Canadian companies under 100 staff use through their first certification. A compliance platform at $8,000 to $30,000 CAD a year earns its money on evidence collection rather than on this document. The gap assessment tool will tell you whether the risk work is the thing holding your project up.