How to Run a Security Tabletop Exercise

Written by: Roxy

Tabletop meetings are opportunities to test out your employees, processes, and procedures to see how a particular scenario would play out.

In this blog post, we’re going to explain how you may want to plan a tabletop meeting, describing the process by starting with the planning phase and then–as if it were different points of a plot in a story–the hook, twist, climax, and resolution.

Plan before you schedule

Before you even schedule your tabletop meeting, define the scope, requirements, and resources available to you for the exercise. Then, depending on the resources and scope, pick the participants and teams involved in the scenarios. The teams should be willing to implement any takeaways.

Starting the meeting

  • Each step that was taken to resolve the scenario
  • Resources and tools used
  • Documentation used (you can even make a rule that only current documentation can be used–and followed exactly–when determining what steps to take so gaps in documentation can be identified)
  • Logs that were pulled
  • Any additional data or reports that were involved
  • Potential areas of improvement to target
  • Goals of the tabletop and how they were achieved (or how they were not)

As you move through the exercise, there are three key aspects of the scenario to cover: the hook, the twist, and the climax. Remember: during these points, keep track of everything that you may want to bring up during the post-tabletop discussion.


  • The initial trigger of the incident–the alert, a user reporting something, a vulnerability finding (from scans or a 3rd party contacting the security team)
  • All the details that would come in with the trigger
  • Logs and reports that are involved
  • What resources are you going to use? Consider who is participating in the tabletop and what they have access to in order to make it more realistic.

Once your scenario’s hook has been established, it’s time to add a twist so the experience doesn’t follow a linear, predictable path. When tabletop scenarios follow an expected path, it leaves little room for anomalies and situations that require a creative solution.


You can also use a twist to create more detail, but it’s not necessary if the scenario is already going to take awhile.

Possible twists to consider:

  • Incomplete or missing logs
  • Unavailable systems or unavailable data
  • Data that has been tampered with and is unreliable


  • Are the steps achievable based on available resources? For example, you can’t use firewall logs if you aren’t able to access them or have not been storing them correctly.
  • Read through any playbooks, policies, or procedures instead of assuming or running off how you do things. Are you following everything as it is written?
  • How efficient are the steps you are taking? What are some additional ways you can resolve the scenario?

After the exercise

  • Were the participants involved able to complete all the tasks required? Do you need additional participants next time? If there were firewall changes involved for example, and nobody in the tabletop meeting could do that, then the networking team may need to be involved next time.
  • Review–What were the takeaways? What needs to be updated as far as the playbooks, policies, training materials, and so on?
  • Where could it have gone wrong? What are potential points of failure for future tabletops?


Just a bunch of infosec nerds with a knack for Splunk. Comic book and Nerf gun fanatics.