NIS2 incident response exercises and tabletop testing, what to test

NIS2 incident response exercises: what your organization must test and prove

A significant incident can start the 24-hour early warning clock with no tested process behind it. NIS2 requires incident response procedures, communication plans with the CSIRT or competent authority, and continuity, disaster recovery and crisis plans to be tested at planned or regular intervals. The organization owns this testing. A supplier can help design and run exercises, but the management body and the entity's own staff must be able to show that the plans work and that the people named in them know their roles.

Implementing Regulation (EU) 2024/2690 sets the detail for the entities it covers, including DNS, TLD, cloud, data center, CDN, managed and managed security service providers, online platforms and trust service providers. Those entities must also test after significant incidents or significant changes, and the crisis management process must define roles and reporting timelines to authorities. Every other in-scope entity should check the same expectations against its own size, sector and number of reporting authorities, because these set how many scenarios, participants and cross-border reporting paths the exercises must cover. Confirm with your national competent authority which testing expectations apply to you.

NIS2 creates no certificate of compliance. An independent auditor, where one is engaged, or the national competent authority, through inspections and information requests, will assess the evidence: dated exercise plans, scenario scripts, attendance records, timestamps showing whether the early warning and notification were drafted in time, and documented lessons learned with follow-up actions. Ask any implementation partner to produce these records as part of the agreed scope, and keep them current, because a plan tested once and never revisited will not satisfy a supervisor reviewing the next significant incident.

How to design a NIS2 exercise programme

This sequence turns NIS2 incident response from a document into a tested capability, with dated plans, recorded decisions and a gap register that feeds updates to the response, continuity and crisis plans.

Set the test calendar and scope
The management body or the person accountable for the Article 21 measures sets a dated exercise calendar covering incident response, continuity, disaster recovery and crisis plans, and names the systems, services and sites in scope. Testing must happen at planned intervals, so the calendar should show when each plan is next tested and which trigger events, such as a significant incident or a significant change, force an unscheduled test. The output is a dated test plan with an owner, participants and the plans it covers. You know it is done when every response, continuity and crisis plan appears on the calendar with a named owner.
Pick scenarios from your incident categories
Build each scenario from the incident categories and severity thresholds already in your response plan, not from generic examples. Include at least one scenario that could become a significant incident, one that tests containment and recovery, and one that involves a supplier or managed service provider. Where a recurring pattern could meet the aggregation rule for significance, add a scenario with repeated low-impact incidents that share an apparent root cause. The output is a scenario record listing the trigger, assumed facts, injects, decision points and the plans tested. You know it is done when each scenario maps to a documented incident category and the reporting decision it tests.
Run a tabletop with decision makers
Convene the people who make the calls: the management body representative, the crisis lead, the security lead, legal, the data protection contact, communications and the operations owner for the affected service. Walk through the scenario in timed injects, and require each participant to state the decision, the information they need and who they inform. Cover communication with the CSIRT or competent authority, roles in the crisis, and measures to keep systems secure during the crisis. The output is a participant log recording attendance, decisions, open questions and time taken for each decision. You know it is done when every decision point has a recorded owner and outcome.
Run a technical or functional drill
Test the parts of the response that a tabletop cannot prove, such as isolating an affected segment, revoking credentials, restoring from backup or failing over a service. Use a controlled environment or a planned window agreed with system owners, and record what was actually done, not what the runbook says should be done. Check that containment, eradication and recovery steps produce the evidence your reporting depends on, such as log exports, timestamps and affected-asset lists. The output is a functional drill record with commands or actions taken, timestamps, evidence captured and deviations from the runbook. You know it is done when each containment and recovery step is either confirmed or logged as a gap.
Rehearse the early warning and notification
Rehearse the 24-hour early warning and the 72-hour incident notification as separate timed exercises, starting from the moment the scenario says the entity became aware of the significant incident. Draft the early warning and notification from the information available at that point, including what is known, what is unknown and whether the incident may be caused by unlawful or malicious acts, and send them through the channel named in your plan. Include the one-month final report in a later round so that the intermediate content is reviewed for consistency. The output is a timed reporting record showing the awareness time, each draft, the submission time and any missing fields. You know it is done when each deadline is measured against the recorded awareness time, not against the end of the exercise.
Record gaps in a gap register
Consolidate findings from the tabletop, the drill and the reporting rehearsal into a single gap register. Each entry should state the observed gap, the plan or control it affects, the root cause where it can be identified, an owner and a target date agreed by the owner. Where the exercise surfaced a pattern of similar weaknesses, check it against the quarterly assessment of recurring incidents, since repeated low-impact events may need to be treated under the aggregation rule. The output is a gap register with owners and dates. You know it is done when every finding is either assigned to an owner or formally accepted by a named decision maker with a recorded reason.
Update plans and document lessons learned
Update the affected response, continuity, disaster recovery and crisis plans, then write a post-incident style lessons learned record for the exercise. Where the root cause could be identified, document it, and state what changed in roles, communication contacts, reporting templates or technical procedures. Keep version history so an assessor or supervisor can see that the plans changed after testing, not before. The output is revised plan versions and a signed lessons learned record. You know it is done when each closed gap points to a changed plan or control and the next test date is set for the plan.

