Incident Response Tabletop Exercise: 5 Scenarios for Small Teams
A tabletop exercise is a guided discussion of a realistic incident, run around a table in 90 minutes. It is the cheapest way to find gaps in your incident plan, and EU rules increasingly expect it. Here are five scenarios you can run next week.
Why test at all
Testing is built into the rules. DORA requires financial entities to test their ICT business continuity and response and recovery plans at least yearly, including cyber-attack scenarios for most firms (Article 11(6) of Regulation (EU) 2022/2554). For NIS2 digital providers, Implementing Regulation (EU) 2024/2690 requires incident handling roles and procedures to be tested at planned intervals (Annex, point 3.1.3), and business continuity and disaster recovery plans to be tested (point 4.1.4). For everyone else, it is simply the fastest way to discover that the plan says "call the IT manager" and the IT manager is on holiday.
How to run one
- Pick a facilitator who knows the scenario but does not take part.
- Invite the decision-makers: management, IT or your provider, whoever handles communications, legal or the DPO, and finance for payment scenarios.
- Present the scenario in stages ("injects"). After each, ask: what do we know, what do we do, who decides, who do we tell?
- Run the clock. Note when, in exercise time, each reporting deadline would be triggered and met.
- Write down every gap as an action with an owner and a date. That list is the outcome of the exercise.
Scenario 1: Ransomware on a Monday morning
- Inject 1: Staff cannot open files; a ransom note appears on several laptops and the file server.
- Inject 2: Your IT provider finds the attacker had access for two weeks and copied a folder containing customer data.
- Inject 3: A journalist emails asking for comment; the attacker threatens to publish the data.
- Discuss: Who decides to disconnect systems? Are backups offline and when were they last restored? Do we pay? When did the GDPR 72-hour clock start? Are we under NIS2 and, if so, is this a significant incident needing a 24-hour early warning?
Scenario 2: Invoice fraud through a hijacked mailbox
- Inject 1: A supplier calls asking why their last two invoices were not paid; your records show they were, to a new bank account.
- Inject 2: The finance manager's mailbox has a forwarding rule nobody created; MFA was not enabled on that account.
- Discuss: Can the bank recall the payments, and who calls them? Which mailboxes are without MFA? Was personal data in the mailbox accessed, and does that make it a reportable breach?
Scenario 3: Your main cloud provider is down
- Inject 1: Your core SaaS application has been unavailable for three hours; the status page says "investigating".
- Inject 2: After eight hours the provider reports a regional failure with no restore time.
- Discuss: Which business functions stop? What is our recovery time objective and do we have a workaround? Do we have an export of our data? For financial firms: does the outage meet DORA's thresholds for a major incident? See our DORA classification guide.
Scenario 4: The spreadsheet sent to the wrong person
- Inject 1: An employee emails a spreadsheet of 2,000 customers, including dates of birth, to an external address by mistake.
- Inject 2: The recipient does not answer requests to delete it.
- Discuss: Is this a personal data breach? What is the risk to the people affected, and does it require notifying the authority, the people, or both? Who documents the decision? See GDPR breach notification.
Scenario 5: A supplier is compromised
- Inject 1: Your managed IT provider tells you its remote management tool was breached, and attackers may have reached client environments.
- Inject 2: You find unknown admin accounts on two servers.
- Discuss: What access does the supplier have to us, and can we revoke it now? Does the contract require them to notify us and help? Which of our reporting duties start, and from when? See NIS2 supply chain security.
| Clock | Starts | Deadline |
|---|---|---|
| GDPR notification to the authority | When you become aware of a personal data breach | 72 hours, where feasible |
| NIS2 early warning | When you become aware of a significant incident | 24 hours |
| DORA initial notification | When you classify an ICT incident as major | 4 hours (and within 24 hours of awareness) |
| CRA early warning (manufacturers) | When you become aware of an actively exploited vulnerability or severe incident | 24 hours |
After the exercise
Within a week, turn the gap list into owned actions, update the incident plan and contact list, and schedule the next exercise. Record that the exercise took place, who attended and what changed: under NIS2 and DORA, that record is evidence of testing.
Start with the plan: if you do not have one yet, our guide to writing an incident response plan gets you to a first version.
Plans to test against. The Incident Response Playbook includes three further tabletop exercise scenarios, a master incident response plan, six scenario playbooks (ransomware, data breach, business email compromise, DDoS, insider threat, third-party incident), regulatory notification templates and a post-incident review template.
Sources
- Regulation (EU) 2022/2554 (DORA), Article 11(6), EUR-Lex
- Commission Implementing Regulation (EU) 2024/2690, Annex, points 3.1.3, 4.1.4 and 4.2.6, EUR-Lex
- Regulation (EU) 2016/679 (GDPR), Article 33; Directive (EU) 2022/2555 (NIS2), Article 23, EUR-Lex
Related tools
Further reading: How to Write an Incident Response Plan · NIS2 Incident Reporting
ClevSec
Compliance & security tools for modern businesses
We build practical tools and templates that help startups and SMBs stay compliant with NIS2, GDPR, and DORA. Explore our free tools →
This article is for informational purposes only and does not constitute legal advice. Last updated: October 2026.