Your Provider Passed the Audit. Did Your Workload?

There's a moment in a lot of UK cloud procurements where the sales deck reaches a slide full of badges — Cyber Essentials, Cyber Essentials Plus, ISO 27001, maybe a SOC 2 report for good measure — and the room relaxes. The logos look like a finished argument. Audit done, box ticked, risk handled.

Except the badges don't say what the room thinks they say. They describe the provider's own housekeeping at a point in time, within a scope the provider itself has defined. They do not describe the workloads you've built on top of that provider, the way your team has configured them, or whether your data is actually handled the way your board assumes.

That's not a reason to ignore certificates. It's a reason to read them properly.

What the badges actually attest to

Cyber Essentials is a UK scheme backed by the NCSC. At its base level it's a self-assessed set of five technical controls; Cyber Essentials Plus adds independent technical verification. It's a useful signal that an organisation has thought about patching, firewalls, access control, malware and secure configuration. But the assessment covers a defined scope — and in a cloud provider's case that scope is often corporate IT, not the platform you're renting.

ISO 27001 is different again. It certifies an information security management system for a defined scope. That's a mouthful, and the important word is scope. The certificate names a legal entity, a set of sites, and a statement of what's covered. It is not a guarantee that every product in the portfolio is equally well run, nor that every region and service you use sits inside the audit boundary.

In other words: the badge is a claim about a perimeter. Your job is to find out whether your workload lives inside it.

The shared-responsibility line, in plain English

Every cloud contract has one, even if it's buried in an addendum. The provider secures the physical buildings, the hardware, the hypervisor, the core network — the stuff you'll never touch. You secure identities, permissions, configurations, data classification, logging, and the way your applications behave.

A certificate tells you the provider has done its half. It tells you nothing about yours. The most common cloud incidents UK teams see — public storage buckets, over-permissive roles, unpatched containers, keys in a repo — sit firmly on the customer side of that line. Your provider can be immaculately certified and your workload can still be a mess.

This is where the logo stops being useful. It's not a transfer of risk. It's a data point.

Where the certificate runs out of road

Three places, mainly.

First, regulators and auditors increasingly ask you to demonstrate control over your own data. Waving a vendor certificate is not a control. It's evidence of a supplier's maturity, which is helpful context, but it doesn't answer the question 'how do you know who accessed this dataset last Tuesday?'

Second, certificates have dates. ISO 27001 runs on a three-year cycle with surveillance audits, and a certificate can be suspended. Cyber Essentials is annual. A PDF from 2023 in a procurement pack is not current assurance; it's a historical document. Ask for the current status letter.

Third, group structure gets messy. The entity that holds the certificate may not be the entity you contract with, and the data centre you're using may sit in a different legal entity entirely. That's not necessarily sinister, but it matters when you're mapping accountability.

Seven questions worth asking before you renew

None of these are gotchas. They're the questions a competent supplier should be able to answer without breaking a sweat.

1. Which legal entity holds the certificate? Compare it to the entity on your order form.
2. What is the scope, in the certificate's own words? Ask for the scope statement, not a summary slide.
3. Does the scope include the service and region we actually use? If you're on a newer product line, it may sit outside the audit boundary.
4. When was the last assessment, and are there open findings? A good supplier will tell you the date and whether anything is outstanding.
5. Can we see a summary of the Statement of Applicability, or a penetration test summary, under NDA? You don't need the full document; you need enough to judge.
6. Who owns which control? Ask for the shared-responsibility matrix in writing, mapped to the services you buy.
7. What changes at renewal? Scope, price, evidence rights — get the answer before the commercial conversation closes.

What a good answer sounds like

Specific. Dated. Written down. It names a person and a document. It says 'here is the scope, here is the certificate number, here is our last assessment date, and here is what we need from you.'

A weak answer sounds like 'we're fully certified' followed by a logo-laden PDF and a change of subject. That's logo theatre. It's not malice — plenty of sales teams genuinely believe the badge is the whole story. But you're the buyer, and you're allowed to ask for the rest of it.

Put the split in the contract

If there's one practical move from all this, it's to stop treating the shared-responsibility model as a diagram in a slide deck and start treating it as a contract schedule. Attach the matrix. Name the controls. Agree how material changes get notified — a new region, a new sub-processor, a change in certification status. Add a right to request current evidence at renewal. None of this is exotic; it's just procurement doing its job.

Badges are useful shorthand for a shortlist. They are a terrible substitute for a conclusion. Use them to decide who gets a second meeting, then do the unglamorous work of finding out what the certificate actually covers — and what your team still owns.