Rehearsing the 24-hour early warning and 72-hour notification

The 24-hour early warning and 72-hour notification under Article 23(4) are short clocks that start when the organization becomes aware of a significant incident. Rehearsal turns them from a deadline on paper into a sequence people can execute under pressure, with decisions, templates and channels already in place.

Start the clock at awareness

Run the drill from the moment a scenario alert reaches the on-call person, not from the moment a manager agrees the incident is serious. The Article 23(4)(a) early warning is due without undue delay and in any event within 24 hours of becoming aware of a significant incident, so the exercise must test how long it takes to recognize awareness. Record the start time in the drill log and check whether staff know what counts as awareness in your organization.

Prepare the report template

Keep a pre-approved early warning template and a 72-hour notification template that list the fields the competent authority or CSIRT will ask for, such as the entity, the incident's apparent cause, the affected services and whether the incident may be cross-border. During the drill, staff should fill in the template from known facts only, mark unknown fields as unknown and update them later. Confirm the current field requirements with your national competent authority.

Name approvers and backups

Assign a named person who decides significance, a person who approves each report and a backup for each role, with contact details that work outside office hours. Rehearsals should include the case where the primary approver is unavailable, because a report waiting on one person can miss the 24-hour window. Decide in advance who may submit when the approver is unreachable, and document that authority.

Test the reporting channel

Confirm how your national authority accepts early warnings and notifications, whether through a portal, a form or a secure email address, and test that channel before the drill. Check that accounts, certificates and credentials work for the people who would submit, and that no step depends on a system the incident might take down. Use a test submission only where the authority allows it, and confirm the process with the authority directly.

Record the time each step took

Capture timestamps for awareness, significance decision, template completion, approval, submission and acknowledgment, then compare them with the 24-hour and 72-hour limits. The log shows which step consumed the most time and gives you evidence that the process was tested at planned intervals. Feed slow steps into the post-incident review and the next update of the response plan.

Keep the decision with the organization

The organization decides whether an incident is significant and submits its own reports. Rehearsals should show that the entity makes that determination against its criteria, not that a managed security provider or consultant files on its behalf without the entity's approval. A provider may prepare drafts and monitor the clock, but the accountable decision and submission stay with the entity's named roles.

Tabletop, functional and full-scale exercises compared

A tabletop exercise is a structured discussion in which participants talk through a realistic but invented incident scenario and decide what they would do at each stage. No systems are touched. The purpose is to test decisions, roles, escalation paths and the wording of communications, including whether the team can determine significance and prepare the 24-hour early warning and 72-hour notification inside the required windows. The Implementing Regulation expects incident response procedures to include communication plans with the CSIRT or competent authority and to be tested at planned intervals, and tabletops are the usual way to meet that expectation for the decision layer.

