NIS 2 incident handling under Article 21(2)(b)
Article 21(2)(b) is the internal duty: detect, contain, recover, document, learn. Article 23 is the external duty: tell the BSI or your national CSIRT. Two different duties, often mixed up. CIR (EU) 2024/2690 §3 spells the internal one out.
The short version
Incident handling is point (b) on Article 21(2)'s list of ten cybersecurity duties. It is about what you do inside the company when something goes wrong: spot it, contain it, recover, write down what happened, learn from it.
CIR (EU) 2024/2690 §3 fills in the detail in six sub-sections: §3.1 a written incident handling concept, §3.2 monitoring and logging, §3.3 internal escalation of events, §3.4 classification, §3.5 the response itself (containment, eradication, recovery), §3.6 the post-incident review. If you run DNS, cloud, a data centre, an MSP or any other CIR Annex sector, this binds you directly.
Germany puts the same duty into national law through §30(2)(2) BSIG. The phrase is 'Bewältigung von Sicherheitsvorfällen', the same words as the directive. This page walks the directive, the EU follow-up regulation, and the German transposition in that order.
Article 21(2)(b) NIS 2 Directive (2022/2555)
Incident handling.
Point (b) on the list of ten cybersecurity measures. Two words in the directive text. CIR §3 turns those two words into operational detail. Important: this is the internal handling duty. The external duty to notify the CSIRT lives in Article 23 and is a separate page.
CIR (EU) 2024/2690, Annex §3
For the purposes of Article 21(2)(b) of Directive (EU) 2022/2555, the relevant entities shall establish and implement a policy on incident handling, defining roles, responsibilities and procedures for the timely detection, analysis, containment or response, recovery as well as documentation and reporting of incidents.
Because this is a regulation, it is directly binding EU law. No national transposition needed. The §3 Annex breaks the duty into six sub-sections: concept (§3.1), logging (§3.2), internal escalation (§3.3), classification (§3.4), response (§3.5), post-incident review (§3.6).
§30(2)(2) BSIG (Germany)
Bewältigung von Sicherheitsvorfällen.
Germany copies the directive wording word for word. The substance is identical to Article 21(2)(b). The BSI then uses IT-Grundschutz building blocks (in particular DER.2 'Vorfall-Bewältigung') to show what a written incident handling concept looks like in practice.
A written incident handling concept
Write down who does what when something goes wrong. Roles, responsibilities, the steps for detection, analysis, containment, recovery, documentation and internal reporting. CIR §3.1.1 demands the concept exists before the incident, not after. The management body has to sign off on it.
Monitoring and logging
You cannot handle what you cannot see. CIR §3.2 lists twelve event types you have to log (login attempts, privilege changes, malware detections, network anomalies and others). Logs need to be tamper-resistant and kept long enough to support analysis. This is the detection layer.
Response phases: containment, eradication, recovery
CIR §3.5 splits the response into three phases. Containment stops the incident from spreading. Eradication removes the root cause. Recovery brings systems back to a known good state. Each phase has to be documented as you go, so §3.6 (post-incident review) has something to work with.
Internal handling is not external reporting
Article 21(2)(b) is what you do inside the company. Article 23 is what you tell the regulator (24-hour early warning, 72-hour incident notification, one-month final report to the BSI or your national CSIRT). Two separate duties. Doing the reporting does not discharge the handling, and doing the handling does not discharge the reporting.
Post-incident review feeds back into risk management
CIR §3.6 closes the loop. The lessons from each incident feed back into the CIR §2 risk management framework. New risks get added, treatment plans get updated, controls get adjusted. That is the PDCA cycle. An incident you handle but do not learn from is half a job.
BSI / §30(2)(2) BSIG
The BSI lists incident handling in the Infopakete as the second of the ten Article 21(2) measures. The German transposition uses the same phrase as the directive. The BSI points at IT-Grundschutz building block DER.2 ('Vorfall-Bewältigung') as the practical route. DER.2 walks you through the concept, the playbook, the roles and the post-incident review.
ENISA Technical Implementation Guidance
ENISA's TIG takes CIR §3 and shows you what evidence looks like in practice: the written concept, the playbook, the simulation records, the post-incident review notes. It also maps §3 onto established controls in ISO/IEC 27001:2022 (clause A.5.24 to A.5.28) and NIST CSF 2.0 (the Respond and Recover functions), so an existing certification gives you a head start.
National transposition laws
Every member state has its own transposition law (Netherlands: Cyberbeveiligingswet, Austria: NISG, Belgium: NIS2-Wet). The duty is the same because the directive sets one EU-wide standard. What differs: which CSIRT you talk to for the Article 23 reporting, and how each national authority phrases the practical guidance.
We report to the BSI when something happens, so we are covered.
That covers Article 23, not Article 21(2)(b). Reporting to the CSIRT is the external duty. Article 21(2)(b) is the internal one: detect, contain, recover, document, review. Both have to exist. An auditor will ask to see the incident handling concept (CIR §3.1) on top of the Article 23 reporting log.
We will write the playbook when something happens.
CIR §3.1.1 is explicit: the concept has to be 'established and implemented' before the incident. Roles, responsibilities, procedures, all on paper, signed off by management. Writing it during the incident is not handling, it is improvising. Auditors check for the dated, signed concept first.
The IT team handles it, that is enough.
CIR §3.1.1 demands documented roles and responsibilities. Who declares an incident. Who decides on containment. Who talks to legal. Who signs off on recovery. The management body has to approve the concept. 'The IT team handles it' is not a structure, it is an assumption.
The typical Mittelstand gap is documentation, not capability. Detection happens (someone notices, IT investigates, the issue gets fixed). Documentation does not. Without the dated record of who did what, the auditor has no way to check that §3 was followed. The fix is to build the playbook first, then simulate twice a year, then capture the lessons in the post-incident review template.
Two simulations per year is what most practitioners we talk to land on. One tabletop (people round a table, walking the playbook through a scenario), one technical (a controlled restore from backup, a phishing-response drill, something that exercises the tools). The point is to find the gaps before an auditor does, or before a real incident does. Article 21(1) proportionality lets you scope the simulation to your size and risk picture; it does not let you skip them.
We built CIR §3 into the platform as the INC module. You register an incident, capture the classification under §3.4, walk through the response phases (containment, eradication, recovery) with timestamps, and run the post-incident review at the end. The audit trail records every step. No spreadsheet pile.
The §3.6 post-incident review is the part most teams skip. We made it a required field before an incident can be closed: what went wrong, what worked, what changes get fed back into the CIR §2 risk framework. The Article 23 reporting (24h / 72h / one-month) is a separate module that uses the same incident record, so you do not type the facts twice.
- Directive (EU) 2022/2555 (NIS 2), Article 21(2)(b) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690 (CIR), Annex §3 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI Act (BSIG), §30(2)(2) as amended by the NIS2 Implementation and Cybersecurity Strengthening Act
- BSI IT-Grundschutz building block DER.2 'Vorfall-Bewältigung' — bsi.bund.de/grundschutz
- ENISA Technical Implementation Guidance for CIR (EU) 2024/2690, §3 mapping to ISO/IEC 27001:2022 and NIST CSF 2.0