NIS2 Incident Simulation: How to Run the Test CIR 2024/2690 Requires

A well-rehearsed tabletop exercise can still leave an organisation unable to contain a real breach. The team talks through the ransomware scenario, agrees who calls whom, nods at the 24-hour notification clock — and six months later, when an actual encryption event hits, nobody has ever actually opened the incident logging tool under pressure, let alone tested whether the isolation script works against the current network segmentation. The plan was rehearsed. The capability wasn’t.

That gap is exactly what NIS2 incident simulation is built to close, and it’s a different exercise from the tabletop discussion most compliance programmes already run. This guide explains what a live incident simulation actually is, what CIR 2024/2690 requires of your testing programme, how to design one using the two dominant methodologies — inject-based and scenario-based — and how technical and management-level simulations test entirely different things.

Does This Apply to You? The CIR 2024/2690 Testing Duty

If your organisation is an essential or important entity under NIS2, having an incident response plan isn’t the finish line — proving the plan works is a separate, mandatory control. Article 21(2)(f) of the NIS2 Directive lists "policies and procedures to assess the effectiveness of cybersecurity risk-management measures" as one of the ten mandatory measure categories, sitting alongside — but legally distinct from — Article 21(2)(b)’s requirement to have incident-handling procedures in the first place. One measure says: have a plan. The other says: prove it works.

Entity type	Does CIR 2024/2690 Annex 3.5.5 bind you directly?	Basis
DNS providers, TLD registries, cloud, data centre, CDN, MSP/MSSP, online marketplaces, search engines, social platforms, trust services	Yes — directly binding	CIR 2024/2690 is the technical implementing regulation written specifically for digital-infrastructure-type entities
All other essential/important entities (manufacturing, healthcare, energy, transport, public administration, etc.)	By analogy / interpretive reference only	Article 21(2)(f) of the Directive imposes the general testing duty on every entity; the CIR shows the digital-infrastructure sector one worked example of what "test at planned intervals" means in practice

The CIR’s own words, for the entities it directly binds: "The relevant entities shall test at planned intervals their incident response procedures." That’s the entire operative text of Annex Section 3.5.5 — it establishes the obligation to test, but it does not name a specific test format. Nothing in the provision says the test must be a live simulation rather than a tabletop discussion. That silence is exactly where most testing programmes go wrong, because a discussion that never touches a real tool or a real log doesn’t generate much evidence that the "incident response procedure" actually functions.

Tabletop vs Incident Simulation: Two Different Tests, Not Two Names for the Same Thing

Treating a tabletop exercise and an incident simulation as interchangeable is the single most common gap we see when reviewing NIS2 testing programmes — teams run one tabletop a year, file it under both "incident response testing" and "business continuity testing," and assume the box is checked.

The clearest reference taxonomy here comes from NIST Special Publication 800-84, the standing US government guide to IT test, training, and exercise programmes. It defines three distinct categories, and the middle two map directly onto the tabletop/simulation split:

	Tabletop Exercise	Incident Simulation (Functional Exercise)
Format	Discussion-based, facilitated conversation	Hands-on, performed in a simulated or real operational environment
What it validates	Roles, decision-making, escalation paths, communication	Actual execution: detection tooling, containment scripts, log correlation, notification drafting under time pressure
Equipment used	None — participants talk through the scenario	Real (or realistic) incident response tools and systems
Typical duration	2–4 hours	Several hours to multiple days, depending on scope

NIST’s definition is explicit that in a tabletop, participants "do not deploy any equipment or resources" — they talk through decisions in a conference-room setting. A functional exercise (what most NIS2 guidance calls an incident simulation) puts people in front of the actual tools and asks them to perform the response for real, inside a controlled environment. In practice, most compliance teams treat the two as complementary rather than substitutable: a tabletop alone can confirm your team knows the plan, but it can’t confirm your SIEM alerting actually fires, your containment script actually isolates the right segment, or your legal officer can actually draft an Article 23 early-warning notification inside the 24-hour window under real time pressure.

Designing the Simulation: Inject-Based vs Scenario-Based

