ISO 27001 Statement of Applicability: Build One That Stays True

You passed the audit. Your Statement of Applicability looked complete. Twelve months later, it isn't true anymore.

Controls marked "Implemented" have drifted. Owners have changed roles. Suppliers have been replaced. The risk treatment plan was updated in Q3, but nobody touched the SoA. When your auditor arrives, the document says one thing. Operations does another.

This is not a compliance failure. It is a governance failure — and it is almost universal among teams that treat the SoA as a document to be filed rather than a governance object to be maintained.

The UK's National Cyber Security Centre logged over 2,000 cyber-attack reports in a single year. Boards consistently rank cyber among their top systemic risks. At that pace of change, "implemented" controls can degrade fast if your SoA isn't designed to keep pace with the environment it describes.

This guide covers what an honest, auditor-ready SoA contains, where most ISO 27001 programmes fall short, and how to build a lifecycle that keeps your SoA accurate between audits — not just at them.

A Statement of Applicability (SoA) is a mandatory ISO 27001 artifact that records your organisation's decisions for all controls in Annex A of ISO/IEC 27001:2022. For each of the 93 controls, it captures applicability (yes or no), justification for that decision, and implementation status. Mature teams also include a named owner, evidence references, and a scheduled review date — because without those fields, the SoA is a record of past decisions, not a current statement of your control environment.

The SoA is not a risk register. It does not replace the Risk Treatment Plan. Its sole function is to document which Annex A controls apply to your ISMS, why, and whether they are in place.

The canonical fields — keep them consistent across every row:

1. Applicability (Yes/No)
2. Justification (one to two lines naming the driver: risk reduction, legal or regulatory requirement, contractual obligation, or customer expectation)
3. Implementation status (Implemented / Partially / Planned)
4. Evidence reference (policy ID, ticket, configuration path)
5. Owner, review date, version

Yes. Your SoA must address every control in Annex A of ISO/IEC 27001:2022 — all 93. You cannot omit irrelevant controls with a single catch-all exclusion note. Each control requires a recorded decision and a rationale. What you can do is reference a reusable exclusion note across multiple rows to keep the document concise without sacrificing completeness.

The General Exclusion Note pattern works as follows. Create a short, reusable statement — for example, GEN-EX-01: "No in-house software development within the ISMS scope." Each development-related control row remains in the SoA and references GEN-EX-01 in its justification field. The SoA stays complete. Auditors see the rationale in one place. Every row still has a recorded decision.

The 2022 revision consolidated controls from 114 (in ISO/IEC 27001:2013) to 93, reorganised into four themes. If your SoA was built against the 2013 standard, it needs re-mapping — not just renumbering. Control IDs have changed. Justifications based on old groupings may no longer be accurate.

Editor's note: Confirm the current transition deadline with your certification body. The IAF's transition communiqué is the reference for mandatory migration timelines. 

SoA drift is the gap between what your Statement of Applicability says and what your control environment actually does. It is almost universal. And it is invisible until an auditor points it out.

Drift accumulates in predictable ways. A control owner changes role; accountability is implied rather than reassigned. A cloud supplier is replaced; the evidence reference still points to the old vendor's assurance report. A system is decommissioned; the controls that depended on it are still marked "Implemented". The risk treatment plan is updated mid-year following an incident; the SoA is not.

The problem is not that teams are careless. The problem is that spreadsheet-based SoAs have no mechanism to detect or surface drift. There are no workflow triggers when a supplier changes. No attestation reminders when a review date passes. No immutable record when a status is manually edited.

The fix is a lifecycle, not a better spreadsheet. Treat the SoA as a governance object with named owners, approval workflows, version history, and evidence references that lead auditors to proof in a single step. Define the events that trigger an immediate review — not just an annual one.

Material change triggers that should force an immediate SoA review:

1. New systems, platforms, or infrastructure changes within ISMS scope
2. New or replaced third-party suppliers
3. New locations or operating entities brought into scope
4. Material incidents, including near-misses with control failures
5. Legal, regulatory, or contractual changes affecting your obligations
6. Audit findings or non-conformities
7. Changes in the risk treatment plan

Editor's note: The above trigger list reflects common practice in mature ISMS programmes. Verify against your certification body's surveillance expectations and your organisation's documented change management procedure.

Marking a control "Implemented" is a claim. Without linked evidence, it is an unverifiable claim — and auditors treat unverifiable claims as findings.

Evidence must be findable, current, and clearly mapped to the control it supports. A control row that says "Implemented" with no evidence reference, or one that points to a policy document that has not been reviewed in three years, will create audit friction at Stage 2 and every surveillance visit after it.

Translate each status into proof:

1. Policy control: Point to the approved policy ID, the latest change log entry, and a distribution or acknowledgement record confirming the policy reached the people it governs.
2. Vulnerability management: Show the scan schedule, exception register, remediation SLAs, and a recent closed ticket that met the SLA. Not the policy that describes the process — the evidence that the process ran.
3. Cloud services (A.5.23): Reference the supplier register entry, the Data Processing Agreement, current SLAs, the latest available assurance report (SOC 2, ISO 27001 certificate, or equivalent), and logs showing you actively review supplier performance.

Evidence quality is not a bureaucratic concern. It is what separates a control that exists from a control that works. Your SoA should make that distinction visible, not obscure it.

The Risk Treatment Plan (RTP) and the Statement of Applicability serve different purposes. Conflating them creates confusion during audits and slows down the review process.

