NIS2 Incident Handling: The Classification Matrix, CIR Section 3 Checklist, and Mandatory IR Plan Fields for Art. 21(2)(b)

Most NIS2 guides treat Article 21(2)(b) as a one-line checkbox: “have an incident handling process.” It is one line — the Directive itself says nothing more than “incident handling.” But the technical substance sits in a separate regulation almost nobody reads past its headline number, and that regulation applies differently depending on what kind of entity you are. Get that distinction wrong and you’ll either over-build a compliance program against rules that don’t bind you, or under-build one and hand an auditor a policy with no classification logic behind it.

This guide covers the part most Article 21 overviews skip: the actual CIR 2024/2690 Section 3 lifecycle behind incident handling, the classification matrix that tells you when an incident is “significant,” the fields your incident response (IR) plan document needs to survive an audit, and who on your team owns each step.

What Article 21(2)(b) Actually Requires — and the Two-Track Legal Reality Most Guides Miss

In plain language: every essential and important entity must have a documented, practiced process for detecting, assessing, containing, and recovering from cybersecurity incidents. How detailed that process needs to be — and which specific technical rulebook governs it — depends on your sector.

Article 21(2) of Directive (EU) 2022/2555 lists ten mandatory risk-management measures. Incident handling is the second: the Directive’s own text for 21(2)(b) is exactly “incident handling” [1] — no further detail. The technical substance was delegated to the Commission under Article 21(5), which works in two tiers. The first tier obliged the Commission to adopt an implementing act with technical and methodological requirements for a defined set of digital infrastructure and ICT-service entities. That implementing act is Commission Implementing Regulation (EU) 2024/2690 (the “CIR”), in force since 17 October 2024 [3]. The second tier gives the Commission discretion — not yet exercised — to issue similar implementing acts for other essential and important entities [1].

The practical consequence: the CIR’s Annex Section 3 only legally binds the entity types it names — DNS service providers, TLD name registries, cloud computing providers, data centre providers, content delivery network providers, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers [3]. If you’re a manufacturer, hospital, energy operator, or public administration body, the CIR doesn’t directly apply to you. Your binding obligation is Article 21(2)(b) itself, interpreted through your national transposing law and Article 23(3)’s significance test (next section).

That said, treating the CIR’s Section 3 structure as a design template — not a binding rulebook — is defensible good practice for every sector. It’s the Commission’s own methodology for what “incident handling” should look like, and national competent authorities and auditors routinely reference it as an interpretive benchmark even outside its binding scope [6]. The gap analysis worth running is: which of the six CIR sub-requirements below does your current incident process already satisfy, and which would take low, medium, or high effort to add?

Is Your Incident Significant? The Classification Matrix

In plain language: two separate tests exist, and mixing them up is the single most common classification mistake. One test is universal law; the other is a specific rulebook for specific entities.

The universal test comes from Article 23(3) of the Directive and applies to every essential and important entity, regardless of sector. An incident is significant if either limb is met: (a) “it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned,” or (b) “it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage” [2]. Note the language — “capable of causing,” not “has caused.” A near-miss that could plausibly have disrupted service counts.

The CIR layers quantified numbers on top of that qualitative test, but — consistent with the scope point above — those specific figures are binding law only for the CIR-covered digital infrastructure and ICT-service entities. For those entities, CIR Article 3 sets baseline significance criteria including a financial-loss threshold of roughly EUR 500,000 or 5% of annual turnover (direct and indirect costs, whichever figure is lower), exfiltration of trade secrets, and incidents causing death or considerable damage to a person’s health [5][8]. Recurring incidents with the same root cause within a six-month window can be aggregated and treated as a single significant incident even if no individual occurrence meets the threshold alone [5]. Scheduled maintenance and contractually agreed service interruptions are explicitly excluded [8].

Test	Criteria	Who it binds	Source
Universal (Art. 23(3))	Severe operational disruption or financial loss to the entity, OR considerable damage to other persons	Every essential and important entity	NIS2 Directive Art. 23(3)
CIR quantified (Art. 3)	~EUR 500,000 / 5% turnover loss; trade-secret exfiltration; death or considerable health damage; 6-month recurring aggregation	DNS, TLD, cloud, data centre, CDN, MSP/MSSP, marketplaces, search engines, social platforms, trust services only	CIR 2024/2690 Art. 3
CIR entity-specific (Art. 5-14)	Per-service thresholds, e.g. availability drops or response-time failures	The specific service type named in each article	CIR 2024/2690 Art. 5-14

For compliance officers building a classification policy: document which row applies to your entity, then set your own internal severity bands calibrated to whichever row governs you — using the CIR’s numbers as a sanity-check benchmark even if you’re outside its binding scope is a defensible, auditable choice, as long as your documentation is honest about which figures are law and which are borrowed practice.

