7.4 The Statement of Applicability (SoA)

The Statement of Applicability (SoA) is the single document most heavily scrutinized during an ISO/IEC 27001 certification audit. It is the artifact that proves the organization has done the risk-treatment work Clause 6.1.3 demands, and it is the bridge between the organization's specific risks and the generic Annex A control set. Foundation exam questions on the SoA are common and tend to test (a) where the requirement comes from, (b) what the SoA must contain, (c) what the SoA is NOT, and (d) how it links risk treatment to Annex A.

The Requirement

Clause 6.1.3 d) of ISO/IEC 27001:2022 states that the organization must produce a Statement of Applicability that contains:

• the controls that are necessary to implement the chosen risk treatment options;
• the justifications for their inclusion;
• the controls that are implemented from Annex A;
• the justifications for the exclusion of any Annex A controls; and
• the method used to verify the implementation of the controls.

(The 2022 wording also requires the implementation status of each applicable control — planned, in progress, implemented, operating effectively — to be visible.)

The SoA is documented information under Clause 7.5. It must be maintained and updated whenever risk treatment decisions change, the risk landscape changes, or controls are added, modified, or retired.

---

What the SoA Must Contain

A compliant SoA is typically a table — one row per control — with columns that mirror the Clause 6.1.3 d) requirements:

Worked Example Rows

The excluded row (8.30) is critical: an Annex A control may be excluded only with a documented justification. Silently dropping a control is non-conformant.

---

What the SoA Is — and What It Is Not

The exam frequently tests the distinction between the SoA and related documents. The SoA is:

• A justification document — every included or excluded control has a stated reason.
• A risk-treatment-to-control linkage — each included control traces back to a risk treatment decision from Clause 6.1.3 b)/c).
• A living document — updated as risks, controls, and treatment decisions evolve.
• A mandatory documented information artifact under Clause 7.5.

The SoA is NOT:

• A generic control checklist that simply lists every Annex A control with "Yes" in every row.
• A copy of Annex A — it is organization-specific.
• A risk register — that lives elsewhere and feeds the SoA.
• A policy document — it references policy but is not itself a policy.
• A substitute for implementing controls — listing a control in the SoA does not make it implemented; implementation status must be honest and evidence-backed.

The Most Common Exam Trap

"The SoA is a list of all 93 Annex A controls."

Wrong. The SoA is a justification document tied to risk treatment, not a catalogue. A compliant SoA may exclude Annex A controls, but only with a stated justification. It may also include controls from outside Annex A (for example, a PCI-DSS or NIST 800-53 control the organization adopts) when justified by risk treatment — Annex A is a reference set, not a closed universe.

The Second Most Common Trap

"If a control is listed in the SoA, it is implemented."

Wrong. The SoA reports implementation status. A control can be listed as planned or in progress and still be conformant, provided the status is truthful and the plan is realistic. The auditor will verify implementation status by sampling evidence — policy documents, procedure records, configuration baselines, training logs.

---

How the SoA Connects to Other ISMS Documents

flowchart LR
    A[Clause 6.1.2 Risk Assessment] --> B[Clause 6.1.3 Risk Treatment]
    B --> C[Risk Treatment Plan]
    B --> D[Statement of Applicability]
    D --> E[Annex A Controls]
    D --> F[Implementation Status]
    F --> G[Clause 8 Operation]
    G --> H[Clause 9 Performance Evaluation]
    H --> I[SoA Update]
    I --> B

In words:

1. The risk assessment (Clause 6.1.2) identifies risks.
2. The risk treatment (Clause 6.1.3) selects treatment options and controls.
3. The Risk Treatment Plan records the chosen options and risk owners.
4. The SoA records which Annex A controls are applicable, with justification and status, and links each to the treatment option it implements.
5. Clause 8 Operation implements the controls in production.
6. Clause 9 Performance Evaluation measures whether controls are operating effectively.
7. Findings feed back into the SoA (status changes) and into the next risk-treatment cycle.

This loop is why the SoA is a living document. It must be reviewed at planned intervals and after significant changes (new service, new supplier, new threat, post-incident).

---

Audit Scrutiny

The SoA is the first or second document the Stage 1 auditor asks for, alongside the Information Security Policy and the Risk Treatment Plan. Auditors scrutinize:

• Coverage: Did the organization address every Annex A control (include or exclude with justification)? A missing row is a finding.
• Justification quality: "Not applicable" with no rationale is a finding. The justification must tie to a specific organizational fact ("no cloud services used" or "risk assessment identified no risk requiring this control").
• Status honesty: A control marked "Operating effectively" with no supporting evidence in the policy library, configuration, or training records is a finding.
• Linkage to risk treatment: A control included without traceability to a risk treatment decision suggests the SoA was written backwards from Annex A rather than derived from risk treatment.
• Currency: A SoA dated two years before the audit suggests it is not being maintained.

A typical Stage 1 finding pattern is: "The SoA includes A.8.28 Secure Coding with status 'Operating effectively,' but the development team could not produce secure coding guidelines or evidence of peer review." That is both a documentation finding and a status-honesty finding.

---

Maintenance and Update Triggers

The SoA must be updated when:

• The risk landscape changes (new threats, new vulnerabilities, new assets).
• Risk treatment decisions change (a modify treatment is replaced by a share treatment, requiring different controls).
• Controls are added, modified, or retired.
• Internal audit or management review identifies issues that change applicability or status.
• An incident reveals a control gap that needs to be closed.
• The organization's scope or context changes (new service, new jurisdiction, new supplier relationship).
• A planned review interval is reached (typically annually, often aligned with management review under Clause 9.3).

The exam may test this by asking whether the SoA is a one-time document. It is not — it is maintained documented information.

---

Common Exam Traps (Consolidated)

• Trap 1 — "The SoA is a control checklist listing all 93 Annex A controls." Wrong. It is a justification document tied to risk treatment; some Annex A controls may be excluded with justification, and some non-Annex A controls may be added.
• Trap 2 — "A control listed in the SoA is by definition implemented." Wrong. The SoA records implementation status, which can be planned, in progress, implemented, or operating effectively.
• Trap 3 — "Annex A controls can be silently dropped if the organization thinks they are unnecessary." Wrong. Excluding an Annex A control requires documented justification.
• Trap 4 — "The SoA is owned by the IT department." Not necessarily. The SoA is owned by the organization's risk owner / ISMS team and approved by top management; it is a management document, not a technical artifact.
• Trap 5 — "The SoA is required by Clause 8." Wrong. The SoA is required by Clause 6.1.3 d), in the Planning clause.
• Trap 6 — "The SoA is the same as the Risk Treatment Plan." Wrong. The Risk Treatment Plan records treatment options and risk owners; the SoA records control applicability, justification, and status. They are companion documents produced by the same clause.

---

Key Takeaways

• The SoA is required by Clause 6.1.3 d) and is documented information that must be maintained.
• The SoA must include, for each Annex A control: applicability, justification for inclusion or exclusion, implementation status, and linkage to risk treatment.
• The SoA is not a generic control checklist — it is a justification document tied to risk treatment.
• Annex A controls may not be silently dropped; excluding one requires documented justification. Controls outside Annex A may be added when justified.
• The SoA is one of the most scrutinized documents during a certification audit and is updated whenever risks, controls, or treatment decisions change.