Tabletop Exercises: How to Run a Security Scenario Test That Improves Your Response
A tabletop exercise where everything goes to plan is a missed opportunity. The purpose of a tabletop is not to demonstrate that your team can execute a procedure. It is to find out where your procedure does not hold, where decisions get stuck, and where the assumptions embedded in your incident response plan turn out to be wrong. If your last tabletop felt like a rehearsal, it probably was not achieving much.
The most valuable exercises we facilitate are the ones that make participants uncomfortable. Not because discomfort is the goal, but because it indicates the scenario is testing real decision-making under uncertainty rather than confirming what everyone already knows. When a team has to debate who has authority to authorise a system shutdown, or realises mid-exercise that the person who knows the forensics provider contact is on leave, those are the moments that improve actual response capability.
Designing a Scenario That Does Not Resolve Too Easily
The scenario is the most important design decision in a tabletop. It needs to be plausible for your environment, specific enough to drive realistic decisions, and structured to introduce complications that expose gaps in your plan. A scenario that is too generic, such as "a ransomware attack has occurred," does not create the specificity needed for teams to make real decisions. A scenario that names which system is affected, what data may be at risk, which third parties are involved, and what is visible in your monitoring environment forces genuine engagement.
Build complications into the scenario at timed intervals. Introduce a twist at the forty-five minute mark: the incident is spreading, a senior staff member is unreachable, the forensics provider says they cannot attend for twenty-four hours, the media has published a story, the regulator calls. These injects test adaptability and escalation, which are the capabilities that matter most when real incidents diverge from the script, as they always do.
Facilitation Principles
The facilitator's role is not to guide the team toward the right answer. It is to present situations, ask clarifying questions that expose assumptions, and create space for genuine deliberation. When a team reaches consensus quickly on a difficult decision, the facilitator's job is to probe that consensus: what information would change this decision? What if the forensics data showed something different? Who else should be consulted before acting?
Ground rules matter. Participants need to engage with the scenario as presented, not assume resources or capabilities they do not currently have. "We would just call our provider" is not a valid answer if the exercise reveals that no one has the provider's number. "Legal counsel would advise us" is not a valid answer if legal counsel is not in the room and the exercise exposes that no one knows the escalation path. The facilitator should be prepared to push back on responses that rely on untested assumptions.
Who Should Be in the Room
The most common mistake in tabletop exercises is restricting attendance to the security team. A ransomware incident, a data breach, or a business email compromise does not affect only the security team. It affects IT operations, finance, communications, legal, and executive leadership. A tabletop that only involves security and IT will not expose the coordination failures that actually slow down real incident response.
Executive involvement is particularly important. Many incident response plans require executive decisions that executives have never actually practised making. When does the CEO need to be called? Who authorises paying a ransom demand, and what is the process for making that decision? Who is the designated spokesperson for media enquiries? These questions should be answered in the exercise, not for the first time during an actual incident. Including executives also signals that incident response is a whole-of-organisation function, not a technical problem for the IT team to solve.
Capturing and Acting on Outputs
The value of a tabletop is in what happens after it. Every gap identified during the exercise should be documented with an owner and a remediation timeline. The incident response plan should be updated to address any procedural gaps. Contact lists should be verified. Missing relationships, such as an external forensics provider that has not been pre-engaged, should be established. If a tabletop produces a good debrief discussion and then no action, the organisation is in the same position it was before the exercise.
We recommend a structured post-exercise review conducted in the week following the tabletop, while observations are fresh. That review should produce a short action register with clear ownership and a commitment to revisit at the next planning cycle. The tabletop itself should be an annual fixture, with the scenario updated each year to reflect changes in the threat environment and in the organisation's infrastructure and third-party relationships.
To discuss designing and facilitating a tabletop exercise for your organisation, contact Cyberlinx at info@cyberlinx.com.au.
Related Articles







