Statement of Applicability (SoA) in ISO 27001 Certification

What is a Statement of Applicability (SoA)?

The Statement of Applicability is the document that defines which security controls from Annex A of ISO 27001 apply to your information security management system (ISMS).

The SoA connects three things: your risk assessment, the controls you have selected and the evidence that no relevant control has been overlooked. This makes it one of the first documents auditors typically request – and one that customers often want to see as part of their security questionnaires.

Mandatory SoA requirements under ISO 27001:2022

Clause 6.1.3 d) requires four pieces of information. One additional field is not mandatory under the standard but makes the audit considerably easier.

Overview of the 93 controls in Annex A

ISO 27001:2022 condensed the previous 114 controls across 14 domains into 93 controls organised into four themes.

These 11 controls are new since 2022

1. 5.7 Threat intelligence
2. 5.23 Information security for use of cloud services
3. 5.30 ICT readiness for business continuity
4. 7.4 Physical security monitoring
5. 8.9 Configuration management
6. 8.10 Information deletion
7. 8.11 Data masking
8. 8.12 Data leakage prevention (DLP)
9. 8.16 Monitoring activities
10. 8.23 Web filtering
11. 8.28 Secure coding

These are precisely the controls that are often missing from SoAs copied from outdated 2013 templates.

How to create an SoA in 6 steps

1. Define the scope. Identify the locations, systems, processes and service providers covered by your ISMS – they determine which controls can be relevant in the first place.
2. Assess your risks. Identify assets, threats and vulnerabilities and evaluate them by likelihood and impact. A proven methodology is risk management according to ISO 31000.
3. Plan risk treatment. Define measures for every risk that is not accepted – regardless of their source.
4. Cross-check against Annex A. Go through all 93 controls and check whether a necessary control is missing. Justify each decision with a risk, law or contract.
5. Document status and evidence. Record the implementation status, owners and evidence for each control.
6. Approve and version. Have management approve the SoA and review it whenever the scope changes, after incidents and at least once a year.

Example: what a completed SoA looks like

Fictional example: a SaaS company with 40 employees, operating entirely in the cloud, with no company-owned data centre.

Common mistakes in the SoA

The SoA in the certification audit

In stage 1, the certification body checks whether the SoA is complete and aligned with the risk assessment. In stage 2, auditors take samples: is a control marked as “implemented” actually effective in practice? After certification, the SoA remains the basis for the annual surveillance audits.

Automating and managing your SoA with heyData

At heyData, we support companies throughout their entire journey to ISO 27001 certification – and the Statement of Applicability plays a central role in that process. We don’t just provide a tool to document your SoA – we actively help you build it correctly and continuously adapt it as your ISMS grows.

Our approach ensures that your SoA doesn’t remain a static document but becomes a dynamic reflection of your security strategy.

With heyData, you can:

• Link Annex A controls to your risk assessment and policies.
• Generate your SoA based on your asset and risk registers – with clear traceability and evidence for every control.
• Track implementation progress and assign responsibilities transparently.
• Stay audit-ready with version control and change tracking for every SoA update.
• Integrate continuous improvement by feeding findings from audits and management reviews directly into your SoA.

In short: heyData turns the SoA from a pure compliance requirement into a living management tool that brings governance, risk and security together in one central system.

Take the first step: Book a free demo now