I have seen this scene too many times.
A group of people in a meeting room. Coffee on the table. Laptops open. A slide deck on the screen. The title says something like Ransomware Scenario Q2.
Someone from security reads the scenario. People nod. A few people answer questions. Someone says, “we would escalate to management.” Someone else says, “we would contact legal.” A note-taker captures the obvious points.
Then everyone goes back to work.
That is not incident response training.
That is corporate theatre with a cybersecurity theme.
The problem is not that tabletop exercises are useless. They can be extremely useful. The problem is that too many of them are designed to be comfortable. They are scripted, predictable and passive. They produce meeting notes, but they do not show how people actually behave when the situation gets messy.
And real incidents are messy.
People hesitate. Information is missing. Authority is unclear. Communication breaks. The plan says one thing, but the situation demands something else. Someone needs to make a decision before the team feels ready to make it.
That is the part I want an exercise to reveal.
Not during a real breach. Not when production is down and the CEO is asking for answers.
In a safe room, before it happens for real.

Why Most Tabletop Exercises Don’t Work

A good incident response tabletop exercise should show people how they behave when the situation is unclear, uncomfortable and moving faster than they would like.
Most exercises do not do that.

They Are Too Scripted

A bad tabletop exercise has a beginning, middle and end that were decided before anyone entered the room.
The team can say almost anything and the scenario still lands in the same place. The attacker does not adapt. The pressure does not increase. Bad decisions do not really matter. Good decisions do not change much either.
That is comfortable.
It is also the problem.
In a real incident, the situation reacts to what you do. If you are slow, the attacker gains time. If you communicate poorly, confusion spreads. If you make the wrong assumption, the next decision is built on weak ground.
An exercise should reflect that.
I am not interested in punishing people during training. That is not the point. But the scenario should behave like a system, not like a script. Decisions should move the situation somewhere. Inaction should also move the situation somewhere.
Sometimes the most valuable part of an exercise is the moment when the team realizes that its plan only works on paper.
That is uncomfortable.
Good.
That is where the learning starts.

They Don’t Create Real Pressure

Competent people behave differently when they face genuine uncertainty.
That is one of the main reasons I run these exercises.
It is easy to look prepared when the scenario is clean, the timeline is obvious and every action succeeds. It is much harder when logs are missing, the CEO wants an answer, the press team is asking for a statement, and nobody knows whether the attacker is still inside the environment.
That is incident response.
Uncertainty is not an annoying side effect. It is the job.
So when tabletop exercises remove uncertainty, they remove the thing people actually need to practice.
A good exercise does not need to traumatize anyone. It does not need fake drama. But it should create enough pressure for people to notice their own habits.
Who freezes?
Who dominates the room?
Who asks useful questions?
Who waits for permission?
Who starts coordinating without being asked?
Who avoids making a decision by asking for more information that may not arrive?
That is useful information. You do not always see it in a normal meeting. You see it when time matters and the answer is not obvious.

They Train Inside the Silo

Most incident response exercises involve the security team. Sometimes it is just the security team.
That works until the moment it does not.
A real incident does not stay inside the security team. Legal gets involved. Communications gets involved. Privacy gets involved. Leadership gets involved. None of those people have been in the same room, running the same scenario, making decisions together under pressure.
I ran a Malware and Monsters session where the scenario was a flood of fraudulent GDPR data subject requests — a privacy compliance issue on the surface, a coordinated cyberattack underneath.
The privacy team had been sitting on the anomaly for four days before they brought in security. Why? Because in their minds, this was a compliance issue. Not a security issue.
Meanwhile, the SOC had been seeing unusual outbound traffic alerts for 72 hours. They deprioritized those alerts because they were told to focus on the DSAR emergency.
By the time both teams were in the same room, 2.17 gigabytes of data had already left the building.
When security finally walked in, the first thing Marcus said was: we could have helped. We should have been looped in earlier. Morgan from privacy was defensive. Her team had been overwhelmed. They had not thought to escalate because they had never needed to before.
That is not a failure of individual competence. That is what happens when teams train in silos, exercise in silos, and have no shared language for when a problem crosses from one domain into another.
The exercise made that visible. That is exactly what it was supposed to do.

Cyber Incidents Are Human Before They Are Technical

