I’ve audited ISMSs at companies with ten employees and at companies worth billions.
Open their Statement of Applicability, and you often can’t tell which is which.
Here’s what that looks like. Two companies, both ISO 27001 certified: a 12-person startup and a cloud provider with 40,000 employees. Row A.8.5, Secure authentication, in both SoAs:
Now look at what the two companies actually do. None of this appears in their SoAs:
The startup: everyone logs in with a password and an authenticator app.
The cloud provider: hardware security keys for every administrator, single sign-on with conditional access, phishing-resistant MFA for all staff, and certificate-based authentication between systems.
Both can be exactly right. A 12-person startup doesn’t need what a hyperscaler needs. Different risks, different controls.
But nobody reading the SoA can tell the difference.
What a certificate actually tells you
An ISO 27001 certificate confirms that an organization has established an ISMS that meets the requirements of the standard and is capable of achieving its information security objectives.
That’s it. It doesn’t tell you how secure the organization is, and it was never meant to.
The Statement of Applicability is supposed to fill that gap. It’s the one document that should explain how a company treats its specific risks. When every SoA looks the same, so does every certificate.
How almost every SoA is built
Ctrl+C. Ctrl+V.
A spreadsheet with Annex A copied in, plus three extra columns:
Applicable? (Yes/No)
Status (Implemented/Not implemented)
Justification for inclusion/exclusion
Fill in the columns, done.
Notice something? The standard never asks for an “Applicable” column. It asks you to justify why each control is included, and why any Annex A control is excluded. A Yes/No answers neither.
What ISO 27001 actually asks for
Clause 6.1.3 describes a sequence. The organization has to:
Determine all controls that are necessary to treat its risks.
Compare them with Annex A to make sure no necessary control has been missed.
Produce the SoA: the necessary controls, why they’re included, whether they’re implemented, and why any Annex A controls are excluded.
Your risks and your controls come first. Annex A comes second, as a safety net.
That’s also why you can’t “implement” A.8.5. In essence, it asks you to authenticate securely, in line with your access rules. It doesn’t name a technology, a configuration, or where to apply it, because that depends entirely on your risks. What you implement are specific controls that achieve it.
The structure I recommend instead
Turn the SoA around. Start with your controls, then map them to Annex A:
Three things change:
Every row points to a risk. That’s your justification for inclusion, and it’s specific.
Every control is testable. An auditor, a customer or your own internal auditor can check it.
Annex A does what it was designed for. Any Annex A control that no row maps to needs a justified exclusion. That’s your cross-check.
Try it this week: take the three biggest risks from your risk register. For each one, write down the specific controls you actually run. Then map them to Annex A. If a row in your current SoA can’t be traced back to one of them, you’ve found where to start.
What the copy-paste costs you
Your certificate says what everyone else’s says. A customer can’t tell from your SoA whether you’re the startup or the cloud provider.
Your customers send the questionnaire anyway. Because the SoA doesn’t tell them what you do, they ask a few hundred questions to find out.
The SoA is useless as a tool. It can’t guide your internal audits, bring a new CISO up to speed, or show anyone what your security program actually looks like.
An honest note from the auditor’s chair
Most auditors accept an SoA that’s a copied Annex A. I have too. It usually passes.
But passing the audit isn’t the bar. Organizations that build their SoA the way the standard intends get a document that works for them, not just for the auditor.
This Friday: Why your SoA is not compliant
On Friday, October 16, at 3 PM CEST (9 AM ET), I’m going live on Substack.
We’ll take a typical copy-paste SoA and rebuild it, step by step:
From a risk to a necessary control that you can actually test
How to structure the SoA around your controls and map them back to Annex A
How to write justifications for exclusions that hold up in an audit
What I look at as an auditor when I open an SoA
Bring your own SoA and your questions. There’s a live Q&A at the end. It’s free.
Be the GRC Practitioner AI can’t replace,
— Aron
P.S. What does the justification column in your SoA say for A.8.5? Hit reply and tell me. I read every answer, and the most common ones will make it into Friday’s session.