How to Run a Tabletop That Isn't Theater

Category: Operational Resilience Author: Cody Swidler Tags: tabletop exercises, incident response, injects, after-action, resilience testing

The worst tabletop I ever sat through had a slide that read "Backups restore successfully. Systems recovered." Everyone nodded. The facilitator advanced to the next slide, the exercise concluded on schedule, and the after-action report recorded zero findings. Fourteen months later that organization had a real ransomware event, and the backups did not restore successfully — the restore had never been tested at production scale, a fact a competent exercise would have surfaced in twenty minutes. The tabletop hadn't just failed to find the weakness. It had actively manufactured confidence in it.

That's the thing about bad tabletops: they're worse than no exercise at all, because they convert untested assumptions into documented assurance. And most tabletops are bad in exactly this way — a narrated slideshow where the scenario cooperates, the plan works, and everyone leaves feeling prepared. That's not an exercise. That's theater with a sign-in sheet.

The Exercise Is Only as Good as Its Injects

A real tabletop turns on the moments where the comfortable plan gets invalidated. "The backup restore is also encrypted." "The vendor's status page still says operational, but nothing is flowing." "The incident commander's phone is going to voicemail." "A reporter just emailed the CEO directly." Each of those injects removes an assumed resource or contradicts an assumed fact, and the room has to decide something with what's left. That decision — made badly or well, but made visibly — is the entire product of the exercise.

So design the scenario backwards from the decisions you want to force. If you want to know whether anyone can actually invoke the vendor contingency, write the inject that takes the vendor dark and keeps them dark past the comfortable window. If you want to test the notification clock, inject the fact pattern that starts it ticking and see whether anyone in the room notices. Six to eight timed injects per scenario is plenty; more than that and you're rushing past the discussions that matter.

Rules of Engagement

Two rules do most of the work. The first is no-fault: the exercise judges the program, not the people, and it must be said out loud at the open, because the moment participants believe findings will be career events, they stop volunteering the truths you're paying for. The second is the injects are true: no litigating the scenario. Every tabletop has someone who wants to argue that the outage couldn't happen that way. It could, it just did, and the clock is running — move to what you'd do about it.

The facilitator's discipline matters as much as the rules. Time-box the discussions and cut them at the box, because real incidents don't wait for consensus. Ask probing questions instead of leading ones — "who owns this decision right now?" is worth ten minutes of scenario narration. And insist on the structural answer over the heroic one: when someone says "I'd just call Dave," the follow-up is "what's the answer when Dave is on a plane?" — which is the entire argument I made in incident command is the backbone of resilience. Exercises that let individual heroics stand as answers are testing your luck, not your program.

Capture Is a Role, Not an Afterthought

The findings from a tabletop have a half-life of about 48 hours. If they live in the facilitator's memory or a chat scroll, they're gone. So the scribe is a dedicated role with a structured capture format: the observation, the moment it surfaced, and — this is the part everyone skips — whether it's a gap in the plan, a gap in capability, or a gap in knowledge. Those three route to different fixes. A plan gap is an edit. A capability gap is a budget item. A knowledge gap is training. Mixing them produces after-action reports where every finding becomes "update the documentation," which fixes almost nothing.

Within ten business days, every finding gets an owner and a due date, and the list enters the same tracking rhythm as your audit issues — in a connected program, exercise findings are just another evidence stream feeding the model, the same way I described incidents feeding risk ratings in the connected GRC model. A finding without an owner is a memory. Six months of unowned findings is how the same weakness shows up in three consecutive exercises, which I've watched happen at organizations that were genuinely proud of their exercise cadence.

Who's in the Room

Run the technical scenario with the responders, but don't stop there. The exercises that change organizations put executives in the seats, playing themselves, making the calls only they can make — approve the ransom-response posture, take the regulatory notification decision, accept the revenue hit of a conservative recovery. The first time a CFO experiences deciding at minute forty with partial information, the resilience budget conversation changes permanently. An exercise program that never inconveniences an executive is signaling, loudly, that resilience is a middle-management concern. That's the ownership failure I keep returning to in operational resilience is an ownership problem.

Cadence and Escalation

One exercise a year is a compliance artifact. A working cadence looks like: tabletops per quarter rotating through your scenario library, one scenario a year escalated to a functional test where something actually gets failed over, and every exercise attacking a known weak point — ideally the recovery gaps your BIA already flagged — rather than re-proving last year's strengths. The scenarios themselves should rotate across your real threat surface: ransomware with backup compromise, a cloud-region outage, a critical vendor going dark mid-day, a data breach with the notification clock running, a regional disruption with key people unavailable. If a scenario has gone two years without producing a finding, it's either solved or soft. Retire it or sharpen it.

Run this way, tabletops become the cheapest resilience instrument you own: a few hours of structured discomfort that finds failures while they're still hypothetical. Run the other way, they're a quarterly ceremony that certifies assumptions nobody tested. The difference is the injects, the capture, and the willingness to let the exercise be uncomfortable on purpose — because the real event will not check whether the room is ready before it starts.

Cody Swidler is the founder of PivotRisk and a Principal Program Manager, Enterprise Resiliency at Apex Clearing. He has built and scaled GRC, resilience, and risk programs across Microsoft, Twilio, Box, Zayo, and Miro.