Your Tabletop Exercise Is Boring and That Is Why It Is Not Working
Somewhere in corporate America right now, a security leader is running a tabletop exercise. The scenario came from a template. The participants are mostly from engineering. The head of marketing sent a junior person who is checking email under the table. Finance is not there at all because nobody thought to invite them. The whole thing will wrap up in ninety minutes, a report will get filed, a box will get checked, and leadership will walk away believing the organization has rehearsed its incident response.
It has not. What it has produced is the appearance of preparation, which is an entirely different thing, and which provides almost none of the value that a real tabletop is supposed to deliver.
The biggest mistake security leaders make when running these exercises is treating them like a compliance checkbox rather than an experience worth having. When the scenario is generic, overly technical, or obviously recycled, participants disengage almost immediately.
This is especially true for the non-technical side of the company. Marketing, sales, customer success, and finance show up already convinced the exercise has nothing to do with them. When the scenario turns out to be a standard walkthrough aimed squarely at engineering, they are usually right. The exercise confirms their suspicion that security is someone else’s problem, and everyone leaves slightly more convinced of the wrong lesson than they were when they arrived.
The signs of a failing tabletop are visible within the first thirty minutes. Participants go quiet. Conversations stay narrowly technical. Teams outside engineering have nothing to contribute. Decisions feel predetermined rather than genuinely debated.
If people are mentally checking out, the scenario is not doing its job. No amount of post-exercise documentation will make up for the fact that the gaps nobody tested are exactly the ones that will show up when something actually happens.
And those gaps do show up. When an actual breach occurs, the miscommunication between departments, the delayed decisions, the confusion about who owns what, the teams that have never had to coordinate under pressure all suddenly try to figure it out in real time, while a threat actor is actively working against them and a clock is running. That is a genuinely bad time to discover that your head of sales and your head of marketing have different ideas about what customers should be told, and that neither of them has ever met the outside counsel who is now on the phone asking everyone to stop talking.
What Tabletop Gaming Knows That Corporate Tabletop Exercises Do Not
The useful model here is not a compliance framework. It is a tabletop RPG.
Good game masters have spent decades figuring out how to get a group of people, many of whom are tired and distracted and would rather be doing something else, to lean forward, engage with a fictional scenario, and make decisions under pressure that feel real enough to matter.
They do this by building scenarios that feel true to the people in the room. Participants can see themselves in the situation and feel the stakes. Every person at the table has something meaningful to do. This is the entire game. It is also, not coincidentally, exactly what a security tabletop exercise is supposed to accomplish.
Customization is where it starts. A scenario that reflects the organization’s actual environment, its real infrastructure, the kinds of threats that are plausible given the industry and the current threat landscape, will always outperform a template. People can tell the difference between a situation that could happen to them and one that was written for a generic mid-sized company that does not exist. The first one makes them think. The second one makes them check their phone.
From there, the design challenge is giving every department a pressure-tested role. Consider what this looks like in practice. A scenario opens with a suspicious authentication pattern in the production environment. Engineering starts working the technical response. But then it develops. The compromised account belongs to an employee who handles contract renewals, which means the head of sales needs to figure out which customer data was accessible through that account, and customer success needs to start thinking about which accounts might require proactive notification. The engineering team realizes the affected systems include a workflow that touches payment data, which pulls finance in to start reconstructing exposure. Marketing starts drafting holding statements because if this goes public before the company is ready, the narrative will be written by whoever talks first.
Suddenly everyone has a job. Not an observer seat. Not a token presence. A real part of the response, with real decisions to make, where the wrong call has visible consequences for the people sitting across the table.
If the non-technical teams do not have meaningful things to do, they will correctly conclude that the exercise is not for them, and the next time they are invited, they will find a reason to decline.
The Pattern Interrupt
A scenario that is merely customized and inclusive is already better than most. The best exercises add one more thing, which is the pattern interrupt.
Midway through, a good facilitator introduces something unexpected. Something that forces participants to abandon the assumptions they have settled into and re-engage with the scenario on new terms. This is the moment where a tabletop stops being an exercise and starts being a simulation, because real incidents never go the way the runbook predicts.
A particularly effective version is the media leak twist. The team believes nothing has been disclosed publicly. They are feeling good about their deliberate and professional approach, perhaps even drafting a careful responsible disclosure statement, when the facilitator slides a piece of paper across the table. A reporter from a trade publication has reached out. The reporter knows something. The reporter has most of it wrong, in a way that sounds significantly worse than the truth, and the reporter has a deadline in four hours.
Watch what happens next. The head of marketing, who until this point had been half-listening, suddenly leans forward because this is now very much her problem. The Engineering Director is still running incident response in parallel and now has to decide how much technical detail can be shared to correct the record without compromising the investigation. Finance is trying to calculate, on the fly, what the actual scope of data exposure was so marketing has accurate numbers to work with. The head of sales is already pulling up the list of strategic accounts who will see the story and trying to decide who needs a call before it runs. Someone realizes nobody has told the CEO yet. Someone else realizes they do not actually know who on the board should be notified or in what order.
And the room has gone from quiet and dutiful to leaning forward and talking over each other, because every person at the table is now working a different piece of the same problem and they need each other to solve it.
That is the moment the exercise is working. People are using their actual expertise. They are coordinating without being told to. They are discovering, in real time, the handoffs their incident response plan did not account for. They are also, whether they would admit it or not, having fun, because solving a hard problem with a group of smart people under time pressure is one of the most engaging experiences available to a working adult, and almost nobody expected to have it at a tabletop exercise.
That single scenario tests technical response, financial analysis, communications strategy, and customer relations at the same time, which is much closer to the experience of an actual incident than any siloed exercise can deliver.
A Simple Test
The test for whether an exercise is working is simple. Are people leaning forward? Are they asking what happens next? Are they arguing with each other about what to do, not in a hostile way, but in the way that people argue when they actually care about the outcome?
When you get that, you have built something worth doing. You have also, almost as a side effect, built the kind of cross-functional muscle memory that makes a real incident survivable.
The departments have talked to each other. The Engineering Director has met the head of marketing under conditions resembling actual pressure. The head of sales knows who to call in the first ten minutes. People have practiced making decisions with incomplete information, which is the only kind of information that is ever available during an actual breach.
A great tabletop exercise should secretly be a little fun, in the way that good tabletop gaming is fun. That is not a failure of seriousness. It is the mechanism by which the exercise actually teaches anything. The alternative, the grim and dutiful walkthrough nobody wants to attend, is what a tabletop looks like when it has given up on doing the job.
Asteros is primarily a web application penetration testing firm, which means we spend our working hours executing the same tactics real threat actors use against the kinds of companies that end up in tabletop scenarios. That perspective is what makes a good tabletop work. The twists that feel plausible, the pressure that lands in the right places, the details that make a scenario feel like it could actually happen to the people in the room, all of it comes from knowing how attackers actually behave rather than how a template says they behave. If your last exercise felt like a checkbox and you would like the next one to feel like something else, get in touch.
