A Badge Is a Receipt, Not a Reference: What UK Software Buyers Should Actually Check

Somewhere along the way, UK software procurement quietly turned a certificate into a personality trait. You see it in the tender response: a vendor lists ISO 27001, Cyber Essentials Plus and SOC 2 Type II across the top of the page, the buyer ticks a box, and everyone moves on to haggling about seat count. The paperwork gets filed. The questions never get asked.

That is a problem, and not because the standards are bad. It is a problem because a badge answers a much narrower question than the one most buyers think they are asking.

What the certificate is actually attesting to

Take ISO 27001. It certifies that an organisation runs a management system for information security: a defined scope, a risk register, documented controls, internal audits and a review cycle. That is genuinely hard work, and it catches sloppy operations. But the standard asks whether you have a system, not whether the system is any good. A company can hold a perfectly valid certificate while treating your data as an afterthought, provided they wrote that attitude down and reviewed it last quarter.

SOC 2 is different again. It is an attestation from an auditor covering a period of time, measured against criteria the service organisation chooses. It is a report, not a rubber stamp, and the useful part is usually the exceptions section rather than the cover page.

Cyber Essentials is a baseline: five technical controls, self-assessed or verified, and honestly a sensible starting point for any small UK firm. It is also a floor. Nobody has ever stopped a breach by displaying the badge.

The common thread is this. A certificate proves that somebody wrote things down and somebody else checked. It does not prove the product is secure, that the team holds up under pressure, or that your data survives a bad week.

The gap between the document and a Friday afternoon

Incidents do not respect the ISMS. They land when the on-call engineer is at a wedding, the status page is broken, and the person who understands the architecture handed in their notice last week. A certificate says nothing about that. What tells you more is whether a vendor can describe their last real incident without reaching for marketing language.

So ask. Ask what happened, how they found out, how long containment took, and who was told. Under UK GDPR, a personal data breach that poses a risk to individuals generally has to reach the ICO within 72 hours of the controller becoming aware. If a vendor goes quiet the moment timelines come up, that silence is your answer.

Four questions that do more work than a PDF

1. What does your incident response actually look like? Not the runbook — the practice. Who declares an incident? Who can pull the plug on production? How are customers informed, and what is the contractual notification window? Anything longer than 72 hours for a processor notifying a controller needs an explanation, not a shrug.

2. Where does our data sit, and where does it travel? At rest, in backups, in logs, in the analytics pipeline, and in whatever AI feature got bolted on last quarter. Then ask about transfers. UK GDPR still expects a lawful mechanism for moving personal data outside the UK, which in practice means an IDTA or the UK Addendum to the EU standard clauses. A vendor who cannot name the region of their primary database is not being coy — they probably do not know.

3. Who else touches it? Subprocessors are where most of the real risk lives. Get the current list, ask how you will be notified when it changes, and check whether you hold a genuine right to object rather than a polite notification email. Flow-down obligations matter too: if your customer contract promises deletion within 30 days, the vendor's own suppliers need to be held to something compatible.

4. What does leaving look like? The question nobody asks until it is expensive. What format does the export take? How long until deletion? Is there transition assistance? What happens to backups, and what does any of it cost? Exit terms are a surprisingly good proxy for how a vendor thinks about customers in general.

Red flags worth naming

• The claim is 'ISO compliant'. Certification has a scope, a certification body and an expiry date. Ask for the certificate and read the scope — group certificates that do not cover the entity you are actually contracting with are more common than you would like.
• The certification body is not accredited. In the UK you can check against UKAS-accredited bodies, and the IAF CertSearch database answers most of the rest.
• Subprocessor disclosure is refused on the grounds of commercial confidentiality. It is not confidential. It is a list of companies.
• Penetration test summaries are mentioned but never shared.
• The security questionnaire is answered by sales, with no engineer on the call.

A routine that fits a small team

You do not need a procurement department. You need a one-page questionnaire, a folder and twenty minutes. Ask every new vendor the same ten questions, keep the answers, and diarise a review twelve months out. For anything touching customer personal data or payment flows, insist that the security schedule in the contract matches what the sales deck promised — because that is the version a lawyer can actually use.

None of this means ignoring certificates. They are a useful filter that removes a chunk of obviously unserious vendors, and for a small UK business chasing public sector work, Cyber Essentials is often table stakes. Just do not let the logo end the conversation.

The seal on the certificate is a stamp. The software is the thing you are buying. Spend your time on the thing.