The Statement of Applicability is the document every ISO 27001 auditor turns to first, and the one most businesses get wrong. It's not a checklist you tick and file away. It's supposed to show, control by control, what you've implemented, what you haven't, and why. Get that reasoning right and the rest of your audit gets a lot easier.
What the SoA actually is
ISO 27001 clause 6.1.3 requires you to produce a Statement of Applicability once your risk assessment and risk treatment plan are in place. It lists every control you've decided to apply, states whether it's implemented, and justifies why it's there — or why it isn't, if you've excluded a control from Annex A. Annex A currently sets out 93 controls across four themes: organisational, people, physical and technological. The SoA is where you map your actual risk treatment decisions back to that list, control by control, with reasoning an auditor can follow line by line.
Why "implemented" isn't enough
Businesses often treat the SoA as a box-ticking exercise — mark each control yes or no and move on. That misses the point entirely. Auditors want to see the reasoning behind each decision, not just the outcome. If you've marked a control as implemented, you need evidence it's actually operating, not just a policy document sitting in a folder. If you've excluded one, the justification has to be rooted in your risk assessment, not "we don't think it applies to us." I've seen SoAs picked apart at Stage 2 because the justification column had clearly been copied from a template and never adapted to the business in front of the auditor.
Keeping it aligned with your risk treatment plan
The SoA and your risk treatment plan have to tell the same story. If your risk assessment flags a threat around remote access and your treatment plan commits to multi-factor authentication, the SoA needs to show that control as implemented, with a justification tied back to that specific risk. When the two documents drift apart — which happens as businesses grow, add new systems, or bring on new suppliers — auditors notice immediately, usually within the first hour of Stage 2. Review the SoA every time your risk assessment changes, not just once a year in the run-up to recertification.
Common gaps that catch businesses out
The most frequent finding I see is an SoA that hasn't been touched since implementation, sitting alongside a business that's since added cloud services, new remote workers, or a new supplier chain. Another common gap: controls marked "implemented" with no linked evidence — no policy, no log, no record an auditor can actually sample. And a subtler one: exclusions justified by cost or inconvenience rather than genuine risk-based reasoning, which auditors will challenge every time they see it. None of these are exotic problems. They're basic housekeeping that gets skipped because the SoA feels like a one-off exercise instead of a living document that should move with the business.
Who should own it
The SoA shouldn't sit solely with whoever led your original implementation, especially if that was an external consultant who's long gone. Someone inside the business — usually your information security lead or management representative — needs to own it, understand every line, and update it as risks and systems change. If nobody in the room can explain why a particular control is excluded, that's the finding waiting to happen, not the paperwork gap itself.
Treat the Statement of Applicability as a working record of your risk decisions, not a form you complete once and forget. Review it whenever your risk assessment changes, keep the justification for every control specific to your business, and make sure evidence exists for everything marked implemented. Do that consistently and the SoA stops being an audit risk and starts being what it's meant to be — proof that you actually understand your own security posture.
Ready to talk about your business?
Book a free, no-obligation call. We will tell you exactly what certification would involve for your size, sector, and starting point.