Skip to main content
Oyoon Altaqnya

Article Oyoon Altaqnya security team

Running your first tabletop exercise: a facilitator's checklist

How to plan, run and follow up a cyber tabletop exercise that tests your incident response plan in a meeting room, without touching a single production system.

An incident response plan that has never been exercised is an assumption. It assumes the contact list is current, that the right person can approve shutting a service down at two in the morning, and that someone knows what to tell customers and the regulator. A tabletop exercise tests those assumptions safely: a facilitator presents a realistic scenario in stages, and the people who would really respond talk through what they would do.

NIST describes this kind of discussion-based exercise in SP 800-84, its guide to test, training and exercise programmes. Nothing is switched off, nothing is attacked and no production system is touched. What you get is a clear view of where your plan, your people and your communication would hold — and where they would not.

This checklist covers a first exercise of two to three hours.

1. Set two or three objectives

Objectives decide everything else: the scenario, who attends and how you judge the result. Make them specific enough to answer with yes or no. For example:

  • Confirm who can authorize taking a customer-facing service offline, and how quickly they can be reached.
  • Test how and when we notify management, the regulator and affected customers.
  • Check that the incident response plan’s contact list works outside office hours.

Three objectives is plenty for a first exercise. Base them on your current incident response plan; NIST’s SP 800-61 Rev. 3 is a good reference if the plan itself needs updating first.

2. Choose a scenario that fits your organization

The scenario should be realistic for your sector and use your real systems and names. Good first scenarios include:

  • Ransomware encrypting shared file servers.
  • Business email compromise of a finance manager’s mailbox.
  • A stolen remote-access account used to reach internal systems.
  • Customer data published online after a breach of a web portal.

Avoid the cinematic. A scenario nobody believes produces a discussion nobody learns from. Draw on your risk register and on incidents seen in your sector. If you want a starting point, CISA publishes tabletop exercise packages with template objectives, scenarios, discussion questions and planning documents that you can adapt.

3. Invite the right people — and only them

Invite the people who would make or carry out decisions in a real incident:

  • An executive sponsor who can make business decisions.
  • IT operations and security staff.
  • The owner of the business service in the scenario.
  • Legal or compliance.
  • Communications, for customers, staff and the media.
  • Human resources, if the scenario involves an insider.

Keep the group small enough that everyone speaks. Then assign three roles that are not participants: a facilitator who runs the session, a note-taker who records decisions and gaps, and, if possible, an observer who watches how the group works. The facilitator should not be someone whose own decisions are being tested.

4. Write the injects

An inject is a new piece of information that moves the scenario forward. Four to six injects are enough for a first exercise. Each one needs a short description and two or three questions. A ransomware scenario might run like this:

Inject What participants learn Questions for the group
1 The help desk reports that files on a shared drive will not open. Who is told first? Who decides this is an incident?
2 A ransom note is found on several servers. Do we isolate systems? Who authorizes it, and how do we reach them?
3 The backup administrator is unsure the latest backups are clean. How do we check? What do we restore first?
4 A post on social media claims customer data was stolen. Who speaks for us? What do we say, and to whom?
5 Next morning, a regulator asks for an update. What are we obliged to report, by when, and who signs it off?

Write the injects in your own vocabulary — your system names, your teams, your services — so participants recognize their environment.

5. Set the ground rules

Open the session by agreeing how it will work:

  • No fault. The exercise tests the plan, not individuals.
  • Answer for today. Respond with the people, tools and authority you have now, not the ones you plan to have.
  • Use the real documents. Bring the incident response plan and contact lists into the room and use them.
  • Record, don’t fix. When a gap appears, the note-taker records it and the group moves on. Solutions come afterwards.

6. Run the session

A simple running order:

  1. Welcome, objectives and ground rules — about ten minutes.
  2. Present each inject, then discuss its questions. Ask open questions and push gently for specifics: “Who exactly?”, “How would you know?”, “Where is that written down?”
  3. Watch the clock, and bring quieter participants in by name.
  4. Close with a short summary of decisions and open questions.

The note-taker keeps a simple log with three columns: decisions made, gaps found and questions nobody could answer.

7. Debrief while it is fresh

Hold a debrief, sometimes called a “hot wash”, straight after the exercise. Spend fifteen to twenty minutes on three questions: What worked? What did not? What surprised us? People remember most in the first hour, and this is where the most honest observations come from.

8. Write the after-action report and follow up

Turn the notes into a short after-action report within a couple of weeks. It should state:

  • each objective and whether it was met;
  • what worked well and should be kept;
  • each gap, with an owner and a target date;
  • the changes needed to the incident response plan, contact lists or procedures.

Then track the actions to completion. Book the next exercise before this one fades. Over time, increase the difficulty: a longer scenario, a joint session with executives and technical teams, or a functional exercise that tests real procedures as well as decisions.

Common pitfalls

  • Too big a scenario. Five injects that are well discussed teach more than fifteen that are rushed.
  • Too technical for the room. Executives switch off when the discussion turns into a technical deep dive; keep the technical detail for a separate session.
  • Treating it as an exam. A “pass” teaches nothing. The gaps are the value.
  • No follow-up. An exercise without an action list is a meeting, not an improvement.

How we can help

Our cyber crisis tabletop exercises are designed around your own plans, systems and sector: we write the scenario and injects, facilitate the session, run the debrief and deliver an improvement plan. Where the exercise shows that plans themselves need work, our business continuity and resilience consulting helps you close those gaps.

Sources