The Statement of Applicability & Risk Treatment Plan

Every concept from lessons 4 through 10 converges here. The Statement of Applicability (SoA) is arguably the single most important document in an ISO/IEC 27001 ISMS — and it's also the document auditors scrutinize hardest, because a weak SoA usually signals that everything upstream of it (risk assessment, risk treatment) was weak too.

What an SoA actually is

The SoA is a structured record covering every one of the 93 Annex A controls, stating for each:

1. Whether it's included or excluded
2. The justification for that decision
3. Whether it's currently implemented (a control can be "included" as applicable but not yet fully implemented — that's a legitimate, tracked gap, not a lie)
4. A reference to supporting evidence (a policy, a system configuration, a supplier certification — something concrete, not just the word "yes")

A minimal, defensible SoA row looks like this:

Control: 8.24 — Use of cryptography
Applicable: Yes
Justification: Risk assessment (RA-2024-014) identified data-in-transit
                interception as a Medium risk; TLS 1.3 is required for
                all external connections per our Cryptography Policy v2.
Implemented: Yes
Evidence: Cryptography Policy v2 (approved 2024-03), nginx TLS
          configuration audit (2024-06)

Compare that to an indefensible row: Control: 8.24 — Yes — see policy. No risk linkage, no policy version, no evidence reference — this is the SoA equivalent of the "silently omitted" exclusions covered in earlier lessons, except here it's a silently unjustified inclusion, which is just as much of a finding.

The SoA is not a creative writing exercise — it's a trace

The most common Foundation-level misunderstanding is treating the SoA as something you write from scratch, independently, based on what "sounds reasonable." In a properly functioning ISMS, the SoA is entirely derived:

Clause 6.1.2 Risk Assessment
        │  identifies specific risks
        ▼
Clause 6.1.3 Risk Treatment
        │  selects modify/retain/avoid/share for each risk
        ▼
Statement of Applicability
        │  records which Annex A controls this implies,
        │  included or excluded, with justification
        ▼
Risk Treatment Plan
   records WHO implements each control, BY WHEN, and tracks
   progress until implementation is complete

If a control appears in the SoA as "included" but no corresponding risk in the risk assessment explains why it's needed, that's a traceability gap — the SoA and the risk assessment have drifted apart, which is exactly the kind of inconsistency an auditor is trained to pull on.

SoA vs. Risk Treatment Plan — not the same document

These two are frequently confused:

The SoA is closer to a stable reference document; the Risk Treatment Plan is closer to a live project tracker. Both matter, but conflating them is a common mistake — an auditor asking "show me your Risk Treatment Plan" and being handed only the SoA (or vice versa) is a sign the organization doesn't clearly understand the distinction.

Keeping the SoA current

The SoA isn't written once at initial certification and forgotten — it must be reviewed whenever the risk assessment changes (new risks, changed context per clause 4.1) and as part of the ongoing management review cycle (clause 9.3, from an earlier lesson). An SoA that hasn't been touched in three years, in an organization that has clearly changed technology or grown significantly in that time, is itself a red flag regardless of what it says.