Overview
The Statement of Applicability (SoA) is a mandatory ISO 27001 document that lists all 93 Annex A controls and explains whether each control is included in your ISMS or excluded. For included controls, it describes how they're implemented. For excluded controls, it provides justification for exclusion.
What it means in practice
The SoA is your control selection blueprint - it connects your risk assessment results to the specific security controls you've chosen to implement. Auditors use it as their roadmap to verify your ISMS addresses identified risks appropriately.
Real-world example: Your risk assessment identifies ransomware as a critical threat. Your SoA would show control A.8.7 (Protection against malware) as "Included" with implementation details like "Endpoint detection and response software deployed on all devices with centralized management," while control A.7.4 (Physical security monitoring) might be "Excluded - organization is cloud-only with no physical data center."
Why the SoA matters for ISO 27001
Mandatory requirement
ISO 27001 Clause 6.1.3(d) explicitly requires maintaining "a Statement of Applicability containing the necessary controls and justification for inclusions and exclusions." You cannot achieve certification without a complete, accurate SoA.
Demonstrates risk-based approach
The SoA proves you're not randomly implementing controls or blindly applying templates. It shows how each control decision traces back to your risk assessment.
Audit roadmap
Auditors use your SoA to plan what they'll verify during certification audits. Included controls need evidence of implementation and effectiveness. Exclusions must be justified based on risk assessment or business context.
Change management
As risks evolve, your SoA should update to reflect new control requirements or allow previously excluded controls to be removed if risks decrease.
Common audit finding: SoA justifications that don't align with risk assessment results. For example, excluding backup controls (A.8.13) while your risk assessment identifies data loss as a high risk will result in nonconformity.
What the SoA must include
Complete control listing
All 93 Annex A controls from ISO 27001:2022 must appear in your SoA, organized by theme:
Organizational controls: A.5.1 through A.5.37 (37 controls)
People controls: A.6.1 through A.6.8 (8 controls)
Physical controls: A.7.1 through A.7.14 (14 controls)
Technological controls: A.8.1 through A.8.34 (34 controls)
Inclusion/exclusion status
For each control, clearly state whether it's included in your ISMS or excluded. Avoid ambiguous statuses like "partially applicable" - controls are either in or out.
Implementation description (for included controls)
Briefly describe how you implement each included control. Include:
Specific policies, procedures, or technologies used
Who is responsible for the control
Where evidence of implementation can be found
How the control addresses identified risks
Exclusion justification (for excluded controls)
Explain why excluded controls aren't part of your ISMS. Valid justifications:
Risk-based: "No risks in our assessment require this control"
Context-based: "Not applicable - we are cloud-only with no physical infrastructure"
Legal/regulatory: "Prohibited by data residency laws in our jurisdiction"
Justification quality: Strong exclusion justifications reference specific risk assessment findings or organizational context. Weak justifications like "not relevant" or "not implemented yet" will be challenged by auditors.
SoA structure and format
Tabular format (most common)
A table with columns for:
Control number (e.g., A.5.1)
Control name (e.g., "Policies for information security")
Status (Included / Excluded)
Implementation description or exclusion justification
Risk reference (linking to risk register)
Evidence location (optional but helpful)
Narrative format
Some organizations prefer a narrative document describing control implementation grouped by theme. Less common but acceptable if it clearly addresses all 93 controls.
Tool-based format
GRC platforms and ISMS tools often generate SoAs automatically based on control selection and linking to risk assessments. These still need manual validation for accuracy.
Auditor preference: Most auditors favor tabular SoAs because they're easy to scan and cross-reference. Keep implementation descriptions concise (2-3 sentences per control) - detailed procedures belong in separate procedure documents, not the SoA.
Creating your SoA
Step 1: Complete risk assessment
Your SoA is a direct output of risk assessment. Identify all risks requiring treatment before determining which controls to implement.
Step 2: Map controls to risks
For each risk requiring treatment, identify which Annex A controls would reduce it to acceptable levels. One risk may need multiple controls; one control may address multiple risks.
Step 3: Determine inclusion/exclusion
Controls addressing identified risks are included. Controls not addressing any of your risks can be excluded (with justification).
Step 4: Describe implementation
For included controls, document how you're implementing them. Be specific enough that auditors understand your approach without duplicating entire procedures.
Step 5: Justify exclusions
For excluded controls, explain why based on your risk assessment or organizational context. Reference specific findings from your risk register where possible.
Step 6: Review and approve
Management should formally review and approve the SoA, acknowledging the control selection decisions and any residual risks.
Version control: The SoA is a living document that must be updated when risks change, controls are added or modified, or exclusions are reconsidered. Maintain version history showing when and why changes occurred.
Common SoA mistakes
Excluding too many controls
Organizations sometimes exclude controls to reduce implementation effort. Auditors scrutinize exclusions carefully - if your risk assessment is thorough, most controls should be included.
Generic implementation descriptions
Copying control descriptions from ISO 27002 without describing your actual implementation. Auditors need to understand what you do, not what the standard says.
Missing risk linkages
Failing to connect controls back to specific risks in your risk assessment. This breaks traceability and suggests controls were selected arbitrarily.
Incomplete coverage
Forgetting to address all 93 controls. Even if a control seems obviously not applicable, it must appear in the SoA with exclusion justification.
No review cycle
Creating the SoA once during initial implementation and never updating it despite organizational changes or new risks.
Efficiency tip: Use ISMS Copilot to generate an SoA template with common implementation descriptions for your industry. Customize the output based on your specific risk assessment results and context.
SoA vs. other ISO 27001 documents
SoA vs. Risk Treatment Plan
The Risk Treatment Plan details how you'll implement selected controls (timelines, responsibilities, resources). The SoA declares which controls are implemented and why. The two documents are complementary.
SoA vs. Control Evidence
The SoA describes what controls you implement. Evidence proves the controls are actually operating effectively. During audits, auditors sample controls from your SoA and request corresponding evidence.
SoA vs. Policies and Procedures
Policies and procedures provide detailed instructions for implementing controls. The SoA summarizes at a high level which controls exist and how they work.
How auditors use the SoA
Stage 1 audit (documentation review)
Auditors verify your SoA is complete (all 93 controls addressed), logically structured, and aligned with your risk assessment. They check justifications for exclusions make sense.
Stage 2 audit (implementation verification)
Auditors sample controls from your SoA and request evidence they're implemented as described. They'll test controls across all four themes and organizational areas within scope.
Nonconformity triggers
Common reasons auditors issue nonconformities related to SoA:
Controls marked "included" but not actually implemented
Exclusions without valid justification
SoA doesn't reflect actual risk assessment results
Missing controls (fewer than 93 listed)
Implementation descriptions too vague to verify
Audit preparation: Before certification audit, review every "included" control in your SoA and gather corresponding evidence. If you can't find evidence for a control, either implement it properly or update the SoA to exclude it with justification.
Maintaining the SoA over time
Annual risk assessment updates
When you perform scheduled risk reassessments, review the SoA to determine if control selections remain appropriate. New risks may require previously excluded controls.
Organizational changes
Update the SoA when:
New technology is deployed (may require new technical controls)
Business model changes (e.g., moving to cloud changes physical controls)
Geographic expansion introduces new regulatory requirements
Mergers or acquisitions change risk profile
Incident-triggered reviews
After significant security incidents, review whether existing controls were effective or if additional controls (previously excluded) should be implemented.
Surveillance audits
Auditors will check during annual surveillance audits whether the SoA has been kept current. Evidence of regular review demonstrates your ISMS is active, not abandoned post-certification.
SoA and control customization
Standard allows tailoring
ISO 27001 permits organizations to implement controls differently based on size, complexity, and risk. Your SoA should reflect your specific implementation, not a generic template.
Additional controls beyond Annex A
If your risk assessment identifies risks not adequately addressed by the 93 standard controls, you can implement additional controls. List these in your SoA or a supplementary document.
Proportionality matters
A 10-person startup's implementation of "A.6.3 Information security awareness training" will differ from a 10,000-person enterprise. Both can be compliant if appropriate to context and effective at reducing risk.
Example of proportional implementation: A small cloud-only SaaS company might exclude A.7.1-A.7.14 (physical controls) by justifying "No physical infrastructure - all systems operate in AWS with security managed by cloud provider SOC 2 controls." This is acceptable if their risk assessment reflects the cloud-first architecture.
Related concepts
Annex A Controls - The 93 security controls your SoA must address
Risk Assessment - Process that drives control selection in your SoA
Risk Treatment - Implementing controls identified in your SoA
Control - The security measures you select in your SoA
Getting help
Accelerate SoA creation with ISMS Copilot. Generate customized implementation descriptions, validate your justifications against risk assessment results, and ensure all 93 controls are properly addressed.