Cyber tabletop exercise playbook: plan, run and evidence it

A step-by-step playbook to plan, facilitate and evaluate a cyber tabletop exercise, and turn the after-action report into evidence for NIS2, DORA and CyFun.

This playbook is for CISOs, risk and compliance managers, IT managers and the consultants or MSPs who support them. It assumes you have an incident response plan and a business continuity plan on paper, and you now need to show that they work and that the management body understands its role. By the end you will have planned, run and documented a two- to three-hour tabletop exercise, with an evidence pack that a supervisor or auditor can follow from objective to closed action.

Before you start

Nominate an exercise lead (usually the CISO or the incident manager) and a small planning team of two or three people who will not play. Players who help write the scenario cannot be surprised by it. Collect the documents the exercise will test: the incident response plan, the business continuity and disaster recovery plans, the crisis communication plan, the contact list and the incident notification procedure for your supervisor. Agree with the CEO or managing director that members of the management body will attend at least part of the session. Under NIS2 Article 20 the management body approves the cybersecurity risk-management measures, oversees their implementation and must follow training^[1], so an exercise that only involves IT misses the point.

Phase 1: Define objectives and scope

An exercise without measurable objectives produces a pleasant conversation and no evidence. Write three to five objectives, each phrased so that an observer can later say whether it was met. Tie each objective to a specific plan, control or legal requirement.

• Example: “The crisis team decides within 30 minutes of the relevant inject whether the incident is significant, and drafts the 24-hour early warning.”
• Example: “The business owner of the order platform confirms the recovery priority and accepts or challenges the documented recovery time objective.”
• Example: “The management body takes a documented decision on external communication and on involving law enforcement.”
• Define scope: which sites, services, suppliers and plans are in play, and what is explicitly out of scope (for example, technical containment steps).
• Choose the format: a discussion-based tabletop for this playbook; technical or hybrid simulations can follow later.

Phase 2: Select participants and roles

Keep the player group small enough to talk, typically eight to fifteen people. Every person in the room needs a role.

Role	Who	What they do
Facilitator	Exercise lead or external facilitator	Runs the clock, delivers injects, asks probing questions, keeps the discussion on objectives
Players	Crisis team: management body member(s), IT, security, legal, DPO, communications, HR, business owners	Make decisions as they would in a real incident
Observers / evaluators	One or two people from the planning team or internal audit	Record timestamps, decisions and gaps against the objectives
Simulated parties	Planning team	Play the supervisor, the CSIRT, a journalist, a key customer or the managed service provider

Where a critical supplier (your MSP, cloud host or SOC provider) is part of the scenario, consider inviting them.

Phase 3: Design the scenario and injects

Build the scenario from your own risk register and threat picture, not from a headline. A scenario is a storyline in three or four stages, and each stage is released through injects: short messages, emails, phone calls or screenshots that add information and force a decision. Public packages can help you start. The US Cybersecurity and Infrastructure Security Agency publishes more than 100 free tabletop exercise packages with scenarios, discussion questions, feedback forms and an after-action report template^[5]. ENISA published its Cybersecurity Exercise Methodology with a support toolkit of templates on 16 February 2026^[4]. Adapt either to your organisation and your legal context, since US packages do not cover NIS2 or GDPR deadlines.

• Pick one primary scenario. Useful starting points are ransomware with data exfiltration, a compromise of your managed service provider, business email compromise with a fraudulent payment, and a prolonged cloud or SaaS outage.
• Write 8 to 14 injects, each with a planned release time, the target role, the expected decision and the objective it tests.
• Include at least one inject that triggers a reporting decision (NIS2 significant incident, DORA major ICT-related incident or a GDPR personal data breach).
• Include one curveball, such as an unreachable key person or an incomplete backup.

Phase 4: Prepare the logistics and the facilitator script

Book a room or video call for two to three hours, plus 30 minutes for the hot debrief. Prepare a short slide deck or printed handouts, and a facilitator script that lists, for each stage, the inject text and three or four prompting questions. Send players a short read-ahead one week before: the date, the ground rules, which plans to bring and a reminder that the exercise is “no fault”.

• Agree ground rules: decide with the information you have, assume normal staffing unless told otherwise, and speak as you would in reality.
• Use an accelerated exercise clock so you can cover the first 72 hours.
• Give observers a structured log template with columns for time, inject, decision, owner and gap.

