The Statement of Applicability explains which Annex A controls are included or excluded and why, while the risk treatment plan explains how identified risks will be addressed. One is the control justification record, the other is the action plan.
Why ISO 27001 Separates the SoA From the Risk Treatment Plan
The distinction matters because iso 27001 uses two different records for two different decisions. The statement of applicability is the control-selection and justification document, while the risk treatment plan is the execution record for how specific risks will be treated. Treating them as interchangeable usually creates confusion in audits, ownership, and control traceability.
The Statement of Applicability sits inside the ISMS as the place where an organisation records which Annex A controls are in scope, which are excluded, and the rationale for each decision. The risk treatment plan sits on the risk-management side and translates assessed risk into treatment actions, owners, and timing. One explains control choice; the other explains risk response.
That separation is useful because ISO 27001 does not assume every control exists for every risk. A control can appear in the SoA because it is applicable to the ISMS, even when a particular risk is being treated some other way. Likewise, a treatment action can address a risk without making the SoA a full remediation tracker. The two documents are related, but they answer different governance questions.
For the standard itself, see ISO/IEC 27001:2022 Information Security Management and the companion guidance in ISO/IEC 27002:2022 Information Security Controls. If you want a broader control-mapping lens across regulatory and security frameworks, the Identity Security Regulatory Map is useful context for how control justification and governance records relate to wider compliance obligations.
What Each Document Must Prove in Practice
The SoA should prove that control selection is deliberate, risk-informed, and traceable. It should show what Annex A controls were considered, whether each was included or excluded, and why that decision was made. In practice, auditors look for internal consistency between the SoA, the risk assessment, and the treatment decisions, not just a long list of controls.
The risk treatment plan should prove that identified risks have a decided response. That response may be to reduce, avoid, share, or accept the risk, but the plan must show what action will happen, who owns it, and when it is expected to be completed. It is a management plan, not a catalogue of controls. A strong plan can reference controls, but its job is to close the loop on risk decisions.
A useful way to think about the relationship is that the SoA justifies the control architecture, while the risk treatment plan operationalises the risk response. If a risk treatment introduces a new control, the SoA may need to be updated so the control justification record stays aligned with the ISMS. If a control is removed or changed, the impact should also be reflected back into treatment and risk acceptance records.
The control-selection logic behind the SoA is closely aligned with ISO control guidance, while treatment planning is where the organisation translates policy into delivery. That is why teams that keep these documents separate usually manage reviews, approvals, and audit evidence more cleanly than teams that collapse them into one spreadsheet.
How to Keep the Two Records Aligned Without Merging Them
Keep the documents linked by reference, not merged by structure. Each identified risk should map to a treatment decision, and each selected control in the SoA should be explainable in terms of why it exists in the ISMS. The goal is traceability, not duplication.
Use the ISO/IEC 27002:2022 Information Security Controls guidance to make sure the control rationale is defensible, then ensure the treatment plan names the actual corrective or mitigating actions. If a control is adopted because it is broadly required by the ISMS, that belongs in the SoA. If a specific risk drives a compensating control, that belongs in the treatment plan and should then flow back into the SoA if it changes the control set.
This separation becomes especially important during audits and management review. The SoA is typically reviewed for completeness and rationale, while the risk treatment plan is reviewed for progress, overdue actions, and unresolved exposure. If one document tries to do both jobs, neither job is done well.
When teams use the SoA as a remediation tracker, they often lose sight of exclusions and applicability decisions. When they use the risk treatment plan as a control inventory, they often lose sight of the reasons controls were selected in the first place. Keeping the records distinct avoids both problems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
ISO/IEC 27001:2022 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.1 — Policies for information security | SoA and treatment planning both sit inside ISMS governance and policy decisioning. |
| A.5.21 — Managing information security in the ICT supply chain | Risk treatment decisions often translate into control selections that must be justified in the SoA. | |
| A.5.36 — Compliance with policies, rules and standards for information security | The SoA is the record that shows which controls are adopted or excluded and why. | |
| Recommendation — Use policy governance to keep control justification and treatment actions aligned. Map supply-chain-related risk treatments to documented Annex A control choices. Maintain a clear control-justification record and review it against the ISMS. | ||
Practitioner Guidance
What to verify: Confirm that every Annex A inclusion or exclusion in the SoA has a clear rationale, and that every material risk in the treatment plan has an owner, due date, and chosen treatment path. If you cannot trace a control decision back to governance logic, or a treatment action back to a risk, the records are too weak for audit use.
Decision rule: If the question is “why is this control in or out?”, use the SoA. If the question is “what are we doing about this risk?”, use the risk treatment plan. If a single document is trying to answer both, split it before review rather than after a finding.
Common mistake: Teams often let the SoA become a static compliance appendix and the treatment plan become a task list with no control logic. Good ISO 27001 practice keeps both current and cross-referenced, so control justification and risk response remain aligned as the ISMS changes.
Practitioner takeaway: The SoA is about control applicability and justification, while the risk treatment plan is about action and accountability; keeping them separate is what makes ISO 27001 traceable, reviewable, and audit-ready.
Related resources from NHI Mgmt Group
- Why do gaps in the internal audit, risk assessment, or Statement of Applicability block stage two of ISO 27001?
- What is the difference between Annex A and the Statement of Applicability in ISO 42001?
- How should security teams govern non-human identities for ISO 27001?
- What is the difference between attack surface management and NHI governance?