Who attends: the management body or a delegate, the incident response lead, legal, communications, the data protection officer and business owners of the affected services.
What it proves: that people know who decides, who notifies, and what information the reports must contain.
Typical evidence: the scenario, a timed log of decisions, attendance records, draft notifications produced during the session and an action list with owners.
When it fits: early in the program, after a plan change, and when new management members or new suppliers join the response chain.

After each session, check that the action list was closed and that the plan, contact lists and templates were updated where the exercise found gaps.

Quarterly reviews for recurring incidents

The quarterly review is where an entity checks whether small incidents it has been treating one at a time are, taken together, a significant incident under NIS2. Implementing Regulation (EU) 2024/2690 requires covered entities to assess the existence of recurring incidents on a quarterly basis (Annex, point 3.4.2(b)). Article 4 of the regulation sets the trigger: incidents that are individually not significant count as one significant incident if they occur at least twice within 6 months, share the same apparent root cause, and together meet the financial loss threshold. The review therefore has to look back across the incident log for the previous 6 months, not just the last quarter, and it has to test all three conditions for each cluster of incidents.

The review record should show the period covered, the incident log extract used, and the grouping logic applied. For each candidate cluster, record the incident identifiers, the dates of occurrence, the apparent root cause with the reasoning behind it, and the financial loss estimate with its basis. Where the cluster meets all three conditions, the record must show the decision to treat it as a significant incident and the consequent start of the reporting clock under Article 23. Where the cluster does not qualify, record why, so an authority reviewing the log can see the conditions were tested rather than skipped. The threshold figures and the exact way loss is measured should be confirmed against the regulation text and the entity's own finance definitions before the first review cycle.

Documenting lessons learned and root cause

Post-incident reviews turn an exercise or a real incident into evidence that the response process improves. The cards below cover what a review must establish, how the resulting changes are tracked and verified, and how findings carry into the next exercise.

Root cause identification under point 3.6.1

Point 3.6.1 of Implementing Regulation 2024/2690 asks for root cause identification where possible, so a review must record the technical and procedural causes, not only the timeline. For a tabletop, check that the team separated what the scenario injected from what the organization's own process failed to do. Where the root cause cannot be established, the record should say why and what further analysis is planned. A review that names no root cause is weak evidence.

Documented lessons learned

Lessons learned must be written down in a form an assessor can read without the participants present. Each lesson should state the observation, the affected process, the person accountable for the fix and the evidence that will show it was closed. Store the record with the exercise report so the review, the findings and the follow-up sit together. Confirm your retention period with your competent authority or internal policy.

Plan updates after significant incidents

The continuity, disaster recovery and crisis plans must be updated after significant incidents and after significant changes, under points 4.1.4 and 4.3.4 of the Annex. Check that every review produces a list of plan sections to amend, including the incident response plan, escalation contacts, reporting templates and the communication plan with the CSIRT or competent authority. Record the version and date of each amended plan so the change history can be shown.

Action tracking with owners and dates

Each corrective action needs a named owner, a due date and a status that moves through open, in progress and verified. Track actions in a system the organization controls, such as a self-hosted ticketing or issue tracker, so the history cannot be altered without a record. Review overdue items at the management body's regular security meetings, since accountability for NIS2 risk management sits with management. Ask for the open action count and the age of the oldest action in every report.

Evidence that changes were made

Closing an action requires proof that the change exists and works. Evidence may include a revised runbook with its version history, a configuration export showing a new alert rule, a signed training attendance record or a re-run exercise showing the step now succeeds. Avoid marking an action closed on the strength of a meeting note alone. Assessors and supervisors will ask to see the artifact, so link each closed item to its evidence file.

Feeding findings into the next exercise

