How to run a tabletop exercise for security teams: Step-by-step instructions

Most organizations have an incident response plan. It describes how to identify, escalate, and manage incidents, who’s responsible for making decisions, and how different teams should coordinate their response. 

But how confident are you that those arrangements will work when something actually goes wrong? Plans describe how people are expected to respond. They don't tell you how teams will behave when information is incomplete, decisions are time-sensitive, and normal operations are disrupted.

Tabletop exercises provide an opportunity to explore those challenges in a controlled environment. A tabletop exercise is a discussion-based rehearsal in which participants work through a simulated incident, examining the actions they'd take, the decisions they'd make, and how they'd coordinate their response. 

You don't need specialist tools or a large budget to get started. Here are eight steps to help you plan, run, and learn from a tabletop exercise with your security team.

It's tempting to start planning a tabletop exercise by building a scenario around an interesting incident like a ransomware attack or compromised administrator account.  This approach can generate plenty of discussion, but it won’t tell you much about your team's ability to respond. 

A more useful starting point is to consider what you want to learn about your existing capabilities and then design the exercise around those objectives. For example, you might want to understand: 

• If analysts can recognize when an incident needs escalating

• How effectively security and IT operations coordinate containment activities

• Who makes decisions when those activities could disrupt critical business services

• How technical information reaches senior leadership when they need answers the investigation hasn't found yet

For a short exercise, two or three well-defined objectives will usually provide enough focus to explore those questions in meaningful depth.

Once you've established your objectives, identify the people needed to explore them. As an example, an exercise focused on SOC investigation and escalation might involve security analysts, incident responders, and their managers. 

However, when the objectives extend to decisions that could affect business operations, bring in people who understand those consequences and are responsible for managing them.

A serious cyber incident rarely remains confined to the security team. IT operations may need to isolate systems or restore services, while finance, HR, legal, and corporate communications have their own responsibilities as disruption spreads.

Senior leaders may also need to make decisions based on incomplete technical information. The exercise should explore these dependencies when they're relevant to your objectives, rather than assuming the security team can speak for the rest of the organization.

That doesn't mean every department needs to participate in every exercise. What counts is whether the people involved can realistically explore the decisions and dependencies you want to test. 

You'll also need someone to facilitate the discussion and someone to record observations. For smaller exercises, one person can perform both roles, although separating them allows the facilitator to concentrate on how the conversation develops.

The scenario is the context in which participants explore their incident response. It should reflect credible threats and your organization's operating environment, with enough detail to support meaningful decisions without becoming unnecessarily complicated.

Consider which services and systems your organization depends on and what might happen if they became unavailable or compromised. A ransomware attack affecting a critical business service could introduce questions about investigation, containment, and recovery, alongside decisions about business continuity. You don't need to explain every technical detail of the attack unless those details are relevant to your objectives.

Real incidents rarely present themselves with all the information needed to make confident decisions. Allowing some uncertainty in the scenario gives participants an opportunity to consider what additional information they'd seek and how they'd respond while the situation is still developing.

As the exercise progresses, you'll need a way to introduce new information and developments. These are commonly called injects, and they might take the form of a security alert, an update from IT operations, an employee report, or a customer enquiry. Each inject should support an exercise objective by prompting participants to consider a decision or explain how they'd respond.

For example, an inject reporting suspicious privileged account activity could explore how analysts investigate, establish ownership, and decide when to escalate. A subsequent report that a critical system has become unavailable could introduce questions about containment, recovery priorities, and the operational consequences of taking other systems offline.

Some of the most useful injects explore how the security team interacts with the wider organization. Imagine the CEO has been asked to give a television interview while an investigation is still underway. The communications team needs an accurate briefing, but the technical team hasn't yet established the full extent of the incident. 

How would reliable information reach the communications team, who would verify it, and how would uncertainty be explained? These are important dependencies that might otherwise be overlooked in a purely technical exercise.

You don't need a long sequence of injects to create a worthwhile discussion. A handful of carefully chosen developments can be sufficient, particularly if they encourage participants to examine how they would make decisions, not just what procedures they’d follow.

Once you’ve prepared the scenario and injects, you can turn your attention to delivery. Create a short facilitator guide containing the objectives, scenario, injects, and key discussion questions to keep things on track. 

Participants should also have access to relevant plans and procedures, since these are resources you'd expect them to use during a real incident. For a small, focused exercise (about 60 to 90 minutes), provide a debrief as a starting point. Exercises involving several business functions may need more time.

The briefing should explain the objectives, how the exercise will work, and what’s expected of participants. It's important to establish an atmosphere where people feel comfortable acknowledging uncertainty or questioning existing arrangements. 

An exercise is an opportunity to learn, not an examination of individual performance. A participant who identifies something they don't understand may reveal the exact issue you need to resolve.

The quality of facilitation can significantly impact your tabletop exercises. A facilitator isn't there to demonstrate how they'd handle the incident or steer participants toward a predetermined answer. Their role is to encourage a productive discussion, explore the reasoning behind decisions, and keep the conversation relevant to the objectives.

As participants work through the scenario, the facilitator should ask questions to reveal how the response would operate in practice. If someone proposes isolating a server, for example, the facilitator might explore who has authority to approve that action, what other services could be affected, and how the consequences would be assessed. If the team intends to escalate to an incident manager, it's worth understanding what happens if that person isn't available.

These discussions need room to develop naturally. Participants should have opportunities to challenge assumptions, consider alternatives, and disagree with one another, particularly where technical and business priorities come into conflict. 

The facilitator also needs to be conscious of group dynamics. More senior or experienced people can unintentionally dominate a conversation, and quieter participants may hold information that's essential to understanding how the response would work.

Not every disagreement needs to be resolved during the exercise. If participants discover that nobody knows who can authorize a particular action, or that different teams have conflicting expectations, that's a useful observation in its own right. The facilitator can explore the implications, capture the issue, and allow the discussion to continue rather than attempting to solve everything immediately.

Throughout the discussion, the observer should record significant decisions, assumptions, uncertainties, and examples of effective coordination. The aim isn't to create a transcript of everything participants say, but to collect evidence that helps evaluate the exercise against its objectives.

Specific observations are particularly valuable. Rather than concluding that roles and responsibilities were unclear, the observer might record that participants couldn't identify who had authority to approve the isolation of a business-critical system. That provides a concrete issue to investigate and is much more useful when considering improvements.

A short debrief at the end gives participants an opportunity to reflect on what worked, what was difficult, and what surprised them. It's worth recognizing strengths as well as weaknesses, while considering why particular problems arose. An unclear decision might reflect missing documentation, inadequate training, conflicting responsibilities, or poor coordination between teams.

Use observations from the tabletop exercise to inform a manageable set of improvements. This might include straightforward changes such as clarifying an escalation threshold or more substantial work involving responsibilities, training, or coordination with other business functions. Prioritize the issues most likely to affect the organization's response, assign owners, and establish how the improvements will be validated.

Updating a procedure doesn't necessarily mean people will understand it or be able to apply it. Follow-up exercises can help establish whether changes have been effective, while you may need practice testing to uncover technical weaknesses.

A useful tabletop exercise doesn't need an elaborate scenario or sophisticated tooling. It needs clear objectives, the right participants, and a willingness to explore how people respond when circumstances are difficult. Its greatest value often comes from discovering something that wasn't previously understood, whether that's an unclear responsibility, an overlooked dependency, or weak communication.

At the end of the day, incident response plans provide a foundation, but truly effective response depends on people understanding their responsibilities, working together, and rehearsing how they'll make decisions under pressure.