What is a tabletop exercise?

A tabletop exercise is a discussion-based exercise in which a team works through a scenario together and talks about the decisions it would take. No systems are touched; what is tested is whether the plan, the roles and the communication hold up.

How long does a tabletop exercise take?

For a company of 10 to 100 people, 90 minutes is a workable length. That leaves room for one scenario with three developments and a debrief of at least 20 minutes.

Who should take part in a tabletop exercise?

The people who would decide and act in a real incident, usually a member of management, the person responsible for IT or security, someone for communications or customer contact, and someone keeping the log. A facilitator with no role in the scenario runs the session.

Does a tabletop exercise count as evidence for an ISO 27001 audit?

A record of participants, scenario, findings and completed actions is useful evidence for the incident management and continuity controls. The auditor mainly looks at whether the improvements were actually followed up.

Tabletop exercise: how to test your incident and continuity plan in 90 minutes

Q: How often should you run a tabletop exercise?

Neither ISO 27001 nor the Dutch Cybersecurity Act sets a fixed frequency for tabletops. The Dutch NCSC advises reviewing the effectiveness of measures periodically, for example once a year, so many organisations exercise at least annually and after major changes.

A tabletop exercise is a discussion of about 90 minutes in which a team talks through a realistic incident and tests whether its incident response and continuity plan gives enough guidance. Nothing is switched off or restored. The outcome is a list of improvements with owners, and evidence of practice for ISO 27001 and, where it applies, NIS2.

A tabletop exercise takes about 90 minutes and shows whether your incident response and continuity plan works before you actually need it. A team sits round a table, is given a scenario in stages and discusses at each stage what it would do, who decides and who communicates what. Nothing is switched off, restored or reported. What you do get is an honest picture of the gaps in the plan and a list of improvements with owners.

Why practising round a table works

An incident response plan or business continuity plan is written at a quiet moment. Only during an incident does it become clear whether the hosting provider's phone number is right, whether anyone knows who may decide to take a customer environment offline, and whether the backup can really be restored within the time you have promised customers.

A tabletop brings those questions forward without anything breaking. The Dutch National Cyber Security Centre (NCSC-NL) describes the tabletop as a discussion-based exercise in which employees run through a scenario together, and stresses that evaluation afterwards is where the improvements come from. An exercise assesses the plan, not the people, so it needs to feel safe to say what nobody knew.

How a tabletop exercise is structured

Every tabletop has the same parts:

Objectives. Two or three concrete questions you want answered, for example: do we know within an hour who decides, and can we meet the recovery time in our continuity plan.
Scenario. A realistic incident that fits your services, split into three or four developments (injects) that make the situation steadily worse.
Participants and roles. The people who would be in the room during a real incident.
Evaluation. A debrief straight after the exercise and a short report with actions.

ENISA's methodology for cybersecurity exercises describes the same lifecycle at a larger scale: plan, run and evaluate.

Roles

Role	What this person does
Facilitator	Keeps time and objectives, introduces the developments and plays the outside world (customer, supplier, press). Has no role in the scenario.
Decision maker	Usually a member of management. Takes the decisions the plan assigns to management.
IT or security lead	Describes what would happen technically and what recovery would require.
Communications and customer contact	Drafts messages to customers, staff and, where needed, regulators.
Note taker	Keeps a log of decisions, times and open questions.
Observer (optional)	Watches where the plan falls short, without joining the discussion. Often the ISMS owner.

This matches the team NCSC-NL recommends for its crisis exercises: a decision maker, someone for internal and external communications, someone for documentation and support, and the person responsible for IT security.

A 90-minute run sheet

0 to 10 minutes, opening. Objectives, ground rules and roles.
10 to 25 minutes, first development. The first signal. Questions: who notices it, who gets called, is this an incident by our own definition.
25 to 45 minutes, second development. The situation grows. Questions: who decides on measures that affect customers, what do we tell customers and when.
45 to 65 minutes, third development. The scenario touches continuity or legal duties. Questions: will we meet the recovery time, do we need to report, to whom and by when.
65 to 85 minutes, debrief. What went well, where the plan had no answer, what needs to change.
85 to 90 minutes, close. Actions with an owner and a date.

