ISO 27001 Statement of Applicability: A Complete Guide

Introduction

The Statement of Applicability (SoA) is the single most important document in an ISO 27001 implementation. It connects your risk assessment to the controls you implement, documents every decision about which Annex A controls apply to your organization, and serves as the primary reference for certification auditors.

Many organizations underestimate the SoA's importance and produce it as a last-minute tick-box exercise. This is a mistake. A well-constructed SoA is a living management document that drives your control implementation, demonstrates the logic of your ISMS, and simplifies your annual surveillance audits significantly.

What Is the Statement of Applicability?

The SoA is formally required by ISO 27001 Clause 6.1.3(d). It must document all of the 93 controls from ISO 27001:2022 Annex A and for each one record:

Applicability: Whether the control is applicable to your organization (yes or no, with justification for exclusions).

Justification for inclusion: Why the control is applicable — typically linked to a risk in your risk register, a legal/regulatory requirement, or a contractual obligation.

Implementation status: Whether the control is fully implemented, partially implemented, or planned.

How it is implemented: A brief description of the control mechanism (e.g., "Access control is implemented via Active Directory with role-based group membership and quarterly access reviews").

In ISO 27001:2022, no controls can be completely excluded without a documented rationale. The SoA is the formal record of that rationale.

The Three Decisions for Each Control

For each of the 93 Annex A controls, you need to make three decisions:

Decision 1 — Is it applicable? Most controls will be applicable to most organizations. Exclusions must be justified — you cannot exclude a control simply because it is difficult to implement. Valid exclusion reasons include: the risk it addresses doesn't apply to your scope (e.g., physical access controls for a fully remote, cloud-only organization), or the risk is addressed through an alternative control.

Decision 2 — Why is it included? Link each applicable control to at least one driver: a specific risk from your risk register (reference the risk ID), a legal or regulatory requirement (e.g., GDPR Article 32), or a contractual obligation from a customer or partner.

Decision 3 — What is the implementation status? Use a consistent status model: Planned (not yet started), In Progress (partially implemented), and Implemented (fully operational). Your SoA is a snapshot of your current ISMS maturity.

Building Your Statement of Applicability

Step 1 — Start with the risk treatment plan. Every control you have selected in your RTP should appear in the SoA as applicable and linked to the corresponding risk(s).

Step 2 — Add controls from legal/regulatory requirements. Map your GDPR obligations, sector-specific regulations, and contractual security requirements to the appropriate Annex A controls.

Step 3 — Review remaining controls. For controls not yet covered, assess whether they apply. Many controls will naturally apply to any modern organization (e.g., A.8.5 Secure Authentication, A.8.2 Privileged Access Rights, A.5.10 Acceptable Use).

Step 4 — Document exclusions carefully. For any control you exclude, write a clear, defensible justification. Auditors will probe these — "not applicable because we are cloud-based" is not sufficient without explaining which specific risk the control addresses and why that risk doesn't apply.

Step 5 — Get management sign-off. The SoA should be formally approved by senior management, not just the security team.

Common SoA Mistakes That Fail Audits

Generic justifications: Writing "N/A" or "not required" without explanation for excluded controls is a red flag for auditors.

Decoupling from the risk register: Your SoA should directly reference risk IDs. If controls are listed with no link to specific risks, auditors question whether your risk assessment is genuinely driving control selection.

Optimistic status reporting: Marking controls as "implemented" when they are only partially in place. Auditors will verify implementation — if what they find doesn't match the SoA, it is a non-conformity.

Static document: Treating the SoA as a one-time document rather than updating it when new controls are added, the scope changes, or the risk assessment is revised.

Missing implementation evidence link: The best SoAs reference where implementation evidence can be found (e.g., "Access review logs stored in SharePoint/Compliance folder"). This dramatically accelerates surveillance audits.

Keeping the SoA Current

The SoA must be reviewed and updated at a minimum annually, and whenever significant changes occur:

Scope changes: New services, offices, or technologies added to scope require assessment of new controls.

New risks identified: If new risks are added to your register, ensure the SoA reflects the controls selected to treat them.

Control status changes: As you implement new controls or retire old ones, update implementation status promptly.

Audit findings: Non-conformities often point to SoA inaccuracies. Correct both the finding and the SoA simultaneously.

Treat your SoA review as a standing agenda item in your quarterly ISMS management review. A 30-minute review per quarter is far more manageable than a complete reconstruction before each surveillance audit.

Key Takeaways

The Statement of Applicability is the backbone of your ISO 27001 ISMS. It connects risk to controls, demonstrates management decision-making, and guides auditors through your security posture. A high-quality SoA accelerates certification, simplifies surveillance audits, and provides a clear roadmap for ISMS improvement.

Invest the time to do it properly: link every control to specific risks or requirements, document exclusions rigorously, and keep it updated as your ISMS evolves.