Once you’ve decided to run an actual technical simulation rather than another discussion, the design question is how to structure it. The freshest authoritative framework here is ENISA’s Cybersecurity Exercise Methodology, published 16 February 2026 as an EU-wide, end-to-end framework for planning, running, and evaluating cybersecurity exercises — the first standardised methodology of its kind at EU level, and current enough that most competing guides on this topic don’t reference it yet.

The methodology separates two design elements that are often blurred in informal exercise planning: the scenario and the injects. The scenario is the storyline — the overall narrative of what’s happening (a supplier’s VPN credentials are compromised, an attacker pivots to the file server, ransomware detonates at 3 a.m.). The injects are the individual, precisely timed triggers — an email, a phone call, a simulated system alert — delivered to participants at specific points to force a decision. ENISA’s Master Scenario Event List (MSEL) sequences these injects, incidents, and events into a controlled timeline that the exercise controller runs during execution.

The distinction matters because a scenario alone is passive — participants can describe what they’d do in general terms without ever being forced to act in real time. Injects are what convert a scenario into a test: each one demands a concrete response, on the clock, from whoever is supposed to own that decision. A well-built MSEL for an incident simulation typically sequences 8–15 injects across detection, containment, notification, and recovery, timed to reveal exactly where your documented procedure and your team’s actual behaviour diverge.

Technical Simulation vs Management Simulation — Who’s Actually Being Tested

A live simulation can be aimed at two distinct audiences, and NIS2 testing programmes that only run one of them are leaving half the Article 21(2)(f) obligation unaddressed. A technical simulation puts your security team in front of real tools; a management simulation puts your compliance, legal, and executive stakeholders in front of the decisions only they’re authorised to make.

Role	What a Technical Simulation Tests	What a Management Simulation Tests
CISO / IT Security Manager	Detection tooling, containment playbook execution, log correlation, whether the runbook steps actually work against current infrastructure	Escalation timing, resourcing authority, when to call in external support
Compliance Officer / Legal	Whether they can pull the facts needed to draft a notification from a live incident, not a hypothetical one	Whether the 24-hour Article 23 early-warning form can genuinely be completed and submitted inside the window, under time pressure, with real facts
Board / C-Suite	Rarely directly involved	Decision authority for external communication, understanding of personal liability exposure under Article 20
SME Owner / Non-technical lead	Usually observes rather than participates	Whether they know exactly who to call, and which decisions are legally theirs to make, without needing a CISO on staff

In practice, a management-level simulation is closer in format to a tabletop — discussion and decision-making rather than hands-on tooling — but it’s aimed specifically at executives and compliance staff, using the real outputs of a technical simulation (an actual incident timeline, an actual draft notification) as the material to react to. Run in sequence, technical-then-management, the two together generate the kind of end-to-end evidence an auditor reviewing your Article 21(2)(f) effectiveness-assessment procedure is actually looking for.

Building Your First Incident Simulation: A 6-Step Framework

Most organisations that have never run a technical simulation over-scope the first attempt and stall before scheduling it. Narrowing the first exercise keeps it achievable.

1. Define one objective and scope it narrowly (Low effort). Pick a single procedure to test — ransomware containment on one segment, or the 24-hour notification workflow — rather than attempting to validate the entire incident response plan in one sitting.
2. Build the scenario narrative (Medium effort). Base it on a threat pattern realistic to your sector rather than a generic template; a manufacturing OT scenario and a SaaS credential-compromise scenario should look nothing alike.
3. Draft the MSEL and inject list (Medium effort). Sequence 8–15 timed injects, each specifying the delivery channel (simulated alert, phone call, email) and the exact decision it’s meant to force.
4. Assign separate controller and evaluator roles (Low effort). The person running the injects and the person scoring the response should never be a participant being tested — conflating the roles produces unreliable results.
5. Execute in a test or staging environment (High effort). A first-ever technical simulation belongs nowhere near production; the point is testing the response, not creating the incident it’s meant to respond to.
6. Write the After-Action Report and feed it into the Corrective Actions Register (Medium effort). This step closes the loop back to Article 21(2)(f) — without a written record connecting findings to remediation, the exercise generated activity but not evidence of an effectiveness assessment.

How Often to Test — Turning "Planned Intervals" Into a Real Schedule

