What Is the ISO 27001 Statement of Applicability? CISOGenie's Guide to Writing One That Passes Audit
The SoA is the document auditors reach for first. A weak one produces non-conformities, delays certification, and gets rewritten under time pressure. CISOGenie keeps your SoA connected to your risk register and control evidence so it reflects operational reality — not a point-in-time drafting exercise.
Summarize and analyze this content with:
Executive Summary
The ISO 27001 Statement of Applicability (SoA) is a mandatory document required under Clause 6.1.3(d) of ISO/IEC 27001:2022. It lists all 93 Annex A controls, declares each as applicable or not applicable, and gives justified reasons for inclusions and exclusions. It's also the document auditors reach for first during certification and surveillance audits, and the one most likely to generate non-conformities: justifications that are thin, exclusions nobody can really defend, a document that hasn't been touched since the last cycle. CISOGenie's Risk-Led Security Management Platform keeps the SoA connected to the risk register, Annex A control evidence, and policy documentation, so it reflects what's actually happening at every audit, not just what was true the day it was first written.
Understanding the ISO 27001 Statement of Applicability
The Statement of Applicability is a mandatory document under Clause 6.1.3(d) of ISO/IEC 27001:2022. It lists all 93 controls from Annex A, declares each as applicable or not applicable to the organization's ISMS, explains why applicable controls have been selected, and justifies any exclusions.
That last part, the justification, is where most SoAs run into trouble. Listing a control as "not applicable, low risk" without tying that exclusion to a specific risk assessment finding isn't really a justification. It's a placeholder. Auditors know the difference, and they'll ask about it.
Think of the SoA as the bridge between the risk treatment plan and the control environment you've actually built. The risk treatment plan documents which risks were identified and how they're being addressed. The SoA documents which Annex A controls are in scope for that treatment, and why. If the two don't line up, auditors will find the gap. And if the SoA lists controls that aren't actually implemented, control testing tends to surface that too.
The hard part of the SoA usually isn't writing it the first time. It's keeping it current. A control that made sense at certification might stop applying after a system migration, or after the organization's risk appetite shifts. New controls need to show up before the next audit, not after. An SoA that gets reviewed whenever the risk register changes and re-approved by management before each audit cycle is a fundamentally different document from one that was correct once, at certification, and hasn't been looked at since.
What the ISO 27001 SoA Must Include
The five areas auditors evaluate for completeness, justified reasoning, and factual presentation.
All 93 Annex A Controls — Listed and Addressed
Every control in Annex A has to appear in the SoA, including the ones the organization has decided are not applicable. Simply leaving out controls you don't implement doesn't satisfy the standard. Every control needs a status and a reason attached to it. The 93 controls sit across four themes: Organizational (A.5, 37 controls), People (A.6, 8 controls), Physical (A.7, 14 controls), and Technological (A.8, 34 controls).
Applicability Determination with Justified Reasons
For each control, the SoA has to say whether it's applicable and why. For applicable controls, the justification should point back to the risk treatment decision that led to its selection. For excluded ones, it needs to explain why the control genuinely isn't relevant, not just assert that the risk is low without showing the work.
Implementation Status for Each Applicable Control
For controls declared applicable, the SoA should record implementation status: fully implemented, partially implemented, or planned. This gives auditors a starting point for control testing. Controls marked "implemented" that can't actually be evidenced during testing create findings, and so do controls marked "planned" with no task or timeline behind them.
Reference to Evidence and Policy Documentation
An SoA that points auditors to specific policies, procedures, and evidence sources is significantly easier to audit than one that makes claims without references. When the auditor reads that a control is implemented, they should be able to follow a reference to the relevant policy and evidence of its operation.
Management Review and Approval
The SoA needs to reflect current organizational decisions, which means management has to review and approve it before each certification or surveillance audit. This feeds the Clause 9.3 management review evidence trail. An SoA that was signed off at initial certification and never formally re-approved doesn't show active ISMS governance, no matter how good the document originally was.
Five Reasons SoAs Fail Audits
The most consistently cited non-conformity patterns in ISO 27001 certification audits.
01. Exclusion justifications that don't hold up
Weak, unsupported exclusions
Excluding a control requires a credible reason grounded in the risk assessment, not a generic "not applicable to our business." Auditors test exclusions by asking what the organization's exposure would be if that control weren't in place.
Audit Impact: Weak or unsupported exclusions mean rework before certification can proceed.
02. Inconsistency with the risk treatment plan
SoA and treatment plan don't align
When the SoA and the risk treatment plan contradict each other — controls selected in one that don't appear in the other — auditors have a non-conformity that must be resolved before certification proceeds.
Audit Impact: A mismatch here is a non-conformity regardless of how well individual controls are implemented.
03. Implementation status that doesn't match reality
Claims without evidence
Marking controls as "implemented" without evidence is the most direct path to an audit finding.
Audit Impact: Overstating implementation makes the audit harder, not easier.
04. A document that hasn't been updated since initial certification
Stale since day one
New infrastructure, personnel changes, and new risks all potentially affect SoA entries between audit cycles.
Audit Impact: As ISMS scope expands, the SoA has to expand with it, or auditors will surface the gap.
05. Missing or undocumented management approval
No governance sign-off
An SoA that hasn't been formally reviewed and re-approved since the last audit cycle doesn't demonstrate active ISMS governance at the leadership level.
Audit Impact: An SoA without documented review doesn't demonstrate active governance.
Why CISOGenie — An SoA That Stays Current
Writing the SoA is really the easy part. What's hard is keeping three underlying records current all year: the risk register, control implementation status, and policy documentation. When those are maintained continuously instead of assembled the week before the audit, the SoA ends up reflecting how the organization actually operates, not a snapshot reconstructed under deadline pressure.
CISOGenie keeps all three current by design. Risk Management holds the risk register and the treatment decisions that justify every SoA entry. Gap Assessment tracks implementation status against all 93 Annex A controls in real time. Policy Management keeps ISMS policies aligned to the controls they support, so nothing drifts out of sync between audits.
In practice, that means the SoA stops being a compliance form assembled under pressure and becomes a governance document that actually represents how the organization manages information security risk.
See how CISOGenie handles multi-framework compliance.
How It Works
Discover
Gap Assessment maps current control posture against all 93 Annex A controls, producing the evidential basis for every inclusion and exclusion decision before a single SoA entry is drafted.
Impact Metrics
Initial Audit Readiness
4–5 weeks to initial ISO 27001 audit readiness with pre-structured documentation.
Manual Effort Reduced
Reduction in manual effort on gap tracking and SoA updates.
Continuous SoA Accuracy
Updated automatically whenever the risk register or control set changes.
One Control Map
One control map for ISO 27001, SOC 2, GDPR, DPDPA, and 40+ frameworks.
Perfect For
Key Risks You Can't Ignore
Non-conformity on exclusion justifications
This is the most common SoA audit finding. Weak or unsupported exclusions mean rework before certification can proceed.
Inconsistency with the risk treatment plan
A mismatch here is a non-conformity regardless of how well individual controls are implemented.
Stale implementation status
Overstating implementation makes the audit harder, not easier.
Missing management approval
An SoA without documented review doesn't demonstrate active governance.
Scope drift without SoA updates
As ISMS scope expands, the SoA has to expand with it, or auditors will surface the gap.
What Makes CISOGenie Different
Less dependency on consultants
The document updates from a live control record instead of a paid re-drafting exercise before every audit.
Built by CISOs
Control mapping and gap assessment are built to support defensible SoA entries, not generic ones.
Fast go-live
Customers are in production within 4–5 weeks.
Continuous SoA accuracy
Risk register updates and control changes feed into the SoA record continuously.
Full data sovereignty
Your ISMS documentation and control evidence never leave your perimeter.
OSCAL-powered, multi-framework
Map once and Annex A controls contribute automatically to SOC 2, GDPR, DPDPA, ISO 42001, and 30+ other frameworks.
Platform plus expertise
GRC professionals with ISO 27001 experience support SoA structure and exclusion-justification review.