Contents:
Two businesses can both tell you they’re ISO 27001 certified. One has certified everything it does. The other has only covered a narrow slice of it.
So, what does the badge actually prove? After my chat with Simon Green, I think the honest answer is that it depends on the scope.
Why Simon puts scope first
Simon has spent a lifetime in governance and assurance. He was a lead auditor at LRQA and head of information security for a global SaaS provider.
When he talks about taking on ISO 27001, scope is one of the first steps he names. He calls it “a critical part of your certification”, and he believes not many people realise that.
What a scope covers
A certification doesn’t automatically apply to the whole company. The business chooses what goes in, whether that’s particular services, teams, locations, or types of information. The certificate then vouches for that scope and nothing outside it.
Simon describes ISO 27001 as being about the risk to a business’s information.
Whether that’s your client’s information, your business critical information, source code, employee data, wherever it’s written down on a bit of paper, on a pen drive, on your desktop, in the cloud, wherever it’s sat, it’s about the risk to that information.
But a scope can cover all of that or only part of it, and the line decides which information gets the attention.
Scope is a choice, which is why it varies so much
Simon doesn’t treat the choice of framework as a maturity ladder. For him it’s a commercial one. In the UK and Europe, he says tenders very often ask for ISO 27001, and NHS contracts usually want it alongside Cyber Essentials Plus as a minimum.
Simon’s advice is to look at the contracts you want to win over the next six, 12, and 18 months, and let those tell you what to certify against.
Once the contract has picked the framework, the next job is scope. Simon says the first steps are your timeframe and what you’re going to certify against, and he calls it “foundation work”.
In other words, someone decides where the line goes, and they decide it before the certification work begins.
So, a narrow scope is a choice, not an accident.
It isn’t automatically a bad one, but it does mean the certificate covers less than the headline suggests. What matters is whether the line sits around the thing you’re relying on.
How to check a vendor’s certificate in five minutes
The scope statement is shorter than you’d expect, often a line or a paragraph, and it sits on the certificate itself.
Ask the vendor for a copy and read that line before anything else.
A good one names what’s covered, usually the products or services, and sometimes the locations or teams.
Be wary of wording so broad that it doesn’t say what’s covered, like “the entire business”.
There are two main questions you need to ask:
- Is the service you’re buying inside it?
- Is the information you’ll hand over inside it?
If both are, a narrow scope is doing its job. If either is outside, the certificate says nothing about it.
Say you’re choosing a backup provider, and their certificate covers the data centre where your backups will sit and the team that runs it. That’s a narrow scope, but it covers exactly what you’re buying.
Now say the same certificate covers only the provider’s head office IT, and your backups run on a platform that isn’t mentioned. Same badge, and it tells you nothing about your data.
Check who issued it, and whether it’s current
Once you’ve read the scope, check the certificate itself. In the UK, UKAS CertCheck is the place to do it.
UKAS is the national accreditation body, so it checks the certification bodies, the firms that audit businesses and issue ISO 27001 certificates. CertCheck is a free, public database of certificates issued by those accredited bodies.
Search by company name or certificate number, and you’ll see the scope, the date issued, the locations covered, and the certification body that awarded it.
That tells you who issued the certificate and whether it’s current. It also lets you compare the scope on the database with the one on the document you were sent.
It has limits. CertCheck only lists certificates from UKAS accredited bodies. A missing entry means the certificate isn’t currently UKAS accredited, but it doesn’t prove the business has no certificate at all. There are other accreditation bodies that could have issued it.
Also, CertCheck shows you the scope, but it can’t tell you whether that scope covers what you’re buying. That’s still your call.
Your clients will read your scope too
The same habit applies to you. If your clients check certificates, they’ll hold your scope up against the services you sell them.
MSP finance specialist Heather MacDonald Alford told me once that she was very strict about security certification when choosing suppliers.
I moved MSPs because I wanted to look at my supply chain. I wanted to ensure that every vendor in my supply chain had a security certification. Some didn’t so they got shipped out and moved so that my stack was as secure as possible.
Heather MacDonald Alford, owner of Counting Creators
So, read your own scope the way a client would. Does it cover the services you actually deliver?
If a contract asks you for ISO 27001, assume somebody will read the scope line. That’s the argument for settling scope early, which is exactly where Simon puts it.
Ask “for what?”
The next time someone tells you they’re certified, ask what for. It’s a short question, and the answer tells you what the badge is worth.
You can find Simon Green on LinkedIn, and find out more about Sentinel42, the app he built to help businesses run their management system with limited interaction on their part.
If you liked this article, follow us on LinkedIn, Reddit, X, Facebook, and Youtube.