The CIR Section 3 Incident-Handling Lifecycle: Six Sub-Requirements, One Continuous Loop

In plain language: the regulation doesn’t just say “handle incidents” — it breaks the lifecycle into six named components, and each one produces a specific document or log an auditor will ask to see.

CIR 2024/2690’s Annex Section 3, “Incident handling,” is structured into six sub-sections covering “detecting, analysing, containing or responding to, recovering from, documenting and reporting of incidents” [4]. Here’s what each requires, mapped to effort level for a mid-sized entity building this from scratch:

Sub-section	What it requires	Effort
3.1 Incident handling policy	Defined roles and processes for detection, analysis, and response; must be coherent with your business continuity plans, not a standalone document [6]	Medium
3.2 Monitoring and logging	Continuous or periodic automated monitoring, an asset logging inventory, alert mechanisms, and synchronised time sources across logs [6]	High
3.3 Event reporting	Internal alert channels for staff and suppliers to flag suspected events before they’re confirmed as incidents [6]	Low
3.4 Event assessment and classification	A categorisation system that determines an event’s nature and severity — this is where your classification matrix from the previous section gets operationalised [6]	Medium
3.5 Incident response	Containment, eradication, and recovery procedures, plus a communication plan with CSIRTs and, where relevant, affected parties [6]	High
3.6 Post-incident reviews	Root cause analysis and documented lessons learned that feed back into the risk-management measures [6]	Medium

Germany’s BSI — the national CSIRT and competent authority under the NIS2 Umsetzungsgesetz — frames this same lifecycle in four operational phases for entities it regulates: prevention and preparedness (ISMS, risk analysis, contingency plans), detection (continuous evaluation of security-relevant events), response (damage-scope analysis, technical countermeasures, communication, documentation), and post-incident (honest review, vulnerability closure, lessons learned) [7]. The two framings map cleanly onto each other; BSI’s practical language for 3.1’s “policy” and 3.5’s “response” is worth borrowing even if you report to a different national authority, since the underlying CIR structure is EU-wide.

One mechanism worth understanding, not just following: 3.4’s classification step has to happen before 3.5’s response, because your containment strategy differs by severity. Isolating a single compromised laptop is a different operational decision than isolating a production network segment — and if your categorisation system doesn’t exist yet, every incident becomes an ad hoc judgment call under time pressure, which is exactly when the Article 23 24-hour clock is also running.

Mandatory Fields Your Incident Response Plan Document Must Contain

In plain language: “we have an IR plan” isn’t a compliance statement until the plan itself contains specific, checkable fields. Based on CIR 3.1’s policy requirement and BSI’s mandatory-elements guidance, here’s what an auditor expects to find inside the document itself, not just in your head:

• Categorisation/severity scheme — the classification matrix from Section 2 above, translated into your entity’s internal severity levels (CIR 3.4)
• Named roles and responsibilities — who declares an incident, who leads response, who communicates externally (CIR 3.1; BSI names this explicitly as a mandatory element [7])
• Detection and monitoring scope — which systems are monitored, by what tooling, and how alerts escalate (CIR 3.2)
• Communication plan — internal escalation chain plus the CSIRT/competent-authority contact and channel used for Article 23 notifications (CIR 3.5)
• Containment, eradication, and recovery procedures — even at a high level, tied to your asset inventory (CIR 3.5)
• Coherence with business continuity plans — an explicit cross-reference, since CIR 3.1 requires the incident policy not to contradict your continuity/disaster-recovery documentation [6]
• Backup and recovery testing cadence — documented and regularly tested, per BSI guidance [7]
• Post-incident review template — a structure for root-cause analysis and lessons learned, not just a promise to “review after” (CIR 3.6)
• Documentation of IT systems and networks — current enough to be usable mid-incident, per BSI [7]

In my experience reviewing these documents for clients, the field most often missing isn’t a technical one — it’s the explicit cross-reference to business continuity. Teams write the incident policy and the continuity plan separately, on different timelines, and nobody goes back to reconcile them. An auditor asking “what happens if this incident also triggers your disaster recovery plan?” is a common, easily avoidable gap.

Role-Responsibility Matrix and Effort by Implementation Step

Step	Primary owner	Effort	Output
Draft classification matrix	CISO / IT Security Manager	Medium	Severity scheme document
Write incident handling policy	CISO with Compliance Officer sign-off	Medium	Policy document (CIR 3.1)
Deploy monitoring and logging	IT / Security Operations	High	Monitoring architecture (CIR 3.2)
Define CSIRT/authority communication plan	Compliance Officer with Legal	Low	Escalation contact sheet (CIR 3.5)
Run tabletop exercise	CISO, cross-functional	Medium	Test report + gap list
Approve and resource the plan	Board / C-Suite	Low	Budget and mandate
Post-incident review cycle	CISO with Legal and Compliance	Medium	Root-cause report (CIR 3.6)

