ISO 27001 Statement of Applicability
The Statement of Applicability is the document that sits at the center of ISO 27001 certification. It connects your risk assessment to your control selection, tells auditors exactly what you are and are not implementing, and serves as the primary reference for your ISMS scope during the certification audit.
Companies often underestimate how much auditor attention it gets. Getting it right before Stage 1 saves significant rework.
What the SoA Is
The SoA is a structured document that addresses every control in ISO 27001 Annex A. For each control, it states:
- Whether the control is applicable to your organization (Yes / No)
- If not applicable, the justification for exclusion
- If applicable, the implementation status (implemented, partially implemented, planned)
- A reference to where the evidence or procedure for that control lives
ISO 27001:2022 has 93 Annex A controls organized across four themes:
- 5.x Organizational controls (37 controls): policies, roles, responsibilities, threat intelligence
- 6.x People controls (8 controls): screening, awareness, training, disciplinary process
- 7.x Physical controls (14 controls): physical security, clear desk, equipment maintenance
- 8.x Technological controls (34 controls): access management, encryption, vulnerability management, logging
How the SoA Connects to Your Risk Assessment
The SoA does not exist in isolation. It flows from your risk assessment. The process is:
- Identify your information assets
- Assess threats and vulnerabilities to those assets
- Evaluate risk level per threat
- Select controls to reduce unacceptable risks
- Document selected controls in the SoA with justification
- Document excluded controls with justification
Auditors will trace your control selections back to your risk register. If you have included a control, they want to understand which risk drove that decision. If you have excluded a control, they want to understand why that risk does not apply.
An SoA that lists control selections without a linked risk assessment is a finding.
Which Controls Can Be Excluded
Most SaaS companies exclude some physical security controls that apply only to organizations with data centers, manufacturing facilities, or other physical infrastructure they own and operate.
Common justifiable exclusions for cloud-native SaaS:
- 7.4 Physical security monitoring: if you use a cloud provider and have no physical infrastructure
- 7.5 Protecting against physical and environmental threats: same justification
- 7.6 Working in secure areas: if you are fully remote with no office
- 7.8 Equipment siting and protection: cloud-only organizations do not own servers
What you cannot exclude:
- Any control that addresses a risk your risk assessment identified as unacceptable
- Controls that address your primary threats (for most SaaS: access management, encryption, vulnerability management, incident response)
- Controls that auditors consider baseline for any ISMS (5.1 policies, 6.3 awareness, 8.2 privileged access rights, 8.5 secure authentication)
How Auditors Use the SoA
During Stage 1 of your certification audit, the auditor reviews the SoA to:
- Confirm all 93 controls are addressed
- Verify exclusion justifications are documented and credible
- Identify which controls are implemented vs planned
- Scope Stage 2 testing based on what you claim is implemented
During Stage 2, the auditor tests the implemented controls. If your SoA says a control is implemented but you cannot show evidence, that is a nonconformity. If your SoA marks a control as planned, auditors will ask about the timeline.
The most common SoA findings:
- Controls marked as implemented without supporting evidence
- Exclusions without written justification
- SoA not updated after a significant change to the ISMS scope
- Missing controls (the SoA does not address all 93)
Writing the SoA: Practical Steps
ISO 27001 consultants and certification bodies publish SoA templates. The format is a table. Using a template ensures you do not miss controls.
Do not write the SoA before your risk assessment is done. The SoA is the output of the risk assessment, not a standalone document.
For each applicable control, record where the implementation evidence lives. "See Information Security Policy v2.1 Section 4.3" is better than a blank reference field.
"Not applicable to cloud-native organizations" is better than no justification, but "We do not operate physical data center infrastructure; all computing resources are hosted on AWS. This control is addressed through AWS's SOC 2 report under their shared responsibility model" is what auditors want.
Many companies share a draft SoA with their certification body before Stage 1 to identify gaps. Most CBs will give informal feedback.
Knowing which Annex A controls already have evidence and which still need attention before your certification audit is exactly the visibility a fractional CISO keeps for you. Book a call to see where your SoA stands.
Related reading
- ISO 27001 vs SOC 2: Which Should You Do First?
- ISO 27001 Compliance Checklist for SaaS
- ISO 27001 Annex A Organizational Controls Explained
- ISO 27001 Annex A Technological Controls Explained
- SOC 2 Scope Definition Guide
Want a security leader to run this?
Xorabyte is a fractional CISO for startups who can review your cloud for the gaps found first, so a blocked deal or an audit stops being your problem to carry alone. Book a call and you will leave with a clear path, not a sales pitch.