Open findings should become test objectives in the next exercise, so the same gap is not rediscovered in a real incident. Map each finding to a scenario inject that tests whether the fix works under pressure. Record which findings were retested, which were accepted as residual risk and who approved that decision. This loop turns the review into a measurable input to the next planned test rather than a closed document.

What evidence a supervisor or assessor will ask to see

NIS2 creates no certificate of compliance, so nobody hands you a document that says your exercises passed. Instead, the national competent authority reviews your records during an inspection, answers an information request or runs a security audit, and judges whether testing happened as planned and whether it changed anything. The evidence you show has to tell that story from start to finish. Expect to produce an approved test plan that names the scenarios, participants, objectives and the sign-off by the management body, followed by a scenario record for each exercise with the injects used, the decisions taken and the time each decision was made.

Supervisors also look for proof that the right people took part and that the clock was tested. Keep attendance records that show which crisis roles were filled, including the person who would file the early warning and the notification. Keep timed reporting logs that show when the 24-hour early warning and the 72-hour notification were drafted, approved and sent in the exercise, and where the gaps were. Then show the gap register, with each finding, an owner, a due date and a closure record. A register with no closed items, or with findings that never reached the response plan, is a weak signal.

The last part of the evidence chain is change. Show the updated plans that resulted from each exercise and from each significant incident, along with the review minutes that record who approved the changes and when. Quarterly reviews of recurring incidents should appear in the same record. Before you build this pack, confirm with your national competent authority which formats it accepts, whether it wants signed PDFs or can read exported tickets and spreadsheets, how long records must be retained, and whether it expects evidence per entity or per group. Those answers differ between Member States, so do not assume one format fits all.

Who runs the exercises and who owns the outcome

This table compares what the organization, an implementation partner and an independent assessor each do across the exercise cycle. Read it as a split of accountability: the organization decides and signs, the partner prepares and runs drills, and the assessor tests the evidence without designing it.

Activity	Organization	Implementation partner	Independent assessor
Owning the test calendar	Sets planned test intervals in the incident response and crisis plans and approves the calendar through management	Proposes a calendar and tracks dates against the plan	Checks that the calendar exists and was followed; does not set it
Designing scenarios	Chooses scenarios from its own risk assessment, including significance and 24-hour and 72-hour reporting triggers	Drafts injects, timelines and scenario materials for review	Reviews whether scenarios reflect the entity's actual risks; does not write them
Facilitating tabletop exercises	Provides the executives and staff who must make decisions during the exercise	Facilitates the session and records decisions, gaps and timing	Observes only if engaged to test; does not facilitate
Running technical drills	Owns production systems, change approvals and business sign-off for any test impact	Executes containment, log retrieval and recovery drills in agreed environments	Reviews drill records and results against the documented procedure
Signing lessons learned	Approves root cause conclusions, owns corrective actions and signs the post-incident review	Drafts the review and tracks remediation items it has been assigned	Tests whether lessons were documented and acted on; does not sign them for the entity
Assessing the evidence	Retains exercise records, reports and recurring incident reviews for supervisors	Prepares evidence packs and checks completeness against the plan	Issues any independent report or opinion; a national authority decides on compliance

Questions buyers ask about NIS2 exercises

How often must NIS2 incident response exercises run?

NIS2 does not set a fixed number of exercises per year. The applicable requirements in Implementing Regulation (EU) 2024/2690 say that incident response procedures must be tested at planned intervals, and that continuity, disaster recovery and crisis plans must be tested, reviewed and updated at planned or regular intervals and after significant incidents or significant changes. The entity sets those intervals and must be able to justify them. Drivers include the size and complexity of the environment, how often systems change, and what happened in recent incidents. Write the schedule into your policy, record each exercise and its findings, and expect a supervisor to ask why the interval you chose is adequate for your risk.

Is a tabletop exercise enough to meet NIS2 testing requirements?

