How to Run a Tabletop Exercise Step by Step

Introduction

Once the preparation is done, the real value comes from how the exercise is run.

A tabletop exercise does not need to feel formal or complicated, but it does need structure. Without structure, the discussion can drift into theory, become too technical, or turn into a debate about details that do not matter.

A good tabletop session feels realistic, focused, and productive. It helps the team think through how they would actually respond, what decisions would need to be made, and where the process starts to break down.

The goal is not to prove that your plan is perfect. The goal is to expose weak points while there is still time to improve them.

Start by Framing the Session Clearly

At the beginning of the exercise, take a few minutes to explain what the session is meant to accomplish.

Participants should understand that this is a guided walkthrough of a scenario, not a technical drill and not an individual test. The purpose is to evaluate how the team would respond together, using the processes and roles that already exist.

This opening matters more than many teams realize. If the group sees the session as a performance test, people tend to become cautious and defensive. If they understand that the session is meant to improve readiness, they are more likely to speak honestly, admit uncertainty, and surface real issues.

It also helps to remind everyone what scenario is being tested and what assumptions apply. For example, if the exercise is centered on a compromised employee account, make it clear whether the compromise is confirmed, whether production systems may be affected, and what information is available at the start.

Introduce the Scenario in a Way That Feels Real

The scenario should begin with a realistic trigger, not a full explanation of everything that happened.

In a real incident, teams do not start with complete information. They start with a signal. That signal might be an alert, a customer complaint, suspicious account activity, or an unexpected system behavior.

Begin the exercise the same way. Present the initial facts and then ask the team what they would do first.

For example, you might say that an employee in engineering reports unusual sign-in activity from an unfamiliar location and that the account has access to production systems. Then pause and let the team respond.

This approach forces participants to think like they would in a real event. It keeps the discussion grounded in response rather than theory.

Ask the Team to Walk Through the First 30 Minutes

One of the most useful ways to run the exercise is to focus first on the early phase of the response.

Ask the team what happens in the first few minutes. Who is notified first? Who verifies whether the issue is real? Who has authority to disable the account? Who determines whether other systems are affected?

This part of the discussion usually reveals more than any other. It shows whether people know their role, whether escalation paths are clear, and whether the team can move quickly when the situation is still uncertain.

If the answers are vague, that is useful information. It means the process needs more clarity. If the answers are clear and consistent, that is a sign the team is likely to respond well under pressure.

Keep Pulling the Team Back to Decisions

A tabletop exercise works best when it stays focused on decisions, not abstract discussion.

If the conversation starts drifting into what the company generally believes or what could happen in theory, bring it back to the immediate situation. Ask what decision needs to be made right now. Ask who makes that decision. Ask what information they would need before acting.

For example, if the team starts discussing security philosophy, bring them back to whether the account should be disabled immediately, whether access logs need to be reviewed, or whether legal or leadership needs to be informed.

These decision points are the heart of the exercise. They reveal whether the team can actually move through an incident in a coordinated way.

Introduce New Facts Gradually

A tabletop becomes much more valuable when the scenario evolves.

Once the team has responded to the initial situation, introduce a new development. Perhaps logs now show that the compromised account accessed an internal admin tool. Perhaps a customer support ticket comes in asking about unusual behavior. Perhaps it appears that sensitive data may have been viewed.

Adding details in stages mirrors the way real incidents unfold. It also tests whether the team can adapt as the situation becomes more serious.

This is where the facilitator adds the most value. The purpose is not to surprise the team for the sake of difficulty. The purpose is to see how the response changes as new facts appear and whether the escalation path still works as pressure increases.

Test Communication, Not Just Technical Response

Many tabletop exercises focus too heavily on technical actions and overlook communication.

A real incident usually affects more than the engineering team. Leadership may need to be informed. Customers may need to be notified. Internal teams may need direction on what to say and what not to say.

At the right point in the scenario, ask how communication would be handled. Who updates leadership? Who determines whether customer communication is necessary? Who is responsible for making sure messages are accurate and consistent?

These questions are important because communication failures often make incidents worse. Even when the technical response is solid, poor communication can damage trust and create confusion.

A strong tabletop should test both the operational response and the communication response.

Pay Attention to Gaps, Delays, and Uncertainty

As the exercise unfolds, listen carefully for moments where the team hesitates, disagrees, or discovers that something is unclear.

These moments are where the value is.

If no one knows who owns the decision to notify customers, that is a gap. If two people assume the other is responsible for disabling access, that is a gap. If the team realizes they do not have a reliable way to confirm what data was accessed, that is a gap.

Do not rush past these moments. Pause long enough to understand why the uncertainty exists. Very often, the best findings come from these points of confusion.

The purpose of the exercise is not to create a smooth performance. It is to surface the things that would slow the team down in a real event.

Keep the Session Moving Without Solving Everything

One mistake facilitators make is trying to fully solve every issue during the exercise.

That is usually not the best use of the session. If an important gap is identified, note it and keep moving unless the group truly cannot continue without resolving it.

The main value of the exercise comes from seeing the full response unfold. If the session stops every time a weakness appears, you lose the broader view of how the incident would progress.

It is better to capture the issue clearly, finish the scenario, and then address the findings afterward in a more structured way.

This keeps the exercise productive and prevents it from turning into a policy workshop.

Close With a Focused Debrief

At the end of the scenario, do not stop abruptly. Set aside time to debrief while the discussion is still fresh.

Ask the team what felt clear and what felt unclear. Ask where decisions moved quickly and where they slowed down. Ask whether the documented process matched what the team would actually do in practice.

This is often where the most honest insights emerge. During the scenario, people are focused on responding. During the debrief, they can reflect on what worked and what needs improvement.

The debrief should not become defensive or overly broad. Keep it focused on what was learned from the scenario and what needs to change as a result.

A Practical Way to Think About the Flow

A useful tabletop exercise usually follows a simple rhythm.

It begins with an initial signal. The team works through the first decisions. New facts are introduced. The scope of the response expands. Communication and escalation are tested. The session ends with a debrief that captures the gaps.

If you keep that rhythm in mind, the exercise becomes much easier to manage. You do not need a complicated format. You need a realistic scenario, a steady facilitator, and a team willing to walk through the response honestly.

That is enough to produce meaningful results.

Practical Takeaways

Running a tabletop exercise effectively comes down to structure and realism. Start by framing the session clearly so participants understand the purpose. Introduce the scenario as a realistic signal rather than a complete story. Keep the team focused on the decisions they would actually make in the first minutes and hours of the incident.

As the discussion progresses, introduce new information gradually so the scenario evolves in a way that feels real. Test communication as carefully as you test the technical response. Pay close attention to hesitation, confusion, and unclear ownership, because those moments often reveal the most important gaps.

Most importantly, keep the session moving. The exercise is meant to show how the response unfolds, not to solve every problem in real time. Capture the issues, complete the discussion, and use the debrief to turn those lessons into action.

What Comes Next

Once you know how to run a tabletop exercise, the next question is what kinds of scenarios are worth testing.

Which incidents are most useful to simulate, and how do you choose scenarios that reflect your environment and your real risks?

In the next article, we will walk through common incident scenarios and how to select the ones that will give your team the most practical value.

If you're preparing for SOC 2, being able to run a focused and realistic tabletop exercise shows that your team is not just relying on an incident response document, but actively testing how that response would work in practice.