The Statement of Applicability mistakes auditors notice fast
The SoA is the map between your controls and reality. Auditors read it first and use it to decide where to dig. These are the mistakes that invite exactly the wrong kind of attention.
By Kellwick Team · June 3, 2026 · 2 min read
The Statement of Applicability is one of the most revealing documents in your ISMS. It lists every Annex A control, says whether it applies, and justifies the decision. Auditors read it early because it tells them two things at once: what you claim to have, and how carefully you thought about it.
A weak SoA does not just cost you a finding on the SoA itself. It signals where to dig for more.
Mistake 1: Marking everything applicable and implemented
It looks safe to mark every control "applicable, implemented". It is the opposite. Now you have committed to demonstrating every single control, and any one you cannot evidence becomes a nonconformity. A thoughtful SoA excludes what genuinely does not apply, with a real reason - and stands behind what remains.
Mistake 2: Justifications that are obviously templated
"This control is applicable because it supports information security." That sentence, repeated across dozens of controls, tells an auditor you copied a template and did not think. Justifications should reference your actual environment: your cloud, your data, your processes.
Mistake 3: Exclusions that do not hold up
Excluding a control is fine - if the reason is real. Excluding physical security controls because "we are cloud-native" can be reasonable; excluding supplier controls because "we do not really use vendors" while running on a dozen SaaS tools is not. Auditors probe exclusions precisely because that is where teams hide gaps.
Mistake 4: The SoA does not match the risk assessment
The SoA should follow from your risk assessment. When a control is applicable but the risk register never mentions the risk it addresses - or vice versa - the two documents contradict each other. Auditors read them together, and inconsistency reads as a system that was assembled, not reasoned.
Mistake 5: The SoA does not match reality
The most damaging mistake: the SoA says a control is implemented, and the evidence says otherwise. Marked "quarterly access reviews implemented", but there is no Q2 record. Marked "supplier assessments in place", but no assessments exist. This turns a documentation review into a credibility problem for the whole ISMS.
How to get it right
- Start from the risk assessment, not the control list.
- Decide applicability honestly, and exclude with real, specific reasons.
- Write justifications that could only be about your company.
- For every "implemented", confirm you can produce the evidence today.
- Reconcile the SoA, the risk register and the actual evidence so all three agree.
Bottom line
The SoA is a map. If the map does not match the territory, the auditor stops trusting the map - and starts checking everything. Get it honest and consistent, and it becomes what it should be: a confident summary of an ISMS that holds together. If you want a second read before the auditor's, that is exactly what an SoA review is for.
Need a second pair of eyes before the auditor does?
A readiness review shows exactly where your ISMS stands - and what to fix first - while there is still time to act on it.