Does NIS2 require a tabletop exercise?

NIS2 does not name tabletop exercises. Article 21 requires risk-management measures including incident handling, business continuity and crisis management, and policies and procedures to assess whether those measures are effective. A documented tabletop is one practical way to show that your incident handling and crisis procedures have been tested, but national transposing laws and supervisors may set more specific expectations, so check them.

Can a tabletop exercise replace DORA threat-led penetration testing?

No. Threat-led penetration testing under DORA Article 26 is a live, intelligence-led test of critical functions on production systems, required only for entities identified by competent authorities. A tabletop is discussion-based and touches no systems. It complements TLPT and the wider testing programme by testing decisions, reporting and coordination, which technical tests do not cover.

Who should attend a NIS2 or DORA tabletop exercise?

At least one member of the management body, the CISO or ICT risk function, the incident lead, legal or compliance, the person responsible for regulatory reporting, communications and the owners of critical services. For DORA, include whoever manages critical ICT third-party providers. Management attendance matters because both texts make the management body accountable for ICT and cybersecurity risk.

NIS2 Tabletop Exercise: Testing NIS2 and DORA Readiness

Q: What are the NIS2 incident reporting deadlines?

Under Article 23 of NIS2, an entity must send an early warning to its CSIRT or competent authority within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month of the incident notification. An intermediate report can also be requested. National laws implement these steps, so confirm the exact channels and formats in your member state.

A NIS2 tabletop exercise is a facilitated discussion in which your incident, legal and management teams work through a simulated significant incident against the real NIS2 reporting clocks: an early warning within 24 hours, a notification within 72 hours and a final report within one month. The same format works for DORA's major ICT-related incident reporting and continuity testing.

Neither regulation names tabletop exercises. What they do require is incident handling, business continuity, crisis management, a way to assess whether those measures work, and accountable management bodies. A well-documented exercise is one of the cheapest ways to produce evidence for all of those at once. This guide covers what the texts ask for, how to design a scenario around the reporting clocks, and what to keep for auditors and supervisors.

Note: This article summarises parts of NIS2 and DORA for exercise design. It is not legal advice; confirm your obligations under your national transposition and applicable technical standards with qualified counsel.

What NIS2 and DORA actually require

Both texts are principle-based. They say what outcomes you need, not which exercise format to use. That is useful: it means you can choose a tabletop where it fits, as long as you can show it tests the right things.

NIS2 (Directive (EU) 2022/2555)

NIS2 is a directive, so it applies through national law. The transposition deadline for member states was 17 October 2024; the details, supervisory approach and reporting portals vary by country. Three articles matter most for exercise design:

Article 20 (governance). Management bodies must approve the cybersecurity risk-management measures, oversee their implementation, and can be held liable for infringements. Members of management bodies must follow training.
Article 21 (risk-management measures). The measures include incident handling; business continuity, such as backup management and disaster recovery, and crisis management; and policies and procedures to assess the effectiveness of the measures.
Article 23 (reporting obligations). For significant incidents: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report within one month of the notification.

DORA (Regulation (EU) 2022/2554)

DORA is a regulation, directly applicable to in-scope financial entities from 17 January 2025. Relevant parts:

Article 5 (governance). The management body is responsible for the management of ICT risk.
Article 11 (response and recovery). Entities need an ICT business continuity policy and response and recovery plans, and must test the ICT business continuity plans and crisis communication arrangements.
Article 19 (reporting). Major ICT-related incidents must be reported to the competent authority through an initial notification, an intermediate report and a final report. The classification criteria and timeframes sit in the accompanying technical standards; read the current versions rather than relying on summaries.
Articles 24–27 (digital operational resilience testing). A risk-based testing programme. Article 25 lists the kinds of tests it can include, and scenario-based tests are among them. Article 26 adds threat-led penetration testing (TLPT) for entities identified by their competent authorities.

What a tabletop can and cannot evidence

