ISO 27001 Statement of Applicability

The Statement of Applicability (SoA) is required by clause 6.1.3.d of ISO 27001. It is the central document of your ISMS. Every Annex A control appears in the SoA with one of two states: applied or excluded. For each, the SoA documents the justification.

The SoA serves three audiences:

• Auditors: Verify your control selection traces to risk decisions
• Management: Understand which controls operate in the organization
• Customers and partners: Often request the SoA as part of vendor due diligence

The SoA is one of the most-read documents in the ISMS. Quality matters. A thoughtful SoA signals a mature program. A copy-paste SoA with vague justifications signals a paper compliance project.

Reference the ISO 27001 framework guide for the full Annex A control list to populate your SoA.

The SoA is typically a spreadsheet or table with these columns for each Annex A control:

• Control reference: Annex A identifier (e.g., A.5.1)
• Control name: From Annex A (e.g., "Policies for information security")
• Applicability: Yes (applied) or No (excluded)
• Justification: Why the control is applied or excluded, traced to risk treatment
• Implementation status: Implemented, partially implemented, planned
• Implementation description: Brief description of how the control is operating
• Evidence references: Pointers to evidence artifacts (policy documents, system configurations)
• Risk treatment plan reference: Link to the risk(s) this control treats

Some organizations split the SoA across multiple worksheets (one per theme). Others keep it in one table. Either works as long as the columns are present.

The justification column is what auditors scrutinize most. Strong justifications are concrete and traceable.

Strong applied control justification:

A.8.5 Secure authentication. Applicable. Treats risks R-12 (credential compromise) and R-15 (insider misuse). Implemented through Okta SSO with mandatory MFA for all users, password policy aligned to NIST 800-63B, session timeout at 8 hours.

Weak applied control justification:

A.8.5 Secure authentication. Applicable. Required for security.

Strong excluded control justification:

A.7.4 Physical security monitoring. Excluded. Organization is fully remote with no physical offices, data centers, or storage facilities. Information assets reside in cloud services where physical security is managed by the cloud provider (see vendor due diligence records for cloud provider attestations). No physical environment under our control to monitor.

Weak excluded control justification:

A.7.4 Physical security monitoring. Excluded. Not applicable.

The pattern: applied justifications cite the risk treated and the implementation. Excluded justifications cite the reason the control does not apply and what compensates for its absence.

Common exclusions and their typical justifications:

• Physical controls (A.7.x) for fully remote orgs: No facilities under our control. Compensated by cloud provider physical security.
• A.5.20-21 Supplier relationships subset: If specific supplier types do not exist (e.g., no ICT services in our supply chain), exclude with justification.
• A.7.5 Protecting against physical and environmental threats: Cloud-native organizations exclude with reference to cloud provider responsibilities.
• A.8.30 Outsourced development: Companies that build all software internally exclude with rationale.
• A.8.21 Network services security: For some pure SaaS companies on managed services, this control is implemented through cloud providers and may be excluded with inheritance documentation.

Avoid blanket exclusions. "We do not need this control because we are small" fails. The exclusion must trace to a specific organizational characteristic, not to convenience.

The SoA is a living document. Update it whenever:

• The risk treatment plan changes (new risks, modified treatments)
• Controls are added, modified, or removed
• Implementation status changes (planned to implemented, etc.)
• Evidence references change (new policy documents, new systems)
• The standard updates (e.g., transition from ISO 27001:2013 to 2022 SoA)

Version-control the SoA. Each version should have a date, version number, change summary, and approver. Auditors review the version history to see how the SoA evolves alongside the ISMS.

At minimum, review the entire SoA annually as part of management review. The review confirms exclusions still apply, applied controls still operate, and implementation descriptions still match reality.

Pair SoA updates with risk register updates. If a risk gets treated by a new control, both documents should reflect the change in the same review cycle.