NIS2 Incident Handling (Article 21(2)(b)): What You Actually Need

Of the ten risk-management measures NIS2 lists in Article 21(2), incident handling, point (b), is the one most likely to be tested in anger. Sooner or later something will go wrong, and NIS2 doesn’t just expect you to recover: it expects you to detect, classify, respond, and report on a clock. This article explains, practically, what an incident-handling capability needs to look like for an essential or important entity.

This is general guidance, not legal advice. NIS2 is transposed into national law that differs by country (in Italy, for example, via D.Lgs. 138/2024, administered by the ACN). Always confirm the exact obligations and timelines with your national authority.

What “incident handling” means under NIS2

Article 21(2)(b) requires “incident handling.” Recital and Article 23 of the Directive make the reporting side concrete: for a significant incident, in-scope entities must follow a multi-stage notification timeline to their CSIRT or competent authority:

• Early warning, within 24 hours of becoming aware of a significant incident. This is a heads-up, not a full report: is it suspected to be malicious, could it have cross-border impact?
• Incident notification, within 72 hours, updating the early warning with an initial assessment of severity, impact, and (where available) indicators of compromise.
• Final report, within one month of the notification: a detailed description, the type of threat or root cause, mitigation applied, and any cross-border impact.

A “significant” incident is, broadly, one that has caused or can cause severe operational disruption or financial loss, or that has affected others by causing considerable material or non-material damage. The thresholds are refined by national transposition and sectoral rules, but the practical point stands: you have 24 hours, and 24 hours is not enough time to start building a process.

The capability behind the deadline

Meeting a 24-hour clock is impossible without a few things already in place. A defensible incident-handling capability has:

1. A written incident-response policy and plan. Who declares an incident, who leads, who talks to the authority, who talks to customers. Roles, not names, people change.
2. Severity classification. A simple, documented scale so the same event is graded the same way regardless of who’s on call. This is what turns “something’s weird” into “this is significant and the 24-hour clock has started.”
3. Detection and logging. You can’t report what you can’t see. Centralised logs, alerting, and enough retention to reconstruct what happened for the one-month final report.
4. A contact path to your authority/CSIRT that’s known before the incident, not googled at 2 a.m.
5. Tested runbooks. Containment, eradication, recovery steps for your most likely scenarios (ransomware, account compromise, exploited public-facing service).
6. Post-incident review. The final report is easier when you already capture timeline, root cause, and lessons learned as a habit.

Where it meets vulnerability management

Most “significant incidents” don’t start with something exotic, they start with a known, exploited vulnerability on an internet-facing or widely-deployed system. That’s the overlap with Article 21(2)(e). The faster you know which of your systems are affected by a vulnerability attackers are actively exploiting, the more of your incident-handling effort shifts left, from responding to a breach to closing the door before it’s used.

This is where SentriKat fits, honestly and narrowly: it’s exploited-first vulnerability management, continuous tracking of the vulnerabilities attackers actually use, mapped to your real software inventory, with signed NIS2/DORA evidence. It won’t write your incident-response plan, but it shortens the list of incidents you’ll ever have to handle, and it gives your responders accurate “what are we exposed to” data when an alert fires.

A pragmatic starting point

If you’re starting from little, the highest-value first steps are: write the one-page plan and severity scale, confirm the notification path to your national authority, centralise logs with enough retention, and run one tabletop exercise on a ransomware scenario. That alone moves you from “no chance of meeting 24 hours” to “we’d actually make the call.”

Not sure whether NIS2 even applies to you, or how ready you are across all ten measures? Our free, anonymous NIS2/DORA readiness check gives you an indicative scope result and a per-domain gap analysis in about five minutes.