Many organizations still treat incident response as a technical discipline with a bit of communication added at the end.
I think that is backwards.
Of course the technical side matters. Logs matter. Detection matters. Backups matter. Forensics matter. Endpoint data matters. Network visibility matters.
But when things get ugly, the hardest problems are often human.
Who is allowed to make the call?
Who decides whether to isolate a system?
Who tells the board?
Who speaks to customers?
Who decides whether the business can operate tomorrow?
Who writes down what has already been decided?
Who has the authority to say, “we are doing this now”?
That is incident response.
Not just finding the malware. Not just checking the EDR. Not just reading from a playbook.
The technical investigation matters, but the organization still has to make decisions around it. If the humans cannot coordinate, the tools will not save them.

Decisions Happen With Incomplete Information

One of the clearest examples I have seen came during a HackBack game I ran for four experienced practitioners: an IT admin, a CTO, a security architect and an ISM.
The scenario was simple enough on paper.
Ransomware on the CEO’s laptop. Friday afternoon.
Halfway through the exercise, someone asked the question that should have been easy to answer:
Do we even have a backup?
The CTO opened the incident response plan.
There were detection mechanisms. There were response steps. There was process. But there was nothing useful about data protection in that moment.
Nobody could confirm the backup status.
The security architect thought there might be something, somewhere. But that was the problem. The backup was unknown while ransomware was spreading.
Then the conversation moved to the next question, which was even more important:
Even if the backup exists, can we trust it?
The CTO said it plainly:
“We don’t know how long they’ve had access to those endpoints before they triggered the ransomware.”
That is the part many tabletop exercises fail to train.
“Restore from backup” sounds like a decision. But it is only a decision when you know the backup predates the compromise. In that room, they did not know that.
At the start of round two, I told them what I had observed.
Nobody had really taken the lead.
There had been a lot of discussion, but no clear ownership. In a real incident, that uncertainty would have cost them time they did not have.
These were not beginners. They were experienced practitioners with an incident response plan open in front of them.
The problem was not that they were unskilled.
The problem was that the information they needed was not there.
That is why I care so much about making incident response exercises realistic. Real incidents do not wait until you have perfect information. They force you to make decisions while the picture is still incomplete.
A useful tabletop exercise should train that moment.

Communication Breaks Before Technology Does

In a ransomware tabletop exercise, people often want to focus on the ransomware.
I understand why. Ransomware is visible. Encryption is dramatic. Business impact is easy to understand. It creates urgency very quickly.
But the ransomware is not always the most interesting part.
The interesting part is what happens to the organization around it.
The escalation path becomes unclear. The technical team gets busy and stops communicating. Management wants certainty that does not exist. Legal asks careful questions. Communications wants approved wording. The board wants an update. Someone asks whether cyber insurance has been notified. Someone else asks whether systems can be taken offline.
And then the room discovers that nobody knows who owns the final decision.
That is not only a technical failure.
That is a coordination failure.
A good exercise can reveal that before an actual breach does.
If the first time your leadership team discusses ransomware decision-making is during a real ransomware incident, that is not preparedness.
That is gambling.

Emotional Load Is What Nobody Trains

Real incidents create emotion.
Fear. Frustration. Silence. Overconfidence. Blame-deflection. Decision paralysis. The sudden need to look very busy while avoiding the hard question.
People do not become perfectly rational because the incident is serious.
Often, they become less rational.
That is normal. They are human.
But many tabletop exercises are designed as if humans are calm information-processing machines. They are not.
If an exercise creates no emotional activation, it does not train the responses people will need when pressure arrives. I do not mean that people should be scared for entertainment. That is useless. I also do not mean humiliation. That is worse than useless.
The goal is to make the first moment of pressure happen in a safe room, not during an actual breach.
A safe exercise can still be uncomfortable.
In fact, it probably should be.
If nobody felt any tension, if nobody had to defend a decision, if nobody realized something important was missing, the exercise may have been pleasant.
But pleasant is not the same as useful.

How Game-Based Learning Changes the Room

This is where game-based cybersecurity training becomes interesting.
Not because games are fun.
Fun is fine, but it is not the main point.
The point is that a game-based exercise can create structure, pressure, feedback and memory in a way that slide-driven exercises often fail to do.
People need something to do. They need roles. They need constraints. They need imperfect information. They need time pressure. They need decisions that matter. They need consequences they can see.
That changes the room.
People stop watching and start acting.
And once they start acting, you can observe how the team really works.
Not how they say they work.
How they actually work.

Give People Roles, Not Slides

