The Continuity Plan Nobody Opens
In July 2024, the fix shipped in hours and recovery still took days, because a plan written for the auditor does not survive first contact with a crisis. A plan is not a capability.
This is Part 5 of "The Corporate Security Gap", a series on why companies have security on paper but not as a function. Part 1: The Function That Never Got a Seat. Part 2: The Cost Center That Cannot Count. Part 3: Security Built in Silos. Part 4: The Door You Did Not Lock.
Picture the first hours of a real crisis, in a company that did everything right on paper. The systems are down. Somewhere on a shared drive sits the business continuity plan, two hundred pages, approved by the board, refreshed for last year’s certification audit. Nobody opens it. Not out of negligence, but because the person who knows where it lives is on leave, the scenario it describes is not the one unfolding, the contact list in Annex C is two reorganisations old, and the first hour of a crisis is spent doing, not reading. The plan exists. The capability it was supposed to describe does not. And the company discovers, in the worst possible classroom, that those were never the same thing.
This is the fifth article in this series, and it completes a movement the previous two began. Part 3 showed that an attack crosses the seams between internal silos; Part 4 showed that it walks in through suppliers’ doors. Both of those are about how the hit arrives. This article is about what happens after it lands, because at that point protection has already failed by definition, and the only thing that matters is a different property altogether: the capacity to absorb the blow, adapt around it, and recover. The governance gap here is the same one this series keeps finding, in its purest form yet. The board sees a certificate on the wall, a plan in the register, a tick in the continuity box. What the company actually has, or does not have, is a capability. Security without governance is just guarding, and a continuity certificate without capability is just filing.
A document is not a property of the organisation
Be precise about the two things being confused. A continuity plan is a document: a description of roles, procedures, and recovery steps, written at a point in time, for a set of imagined scenarios. Resilience is a property of the organisation itself: the ability to take an unplanned hit and keep functioning, which lives in how the architecture is built, how decision rights are distributed, and what people know how to do without looking anything up. The standards themselves draw this line. ISO 22301 can certify a business continuity management system: it is auditable, because it describes a documented process. ISO 22316 points at organisational resilience as a broader capacity, and it is conspicuously not a certification standard, because the thing it describes is only proven under load.
That distinction explains an uncomfortable fact: certification measures the existence and maintenance of a process, not the presence of a capability. An auditor can verify that the plan exists, that it was reviewed, that an exercise was held and minuted. An auditor cannot verify that the organisation will actually absorb a real hit, any more than a framed gym membership can verify fitness. The certificate is honest about what it certifies. The governance failure is in how it gets read upstream: somewhere between the audit report and the board pack, “we have a certified process” quietly becomes “we are resilient”, and those are different claims.
Why plans do not become capability
Four mechanisms, each common enough to be the default.
First, the plan is written for the wrong reader. Audit-driven continuity planning optimises for the person who will assess the document, not the person who will use it at 3 a.m. So it is comprehensive where it should be terse, generic where it should be specific to this building and these people, and current as of the last audit cycle rather than the last reorganisation. A document optimised for compliance review is, almost by construction, pessimised for crisis use.
Second, the scenarios are linear and the crisis is not. Plans are built scenario by scenario: fire, flood, cyber incident, supplier failure, each with its own chapter. Real incidents, as Part 3 argued about internal seams and Part 4 about vendor doors, are convergent: one event is simultaneously a cyber failure, an operational stoppage, and a communications crisis, and it did not read the chapter structure. A plan organised by cause meets a crisis organised by consequence, and the mapping between them has to be improvised at the worst moment to improvise anything.
Third, the testing is theatre. The standard exercise regime, an annual tabletop, a conference room, coffee, a facilitator reading injects from a script, validates that people can discuss a crisis, not that the organisation can survive one. Nobody’s laptop is actually dead. No customer is actually calling. The exercise tests the plan against the plan. The one thing it cannot test is the plan against reality, which is the only test that will ever matter.
Fourth, and most fundamentally: real resilience lives somewhere else. It lives in architecture, redundant systems, distributed operations, manual fallbacks that are actually exercised. And it lives in people, specifically in whether the person on the spot has the authority and the knowledge to decide in the first hour without waiting for an escalation chain to wake up. None of that can be created by writing a document, and all of it can exist without one. The document, at best, records a capability built by other means. At worst, it substitutes for it, and the substitution is invisible until the day it is tested.
The day the plans met reality
July 2024 ran this experiment at global scale, and this series has touched the event before; here the question is narrower than what happened, it is why the plans did not help. A faulty update from a security vendor took down roughly 8.5 million Windows machines in a morning. The vendor’s fix shipped within hours. That is the detail worth sitting with, because on paper the crisis should have ended there. Instead, recovery ran for days and in places weeks, because every affected machine needed hands-on intervention, booting into safe mode, deleting files, and on encrypted fleets, typing a unique 48-digit recovery key into each device, keys that in some organisations were stored on servers that were themselves down. Hospitals reverted to paper they had not used in years. One major airline cancelled thousands of flights across five days, disrupting over a million passengers, and later sued the vendor, arguing the catastrophe was the vendor’s fault. That claim is contested. But for this article the important point sits elsewhere: the fix existed on day one, and the days that followed were a recovery-capability problem, and the recovery capability was the company’s own.
Read through the continuity lens, the pattern across sectors was consistent. The organisations that suffered longest were not the ones without plans; many were certified, regulated, and recently audited. They were the ones whose plans had never been load-tested against the boring, physical arithmetic of recovery: how many machines, how many hands, how many keys, where are the keys, who decides to revert to manual, and has anyone ever actually run the manual process. UK financial regulators, reviewing the event afterwards, framed the lesson in exactly these terms: the differentiator was not documentation but tested, substitutable ways of operating. The companies that bent instead of breaking were the ones where the fallback was a practised behaviour, not an annex.
The comparison the board never sees
The right-hand column is not a bigger document. In most companies it is a smaller one, attached to a much larger investment in architecture, rehearsal, and delegated authority. That inversion is the point. The plan should be the thinnest possible record of a thick capability. Most companies have built the opposite: the thickest possible record of a capability that was never built.
The line
A plan is not a capability, and the difference does not show up in any audit, board pack, or certificate, which is precisely why this gap survives in well-governed companies. It shows up once, on the day of the hit, when the question stops being “do we have a plan” and becomes “what can this organisation actually do right now, with the systems down and the binder unread”. Every other article in this series has been about gaps a board could, in principle, see coming. This one is harsher: the board has been shown evidence all along, and the evidence was about the wrong thing.
So the closing question is the only honest test available short of a crisis. Take your continuity plan, the real one, and ask when it last made contact with reality: not a tabletop, but a day when systems were genuinely off, the fallback was genuinely run, and the recovery time was genuinely measured. If the answer is never, then what the company owns is a description of a capability it has chosen not to verify, and the certificate on the wall is attesting the description. The final part of this series turns to the deepest layer of the security gap: people. The capability that walks out of the building every evening, and sometimes does not come back.