The Tabletop Exercise Gap: Testing Incident Response for Real
A tabletop exercise where everyone sits in a conference room and narrates what they’d do tests whether people remember the runbook. It doesn’t test whether the runbook survives contact with a real incident — degraded communication tools, a key person on vacation, or an attacker who doesn’t follow the scenario’s script.
Run at least one exercise with a communication channel down
The single most common real-incident failure mode isn’t a missing step in the runbook — it’s that Slack, your usual coordination tool, is either compromised or unavailable (because it’s hosted on the infrastructure that’s on fire). If your tabletop always assumes normal tooling, you’ve never actually tested your incident response — you’ve tested your ability to read a document out loud. Run one exercise per year with the primary comms channel explicitly ruled out of scope.
Inject a wrong turn, not just a scenario
Most tabletop scripts hand the team accurate information and let them respond correctly. Real incidents include red herrings — a misleading log entry, an alert that points at the wrong service, a well-meaning engineer who changes something mid-incident without telling anyone. Build at least one deliberate wrong signal into your next exercise and see how long it takes the team to notice and correct course; that recovery time is a more useful metric than whether they reached the “right” answer eventually.
Test the decision-maker’s availability, not just their competence
Plans routinely name a single incident commander with no tested backup. Pick a tabletop date and explicitly remove that person from the exercise without warning the rest of the team beforehand — if response quality collapses, you’ve found a single point of failure that a real 2am incident will find for you anyway, just with worse timing.