Be precise about this in the exercise report, because supervisors will be.

A tabletop can evidence	A tabletop cannot evidence
Roles, escalation paths and decision rights are understood	That backups actually restore within the recovery time objective
The team can classify an incident against NIS2 or DORA criteria under time pressure	That detection controls would have caught the attack
Reporting owners, channels and approvals are known and workable	That technical containment would succeed
The management body understands its role and was involved	That third-party failover works in practice
Gaps were identified and turned into tracked improvements	Resilience of production systems (that needs technical testing, and TLPT where required)

The clean way to position it: the tabletop tests the people and process layer of incident handling, crisis management and reporting. Restore tests, failover tests and penetration tests cover the technical layer. Together they form a testing programme; neither side replaces the other.

Designing a scenario around the reporting clocks

The most valuable thing a NIS2 or DORA exercise can test is whether the organisation can take a messy, incomplete incident and turn it into a correct, approved report on time. Build the scenario so the clocks drive the pace.

Choose an incident that is ambiguous at first

A clearly catastrophic incident is too easy to classify. Pick something that starts small and becomes significant, so the team has to decide when it became aware and whether the thresholds are met. Good candidates:

A compromise at a managed service provider that gradually affects your own service. The third-party vendor breach scenario works well here, and it also tests DORA's ICT third-party risk expectations.
Exfiltration of customer data, where personal-data breach notification under GDPR Article 33 (72 hours, where feasible) runs in parallel with NIS2. The data breach notification scenario is built for exactly this.
A ransomware attack that degrades a critical service. The ransomware scenario in the library can be adapted by adding the reporting injects below.

Use time compression deliberately

The exercise lasts three hours; the clocks run for a month. Jump the scenario clock between modules and tell players where each deadline stands.

Module	Scenario clock	What the injects force
1. Detection and awareness	T+0 to T+6 h	Declare severity; agree and record the moment of awareness; decide whether the incident may be significant or major
2. Early warning / initial notification	T+6 to T+24 h	Draft the NIS2 early warning (and DORA initial notification if in scope); name who approves and who submits; brief the management body
3. Notification and escalation	T+24 to T+72 h	Update the assessment of severity and impact; decide on notifying service recipients; handle a GDPR decision in parallel
4. Final report and lessons	Day 30	Outline the final report: root cause, mitigation, cross-border impact; check the improvement plan feeds it

Injects that test reporting, not just response

Write at least one inject per clock. Examples:

The classification argument. Security says the incident is contained and minor; the service owner reports customers cannot complete transactions. Who decides whether it is significant, using which criteria?
The portal problem. The person who normally submits reports is on leave and nobody else has access to the national reporting portal or the supervisor's template.
The approval chain. The draft early warning is ready at hour 20. The general counsel wants the CEO to approve it; the CEO is on a flight. Does the plan allow a deputy to sign off?
The parallel clock. The data protection officer confirms personal data is involved. Who owns the GDPR assessment, and does it use the same facts as the NIS2 report?
The supervisor calls. The competent authority asks a follow-up question before the 72-hour notification is due. Who speaks for the organisation?

The guide to designing tabletop injects covers how to write these so they force a decision rather than invite a discussion.

Involving the management body

Article 20 of NIS2 and Article 5 of DORA put accountability on the management body. That makes their participation more than a courtesy, and it changes how you design the exercise.

Give them real decisions. Approving a report, accepting a risk of service disruption, authorising external communication. Do not make them spectators to a technical discussion.
Keep their segment short and focused. A 60–90 minute executive module works better than asking the board to sit through a full technical exercise. The executive tabletop guide covers format options.
Record their involvement. Attendance, decisions taken and questions asked are exactly the kind of evidence that shows oversight is active rather than nominal.
Link it to training. NIS2 requires management body members to follow training. An exercise is not a substitute for a training programme, but a well-debriefed one is a strong practical complement and can be recorded alongside it.

