8 NIS2 Incident Response Mistakes That Turn a 24-Hour Deadline Into a Reportable Failure

Article 23 gives you 24 hours from the moment you become aware of a significant incident to send an early warning. That clock does not pause while your team figures out who owns the decision, what the notification form should say, or whether the incident even clears the significance bar. Most NIS2 incident response failures are not caused by a missing document — they are caused by a plan that has never been pressure-tested against that clock.

The eight mistakes below come from where NIS2 incident response actually breaks in practice: the gap between a written plan and a live, moving incident. Each one includes the specific NIS2 requirement it collides with, why the mistake happens, and the concrete fix. The stakes are not abstract: Article 34 ties administrative fines directly to Article 21 and Article 23 infringements specifically — up to EUR 10,000,000 or 2% of worldwide annual turnover for essential entities, and up to EUR 7,000,000 or 1.4% for important entities, whichever figure is higher in each case [1]. A late or malformed notification is exactly the kind of Article 23 infringement that provision targets.

Why NIS2 Incident Response Plans Fail in Live Incidents, Not on Paper

Article 21(2)(b) of the NIS2 Directive requires essential and important entities to have incident handling measures in place. Article 23 then sets the reporting clock: a 24-hour early warning, a 72-hour incident notification, and a final report within one month of that notification. Most organisations satisfy the letter of Article 21(2)(b) by producing a document. Few test whether that document actually survives contact with a live incident — which is exactly what the German Federal Office for Information Security (BSI), the national competent authority responsible for NIS2 enforcement in Germany, tells regulated entities to prepare for: documented procedures, pre-defined escalation paths, and rehearsed crisis exercises, built before an incident, not during one [3].

This matters differently depending on your role. A CISO needs the classification logic and log-retention depth to hold up under CSIRT scrutiny. A compliance officer needs the reporting deadlines and content requirements documented well enough to defend at audit. An SME owner mostly needs to know that “we have a policy” is not the same as “we could file a compliant 24-hour warning tonight.” All three gaps show up in the same eight mistakes.

Mistake 1: No Documented Classification Procedure Before an Incident Happens

The most expensive minutes in any NIS2 incident are the ones spent arguing about whether it counts as “significant” under Article 23(3) — severe operational disruption or financial loss to your organisation, or considerable material or non-material damage to others [1]. If that test isn’t written down and assigned to a named decision-maker in advance, someone improvises it live, usually too cautiously (over-reporting minor issues) or too slowly (debating significance while the 24-hour clock runs). BSI lists a documented classification and assessment step as part of the pre-incident foundation an organisation needs before it can respond at all [3]. We’ve written a full breakdown of how the universal Article 23(3) test differs from the quantified CIR 2024/2690 thresholds that apply to digital infrastructure entities specifically, including a side-by-side comparison in our incident handling implementation guide — the fix here is simpler than the legal analysis: write the test down, assign who applies it, and rehearse it before you need it.

Mistake 2: Confusing the 24-Hour Early Warning With the 72-Hour Notification

Teams used to GDPR’s 72-hour breach notification sometimes assume NIS2 works the same way and treat the first 24 hours as optional or preliminary in a way the Directive doesn’t allow. It doesn’t. The two NIS2 deadlines ask for genuinely different content, and drafting the wrong one at the wrong stage burns time you don’t have:

Stage	Deadline	What it must contain
Early warning	24 hours from awareness	Whether the incident is suspected to result from unlawful or malicious acts, and whether it could have cross-border impact [1]
Incident notification	72 hours from awareness	Updates the early warning; adds an initial assessment of severity and impact, plus indicators of compromise where available [1]
Final report	1 month after the notification	Detailed description, severity and impact, threat type or root cause, mitigation measures, cross-border impact [1]

BSI states the operating principle plainly: for the 24-hour stage, “speed takes priority over completeness” — file with the information you have, and correct or add detail in the 72-hour and final reports [2]. Treating the early warning as a mini root-cause report is a mistake in the opposite direction: it delays a legally required submission while you chase facts the Directive doesn’t ask for yet. Our Article 23 incident notification guide walks through each stage’s obligations in full if you need the complete picture beyond this comparison.

Mistake 3: An Incident Response Plan That Has Never Been Tested

A written IR plan and a working IR capability are not the same thing, and the gap between them only shows up under pressure. Cisco Talos puts it bluntly: “the plan is only as good as its use during a real incident” [5] — and the only way to know that before a real incident forces the question is a tabletop exercise. Tabletop drills specifically surface “confusion around who can authorise actions such as system isolation, regulatory notification or external communications” [4], which is precisely the kind of gap a document review will never catch, because the document usually names a role, not a tested decision path. Run at least one tabletop exercise a year; organisations handling higher-risk profiles typically run two to four, covering distinct scenarios such as ransomware, a cloud/SaaS provider outage, and a supply-chain compromise [4]. If your plan has never been rehearsed against a clock, treat it as untested regardless of how detailed it reads on paper.

Mistake 4: Log Retention Shorter Than the Investigation Actually Needs

CIR 2024/2690 does not set a numeric minimum for log retention — it requires logs to be maintained for a defined period without specifying what that period is. That silence is often misread as permission to keep the default 30- or 90-day window most logging tools ship with. In practice, a CSIRT or competent authority investigating a significant incident frequently needs to look back further than that, since intrusions are often discovered well after the initial compromise. The practical floor that survives most national audits, per our own logging and monitoring research, is 12 months — typically 6 months in hot, queryable storage plus 6 months in cold archive — with some member states referencing 12 to 18 months for critical infrastructure entities, and higher-risk sectors such as finance or healthcare sometimes facing sector rules of up to 7 years. See our full breakdown of what CIR 2024/2690 actually requires for logging for the retention structure and SIEM specifics. If your current policy was set by a default setting rather than a documented risk assessment, that’s the mistake to fix first.

