SoA vs Risk Treatment Plan: Two Documents Teams Always Confuse
Two ISO 27001 documents get muddled more than any others: the Statement of Applicability (SoA) and the Risk Treatment Plan (RTP). They’re related, they overlap in content, and clauses 6.1.3 requires both — but they answer different questions, and an auditor who senses you’ve conflated them will start pulling threads.
The one-line distinction
The RTP is a plan of action: what you’re going to do about each risk, by when, and who owns it. The SoA is a statement of position: which controls apply, why, and their current status. The RTP is forward-looking and time-bound; the SoA is a point-in-time snapshot of your control landscape.
| Risk Treatment Plan | Statement of Applicability | |
|---|---|---|
| Answers | What will we do about each risk? | Which controls apply, and why? |
| Organised by | Risk | Control (Annex A) |
| Nature | Actions, owners, deadlines | Decisions, justifications, status |
| Changes when | A treatment is chosen or completed | A control’s applicability or status changes |
| Clause | 6.1.3 (e) / treatment | 6.1.3 (d) |
How they connect
They’re two ends of the same chain. Your risk assessment produces risks; the RTP decides how to treat each one — most often by applying controls. Those chosen controls then appear as “included” in the SoA, with the risk as their justification. So a healthy pair reconciles perfectly: every control marked applicable in the SoA traces back to a risk treated in the RTP, and every “apply a control” treatment in the RTP shows up as an included control in the SoA.
Where teams go wrong
- Treating the SoA as the plan — writing “to be implemented Q3” in the SoA status column instead of maintaining an actual RTP with owners and dates.
- An RTP that stops at “accept” or “mitigate” with no specific action, owner or deadline — that’s a decision, not a plan.
- Drift between the two: the RTP says a control is being implemented, but the SoA still marks it “not applicable”.
- Forgetting the other three treatment options. Applying a control is only one; the RTP should also cover risks you accept, avoid, or transfer — and those don’t all map to Annex A controls.
Keeping them in sync
The reconciliation is manual pain if the two live in separate spreadsheets, and it’s the first thing that rots between audits. The fix is structural: hold risks, treatments and controls in one linked model, so choosing a treatment in the RTP automatically updates the control’s inclusion and status in the SoA — and a stale entry in one surfaces as a mismatch in the other, not a surprise on audit day.
The bottom line
The RTP is your to-do list for risk; the SoA is your control-by-control position statement. Keep them distinct in purpose but linked in data, and the reconciliation auditors love to probe becomes something you can demonstrate in seconds.
One linked model, no reconciliation
Cyber Horizon links risks, treatments and Annex A controls in a single model — so your Risk Treatment Plan and Statement of Applicability stay in sync automatically, and always agree.
Book a Demo