Tabletop or It's Just a Story

Somewhere in your company's shared drive there is an 80-page business continuity plan. It has a table of contents. It has a document owner and a review date from eighteen months ago. Somewhere in it is a diagram with arrows pointing at boxes labeled "Escalate" and "Notify Stakeholders." The formatting is immaculate. Nobody has ever tried to run it.

That plan makes leadership feel prepared in roughly the same way a fire extinguisher sticker makes a kitchen feel safe. It signals that someone thought about the problem once. It says nothing about what happens when the problem shows up.

A tabletop exercise is the opposite of that comfort. You put six or eight people in a room, nobody touches a single production system, and a facilitator starts describing a disaster in installments. "It's 2am. Your primary database region is unreachable." Everyone nods, someone reaches for the plan. Ten minutes later the facilitator adds one detail: the on-call engineer who owns the failover runbook is unreachable too, because in this scenario she's on a flight. Watch the room's confidence evaporate in real time.

Here's the part nobody puts in the plan: continuity depends on people, and people are the least reliable component in any system you own. The document says "escalate to the incident commander." It doesn't say what happens when the incident commander is the person the outage took out, or on parental leave, or the only one who remembers the vendor's support number, saved in a phone that's now at the bottom of a lake. Real exercises find this in the first act. Reading the document never does, because the document was written by people imagining a version of the disaster polite enough to leave the org chart intact.

Why paper plans lie by omission

A written plan is a set of claims about the future, and claims are free. It costs nothing to write "the backup site will be operational within four hours." Nobody has to prove it. Nobody has to sit through the part where the backup site's DNS records were never updated, or where the runbook references a tool three people no longer have license access to. Step 7 says "notify legal." There's no current number for legal, because the last reorg moved that team under a different VP.

A tabletop drags those claims into a room and asks them to survive a conversation. Say the bad thing out loud, in sequence, to the people who'd actually be holding the phone, and watch where the sentence stops making sense. It usually stops in the same couple of places: a single point of human failure, and an assumption nobody double-checked since the plan was written.

None of this requires touching anything real, which is the part everyone underrates. You get the diagnostic value of an actual incident, the confusion and the scramble to find an owner, without paying for the actual outage. It's the cheapest way to find out your plan doesn't work, which is a strange thing for so many organizations to avoid on purpose.

And yet most of them do avoid it, because a tabletop exercise produces something a compliance checklist specifically does not want: evidence. Once you've run one, you can't honestly call the plan finished anymore. You know exactly which assumptions it's standing on, and you know their names. A plan sitting untested in a shared drive gets to stay theoretical forever. A tested one turns into homework, and homework photographs worse for the board deck than a PDF with a nice cover page.

If your BCM plan has a version number higher than one and a tabletop count of zero, you don't have a continuity plan. You have a well-produced short story about a company that survives disasters, starring a cast of employees who may not even work there anymore.