It is 02:40 on a Saturday and the warehouse system will not start. By 08:00 your CEO, your IT lead and your lawyer are on a call, and nobody is sure who decides what. A tabletop exercise is how you make sure that call goes well, because you have already had it once, in a meeting room, with coffee and no real damage.
This guide shows you how to plan and run a cyber tabletop exercise from start to finish. It includes a ready-to-use ransomware scenario with five injects, the regulatory reporting decisions your team will face under NIS2 and GDPR, and an after-action report template you can copy.
What a tabletop exercise is (and is not)
A tabletop exercise is a facilitated, discussion-based session. A small group of decision-makers walks through a realistic incident, one development at a time, and talks through what they would do. Nothing is switched off, no systems are touched and nobody is graded on technical skill.
It is not a penetration test or a technical drill; those test your controls. A tabletop tests your decisions, communication and plans: who is in charge, who calls whom, what you tell customers, and when you notify regulators.
If you have an incident response plan, the exercise shows whether it works under pressure. If you do not, it shows why you need one. Our guide What is Incident Response? IR Phases Explained is a good starting point for the plan itself.
Set clear objectives first
Write three to five specific, observable objectives. They keep the discussion focused and give you something to measure afterwards. For example:
- Confirm who has authority to declare a major incident and to isolate business-critical systems.
- Test whether the team can decide, within the exercise timeline, if the incident is “significant” under NIS2 and whether a personal data breach must be notified under GDPR.
- Validate the escalation path to senior management, the board and external partners (insurer, legal counsel, incident response retainer).
- Check that a holding statement for customers and staff can be agreed within an agreed time.
- Identify gaps in backup and recovery assumptions for the top three business services.
Avoid objectives like “improve resilience”. You cannot observe that in a two-hour session.
Roles: facilitator, players and observers
A tabletop runs on clearly separated roles. Keep the group small enough to talk: 8–15 players is a practical range for a management-level exercise.
| Role | Who | What they do |
|---|---|---|
| Exercise lead / planner | Security or risk manager | Owns the objectives, scenario design, logistics and the after-action report. |
| Facilitator | Neutral person, internal or external | Presents injects, asks questions, keeps time, draws out quiet voices and stops the group from “solving” the scenario too fast. Does not play. |
| Players | CEO or deputy, IT/security lead, legal, DPO, communications, operations, HR, finance | Respond as they would in a real incident, using real plans and real contact lists. |
| Observers / evaluators | Internal audit, a second security team member, an external trainer | Do not speak during play. Record decisions, timings, gaps and assumptions against the objectives. |
| Scribe | Any reliable note-taker | Keeps a timestamped decision log that feeds the after-action report. |
The facilitator matters most. Choose someone curious, not judgemental, and ideally not the CISO, because players tend to defer to them.
Planning timeline
You can run a simple tabletop with two weeks of preparation, but six to eight weeks gives you time to tailor the scenario and secure senior diaries.
| When | Task |
|---|---|
| 8 weeks before | Agree sponsor (ideally a board member or CEO), scope and objectives. Book players and a 2–3 hour slot. |
| 6 weeks before | Choose the scenario. Collect your incident response plan, crisis communication plan, contact lists, cyber insurance terms and business impact analysis. |
| 4 weeks before | Write the injects and discussion questions. Map each inject to at least one objective. |
| 2 weeks before | Dry run with the facilitator and one trusted player. Brief observers on what to record. |
| 1 week before | Send players a short invitation: purpose, date, ground rules. Do not send the scenario. |
| Exercise day | Run the session, then a 20–30 minute “hot wash” debrief while memories are fresh. |
| Within 2 weeks after | Issue the after-action report and improvement plan, with owners and due dates. |
Ground rules to read out at the start
- This is a no-fault environment. We are testing plans, not people.
- Respond with the resources and information you actually have today.
- Decisions under uncertainty are normal. If you would ask for information, say so and say who you would ask.
- The facilitator may compress time between injects.
- What is said in the room stays in the room; the report records gaps, not names.
Sample scenario: weekend ransomware at a mid-sized company
Setting: You are a 400-person manufacturing and distribution company operating in several EU countries, including Italy. You fall within the scope of NIS2 as an important entity. You use a mix of on-premises servers and cloud services, and you hold customer and employee personal data. Adapt the details to your own organisation.
Inject 1 – Saturday 02:40: systems will not start
The night-shift supervisor reports that the warehouse management system shows an error and several office PCs display a ransom note. The on-call IT technician confirms that file shares are encrypted and the backup server console is unreachable.
Discussion questions:
- Who is called first, and who is called second? Is the on-call list up to date?
- Who has authority to disconnect sites or shut down systems, at 02:40 on a weekend?
- Do you preserve evidence before you start restoring? Who knows how?
- When do you contact your cyber insurer and your external incident response provider? Does the policy require you to use a specific firm?
Inject 2 – Saturday 09:00: the scope grows
The incident response provider confirms ransomware on domain controllers. Logs suggest the attackers had access for at least ten days. Large outbound transfers to an unknown cloud storage service were recorded two days ago. Shipping has stopped at two of three sites.
Discussion questions:
- Who formally declares a major incident and convenes the crisis team?
- What is the business impact by hour? Which customers are affected first?
- How do the crisis team members communicate if email and Teams are compromised?
- When does the CEO inform the board?
Inject 3 – Saturday 14:00: the regulatory clock
Your DPO points out that the exfiltrated file share contained HR records (including payroll and sick-leave data) and a customer database. The legal team asks when the company “became aware” of the incident, because that is when the reporting deadlines start.
Discussion questions:
- Is this a significant incident under NIS2? It has caused severe operational disruption, so the answer is very likely yes. Who makes that call, and is it documented?
- The NIS2 early warning is due without undue delay and in any event within 24 hours of becoming aware. Who submits it, through which portal, and with which login? (In Italy, NIS entities notify CSIRT Italia, the national CSIRT run by ACN.)
- Is this a personal data breach under GDPR? If it is likely to result in a risk to individuals, the supervisory authority (in Italy, the Garante) must be notified without undue delay and, where feasible, within 72 hours. Who drafts it?
- Is the risk to individuals high? If so, GDPR Article 34 requires you to inform the affected employees and customers without undue delay. What do you tell them, and how?
- If you are a financial entity, does DORA apply instead of, or alongside, NIS2? Who checks?
For the details behind these decisions, see our guides to the NIS2 Directive and GDPR data breach 72-hour notification.
Inject 4 – Sunday 10:00: extortion and media
The attackers email the CEO directly. They demand payment in cryptocurrency and post a sample of HR files on their leak site with a five-day countdown. A trade journalist calls the press office asking for comment. Employees are discussing it on a WhatsApp group.
Discussion questions:
- Who decides on the company’s position on the ransom demand, and on what basis? When do you involve legal counsel, the insurer and law enforcement?
- What is the holding statement for the media, customers and staff? Who approves it?
- How do you stop staff from posting details, without creating panic?
- Does the leak change your GDPR assessment of risk to individuals?
Inject 5 – Monday 08:00: recovery and the 72-hour mark
Clean backups from eleven days ago are available, but restoring the warehouse system will take an estimated four days. A major customer threatens to switch suppliers. The NIS2 incident notification (due within 72 hours of awareness) and the GDPR notification are both approaching their deadlines.
Discussion questions:
- Which services are restored first, and who agreed that priority in advance?
- How do you make sure you are not restoring the attacker’s access along with the data?
- What goes into the NIS2 72-hour notification: initial assessment of severity and impact, and indicators of compromise where available?
- Who owns the NIS2 final report, due no later than one month after the incident notification?
- What do you tell the board today, and what will you ask them to approve?
For prevention measures to discuss in the debrief, see How to Prevent Ransomware Attacks in 2026.
Regulatory reporting decisions at a glance
Give players this table as a handout after Inject 3, or keep it for the debrief if you want to test whether they know the deadlines unaided.
| Regime | Trigger | Deadline | Recipient (Italy example) |
|---|---|---|---|
| NIS2 Art. 23 – early warning | Significant incident | Without undue delay, within 24 hours of becoming aware | CSIRT Italia (ACN) |
| NIS2 Art. 23 – incident notification | Significant incident | Without undue delay, within 72 hours of becoming aware | CSIRT Italia (ACN) |
| NIS2 Art. 23 – final report | Significant incident | No later than one month after the incident notification | CSIRT Italia (ACN) |
| GDPR Art. 33 | Personal data breach likely to result in a risk to individuals | Without undue delay and, where feasible, within 72 hours of becoming aware | Garante per la protezione dei dati personali |
| GDPR Art. 34 | Breach likely to result in a high risk to individuals | Without undue delay | Affected individuals |
Two points often surprise players. First, the NIS2 and GDPR clocks run in parallel, to different authorities, with different content. Second, sector rules such as DORA for financial entities set their own timelines. The European Commission has proposed a single reporting entry point as part of its broader Digital Omnibus package, but as of October 2026 that proposal has not been adopted, so today’s separate notifications still apply.
This is general guidance, not legal advice.
After-action report template
The exercise is only worth the time if it produces changes. Issue the after-action report (AAR) within two weeks. Keep it short and specific.
- Exercise overview: date, duration, scenario summary, participants by role (not by name, if you prefer).
- Objectives: list each objective and rate it: met, partially met, not met.
- What went well: three to five strengths with examples, so they are kept.
- Gaps and observations: for each, describe what happened, why it matters and which objective it relates to.
- Decision log: key decisions with the time they were made in the scenario.
- Improvement plan: a table of actions with owner, due date and priority.
- Next exercise: proposed date and scenario, to test the fixes.
| # | Gap | Action | Owner | Due | Priority |
|---|---|---|---|---|---|
| 1 | No one knew who submits the NIS2 early warning | Name primary and backup submitters; test portal access | CISO | 30 days | High |
| 2 | Crisis team relied on corporate email | Set up and test an out-of-band communication channel | IT lead | 45 days | High |
| 3 | No pre-approved holding statement | Draft templates for customers, staff and media | Communications | 60 days | Medium |
Two common mistakes: letting the scenario be “won” (if the backups always work, you learn nothing) and issuing an AAR without owners and dates, which makes it a souvenir rather than an improvement plan.
Free resource: CISA Tabletop Exercise Packages
If you want ready-made material, the US Cybersecurity and Infrastructure Security Agency (CISA) publishes CISA Tabletop Exercise Packages (CTEPs). CISA states that more than 100 packages are available, covering cyber scenarios such as ransomware, insider threats, phishing and industrial control system compromise, as well as physical and cyber-physical scenarios. Each package includes template objectives, scenarios, discussion questions and reference material, and CISA provides supporting documents such as invitation templates, a slide deck, a feedback form and an after-action report template.
The packages are written for a US context, so swap US reporting requirements for NIS2, GDPR and your national rules before you use them in Europe.
AceFortis runs practical cyber tabletop exercises for management teams and boards, with scenarios tailored to NIS2, GDPR and your sector — get in touch to plan a session.
FAQ
How long should a cyber tabletop exercise last?
For a management team, two to three hours of play plus a 20–30 minute debrief works well. Longer sessions lose senior attention; shorter ones rarely get past the first decisions.
How often should we run one?
At least once a year at management level, and again after major changes such as a new incident response plan, a merger or a move to a new core system. NIS2 expects management bodies to oversee cybersecurity risk management, and exercises are practical evidence of that oversight.
Should the board take part?
Ideally, yes, at least once. A shorter board-level session focused on strategic decisions, such as the ransom question, disclosure and business continuity, is often more effective than including board members in the full operational exercise.