Mistake 5: No Named Owner for the “Is This Significant?” Decision

Even with a classification procedure written down (Mistake 1), someone still has to apply it at 2 a.m. when an alert fires. BSI’s pre-incident checklist calls for escalation paths and communication channels to be defined before an incident, not decided in the moment [3], and tabletop exercises exist largely to test whether that authority is real or just written down — whether the named person can actually authorise system isolation or a regulatory notification without waiting for a chain of approvals that doesn’t fit inside a 24-hour window [4]. A classification test with no one empowered to apply it under time pressure is a plan that reads well and fails live. In smaller organisations this often defaults to whoever happens to be online when the alert fires, rather than a role with actual authority to isolate a system or trigger the 24-hour clock — which means the decision-maker changes depending on the time of day, and so does the quality of the call.

Mistake 6: Legal and Communications Left Out Until the Incident Is Already Live

Talos names this directly as a top incident-response-plan mistake: building a plan that is “too IT-focused” and leaves out legal, communications, HR, and the service desk [5]. On a NIS2 timeline this is more than an oversight — Article 23 also requires notifying affected service recipients of significant incidents likely to disrupt their service, along with the protective measures they can take [1], which is a communications task, not a technical one. If legal only sees the 72-hour notification draft after IT has already written it, and communications only finds out about customer notification obligations from a support ticket queue, you’re building both of those deliverables from scratch under deadline pressure instead of executing a pre-agreed process.

Mistake 7: Drafting Notification Reports From a Blank Page During the Incident

BSI’s stated principle — speed over completeness for the early warning [2] — only works if there’s a form to fill in quickly. Teams that wait until an incident is underway to figure out what the 24-hour and 72-hour submissions should look like spend part of that scarce time on formatting and structure instead of substance. The fix is mechanical: pre-build the three notification templates (early warning, notification, final report) mapped to the exact content each stage requires under Article 23(4) [1], so the only work left during a real incident is filling in facts you already have a place to put.

Mistake 8: Treating “Systems Restored” as “Incident Closed”

Restoring service ends the operational emergency; it does not end your Article 23 reporting obligation. The final report, due within one month of the incident notification, has to include the threat type or root cause and the mitigation measures taken and ongoing — not just confirmation that systems are back online [1]. BSI frames this as a distinct step: an honest post-incident analysis with the team, with lessons incorporated into procedures at the organisational level, done separately from the technical recovery [3]. Skipping this turns the final report into a rushed afterthought written from memory weeks after the details were fresh, which is also where root-cause attribution errors creep into the official record.

Self-Check: Which of These 8 Gaps Does Your IR Plan Have?

Mistake	Symptom you’d notice	Fix
1. No classification procedure	Team debates “is this significant?” mid-incident	Write the test, assign an owner, rehearse it
2. 24h/72h confusion	Early warning delayed to gather root-cause detail	Separate templates per stage, matched to Art. 23(4) content
3. Untested plan	Plan has never been run against a clock	Annual tabletop exercise minimum
4. Short log retention	Retention set by tool default, not risk assessment	12-month floor: 6 months hot + 6 months cold
5. No decision owner	Escalation stalls waiting for approval chain	Name the authority; test it in the tabletop
6. Legal/comms excluded	Legal sees the notification after it’s drafted	Include legal, comms, HR in plan authorship and drills
7. Blank-page drafting	Time spent formatting instead of reporting facts	Pre-built notification templates for all 3 stages
8. No lessons-learned step	Final report written from memory after the fact	Post-incident review scheduled before closing the incident

Frequently Asked Questions

Does the 24-hour clock start when we confirm the incident or when we first notice it?
It starts from awareness of the incident, not from confirmation of its cause or scope — which is why BSI’s “speed over completeness” principle exists: you’re expected to file the early warning before you have the full picture [2].

Is a written incident response policy enough to satisfy Article 21(2)(b)?
A document satisfies the requirement to have measures in place, but an untested plan is a real gap in practice — tabletop exercises are how you find out whether the documented roles and escalation paths actually function under time pressure [4] [5].

Do we need to notify our customers, or only the competent authority and CSIRT?
Article 23 also requires notifying service recipients of significant incidents likely to affect the service they receive, along with protective measures they can take — this is separate from the regulatory notification to the competent authority or CSIRT [1].

What happens if we miss the 24-hour deadline or file an incomplete report?
Article 34 ties administrative fines directly to Article 21 and Article 23 infringements: up to EUR 10,000,000 or 2% of worldwide annual turnover for essential entities, and up to EUR 7,000,000 or 1.4% for important entities, whichever is higher [1]. A missed or malformed notification falls squarely under Article 23, which is why a pre-tested classification and reporting process (Mistakes 1, 2, and 7 above) is worth building before you need it rather than after a missed deadline.

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. NIS2 Directive (EU) 2022/2555, Article 23 — Reporting obligations. EUR-Lex
2. BSI (Bundesamt für Sicherheit in der Informationstechnik) — NIS-2-Meldepflicht
3. BSI (Bundesamt für Sicherheit in der Informationstechnik) — NIS-2 Incident Response
4. Cyber Management Alliance — The Ultimate Guide to a Cyber Tabletop Exercise in 2026
5. Cisco Talos Intelligence — Seven Common Mistakes Companies Make When Creating an Incident Response Plan