For the Board: your role here isn’t drafting technical procedure — it’s approving the resourcing and confirming the plan gets tested, since Article 20 places accountability for cybersecurity risk-management measures, incident handling included, at management-body level.

Documentation and Audit-Evidence Checklist

In plain language: auditors don’t test your incident handling by asking you to describe it — they ask for the artefacts. Gap analysis works best as current state versus required state, with effort to close.

Evidence auditors request	Typical current state	Effort to close
Signed-off incident handling policy	Draft exists, never formally approved	Low
Incident log with severity field populated	Ticketing system exists, no severity taxonomy	Medium
Evidence of at least one tested tabletop exercise	Never run, or run informally with no report	Medium
Post-incident review report for a real or simulated event	Missing entirely	Medium
CSIRT communication test (contact details verified)	Contact listed, never actually tested	Low

Common Mistakes That Turn an Incident Into a Second Problem

• Classifying against the wrong test. Applying CIR Article 3’s EUR 500,000 threshold when you’re not a CIR-covered entity either over- or under-reports, depending on which way the number cuts for you. Use Article 23(3)’s qualitative test unless you’re on the covered-entity list.
• Treating detection and classification as one step. CIR 3.3 (event reporting) and 3.4 (assessment/classification) are separate for a reason — an unconfirmed suspicious event shouldn’t trigger the same response as a confirmed significant incident.
• No documented link between the incident policy and business continuity. As noted above, this is the gap auditors flag most often in practice.
• Skipping the tabletop exercise. A policy that’s never been rehearsed tends to fail at the one moment it matters — under real time pressure, with the Article 23 24-hour clock already running [2].
• No post-incident review structure. CIR 3.6 expects lessons learned to feed back into the risk-management measures, not just get filed away [4].

Frequently Asked Questions

Does CIR 2024/2690 apply to my organisation if I’m not a digital infrastructure provider?
Not directly. Its Annex Section 3 legally binds only the entity types named in CIR Articles 5-14 (DNS, TLD registries, cloud, data centres, CDN, MSP/MSSP, marketplaces, search engines, social platforms, trust services) [3]. For every other sector, your binding obligation is Article 21(2)(b) and Article 23(3) directly; the CIR’s structure is a useful reference, not a legal requirement.

What’s the actual deadline once an incident is classified as significant?
Under Article 23(4): an early warning within 24 hours of becoming aware, an incident notification with an initial assessment within 72 hours, and a final report no later than one month after the notification [2]. Our Article 23 notification guide covers the full three-stage workflow and content requirements per stage.

How does incident handling fit with the other nine Article 21(2) measures?
Incident handling doesn’t operate in isolation — it depends on your risk analysis (2(a)) to inform classification, your business continuity plan (2(c)) for coherence, and your logging and monitoring under 2(i)-adjacent asset management. See our complete Article 21 overview for how all ten measures interconnect.

We think an incident might be significant but aren’t certain yet — do we report?
Article 23(3)’s language is “capable of causing,” not “has caused” [2]. When in doubt, most compliance teams report and note the uncertainty in the initial assessment rather than wait for confirmation and risk missing the 24-hour window.

What should our documentation checklist look like before an audit?
Start with a gap analysis comparing your current artefacts against the evidence list in the Documentation and Audit-Evidence Checklist section above. Our gap analysis guide walks through the current-state-to-required-state methodology in more depth.

Key Takeaways

Incident handling under Article 21(2)(b) is one line in the Directive and six sub-requirements in the CIR — but that CIR only binds specific digital infrastructure and ICT-service entities. Everyone else builds from Article 21(2)(b) and Article 23(3) directly, borrowing the CIR’s Section 3 structure as good practice rather than law. Either way, the artefacts that matter are the same: a classification matrix tied to the right legal test, a policy document with the specific fields listed above, tested procedures, and a post-incident review loop that actually feeds back into your risk measures. Build those four things and the reporting deadlines in Article 23 become a formality you can meet, not a scramble.

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

1. NIS 2 Directive, Article 21: Cybersecurity risk-management measures — nis-2-directive.com
2. NIS 2 Directive, Article 23: Reporting obligations — nis-2-directive.com
3. Commission Implementing Regulation (EU) 2024/2690 — Advisera plain-English CIR mirror
4. CIR 2024/2690, Annex Section 3 “Incident handling” — Advisera (Technical and methodological requirements)
5. “CIR 2024/2690 – NIS2 Technical Measures” — NISD2.eu
6. “NIS2 Implementing Act DVO (EU) 2024/2690” — OpenKRITIS
7. “#nis2know: Incident Response” — BSI (Germany’s NIS2 competent authority and national CSIRT)
8. “Art. 21 Cybersecurity risk-management measures” — Springlex