Mapping requirements to the exercise

This table is a starting point for the evidence section of your exercise plan. Adapt it to your national transposition and your own control framework.

Requirement	What the exercise tests	Evidence to keep
NIS2 Art. 20: management approval and oversight	Management body takes reporting and continuity decisions in the scenario	Attendance list, decision log with names and times, board minutes referencing the exercise
NIS2 Art. 21: incident handling	Escalation, severity classification, coordination between teams	Scenario, inject list, scribe notes, observed timings
NIS2 Art. 21: business continuity and crisis management	Crisis team activation, prioritisation of critical services, out-of-band communications	Crisis team roster used, continuity decisions recorded, gaps found
NIS2 Art. 21: assessing effectiveness of measures	Whether documented procedures worked as written	After-action report, improvement plan with owners and dates
NIS2 Art. 23: 24 h / 72 h / one-month reporting	Awareness decision, significance assessment, drafting and approving each report	Draft reports produced in the exercise, time each was ready, approval chain used
DORA Art. 11: testing continuity plans and crisis communication	Continuity plan activation, internal and external crisis communication	Plan version tested, communication drafts, findings against the plan
DORA Art. 19: major incident reporting	Classification against DORA criteria; initial, intermediate and final report preparation	Classification worksheet, draft notifications, owner and deputy identified
DORA Arts. 24–25: testing programme	Scenario-based testing of response and recovery procedures	Exercise listed in the testing programme, scope, results and remediation tracking
DORA Art. 26: TLPT	Not tested by a tabletop	Reference to the separate TLPT programme where applicable

Evidence to keep for auditors and supervisors

Supervisors and auditors are generally less interested in how the exercise felt than in whether it was planned, targeted and followed up. A complete pack usually contains:

Exercise plan. Objectives mapped to the requirements above, scope, scenario summary and the plan version being tested.
Attendance. Names, roles and whether each role holder or a deputy attended, including management body members.
Scenario and injects. The full inject list, marked with the reporting clock each one targets.
Decision log. What was decided, by whom, when in scenario time, and on what basis.
Draft reports. Any early warning, notification or classification worksheet produced during the exercise, clearly marked as exercise material.
After-action report. Strengths, gaps and recommendations. The guide to writing a tabletop after-action report gives a structure.
Improvement plan. Each finding with an owner, a due date and a status that is actually updated.
Retest evidence. Proof that fixed items were tested again, whether in the next tabletop or a targeted walkthrough.

Store the pack where it can be retrieved quickly, and mark it with a traffic light protocol label or your own classification: exercise reports describe your weaknesses in detail.

If you run the exercise with a live tool, much of this is captured for you. The site's live exercise runner records player responses and decisions against each inject and exports an after-action report, which removes most of the scribe's transcription work.

Common mistakes in regulatory exercises

Testing the attack, not the reporting. Hours spent on containment detail and ten minutes on the notification is the most common imbalance. If reporting is an objective, give it a module.
Letting "awareness" stay vague. Several deadlines depend on when you became aware. If the exercise does not force the team to decide and record it, you have not tested the clock.
No deputies. Reports are due regardless of holidays. Invite deputies for the reporting owner, approver and spokesperson.
Treating the exercise as the compliance artefact. The artefact that matters is the improvement plan and its closure. An exercise with no follow-up evidences very little.
Overclaiming. Do not describe a tabletop as resilience testing of systems or as a substitute for TLPT. Accurate scoping makes the evidence more credible, not less.

How often to run it

NIS2 does not set an exercise frequency, and DORA's testing obligations depend on the type of test and the entity. A practical baseline many teams use is at least one reporting-focused tabletop a year for the incident and crisis teams, one executive session involving the management body, and an additional exercise after major changes: a new reporting procedure, a new critical provider, a reorganisation or a significant incident. The tabletop exercise compliance requirements page compares frequency expectations across frameworks.