The balance between play and evaluation is deliberate. The NCSC-NL ransomware crisis exercise allows 15 minutes for setup, around 45 minutes of play and 30 minutes of debrief. Cutting the debrief short to finish the scenario throws away the part that delivers the most value.

Three example scenarios for a SaaS or hosting company

Ransomware in the management environment

On Monday morning the support team cannot log in to the ticketing system. An hour later it turns out that files on a management server have been encrypted and a ransom note has appeared. Second development: the attacker threatens to publish customer data. Third development: the latest usable backup of the management environment is three days old.

What you test: who decides to isolate systems, whether backups are separated from the environment that was hit, and who assesses whether personal data has been breached. A personal data breach may have to be reported to the Dutch Data Protection Authority within 72 hours, and if your organisation falls under the Dutch Cybersecurity Act (Cyberbeveiligingswet), an early warning to the CSIRT is due within 24 hours.

Cloud provider outage

The region your SaaS platform runs in is unreachable. The provider's status page reports an investigation with no expected recovery time. Second development: after four hours the first customers with a contractual availability commitment start calling. Third development: the provider says recovery may take until the next day.

What you test: whether a fallback exists and who decides to use it, whether the recovery time in your continuity plan is realistic, and how you inform customers if your own status page runs on the same provider.

Data breach at a supplier

The supplier of your customer support software reports that an unauthorised party has had access to tickets. Those tickets contain screenshots with patient data, because one customer uses your healthcare software. Second development: the supplier cannot say which tickets were viewed. Third development: a customer asks for a written statement within a day.

What you test: whether you know which data sits with which supplier, what your contracts say about notification periods, and how you inform your customer in time for them to assess their own reporting duty.

Evaluating and following up

The debrief produces three kinds of findings: what is missing from the plan, what is in the plan but does not work in practice, and what people did not know. Record them in a short report with date, participants, scenario, findings and actions.

Then the real work starts. Every action gets an owner and a date and runs through the normal improvement process of the ISMS. Take the outcomes into the management review. At the next exercise, first check whether the previous actions were completed. An auditor wants to see not that an exercise took place, but that the organisation learned from it.

How it maps to ISO 27001

ISO 27001 does not prescribe a tabletop, but an exercise provides evidence for a set of Annex A controls. In our own words:

Control	Subject	What the exercise shows
5.24	Preparing for incident management	Roles and procedures are known and work.
5.25	Assessing events	The team can decide whether something is an incident.
5.26	Responding to incidents	The agreed approach can be carried out.
5.27	Learning from incidents	Findings lead to improvements.
5.28	Collecting evidence	The team knows what to preserve.
5.29	Information security during disruption	Security holds when normal operations fall away.
5.30	ICT readiness for business continuity	ICT recovery is planned and tested against the objectives in the continuity plan.

Control 5.30 in particular calls for testing. A tabletop does not replace a technical restore test, but it does show whether the people and decisions around that recovery are right. Use both.

Exercising under NIS2 and the Dutch Cybersecurity Act

The Dutch Cybersecurity Act, which implements NIS2 in the Netherlands, has applied since 15 August 2026. Its duty of care covers, among other things, business continuity, such as backup management and recovery plans, and crisis management. NCSC-NL also advises reviewing the effectiveness of measures periodically, for example once a year, and mentions cyber crisis exercises as a way to prepare staff.

The law does not name the tabletop. It is, however, a good place to rehearse the reporting duty: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. Even if you are not in scope yourself, a customer who is may ask how you, as their supplier, exercise.

Getting started

Pick one scenario that fits your services, invite four to six people and book 90 minutes. If you want a starting point, Trustbird offers a free online tabletop module: you upload your own policies and procedures, participants individually answer multiple-choice questions on a scenario built from them, and afterwards you see a summary of the report; the full report is a one-off paid download. An AI-generated report does not replace an auditor. Whatever format you choose, the value lies in the debrief and in the actions you complete afterwards.