The Scenario Doesn't Matter

I was listening to a podcast about doubt last week. The guest made a point that stuck with me: doubt is most useful before a crisis, not during it. Under acute stress, people fall back on their habits. If habits are built on unexamined assumptions, they fail. It made me think about tabletop exercises.

What is a Tabletop Exercise?

A tabletop exercise is a structured discussion where a team walks through a simulated incident scenario together. No systems are touched, no alarms go off. The point is to get the right people in a room, give them a plausible crisis, and see what happens when they try to respond.

I run a lot of them. And one thing I've learned — the hard way, more than once — is that the scenario doesn't need to be perfect. As an external consultant, I can never design a simulation that maps 100% onto a client's environment. I don't know every system, every integration, every informal tool the team adopted six months ago and never told IT about. For a long time, I treated this as a limitation. I don't anymore.

Because time after time, an approximate scenario will open a conversation that a perfect scenario never would. The simulation is a pretext. The discussion is the product. Two examples from recent work.

The Password Reset nobody could describe

We were running a session covering Cloudflare dependencies, third-party vendor risk, and data exfiltration through authorized applications. Infrastructure-heavy. Nothing in the scenario pointed toward identity management. Somewhere in the middle of the exercise, the question came up: What happens if someone needs a password reset during an incident? Who verifies the request?

Silence.

Not the silence of people thinking. The silence of people realizing there was no answer. The organization had no verified procedure for password resets, which meant a social engineering attack, a convincing deepfake, could potentially reset credentials for a senior account with no friction.

The scenario hadn't touched any of this. The conversation found it anyway.

The LinkedIn Admin nobody offboarded

A team member had left voluntarily a few weeks earlier. Clean exit, no issues. The offboarding checklist had been followed. What the checklist didn't include was the company's LinkedIn page. Not a SaaS application in the traditional sense — nobody had mapped it as infrastructure. But she still had admin rights, which meant posting rights, for days after her last day. She flagged it herself. We removed the access and reassigned the admin role.

The scenario that surfaced this was about a third-party app going rogue and exfiltrating data. Not remotely the same thing. But it pointed the team toward "what do we actually control?" — and that question led somewhere the checklist had never gone.

What this means for how you run exercises

The goal of a tabletop isn't to rehearse the right answer. It's to surface the wrong assumptions before they become the habits you fall back on when things go wrong. A perfect scenario gives people something to perform against. An imperfect one gives people something to think about. The latter is where the gaps live.

The password reset procedure was built. The LinkedIn admin list got added to the offboarding checklist. Neither of those outcomes had anything to do with the scenarios we started with. That's not a failure of preparation. That's what preparation is for.

I'll be honest: early in my career, I used to stress about scenario design. I wanted the simulation to be airtight — plausible, technically accurate, calibrated to the client's stack. If it wasn't a close match, I worried it wouldn't land.

I don't worry about that anymore.

Not because the scenario doesn't matter at all, but because I've watched too many imperfect ones crack open conversations that a perfect simulation would have sailed right past. The password reset procedure. The LinkedIn admin. A dozen other things I didn't set out to find.

The scenario is what gets people in the room and focused. The discussion is what does the actual work. And a good discussion — the kind where someone says "wait, who actually owns that?" — doesn't need a perfect trigger. It just needs a plausible one.

I'm sold. Less-than-perfect scenarios work. They work because the product was never the scenario.