8. July 2026

ISO 27001 does not stop breaches. That was never its job.

Certified organisations get breached all the time. The useful question is not why the standard failed them — it is whether they were ever really doing what the certificate says they were.

Every few months a familiar headline comes round. A company with a valid ISO 27001 certificate on its website discloses a breach — customer records exposed, a supplier compromised, a known vulnerability left unpatched for months. And every time, the same quiet thought travels through the profession: well, so much for the certificate. If the gold standard of information security cannot keep the attackers out, what exactly is everyone paying for?

It is a fair question, asked in bad faith about half the time. Let me try to answer it in good faith.

Start with the uncomfortable fact and do not flinch from it. Certification does not confer immunity, and it never promised to. Some of the most heavily audited organisations in the world have been breached while holding a current certificate — through a flaw everyone already knew about, through a third party nobody was really watching, through the ordinary distance between a control that exists on paper and a control that works at two in the morning when the person who understood it has long since left. A certificate is not a shield. Anyone who sold it to you as one oversold it.

But "ISO 27001 does not prevent breaches, therefore it is theatre" is exactly as lazy as "we are certified, therefore we are secure." Both mistake the certificate for the thing it is meant to point at. The standard was never a promise that nothing bad would happen. It is a management system: a disciplined way of deciding, consistently, what your risks actually are and what you intend to do about each one — and, when something does go wrong anyway, a way of containing it and recovering faster than an organisation flying blind. Measured against that, and run properly, it earns its place. It lowers the odds. It sharpens the response. What it does not do, and was never built to do, is make you the one company an adversary cannot touch.

So where does the theatre come from? Not from the standard. From the gap between how it is audited and how it is lived.

An audit is a sample, taken at a moment. The auditor arrives on a date you knew about, examines a selection of evidence, and confirms that policies exist, are approved, carry the right version history and appear to be followed. That is a sensible way to check that a management system is present and running. It is a poor way to prove that every control will hold against a motivated attacker on an unannounced Tuesday. The auditor samples your paperwork; the attacker tests your entire estate, continuously, on the days when nobody is looking. Those are not the same examination, and passing the first has never guaranteed surviving the second.

Then there is the quieter manoeuvre, the one that rarely reaches the headlines. Draw the boundary of the management system tightly enough and you can hold a perfectly genuine certificate that covers very little of what truly matters. Commit, on paper, to controls that nobody has the time or the intention to operate. Write the policy, log the training, generate the artefact — and leave the real exposure precisely where it was. None of this breaks a single rule. All of it produces a certificate describing an organisation that does not quite exist. That is where the theatre lives: not in the standard, but in the decision to perform compliance instead of practising security.

Which is the honest answer to "so why are we doing it?" We are doing it because a well-run information security management system remains one of the better methods yet devised for making deliberate, defensible decisions about risk, and for being less lost than we otherwise would be when the alarm goes off. We are not doing it to obtain a certificate that grants permission to stop thinking. The certificate is evidence that, on one day, a sample of the work looked right. Whether the work is real — whether the controls are decisions that people genuinely make, or boxes that someone learned to tick the week before the audit — is a question the certificate cannot answer, and a sampling audit frequently will not. That gap is not a defect in ISO 27001. It is the space in which an organisation quietly chooses what kind of security it actually wants.

So when a certified company is breached, the worthwhile response is not to sneer at the standard. It is to ask which of two very different things was happening. Did a genuinely well-run system meet a genuinely determined adversary and lose, as occasionally happens to everyone? Or did the certificate paper over a business that had been performing security for years without ever practising it? From the outside those two failures look identical — same certificate, same breach notice — and underneath they could hardly be more different. Telling them apart is most of the work, and almost none of it happens on the day the auditor visits.

That, in the end, is the question worth paying someone to ask plainly: not "are we certified?" but "would our controls survive contact with a real incident, or only with an auditor?" It is not a comfortable question, and it is not answered by a neater binder. It is the kind of thing we help organisations look at squarely — while the choice is still theirs to make, and not an attacker's to make for them.