How to run a cybersecurity tabletop exercise

Choose one decision boundary the room genuinely owns. "Do we take the ERP offline while encryption is still spreading?" is testable in 90 minutes. "Test our incident response" is not. Write the objective in a single sentence and read it out at the start; everything you cut later gets cut against it.

• One primary objective, at most two secondary ones.
• Name the decision-maker for each objective — if nobody owns it, it is not a decision.
• Agree what a successful exercise looks like with the sponsor before you build anything.

A tabletop is a decision rehearsal, not a technical drill. You want the executives who authorise money, downtime and public statements, plus the technical lead who can say what is actually possible. Eight to twelve participants is the sweet spot; beyond fifteen, split into a decision table and an observer ring.

• Core seats: CEO or MD, CISO or security lead, IT/infrastructure lead, General Counsel, Comms, HR or Ops if people are affected.
• Optional seats: finance (ransom and recovery cost), insurer or broker, key supplier contact.
• Observers and note-takers watch without touching the exercise — give them a view-only seat, not a chair at the table.

Start from a scenario that already holds up under pressure, then make it theirs. Generic injects get dismissed with "that could not happen here". Rewriting injects around the real environment — cloud or hybrid, device estate, sector, regulators — is what turns polite agreement into an argument worth having.

• Match the scenario to a plausible threat for the sector, not the scariest headline.
• Tailor names, systems, suppliers, regulators and reporting deadlines to the organisation.
• Prepare artefacts: the ransom note, the journalist's email, the regulator's enquiry, the supplier's statement.

Set the exercise clock before the first inject and state the ground rules: assume nothing off-screen, no hero solutions, no punishing honest answers. Say clearly whether the exercise is compressed time (four hours of incident in ninety minutes) and how you will signal a jump forward.

• Confirm confidentiality and that no real systems will be touched.
• Explain that private information may go to individual seats only.
• Tell the room you will pause the clock deliberately — it is a facilitation tool, not a failure.

Release staged injects and let the room work. Your job is pressure, not narration: ask who decides, by when, with what authority, and what they will say publicly. When the discussion drifts somewhere more interesting than your script, follow it — an improvised inject that reacts to what was actually said is worth three scripted ones.

• Keep injects short and unambiguous; ambiguity should come from the situation, not the wording.
• Time-box decisions out loud: "you have six minutes before the journalist publishes".
• Note the decisions, the gaps and the moments of hesitation as they happen — you will not remember them later.

Do the hot wash while the room is still in it. Ask each seat for one thing that worked and one thing that would have failed for real. Capture verbatim quotes — they are the most persuasive part of the report.

• Separate process failures from people failures; only one of them belongs in the report.
• Ask what information they wanted and did not have — that list becomes half your recommendations.
• Collect written feedback before people leave the room.

The exercise is the event; the report is the deliverable. It should record the timeline, the decisions taken, the lessons learned, the recommended alternatives, and an owner with a due date for every action. Delivered on the day, it lands while the discomfort is fresh. Delivered a fortnight later, it lands in an inbox.

• Structure: objective, scenario summary, timeline, decisions, findings, recommendations, owners and dates.
• Circulate a web version for the team and a branded PDF for the board.
• Book the follow-up before the report is read, and re-test the same decision boundary next quarter.