Slides explain responsibilities.
Roles make people inhabit them.
That difference matters.
When someone has a defined role, they become accountable for something. They cannot just nod along. They have to decide, communicate, prioritize and sometimes admit they do not know.
That is much closer to reality.
A communicator should communicate. A technical investigator should investigate. A decision-maker should make decisions. A coordinator should coordinate.
If everyone is responsible for everything, nobody is really responsible for anything.
This is one of the reasons I built Malware & Monsters around distinct incident response roles. Each role has specific responsibilities. Each role can contribute. Each role can also fail the team if it does not act.
When the Communicator fails to brief leadership, that should matter.
When the Detective misses a critical signal, that should matter.
When the team discusses endlessly without someone taking the lead, that should matter too.
Not because we want to blame people.
Because in real incidents, those things matter.

Make Decisions Have Consequences

In many exercises, teams can say the right words and move on.
“We would block that.”
“We would restore from backup.”
“We would inform stakeholders.”
“We would investigate further.”
Fine.
But what happens next?
A decision without consequence is just a sentence.
If the team chooses the wrong control, it should not magically work. If escalation is slow, time should be lost. If communication is poor, confusion should spread. If the team makes an assumption without checking it, that assumption should be tested later.
That feedback loop changes behavior.
In Malware & Monsters, applying the wrong security control against the wrong threat type produces a measurable result. Not because the facilitator decides to punish the team, but because the system responds.
That neutrality matters.
People often accept mechanical consequences more easily than personal criticism. It is not “I think your team made a poor choice.” It is “this is what happened because of the choice.”
That is much harder to argue with.
And it is closer to how incidents work.
The attacker does not care that your decision sounded reasonable in the room. The environment responds to what you actually did.

Let Teams Fail Safely

Most organizations do not like seeing their teams fail in an exercise.
I understand that.
I also think it is exactly why they should do it.
Failure in a safe training environment is not a disaster. It is a gift. It shows you where the plan is vague, where authority is unclear, where communication breaks, where assumptions are hiding and where people need support.
The alternative is discovering all of that during a real incident.
That is the expensive version.
The sweet spot is psychological safety plus visible consequence.
People need to know the exercise is not a trap. They need to understand that the goal is not to embarrass them. But they also need to see that decisions matter.
Remove safety, and people become defensive.
Remove consequence, and the exercise becomes theatre.
Safe failure in training means fewer catastrophic failures in production.
This is obvious in aviation, medicine, emergency response and military training. Somehow, in cybersecurity, many organizations still act as if reading the plan is close enough.
It is not.
You do not build incident response capability by discussing what you would do in theory. You build it by practicing what you will do when the theory stops being enough.

Make the Exercise Memorable, or Don’t Bother

People remember what they felt.
They forget what they read.
That is uncomfortable for people who design exercises as documents and slide decks, but it is true.
If your incident response tabletop exercise feels like a normal meeting, it will be remembered like a normal meeting. Barely.
People may remember that it happened. They may remember the coffee. They may remember that security had a lot of slides.
But will they remember the decision point that exposed a gap in escalation?
Will they remember the moment nobody could confirm the backup status?
Will they remember how it felt to make a decision without enough information?
Will they remember what they personally need to do differently next time?
That is the standard.
A good exercise leaves signals behind.
People are still talking about it the next day. Someone realized the plan did not say what everyone assumed it said. A process owner discovered that “we will escalate” is not a strategy. Leadership understood that asking for certainty does not create certainty. The technical team saw that silence creates its own incident.
That is useful.
That is what I want from an exercise.
Not a perfect performance.
A better understanding of reality.

Stop Mistaking Attendance for Preparedness

So yes, stop running boring incident response tabletop exercises.
Stop mistaking attendance for participation.
Stop mistaking slides for simulation.
Stop mistaking compliance evidence for preparedness.
Run exercises that make people decide.
Make them communicate.
Make them feel pressure while failure is still safe.
Make the scenario respond.
Make the consequences visible.
Make the debrief honest.
Because if nobody remembers the exercise, the attacker probably got more value from it than you did.

Want to Run an Exercise People Actually Remember?

This is why I built Malware & Monsters the way I did.
I do not want people to leave an exercise saying, “that was interesting.”
I want them to leave saying, “we need to fix this before it happens for real.”
Malware & Monsters is built around the things most exercises avoid: real roles, incomplete information, decisions with consequences, and pressure that is uncomfortable on purpose.
Run it before the attacker runs the real version.
Reach out at klaus@relationssec.net or visit malwareandmonsters.com.