Neither the Directive nor the CIR names a frequency. "Planned intervals" is deliberately open, which means the burden is on your organisation to set and document a defensible schedule rather than wait for a regulator to specify one. Germany’s BSI exercise toolkit for critical-infrastructure operators frames this as a Plan-Do-Check-Act cycle — planning the scenario, executing it, reviewing what happened, and acting on the findings — repeated on a fixed cycle rather than run once and filed away. As a general guideline, most compliance teams settle on quarterly tabletop discussions paired with at least one full technical simulation a year; our own six-phase incident response playbook uses that same cadence as its baseline recommendation.

Current State	Required State (Art.21(2)(f) + CIR 3.5.5)	Effort to Close
No documented testing history	At least one logged exercise per year	Low — schedule a tabletop first
Tabletop only, technical simulation never run	Tabletop plus one inject-based technical simulation annually	Medium
Drills run but undocumented	Written MSEL, After-Action Report, and Corrective Actions Register for every exercise	Medium–High
Findings never reach the risk register	Exercise findings feed the Article 21(2)(f) effectiveness review and update the risk treatment plan	High — process change, not just scheduling

Five Mistakes That Undermine a Simulation’s Compliance Value

• Testing only the technical containment, never the notification workflow. A simulation that stops at "we isolated the host" skips the piece Article 23 actually measures you against: the 24-hour clock.
• No written After-Action Report. Running the exercise isn’t evidence; the documented findings and corrective actions are what demonstrate the effectiveness assessment required by Article 21(2)(f).
• Reusing the same scenario every year. A repeated scenario tests whether the team remembers last year’s answers, not whether the current infrastructure and current staff can actually respond.
• Running the first-ever simulation in production. This turns a test into an actual incident and is the fastest way to lose executive buy-in for future exercises.
• Logging tabletop and simulation as the same checklist item. They test different things; an auditor who asks "show me your technical test" won’t accept a tabletop transcript as the answer.

Frequently Asked Questions

Does NIS2 require incident simulation specifically, or just testing in general?

The Directive and CIR 2024/2690 require testing incident response procedures "at planned intervals" without naming a specific format. Neither text mandates a live simulation by name. In practice, a testing programme built entirely on discussion-based tabletops struggles to demonstrate that technical controls actually work, which is why most compliance teams run both formats rather than relying on one.

How often should we run an incident response simulation under NIS2?

There’s no fixed number in the Directive or CIR. As a general guideline, quarterly tabletop exercises paired with at least one full technical simulation per year is the cadence most NIS2 compliance programmes converge on, following a documented plan-execute-review-act cycle.

Can a tabletop exercise satisfy the CIR 2024/2690 testing requirement on its own?

The CIR text doesn’t explicitly rule tabletop exercises in or out. A tabletop can demonstrate that your team understands roles and escalation paths, but it doesn’t generate evidence that your technical tooling and procedures function under real conditions — which is the harder half of what "assess the effectiveness of cybersecurity risk-management measures" is asking for under Article 21(2)(f).

What’s the difference between an inject and a scenario in exercise design?

The scenario is the overall storyline; injects are the individual, precisely timed triggers (an alert, a call, an email) that force participants to make a real decision at a specific moment. ENISA’s Master Scenario Event List sequences injects against the scenario timeline to convert a passive narrative into an active test.

Key Takeaways

A tabletop exercise and a live incident simulation test different capabilities, and NIS2’s testing duty under Article 21(2)(f) and CIR 2024/2690 Annex 3.5.5 doesn’t specify which one to run — which means the responsibility for building a programme that actually demonstrates effectiveness sits with your organisation. Start narrow: one technical simulation, one procedure, a documented MSEL, a written After-Action Report that feeds your Corrective Actions Register. Pair it with a management-level exercise that tests the notification workflow specifically, and repeat both on a schedule you can defend to an auditor.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• Commission Implementing Regulation (EU) 2024/2690 (EUR-Lex)
• “NIS 2 Directive, Article 21: Cybersecurity risk-management measures” (nis-2-directive.com)
• “The ENISA Cybersecurity Exercise Methodology” (enisa.europa.eu, published 16 February 2026)
• NIST Special Publication 800-84, “Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities” (csrc.nist.gov)
• “Übungsbaukasten” exercise toolkit, Bundesamt für Sicherheit in der Informationstechnik (bsi.bund.de)