A tabletop alone is rarely enough for a mature program. A tabletop tests decisions, roles, communication and reporting timelines, which the crisis management and communication requirements in the implementing regulation depend on. It does not prove that backups restore, that containment steps work on real systems or that technical teams can isolate affected services. Most programs combine tabletops with functional tests such as restore drills, failover tests and simulated alerts. The mix should follow the risks in your own risk assessment, and the exercise record should show which parts of the plan were tested and what changed afterwards.

How long does it take to prepare an NIS2 exercise?

Preparation time depends on the scenario, the number of participants, whether systems must be simulated, and how much of the plan is new. No duration is supplied for this topic, so ask any partner to state the effort in a written scope before work starts. Ask what they will prepare (scenario, injects, roles, observer notes, debrief template), who from your side must attend planning sessions, and whether the scope covers only the tabletop or also the evidence pack and follow-up actions. Preparation is usually heavier for the first exercise and lighter once the scenario library and reporting templates exist.

Can our own staff run NIS2 incident response exercises?

Yes, the regulation does not require an external facilitator. Internal staff can design and run exercises if they understand the incident response plan, the reporting deadlines and the systems in scope. An outside facilitator is useful when the exercise needs independence, when internal people are also the responders being tested, or when you need an objective record for a supervisor. Whoever runs it, the organization owns the controls, the plan and the results. Document who facilitated, who observed, what was decided and what was assigned afterwards, so the exercise can be shown to a reviewer.

What does NIS2 exercise testing need from management?

Management needs to approve the plan, the testing schedule and the resources, and it needs to take part in exercises that cover crisis decisions. The management body is responsible for overseeing the Article 21 measures under NIS2, so an exercise that never involves executives leaves a visible gap. Management also decides on significance, authorizes external communication and accepts the risks left open after lessons learned. Ask for a clear record that leadership reviewed the exercise results and approved the corrective actions, with owners and dates.

Do exercises prove that we are NIS2 compliant?

No. NIS2 creates no certificate of compliance, and a successful exercise shows only that your plan worked under the conditions tested on that day. Supervisors judge the whole program, including the risk assessment, policies, evidence and how you act on what the exercises reveal. An exercise shows the process is tested and improving, which supports compliance. Only the competent authority can decide whether your program meets the requirements, and an independent auditor can assess readiness, but neither the exercise nor a consultant issues a compliance statement.

How DeployOpen plans and runs NIS2 incident exercises

DeployOpen helps organizations plan and run NIS2 incident response exercises and tabletop tests against their own self-hosted systems. The organization owns its incident response plan, its reporting decisions and its controls, while DeployOpen prepares the scenarios, systems and records that show the process works. Independent auditors and competent authorities assess the results.

How we scope

Agree the written scope, deliverables and timeline before any exercise work starts, since engagements are fixed-scope.
Confirm which response procedures, continuity, disaster recovery and crisis plans, and reporting steps the exercises will cover.
Confirm which systems, environments and staff roles are in scope, and which decisions remain with the organization's management.

How we build

Design tabletop scenarios that rehearse the 24-hour early warning and 72-hour notification against the organization's own escalation chain.
Prepare test records, injects, timekeeping logs and communication templates so each run produces evidence an assessor can review.
Set up the self-hosted platforms, logging and ticketing needed to show detection, containment, eradication and recovery steps during a drill.

How we hand over

Deliver written exercise reports with findings, root cause analysis where possible, and documented lessons learned for each run.
Provide updated plans and a review log that records changes made after each exercise or significant change.
Walk the organization's named owners through the outputs so they can run the next exercise and the quarterly recurring incident review themselves.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the initial engagement ends.
Agree a retainer scope for repeat exercises, plan updates and quarterly recurring incident reviews, priced from the written scope.
Confirm with your own counsel and competent authority which reporting obligations apply, since DeployOpen does not issue audit reports or certifications.

NIS2 incident response exercises and tabletop testing