ISO 27001 Statement of Applicability

What the Statement of Applicability is and why auditors care about it

The Statement of Applicability (SoA) is one of the most important documents in your ISMS. It lists every control from ISO 27001 Annex A and states whether each one applies to your organization - with a justification either way.

Auditors review your SoA closely because it reveals how well you understand your own security risks. A thoughtful SoA shows you have analyzed your organization’s context, assessed risks properly, and selected controls that actually address those risks. A generic one suggests you copied a template without thinking.

The SoA is required by Clause 6.1.3 of the standard. Specifically, it must contain:

• The controls you have selected and why (based on your risk treatment process)
• Whether each selected control is currently implemented
• Any Annex A controls you have excluded and the justification for excluding them

Getting this right matters. A weak SoA is one of the most common reasons organizations struggle during certification audits.

How to select controls - start with risk, not with Annex A

A common mistake is opening Annex A and working through it like a checklist, deciding yes or no for each control in isolation. That approach produces an SoA that looks complete but lacks substance.

Instead, start with your risk assessment results. Your risk assessment and risk treatment process should identify what risks need addressing and what types of controls are appropriate. The SoA then maps those treatment decisions to specific Annex A controls.

Here is how to approach control selection:

Start from your risks. For each risk that needs treatment, identify which Annex A controls help mitigate it. Some risks will map to multiple controls, and some controls will address multiple risks.

Consider your organizational context. A fully remote SaaS company will have very different control priorities than a manufacturing firm. Your context should visibly influence which controls you emphasize.

Factor in legal and contractual obligations. Some controls are effectively mandatory because of regulations like GDPR or contractual requirements from clients who expect SOC 2 alignment.

Be honest about exclusions. You can exclude Annex A controls - the standard allows it. But the justification needs to be genuine. “Not applicable because we assessed the risk as low” is fine. “Not applicable” with no explanation will get flagged by auditors.

Building your SoA step by step

1. Gather your inputs

Before you start writing, collect:

• Risk assessment and risk treatment plan results
• Your ISMS scope document
• Legal, regulatory, and contractual requirements
• Any existing security controls already in place

2. Work through Annex A systematically

ISO 27001:2022 has 93 controls organized into four themes: organizational, people, physical, and technological. For each control, document:

• Applicable or excluded - and why
• Implementation status - fully implemented, partially implemented, or planned
• How it is implemented - a brief reference to the policy, process, or tool that addresses it

3. Write justifications that mean something

This is where most SoAs fall short. Avoid generic justifications like “required for information security.” Instead, tie each decision back to a specific risk or requirement.

Good: “Control A.8.9 (Configuration management) - Applicable. Addresses risk R-14 (misconfigured cloud infrastructure). Implemented via Terraform IaC with automated drift detection.”

Weak: “Control A.8.9 - Applicable. Important for security.”

4. Assign ownership

Every applicable control should have a clear owner - the person responsible for ensuring it stays implemented and effective. This is not just good practice; auditors expect to see accountability.

5. Get leadership sign-off

The SoA needs formal approval from management. This demonstrates leadership commitment to the ISMS and the specific controls chosen. It is not just a formality - leadership should genuinely understand what they are approving.

6. Plan for ongoing reviews

Your SoA is a living document. Review it at least annually during management reviews, and update it when significant changes occur - new systems, new risks, organizational changes, or regulatory shifts.

Common mistakes that auditors flag

From our experience across dozens of implementations, these are the SoA issues that cause the most problems during audits:

• Excluding controls without proper justification. Every exclusion needs a clear, defensible reason tied to your context and risk assessment.
• Including controls that are not actually implemented. Saying a control is “implemented” when it is only partially in place or planned undermines your credibility.
• No link between risks and controls. If an auditor cannot trace from your risk register to your SoA, the connection between your risk assessment and control selection is not clear enough.
• Stale content. An SoA that has not been updated since the initial certification looks like your ISMS is on autopilot.
• Missing ownership. Controls without assigned owners suggest nobody is accountable for maintaining them.

Choosing the right format

The standard does not prescribe a format. Common approaches include:

• Spreadsheet - the most common choice. Simple, filterable, easy to share. Works well for most organizations.
• GRC platform - tools like eramba or Vanta can generate and maintain your SoA automatically from your risk register and control library.
• Wiki or documentation tool - platforms like Notion or Confluence work well for teams that prefer collaborative editing and linking to supporting documents.

Pick whatever format your team will actually maintain. A beautiful SoA that nobody updates is worse than a plain spreadsheet that stays current.

How 27kay can help

The SoA sits at the intersection of risk assessment, control selection, and documentation - getting it right takes both technical knowledge and practical experience. We help organizations build SoAs that satisfy auditors and genuinely reflect their security posture.

Whether you are building your first SoA or updating one for the 2022 version of the standard, let’s talk - we can walk you through the process and review your draft before the auditor does.