The BCM Plan Nobody Reads Until the Day They Need It

Every company has a business continuity plan. Most got theirs the same way: an auditor asked for one, someone assembled it over a stressful week, and it went into a folder the moment the box got checked. That origin story explains almost everything about what happens to the document next.

What happens next is nothing, for about 358 days a year. Then a calendar reminder fires, subject line Annual BCM Review, and whoever drew the short straw opens a file untouched since the last one, skims it for the length of a coffee break, and signs off. The plan is compliant again. Whether it describes reality is a question nobody in that fifteen-minute window was trying to answer.

Nobody in that review is being lazy, exactly. The plan runs forty pages, references a dozen systems, and touches teams the reviewer has never worked with. Reading it forensically would take a week, and nobody's job description includes a week of forensic accounting on a document everyone hopes never gets used. So the review becomes a formality wearing the costume of due diligence, and the plan passes because passing was never in doubt.

I've read enough of these documents to recognize the fossil layers. The recovery procedure points at a data center that got decommissioned two migrations ago. The escalation chart lists a VP of Infrastructure who left eighteen months back, whose old extension now rings a desk nobody sits at. Somewhere around page nine there is a fax number, added by an editor four owners removed from anyone currently employed.

That doesn't make a company careless, just ordinary. Any document whose only forcing function is a once-a-year skim by someone with no stake in its accuracy drifts the same way. Systems get replatformed, teams reorganize, vendors rotate, and the plan sits untouched, collecting the same quiet inaccuracy any unmaintained artifact collects, waiting for the day someone needs it to be true.

Existence isn't the test

Every audit asks some version of the same question: do you have a plan? The question that actually matters is different: if the payment processor goes dark at two in the morning on a Saturday, does the person holding this document know who to call, what to restart, and in what order? Those two questions produce completely different documents, and most BCM programs are built to satisfy only the first one.

I made a similar argument once about audit logs, systems nobody reads until the moment they desperately need one to say something true, at which point it's already too late to go back and make it accurate. A BCM plan fails the same way, just on a longer timeline. An audit log goes stale in seconds. A plan can go stale for years, because the only time anyone opens it under real pressure is during an actual incident, and incidents don't offer dress rehearsals.

Fixing this costs more than skimming a PDF once a year, and audits don't check for it, so most companies won't bother. The version that works ties the review to actual change events, like decommissions or reorgs, rather than a date on a calendar with no relationship to when the underlying facts changed. A small, unglamorous fix helps more than people expect: naming roles instead of people, so the plan survives the next resignation instead of becoming trivia. It also gets exercised occasionally against a scenario nobody chose in advance, so the gaps surface on an ordinary Tuesday instead of during the incident that was supposed to prove the plan worked.

Most plans will keep existing exactly as they are: technically present, notionally reviewed, describing a company that stopped existing two reorgs ago. Right up until the night someone opens it with shaking hands, looks for the Head of Facilities, and finds a name that left in spring and a data center that is now, as far as anyone can tell, a parking lot.