NIS2 Incident Reporting: How to Actually Meet the 24-Hour Deadline
NIS2 Article 23 requires an early warning within 24 hours, a qualified notification within 72 hours, and a final report within one month. Most organizations have an incident response plan. Very few can actually report under pressure.
NIS2 Incident Reporting: How to Actually Meet the 24-Hour Deadline
An incident response plan exists in every ISMS. It describes who does what in an emergency, which escalation paths apply, and how the incident gets documented. All correct, all important – and none of it is what NIS2 actually evaluates.
NIS2 doesn't evaluate whether a plan exists. NIS2 evaluates whether an organization can deliver a coordinated, fact-based early warning to authorities within 24 hours – while the incident is still unfolding. This is not a documentation problem. It's an operating system problem.
Jump to:
- The three-stage reporting regime in detail
- Why 24 hours is shorter than you think
- What an incident management system must deliver
- The five questions that must be answered in the first 24 hours
What Changed With NIS2
Under the original NIS Directive, reporting obligations existed – but they were less specific, affected fewer organizations, and were rarely enforced in practice. NIS2 has fundamentally changed this.
Article 23 of the NIS2 Directive introduces a binding three-stage reporting regime – with concrete deadlines, concrete content requirements, and concrete consequences for non-compliance. National implementations specify the reporting channels: in Germany, reports go to the BSI as the central CSIRT.
At the same time, the scope has expanded massively. In Germany alone, approximately 30,000 organizations fall under the new requirements. For many of them, submitting a structured incident report to a government authority is entirely new territory.
The Three-Stage Reporting Regime in Detail {#the-reporting-regime}
Stage 1: Early Warning – Within 24 Hours
As soon as an organization becomes aware of a significant security incident, an early warning must be submitted to the relevant authority within 24 hours. "Significant" under NIS2 means: the incident has caused or is capable of causing severe operational disruption or financial loss, or it has affected or is capable of affecting other persons by causing considerable material or non-material damage.
The early warning must indicate: whether the incident is suspected of being caused by unlawful or malicious acts, and whether it could have a cross-border impact.
The early warning is deliberately designed as a rapid initial notification – speed over completeness. But "rapid" doesn't mean "informal": the report must be submitted through official channels and contain the required elements.
Stage 2: Qualified Notification – Within 72 Hours
Within 72 hours of becoming aware of the incident, a qualified incident notification follows. This updates the early warning and includes an initial assessment: severity and impact, affected systems and services, and – where available – indicators of compromise.
This is where the difference between documentation and operational capability becomes tangible for the first time: within 72 hours, an organization must not only have technically analyzed the incident, but also be able to present the results in a structured, traceable, authority-grade format.
Stage 3: Final Report – Within One Month
No later than one month after the initial notification, a final report is due. This includes a detailed description of the incident, root cause analysis, the countermeasures taken, and – where relevant – cross-border impacts.
Additionally, authorities may request interim reports at any time. Operators of critical infrastructure face further detail requirements in their national implementations.
Why 24 Hours Is Shorter Than You Think {#why-24-hours-is-short}
Twenty-four hours sounds like a full day. In the reality of an ongoing security incident, it's an extremely tight window. Here's what typically happens within those 24 hours – simultaneously:
Hour 0–4: Detection and initial triage. An alert fires – or someone reports something unusual. The security team begins triage: Is this a real incident? How severe? What systems are affected? In many organizations, even this phase is chaotic because responsibilities are unclear or the right people aren't reachable.
Hour 4–12: Parallel escalation. While technical analysis continues, decisions must be made in parallel: Who informs executive management? Who coordinates with Legal and Communications? Are there contractual notification obligations toward customers? Does the DPO need to be involved? Each of these questions requires coordination between functions that rarely work together in daily operations.
Hour 12–20: Fact-gathering under uncertainty. The technical facts are still incomplete. Executive management wants clarity. Legal wants to know what can and cannot be said. Communications needs messaging guidance. Meanwhile, the early warning must be prepared – with mandatory content that needs to be formulated reliably despite incomplete information.
Hour 20–24: Reporting. The early warning must be submitted through the official portal. It must contain the required elements, it must be submitted by an authorized person, and it must be documented – for the organization's own evidence trail.
This is why an incident response plan as a PDF isn't enough. Not because the plan is bad, but because the operational challenge lies in coordination – and coordination under time pressure only works with a system, not a document.
The Five Questions That Must Be Answered in the First 24 Hours {#the-five-questions}
Each of these questions sounds simple. None of them are when the incident is still unfolding:
1. What happened – and how bad is it?
Triage and initial classification: Is this a significant incident under NIS2? What systems, services, and data are affected? Are there indicators of an active threat? This assessment must happen quickly, even though information is thin.
2. Who decides what – and based on what?
Executive management is personally liable. But management can't decide alone – they need processed information from Security, IT, Legal, and potentially Data Protection. Who delivers this information? In what format? Through which channel? And who has the authority to approve the early warning for submission?
3. Which external reporting obligations apply?
NIS2 isn't the only obligation. A GDPR notification to the data protection authority may be required in parallel (72-hour deadline). There may be contractual notification obligations toward customers. Critical infrastructure operators face additional requirements. All of this must be managed in parallel – not sequentially.
4. How do the involved functions coordinate?
Security analyzes. Legal evaluates. Communications drafts. Management decides. IT contains. In theory, this is clear. In practice – at 3 AM, with incomplete information and extreme time pressure – this coordination regularly breaks down. What's needed: defined roles, defined communication channels, and a system that tracks who did what and when.
5. How is everything documented – while it's happening?
NIS2 requires traceability. This means: the entire incident response must be documented as it happens – not reconstructed after the fact. Who made which decision when? Based on what information? What communication took place? Which version of the situation assessment was current at the time of reporting? This documentation isn't just relevant for authorities – it protects executive management on the question of personal liability.
Incident Response Plan vs. Incident Management System {#what-an-ims-must-deliver}
This distinction is critical – and it's made too rarely in the market:
An Incident Response Plan (IRP) describes what should happen in an emergency: roles, escalation paths, process steps, contact lists. It's a document – and as such, indispensable. ISO 27001 requires it, and it forms the basis for any incident response.
An Incident Management System (IMS) is the operational infrastructure that executes the plan: real-time coordination between functions, structured communication, versioned documentation, integrated evidence management, status overview for executive management, and the ability to produce reliable reports within regulatory deadlines.
| Capability | Incident Response Plan | Incident Management System |
|---|---|---|
| Roles and responsibilities defined | ✅ | ✅ |
| Escalation paths described | ✅ | ✅ |
| Process steps documented | ✅ | ✅ |
| Real-time coordination between functions | ❌ | ✅ |
| Versioned documentation during the incident | ❌ | ✅ |
| Parallel management of multiple reporting obligations | ❌ | ✅ |
| Integrated evidence trail for authorities | ❌ | ✅ |
| Real-time status overview for executive management | ❌ | ✅ |
| Deadline-compliant reporting under time pressure | ❌ Depends on individuals | ✅ System-supported |
An IRP says "this is how it should work." An IMS ensures it actually does – at 3 AM, when the CISO is on vacation, when three reporting obligations trigger simultaneously.
NIS2 doesn't evaluate the plan. NIS2 evaluates the capability.
What Organizations Should Do Now
1. Test Your IRP Against NIS2 Deadlines
Not theoretically, but practically: tabletop exercise with a realistic scenario and the concrete question – can we produce an early warning within 24 hours that contains the required elements? Where does the process break? Who isn't reachable? Where is information missing?
2. Define Roles for the Reporting Chain
Who has the authority to approve the early warning? Who prepares the content? Who submits it through the official portal? These roles must be assigned by name – with deputies. "Security handles it" is not a role assignment.
3. Map Parallel Reporting Obligations
NIS2, GDPR, contractual obligations, sector-specific requirements – which reporting obligations apply to which incident type? Within what deadline? To which authority? This overview must exist before an incident, not be developed during one.
4. Prepare Templates
Templates for the 24-hour early warning, the 72-hour notification, and the final report – pre-created, pre-approved, pre-tested. Organizations that need to define the format during an incident lose critical time.
5. Establish Documentation as a Real-Time Process
Incident response must be documented as it happens – not retrospectively. This means: a central, versioned location for situation assessments, decisions, communications, and evidence. Scattered emails, chat messages, and personal notes are not evidence-grade under NIS2.
6. Practice Regularly
Tabletop exercises at least twice a year – with varying scenarios, involving all relevant functions including executive management. Every exercise reveals gaps that cost time in a real incident.
The Regulatory Consequences
The consequences for non-compliance with reporting obligations are clearly defined:
For essential entities: fines up to EUR 10 million or 2% of global annual turnover. For important entities: up to EUR 7 million or 1.4%. In Germany, additionally: personal liability of executive management under § 38 BSIG.
But the regulatory consequence isn't the only risk. An organization that cannot report within the required timeframe after a security incident has a double problem: the incident itself – and the evidence that it failed to meet its obligations. The second problem is often the bigger one.
Sources
- Directive (EU) 2022/2555 (NIS2 Directive) – Full Text – Official Journal of the European Union. Article 23 on reporting obligations for significant security incidents.
- BSI – NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) – § 32 BSIG on the three-stage reporting regime.
- BSI – #nis2know Info Package: NIS-2 Reporting Obligation – BSI's information package on implementing reporting obligations.
- ENISA – Implementing Guidance on NIS2 Security Measures – ENISA's implementation guidance, particularly on incident handling and reporting.
- ENISA – NIS2 Technical Implementation Guidance – Technical guidance on reporting formats, deadlines, and evidence requirements.