In an ISO 27001 Stage 2 audit, the auditor does not stop at the risk register. They follow the chain: identified risk, treatment decision, concrete action, owner, deadline, implementation evidence and accepted residual risk. That chain lives in the risk treatment plan required by clause 6.1.3 of ISO/IEC 27001:2022.
Many organisations confuse three distinct documents: the risk register (output of analysis), the Statement of Applicability (which Annex A controls apply) and the treatment plan (what to do with each risk that exceeds acceptance criteria). Having the first without the third is one of the most frequent causes of major findings on first certification.
What the risk treatment plan is and how it differs from the register
The risk treatment plan is the document that records, for each risk requiring action, the chosen treatment option, concrete controls or measures, owners, deadlines and expected residual risk once implemented. ISO 27001 explicitly distinguishes it from risk assessment (clause 6.1.2): assessment identifies and scores; the plan decides and assigns.
The relationship between documents is linear:
- Risk assessment → produces the register with inherent risk levels.
- Evaluation against acceptance criteria → filters which risks need treatment.
- Treatment plan → details actions per risk.
- Statement of Applicability → consolidates which Annex A controls are implemented and why.
- Evidence → demonstrates that plan actions were executed.
If the SoA lists controls that do not appear in any plan linked to a risk, the auditor asks why they were chosen. If the plan describes generic actions (“strengthen security”) with no Annex A control or verifiable evidence, it does not hold up either.
The 4 treatment options under ISO 27005
The standard does not use the colloquial terms “mitigate, accept, transfer, avoid” exactly. In ISO/IEC 27005:2022 the options are:
- Modify the risk: Reduce likelihood or impact through controls. The most common option: select Annex A controls (or documented additional controls) and implement them. Example: unauthorised CRM access risk → control A.5.15 (access control) + A.5.16 (identity management) + MFA on the IdP.
- Retain the risk: Accept residual risk without further action beyond existing controls. Requires residual level within acceptance criteria and formal sign-off by the risk owner. It is not “do nothing”: it is a conscious decision that remaining risk is tolerable.
- Avoid the risk: Remove the activity, asset or process generating the risk. Example: stop storing client data in local spreadsheets, eliminating loss risk from an unencrypted device. Uncommon but valid when control cost exceeds asset value.
- Share the risk: Partially transfer financial impact, usually through cyber insurance or contractual clauses with suppliers. It does not remove operational responsibility: you remain accountable.
Each risk in the plan should have one primary documented option. Combining “modify + retain” is normal (implement controls and accept residual), but it must be explicit what the residual is and who accepts it.
Fields auditors expect in each plan entry
A plan that survives audit is not one paragraph per risk. It is a structured row with traceability. Minimum fields:
| Field | What it must contain |
|---|---|
| Risk ID | Reference to risk register |
| Risk description | Clear scenario: threat + asset + consequence |
| Inherent level | Before treatment |
| Treatment option | Modify, retain, avoid or share |
| Annex A controls | Explicit reference (e.g. A.8.24, A.5.33) |
| Concrete actions | What is implemented, not vague intentions |
| Risk owner | Responsible for decision and residual acceptance |
| Implementation owner | Who executes the action (may differ) |
| Target date | Implementation deadline |
| Status | Planned, in progress, completed, verified |
| Required evidence | Which document or record proves the action |
| Residual risk | Expected level after implementation |
| Residual acceptance | Risk owner signature or minutes |
The guide to creating an ISO 27001 risk assessment covers the prior phase (register and levels). The treatment plan is the next step: turning numbers into a project.
How to build the plan in 5 steps
1. Filter risks that need a detailed plan. Not every register risk needs an expanded plan. Risks below the acceptance threshold can be documented in the register with a “retain” decision and brief justification. Reserve the detailed plan for medium and high risks and any risk where the chosen option is modify with multiple controls.
2. Select controls with criteria, not by copying Annex A. Choosing 93 controls “just in case” inflates the SoA and implementation work. For each risk, ask: which control specifically reduces this threat on this asset. If one control covers several risks, reference it in each plan row.
3. Break down implementable actions. “Implement access policy” is a title, not an action. Valid actions: draft policy, submit for management approval, configure MFA in Entra ID, review admin-cloud group members, document approved exceptions.
4. Assign real owners. The risk owner is usually the process or system owner (product director for SaaS risk, CFO for financial risk). The implementation owner may be IT or security. Confusing both roles leaves actions without an owner.
5. Link to the SoA and schedule verification. When an action completes, update the SoA (control marked implemented), archive evidence and recalculate residual risk. Schedule plan review in management review and on significant changes, as the ISMS risk management framework requires.
Example of an auditable chain (not a generic template)
Suppose a risk identified in a B2B SaaS company:
- Risk R-014: Client data exposure from misconfigured S3 bucket.
- Inherent: High (medium likelihood × high impact).
- Treatment: Modify.
- Controls: A.8.20 (network security), A.8.24 (encryption), A.8.9 (configuration management).
- Actions: Enable Block Public Access on all AWS accounts; implement SCP denying public ACLs; deploy weekly bucket scanner; remediate three buckets flagged on first scan.
- Risk owner: CTO.
- Deadline: 30 days from plan approval.
- Evidence: AWS Config export + closed remediation ticket + scanner report.
- Residual: Low, accepted by CTO in security committee minutes.
That chain is what the auditor follows. They do not need a generic fraud or identity theft example copied from a blog: they need your real risk, your decision and your proof.
6 Mistakes that cause non-conformities in audit
- Plan copied from the register without actions. Same description in both documents, no controls or deadlines.
- SoA controls without plan traceability. The auditor picks a control at random and asks which risk it covers.
- Risk acceptance without owner signature. “Retain” documented only in Excel with no formal approval.
- Completed actions without evidence. Status “done” with no ticket, configuration, report or minutes to prove it.
- Residual risk not recalculated. Plan says “low residual” but register still shows high level.
- Plan frozen since initial certification. No reviews after incidents, new products or cloud provider changes.
Relationship with the Statement of Applicability
The SoA and treatment plan feed each other but are not interchangeable. The plan is operational (project per risk); the SoA is declarative (status of Annex A controls). Recommended flow:
- Build actions in the plan → identify required Annex A controls → consolidate in the SoA with implementation status.
- On annual reviews → update plan for new risks → adjust SoA if new controls or justified exclusions appear.
The ISO 27001 readiness checklist includes checking coherence between register, plan and SoA before calling the auditor.
How PrivaLex can help
The treatment plan is where many well-intentioned ISMS programmes break: the register exists, the SoA is filled in, but the link between risk, action and evidence does not survive auditor sampling. PrivaLex works with organisations designing and implementing the ISMS so clause 6.1.3 is covered in a verifiable way.
Methodology and templates. We define acceptance criteria, scales and plan templates aligned with ISO 27005 and the format your certification body expects. We avoid generic templates disconnected from your processes.
Building the first plan. We facilitate the treatment workshop with real risk owners: for each priority risk, documented decision, selected Annex A control and action with deadline. We do not leave the IT team alone with an empty spreadsheet.
Register – plan – SoA coherence. We review cross-traceability before Stage 1 and Stage 2. We fix gaps where a control appears in the SoA with no associated risk or a plan action has no defined evidence.
Pre-audit follow-up. We support closing pending actions, evidence collection and formal acceptance of residual risks. More context on ISO 27001 and the guide to certification for EU startups.
Post-certification maintenance. We integrate plan reviews into the annual surveillance cycle and after scope changes, so the document stays live and is not an artefact from the week before audit.
Conclusion
The ISO 27001 risk treatment plan is the bridge between analysing risks and demonstrating that the ISMS works. It requires explicit treatment options, traceable Annex A controls, actions with owner and deadline, defined evidence and documented acceptance of residual risk. Without that chain, the risk register is a theoretical exercise and the SoA a wish list. Building it properly from first certification saves findings, partial re-audits and months of reactive remediation.
If you want to review whether your current treatment plan would survive a Stage 2 audit, request your free risk assessment or book a session with our team.
Frequently Asked Questions
ISO 27001 clause 6.1.3 requires a documented risk treatment plan. It can be a separate document or a structured extension of the register, provided it contains treatment decisions, selected controls, owners and expected results. What does not work is a register that only lists risks and levels without traceable treatment decisions.
When residual risk, after existing controls, is within acceptance criteria defined by management and the risk owner documents and signs that acceptance. It is not appropriate for high risks without solid justification or without management involvement. The auditor will verify that acceptance is not a way to ignore risks that should be treated.
No. Only controls that concrete risk treatments require, plus those the organisation implements by choice. The SoA consolidates all applicable controls (implemented or not, with justification). The treatment plan links controls to specific risks. Including all 93 controls in the plan with no risk relationship is as problematic as a SoA that excludes them all without justification.
On significant changes (new product, major incident, critical supplier change, new regulation) and at minimum in the ISMS review cycle, usually annual. Overdue actions without closure are a common finding. The plan works as a project management document: statuses, dates and owners must stay current.
Depends on the action: approved and published policy, configuration screenshot, test report, closed ITSM ticket, training record, committee minutes. Evidence should be defined in the plan row before implementation, not searched for afterwards when the auditor arrives. The auditor samples risks and asks to see the evidence the plan promised.
No. They are complementary documents. The plan answers “what do we do about this risk”. The SoA answers “which Annex A controls apply to the organisation and in what state”. Both must be coherent but serve different functions under ISO 27001 clause 6.1.