Phase 5: Run the exercise

Open with five minutes on objectives and ground rules, then release the injects according to the script. The facilitator’s job is to ask “who decides?”, “what do you need to know?” and “who do you tell, and when?”, not to give answers.

• Stage 1, detection: an alert or a user report. Who triages, who is told, when is the crisis team convened?
• Stage 2, escalation: impact on a critical service. Is this a significant incident? Who drafts the early warning, and within what deadline?
• Stage 3, external pressure: customer complaints, a press request, a ransom note or a supplier statement. What do you say, and who approves it?
• Stage 4, recovery: restore priorities, recovery time objectives, and when to return to normal operations.
• Close with a 20- to 30-minute hot debrief: what went well, what did not, and what surprised you.

Phase 6: Evaluate against the objectives

Within a week, the planning team scores each objective using the observer logs. A simple four-level scale works well: met, partially met, not met, not tested. For each objective, write down the observed strengths and the gaps, with the evidence that supports the rating. Collect participant feedback forms the same week.

• Separate plan gaps (the document is wrong or missing) from capability gaps (people lacked knowledge, tools or authority).
• Check reporting timeliness explicitly: could the 24-hour early warning, 72-hour notification and one-month final report under NIS2 Article 23 have been met^[1]?

Phase 7: Write the after-action report

The after-action report is the core evidence document. Keep it short: four to eight pages. Someone who was not there should understand what was tested, found and changed.

• One-page summary for the management body, including the decisions they took.
• Objectives, scope, scenario and participants.
• Findings per objective with ratings and evidence.
• Improvement plan: each action with an owner, due date and the plan or control it changes.
• Approval: the report is presented to, and noted by, the management body.

Phase 8: Track improvements and close the loop

Supervisors and auditors look for the link between test, finding and fix. Move every action from the report into your normal risk or action register, review progress monthly, and re-test the riskiest gaps in the next exercise. In Secrato, an exercise is recorded as an assessment, and each action becomes a task linked to the controls it affects, so the closure evidence counts for every framework that relies on those controls.

• Update the plans and version them, noting the exercise as the reason for change.
• Report open actions to the management body until they are closed.

The companion template includes a planning sheet, four scenario outlines with full inject lists, a facilitator script, an evaluation form and an after-action report structure you can complete directly.

How an exercise serves as evidence

NIS2 Article 21(2) requires measures for incident handling, business continuity and crisis management, and policies to assess the effectiveness of your measures^[1]. For the digital infrastructure and service providers it covers, Implementing Regulation 2024/2690 makes this concrete: business continuity and disaster recovery plans must be tested and updated at planned intervals and after significant incidents or changes (Annex point 4.1), the crisis management process must be tested and reviewed (point 4.3), and lessons learned must be fed back after incidents (point 3.6)^[2]. For financial entities, DORA requires ICT business continuity and response and recovery plans to be tested at least yearly, including cyber-attack scenarios and crisis communication plans (Article 11), and lists scenario-based tests among the tools in the digital operational resilience testing programme (Articles 24 and 25)^[3]. A tabletop does not replace technical tests, but it is the most direct way to test people, decisions and communication.

How this connects to other frameworks

ISO/IEC 27001:2022 Annex A controls on incident management and ICT readiness for business continuity expect planned and tested responses; an after-action report is direct evidence for both and for management review. In CyFun and the NIST CSF 2.0, exercises support the Respond and Recover functions. Under DORA, the same report feeds the annual testing evidence.

Frequently asked questions

How often should we run a tabletop exercise?

Neither NIS2 nor the Implementing Regulation fixes a number; they require testing at planned intervals and after significant incidents or changes. DORA requires yearly testing of continuity and response plans. Once a year for the full crisis team, plus smaller technical sessions in between, is a defensible baseline for most organisations.

Does the management body really need to attend?

It is strongly advisable. NIS2 Article 20 makes the management body accountable for approving and overseeing cybersecurity measures. Their attendance, and the decisions they take in the exercise, is some of the clearest evidence of that oversight.

Is a tabletop enough to meet DORA testing requirements?

No. It covers scenario-based testing of decisions and communication, but DORA’s testing programme also expects technical tests such as vulnerability assessments, restore and switchover tests and, for some entities, threat-led penetration testing.