The RTP selects controls to treat identified risks. The SoA records how those selected controls — and all other Annex A controls — compare to your decisions and whether they are implemented. Keep the documents distinct. Then link controls to risks and obligations so the traceability is clear to an auditor without requiring explanation.

In practice: a control in your SoA should reference the risk or risks it addresses, and your RTP should point back to the relevant SoA rows. The connection should be visible and navigable, not described in a covering note.

An ISO 27001 SoA built in isolation creates duplicated effort when your organisation also operates under DORA, NIS2, or FCA operational resilience requirements. The same control evidence — monitoring logs, supplier assurance, incident response records — is required across multiple regimes. If each regime has its own evidence trail, you are doing the same work several times over.

The answer is to design your SoA as a connected data source for all frameworks from the start. Add mapping columns for external references — DORA article numbers, NIS2 domains, FCA operational resilience obligations. Your Annex A decisions become the foundation; evidence is attached once and referenced across frameworks.

Why this matters now. DORA enforcement is active. Register of Information submissions to National Competent Authorities were due in March 2026. NIS2's full compliance deadline is October 2026, with German registration closing April 2026. FCA fines for operational resilience failures are already being issued. Your SoA mapping work is not future planning — it is catching up with current obligations.

Ownership breaks when it is implied rather than assigned. A control row without a named owner has no one accountable when the evidence goes stale, the review date passes, or the underlying system changes. This is where the gap between a compliant SoA and an honest one becomes visible.

Build accountability in at the row level:

1. Assign each control to a named role, not a team or department.
2. Schedule quarterly attestations: the owner confirms that the status and evidence are still accurate.
3. The ISMS lead holds overall accountability for the SoA. Responsible leadership approves it. That approval is not a formality — it is the business accountable for the control framework.

Track a small number of operational metrics to surface problems early:

1. Proportion of controls with current, linked evidence
2. On-time attestation rate
3. Number of controls in "drift" — status not confirmed in the last quarter
4. Mean time to close evidence gaps following a change trigger

These are not reporting metrics. They are early warning signals. A falling attestation rate or a growing number of unconfirmed controls tells you where your SoA is degrading before your auditor does.

A spreadsheet-based SoA relies on memory, calendars, and individual discipline. When any of those fail — and over a twelve-month audit cycle, they will — the SoA drifts.

A platform-based SoA relies on workflows. Attestations are scheduled and tracked. Status changes trigger approvals. Evidence is attached to control rows, versioned, and accessible in a single step. When a supplier changes, the relevant control rows surface for review automatically.

You do not need more data. You need execution.

In SureCloud, each SoA row is a live governance object with a status, owner, linked evidence, and review cadence. Framework mappings — ISO 27001, DORA, NIS2, FCA — move with the control. Auditor-ready exports are available on demand. Redacted customer-facing views can be generated separately. The SoA does not degrade between audits because the system does not allow it to.

This is the difference between a SoA that is technically compliant and one that is operationally honest. Compliance gets you through an audit. Operational honesty is what protects the business.

The 2022 revision of ISO/IEC 27001 consolidated controls from 114 to 93 and reorganised them into four themes. Control IDs and groupings changed. A SoA mapped to the 2013 standard is not automatically compliant with 2022 — it needs active re-mapping, not just renumbering.

Migration steps:

1. Update your control list and IDs to the 2022 Annex A.
2. Re-assess applicability for each control based on current risks, legal and contractual obligations.
3. Rewrite justifications that were built around 2013 groupings — they may no longer be accurate.
4. Refresh evidence links. Update owner assignments where roles have changed since the last version.
5. Capture leadership approval and version the new SoA with a clear migration log.

A short migration log — old control ID, new control ID, rationale for any applicability change, owner, and evidence delta — shortens the surveillance audit conversation significantly.

1. [ ] Confirm SoA fields: applicability, justification, status; add owner, evidence link, review date
2. [ ] Create a General Exclusion Note pattern; reference it per affected control row
3. [ ] Assign each row to a named role; schedule quarterly attestations with reminders
4. [ ] Define change triggers that force an immediate review: systems, vendors, incidents, law or contract changes, audit findings
5. [ ] Capture leadership approval; version the document
6. [ ] Map Annex A controls to DORA, NIS2, and FCA references so evidence serves multiple frameworks
7. [ ] Move from spreadsheet to a platform (such as SureCloud) to keep status, ownership, evidence, and mappings current

Your environment changes continuously. Your SoA should too. A control marked "Implemented" twelve months ago may be "Partially Implemented" today — not because anything went wrong, but because systems, people, and obligations change faster than annual review cycles can capture.

Build a lifecycle around your SoA. Assign ownership that holds. Attach evidence that proves status, not just describes it. Define the triggers that force a review when the environment changes, not just when the calendar says so.

GRC isn't a data problem. It is an execution problem. SureCloud keeps your controls, mappings, and evidence aligned so that when your auditor arrives, the SoA reflects your control environment as it actually is — not as it was when you passed the last audit.

1. UK NCSC Annual Review — UK cyber threat volume data

2. ISO/IEC 27001:2022 — the standard itself
3. DORA (EIOPA) — Digital Operational Resilience Act regulatory guidance
4. NIS2 Directive (ENISA) — NIS2 implementation guidance
5. FCA Operational Resilience — FCA supervisory expectations
6. IAF MD 26:2023 — ISO 27001 transition communiqué