A cyber tabletop exercise is a facilitated, discussion-based session where your team works through a realistic cyber incident in real time, making the decisions they would face in a genuine breach, without the pressure of it being real. Done well, it exposes the gaps that technology alone cannot: who decides, who is told, and how fast.
This guide covers how to plan, run, and follow up a tabletop exercise that actually changes behaviour, based on how we run facilitated cyber exercising for UK organisations.
Why tabletop exercises matter
Most breaches do not succeed because of a clever exploit. They succeed because of a slow or wrong human decision, a payment approved on a spoofed email, an alert ignored on a Friday afternoon, a regulator notification delayed past the 72-hour deadline. A tabletop exercise rehearses exactly those decisions, so that when the real thing happens your people have already made them once.
It is also one of the few security activities that engages leadership directly. Firewalls are invisible to a board; a tabletop where the CEO has to decide whether to pay a ransom is not.
Before the exercise: preparation
Set one clear objective
Decide what you are testing before you write anything else. Common objectives include: does our incident response plan survive contact with reality, do people know their roles, and can we make the regulatory notification decision in time? One sharp objective beats five vague ones.
Pick the right people
Invite the people who would actually make decisions in a crisis, not just IT. That usually means a senior leader who can authorise money and public statements, someone from finance, whoever owns communications, an operations lead, and IT or your security provider. Eight to twelve people is a good range.
Choose a realistic scenario
The scenario should reflect a threat your organisation would genuinely face. Ransomware via a compromised supplier, a business email compromise redirecting a payment, or a data leak involving your most sensitive records all work well. Ground it in your real systems and suppliers, a generic scenario gets generic answers.
Running the exercise
Start with the ground rules
Open by making it safe. State clearly that this is a rehearsal, not a test, and that "I do not know" is a valid and useful answer. People learn nothing if they are performing.
Deliver injects, not lectures
An inject is a short piece of new information that moves the story forward, an email, an alert, a ransom note, a journalist's call. Deliver one, then step back and let the room decide what to do. Resist the urge to narrate; the silence while people work out who is in charge is where the learning happens.
Capture decisions as they happen
Keep a running log of what was decided, by whom, and when. This decision log is the single most valuable output; it shows exactly where the team was fast, where it hesitated, and where the plan broke down.
The five decisions to pressure-test
- Who declares an incident, and how fast? Ambiguity here costs hours.
- Isolate systems or keep trading? The business and security answers often conflict.
- When does the regulator "aware" clock start? Under UK GDPR a notifiable breach must be reported to the ICO within 72 hours of becoming aware.
- Pay the ransom or refuse? Decide the posture before you are under a deadline.
- Who tells staff, customers, and the press, and in what order? Getting this sequence wrong turns an incident into a reputation crisis.
After the exercise: the follow-up
The exercise is worthless without a written follow-up. Within a week, produce a short report: what worked, the specific gaps found, and a small number of owned, dated actions. Assign every action to a named role with a deadline. Then schedule the next exercise. Resilience is a habit, not an event.
Common mistakes to avoid
- Making it a test people can fail. Fear kills honesty, and honesty is the whole point.
- Letting IT dominate. If the technical team answers everything, the leadership decisions never get rehearsed.
- No written output. A great discussion that is never captured changes nothing on Monday.
- A scenario that could not happen to you. Realism is what makes the lessons stick.
The three types of tabletop exercise
Not every exercise has the same audience, and running the wrong type is the most common reason a session falls flat.
Executive (strategic). The board and senior leadership. The content is deliberately non-technical: reputational exposure, regulatory notification, ransom posture, customer and press communication, and when to invoke legal or insurance. Typically 60 to 90 minutes. If your CEO has never had to say the words "we are not paying" out loud, this is the exercise you need.
Operational (managerial). Heads of IT, security, operations, comms, HR and finance. This tests hand-offs between functions, the seams where real incidents fail. It is the most useful type for most organisations, because it rehearses coordination rather than either strategy or tooling.
Technical. The security and IT team, working through containment, forensics, evidence preservation and recovery sequencing. Closest to a technical drill, and the only type where deep tooling knowledge is assumed.
A mature programme runs all three on different cycles. If you only ever run one, run the operational exercise.
How long, how often, and in what format
Sixty to 180 minutes is the practical range, with a half-day the most common commercial format. Under an hour you cannot build pressure or reach the second-order decisions; beyond three hours attention degrades and the learning curve flattens.
On cadence, the honest baseline is annually, but annual-only exercising has a known weakness: the team that performs well in November has forgotten the lessons by the following summer. A better pattern is one substantial facilitated exercise a year, supported by short 15-to-30-minute micro-drills each quarter that rehearse a single decision. Regulated firms, and organisations that have had a near-miss, should exercise more often.
Remote exercises over Teams or Zoom work well for distributed teams and cost less, but they lose some of the interpersonal signal, the glance across the table when nobody wants to own a decision. In-person is better for executive sessions and for a first exercise. Hybrid is the hardest to facilitate well, because remote participants tend to go quiet; if you must run hybrid, give remote attendees a named role and call on them directly.
Should you facilitate it yourself?
You can, and for a first internal exercise it is a reasonable way to start. Self-facilitation is cheap, easy to schedule, and builds internal capability.
The limits are real, though. An internal facilitator is usually a participant in disguise: they know the answers, they have a stake in the outcome, and they will find it hard to let a senior colleague sit in uncomfortable silence. The most valuable moments in an exercise are precisely those silences. An external facilitator can also ask the question nobody internal will ask, "who actually signs this off?", without career consequences, and can benchmark what they see against other organisations.
A practical compromise: self-facilitate the quarterly micro-drills, bring in a facilitator for the annual exercise.
A worked example: ransomware via a compromised supplier
Here is a complete inject timeline for a 90-minute operational exercise. Times are from the exercise start, not the clock.
T+0. Supplier email. Your finance team receives an invoice from a genuine supplier, from the supplier's real domain, with changed bank details. *Decision: who verifies, and through which channel?*
T+20. IT alert. Endpoint protection flags unusual encryption activity on a file server. Two members of staff report that documents will not open. *Decision: who declares an incident, and do you isolate?*
T+45. Ransom note. A note appears demanding payment in cryptocurrency within 72 hours, claiming 400GB of data has been exfiltrated including HR records. *Decisions: ransom posture, whether this is now a personal data breach, when the ICO clock starts.*
T+70. Journalist. A trade publication calls the main switchboard asking about "a significant outage". *Decision: who speaks, what is said, and who must be told internally before anything is said externally.*
T+90. Regulator prompt. Your data protection lead asks whether the ICO has been notified, and on what basis the decision was made. *Decision: notify, or document the reasoned decision not to.*
Notice the shape: each inject forces a decision that crosses functions, and the later injects punish vagueness in the earlier ones. That is deliberate. If nobody owned the incident at T+20, the press question at T+70 lands in chaos, and the room learns why ownership matters far better than any slide could teach them.
What good looks like: measuring the exercise
Most exercises are assessed on whether people enjoyed them. That tells you nothing a board can act on. Measure decisions instead:
- Time to first decision. How long from the first inject until the room commits to any action at all. Long gaps usually mean nobody knows who owns it.
- Time to declare an incident. The single most predictive metric for real-world outcome. Ambiguity here delays everything downstream.
- Time to start the regulatory "aware" clock. Under UK GDPR you have 72 hours from awareness. Teams routinely fail to notice that the clock has started.
- Decision reversals. Decisions made and then unmade point to unclear authority rather than to bad judgement.
- Longest decision silence. The biggest gap with no logged action. Long silences mark the places your plan does not cover.
- Participation spread. If two people made every decision, your resilience depends on two people being available.
Capture these live, with timestamps. Retrospective recollection is unreliable and generous.
Mapping exercises to frameworks and regulation
One of the most valuable and least-used outputs of a tabletop is compliance evidence. A well-documented exercise, with a timestamped decision log, is defensible evidence that you test your arrangements, and several frameworks ask for precisely that.
NIST CSF 2.0: the Respond and Recover functions expect response planning, communication and analysis to be exercised, not merely documented.
ISO/IEC 27035: incident management explicitly requires testing and continual improvement of the incident response process.
NCSC Cyber Assessment Framework (CAF): objective D, Minimising the Impact of Cyber Security Incidents, covers response planning and testing; UK public sector and critical national infrastructure organisations are assessed against it.
UK GDPR: Article 32 requires a process for regularly testing the effectiveness of technical and organisational measures. Article 33's 72-hour notification duty is the single decision most worth rehearsing.
DORA: for in-scope UK and EU financial entities, digital operational resilience testing is a formal requirement, and evidence of exercising is expected rather than optional.
NIS2 and the UK's Cyber Security and Resilience regime: both push in the same direction: demonstrable testing, not paper plans.
The practical implication is that you should record, for each exercise, which control areas the scenario actually exercised, and which of those the team demonstrably handled. "We ran an exercise" is weak evidence. "We exercised incident declaration, regulatory notification and supplier compromise, and here is the timestamped log showing how each was handled" is strong evidence.
The post-exercise report
Write it within five working days, while memory is fresh and momentum survives. A report that lands three weeks later changes nothing. Keep it short, six to ten pages is plenty, and structure it as follows:
1. What we exercised. Scenario, objectives, participants, date and duration.
2. What happened. A factual timeline drawn from the decision log, without commentary.
3. What worked. Name it specifically and name the people. Exercises that only produce criticism do not get repeated.
4. Gaps found. Each one described as an observable fact, not a judgement of a person.
5. Prioritised actions. A small number, five or six at most, each with a named owner and a date. Twenty recommendations guarantee that none are done.
6. Framework coverage. Which controls the exercise evidenced, for your auditor or board.
Send it to participants as well as to the board. People who took part are far more likely to act on findings they can see written down accurately.
A simple first exercise you can run next month
If this all feels like a lot, start small. Book 90 minutes. Invite eight people who would genuinely be involved. Use the ransomware-via-supplier timeline above as written. Appoint someone who is not a decision-maker to keep the decision log with timestamps. Run the five injects, resist explaining, and finish with 15 minutes of open debrief asking one question: what would we change before this happens for real?
That exercise costs you one morning and will almost certainly surface something important. The organisations that handle real incidents well are rarely the ones with the best plans. They are the ones that have practised.