The Discipline of Realistic Testing
An untested recovery plan is not a plan. It is a hypothesis — a confident story about how the failure will go, written by people who have never watched it happen. The only way to convert the hypothesis into knowledge is to run it, deliberately, before the disaster runs it for you. Start cheap and safe with a tabletop, climb to a real recovery drill, and eventually pull the plug for real with a live failover. Each rung finds different lies: the tabletop finds the missing decision, the drill finds the runbook that no longer matches reality, the live test finds the shared dependency nobody drew. Testing is how you buy failure's intelligence on your own terms, in daylight, with the coffee on.
Knowledge check
A team runs a tabletop exercise every year and the plan always 'passes' — everyone agrees the documented steps would work. Yet the one time they attempted a real failover, it took four times the target recovery time. What is the likely gap, and what does it reveal about the limits of each kind of test?
Show the answer
The likely gap is that the tabletop only tested the team's shared understanding of the plan on paper, not the plan's contact with reality — the runbooks were probably out of date, automation had drifted, or hidden dependencies existed that a discussion could never surface. It reveals that each kind of test has a ceiling: a tabletop can only find gaps in reasoning and decision-making, not gaps between the documentation and the actual systems. Only executing the recovery on real infrastructure — a drill or live failover — measures the true recovery time and exposes the drift, missing access, and undocumented dependencies that a discussion cannot.