The NIS-2 and DORA incident reporting obligations set legally binding, clock-driven deadlines that begin the moment an organisation becomes aware of a significant incident. Under NIS-2 Article 23, awareness triggers a 24-hour window for an early warning, a 72-hour window for a formal incident notification, and a one-month deadline for a final report. DORA Articles 19 to 23 impose a parallel but structurally different regime for financial entities, with initial notifications required within four hours of classifying an incident as major. Understanding exactly where these two frameworks overlap, where they diverge, and what evidence regulators will demand is no longer an advanced compliance question: it is a baseline operational requirement for every CISO, compliance officer and DPO in a regulated sector.
The exact timelines under NIS-2 Article 23 and DORA Articles 19 to 23
NIS-2 Article 23 establishes a three-stage reporting cascade, while DORA Articles 19 to 23 introduce a separate cascade with shorter initial windows and specific content requirements defined further by Commission Implementing Regulation (EU) 2024/2690.
NIS-2 Article 23: the three-stage cascade
Stage one is the early warning, which must reach the CSIRT or, where applicable, the competent authority within 24 hours of the entity becoming aware. At this stage, the organisation is not required to have completed an investigation. The early warning must indicate whether the incident is suspected to be caused by unlawful or malicious acts and whether it may have cross-border impact. Stage two is the incident notification, due within 72 hours. This must include an initial assessment of severity, the affected services, the preliminary root cause and any indicators of compromise. Stage three is the final report, due within one month of submitting the incident notification. It must cover a detailed description of the incident, the nature of the threat, root cause findings, applied mitigations, and actual and potential cross-border effects. The ENISA CSIRT Network coordinates the exchange of these reports across Member State boundaries when cross-border impact is identified.
DORA Articles 19 to 23: the financial sector parallel
DORA applies to credit institutions, payment institutions, investment firms, insurance undertakings, crypto-asset service providers and a range of other financial entities defined in Article 2. For these entities, DORA Article 19 requires that major ICT-related incidents be reported to the competent supervisory authority. Commission Implementing Regulation (EU) 2024/2690 specifies the content of each report in detail.
| Stage | NIS-2 Article 23 | DORA Articles 19–23 |
|---|---|---|
| Initial alert | 24 hours from awareness | 4 hours from classification as major (max 24 hours from detection) |
| Intermediate notification | 72 hours from awareness | 72 hours from detection: intermediate report with updated classification |
| Final report | 1 month from incident notification | 1 month from submission of intermediate report |
| Recipient | CSIRT or competent national authority | Competent financial supervisor (EBA, ESMA, EIOPA via national authority) |
DORA Article 2(3) establishes it as lex specialis for financial entities. A bank that is also classified as an essential entity under NIS-2 must therefore coordinate filings with both its financial supervisor and the relevant NIS competent authority, using distinct report formats.
What constitutes a significant or major incident
Precise classification thresholds determine whether the reporting clock starts at all. Getting this wrong in either direction carries regulatory consequences.
Under NIS-2, an incident is significant if it causes or is capable of causing severe operational disruption or financial loss to the affected entity, or material harm to other persons. Commission Implementing Regulation (EU) 2024/2690 provides the specific criteria used to assess significance, including estimated number of affected users, duration, geographic spread and the degree to which the service is critical to public order or safety.
Under DORA, the European Supervisory Authorities (EBA, ESMA and EIOPA) publish joint guidelines specifying the thresholds that trigger the major incident classification. These thresholds include criteria such as clients affected, transaction volume impacted, geographic spread, duration of service unavailability, data integrity loss and reputational damage. Because the two frameworks use distinct scoring criteria, organisations within both scopes need two parallel classification matrices in their incident management policy.
Evidence requirements: what authorities and CSIRTs will ask for
Regulators do not accept narrative descriptions alone. The intermediate and final reports under both frameworks require structured technical evidence that can be audited and, where cross-border impact is found, shared with other Member State authorities through the ENISA CSIRT Network.
The evidence baseline that every significant incident file should contain includes: timestamped SIEM logs covering the detection window and the period immediately before it, network flow records, authentication and access logs, endpoint telemetry, any indicators of compromise identified, a change log of mitigating actions taken with timestamps, evidence of notification to affected data subjects where Article 34 GDPR applies, and records of internal escalation showing when management was informed. ISO/IEC 27035, the international standard for information security incident management, provides a process model that maps directly onto these evidence categories and is referenced by regulators when assessing whether an organisation’s incident management capability is proportionate to its risk profile.
Retention periods under NIS-2 and DORA are not harmonised at the framework level, but national transpositions and sectoral supervisory guidance generally require incident records to be retained for a minimum of five years for financial entities under DORA and at least three to five years for NIS-2 entities depending on the Member State.
According to the IBM Cost of a Data Breach Report 2023, the average time to identify and contain a data breach is 277 days. Only 33% of breaches were identified by the organisation’s own security team; the rest were disclosed by attackers or third parties. Against a 24-hour early warning deadline, a 277-day mean detection gap is structurally incompatible with compliance.
How sovereign infrastructure changes the detection and reporting equation
On-premises, self-controlled infrastructure gives an organisation unmediated access to its own evidence at the moment an anomaly appears. This is not a theoretical advantage: it is operationally decisive when a 24-hour window is the outer limit.
In a public cloud environment, the organisation’s security team depends on the provider’s logging pipeline, API rate limits and support escalation paths to retrieve the telemetry needed to classify and report an incident. Cloud providers may impose delays on log export, limit retention periods on lower-tier subscriptions, or require contractual escalation before full forensic access is granted. None of those constraints affect a team with direct access to an on-premises SIEM fed by self-controlled network and endpoint sensors.
Sovereign infrastructure also removes the jurisdictional ambiguity created by the US CLOUD Act and FISA 702. When logs reside on servers controlled by a US-headquartered provider, those logs can in principle be accessed by US authorities without the knowledge of the European data controller. This creates a situation where an organisation may be unaware that its incident evidence has been viewed or modified by a third party, undermining the integrity of the forensic record presented to regulators.
The IBM Cost of a Data Breach Report 2023 found that the average total cost of a data breach in 2023 reached USD 4.45 million, the highest figure in the report’s history. Organisations with a high level of incident response readiness, including tested runbooks and deployed SIEM, consistently showed lower breach costs and shorter containment timelines in the same report.
Structuring a runbook that meets the 24-hour and 72-hour deadlines
A compliant runbook is not a generic incident response checklist. It is a time-boxed procedure that assigns named roles, specifies decision criteria and pre-populates the notification templates regulators require.
The runbook must address the following: a detection-to-classification procedure that produces a documented classification decision within two hours of alert, using the specific NIS-2 and DORA threshold criteria as the classification rubric; a notification chain that does not depend on office hours, naming a primary and a backup contact for each of the CSIRT, the competent authority and the financial supervisor; pre-populated early warning templates that require only variable fields such as timestamp, affected service and initial severity to be completed; an evidence preservation checklist that is triggered at classification, not after the 24-hour filing; and a management notification protocol that satisfies the NIS-2 Article 20 governance requirement by ensuring the management body is informed and approves the filing before it is submitted.
Exercises must simulate incidents occurring on public holidays and outside business hours. The 24-hour clock under NIS-2 does not pause for weekends, and DORA’s four-hour initial notification window makes this even more acute. Regulators in several Member States have already issued guidance stating that reliance on business-hours staffing is not an acceptable operational model for essential or important entities.
Management liability under NIS-2 Article 20
NIS-2 Article 20 makes the management body directly accountable for cybersecurity governance, including the adequacy of incident reporting procedures. As stated in the Directive’s own framing: “Management bodies of essential and important entities must approve the cybersecurity risk-management measures taken by those entities and oversee their implementation.” Article 20(2) requires Member States to ensure that management body members can be held personally liable for infringements by the entity.
In practice, national transpositions allow competent authorities to impose financial penalties on individual managers and, in serious cases, to impose temporary bans on exercising management functions. The governance mitigation is straightforward in principle but demanding in execution: the management body must have documented evidence that it approved the incident response policy, was briefed on its obligations, received regular reports on the organisation’s incident management capability, and was notified promptly when a significant incident occurred.
ENISA has noted that incident reporting is not a bureaucratic exercise but “the mechanism by which authorities and operators together limit cascading harm across critical infrastructure.” That framing reflects the systemic intent behind both NIS-2 and DORA: the reporting obligations exist to make the European supervisory ecosystem function as a real-time defence network, not merely to create a paper trail after damage is done. For management bodies, understanding that purpose is the starting point for proportionate governance.
FAQ
Does NIS-2 Article 23 replace DORA’s incident reporting for banks and payment institutions?
No. DORA Article 2(3) establishes that DORA operates as lex specialis for financial entities already covered by it, meaning DORA’s more detailed ICT incident reporting regime in Articles 19 to 23 takes precedence. NIS-2 Article 23 still applies to non-financial critical infrastructure. Financial entities that are also essential entities under NIS-2 must coordinate reporting to both the competent NIS authority and the relevant financial supervisor.
What is the difference between the 24-hour early warning and the 72-hour incident notification?
The 24-hour early warning is a threshold-crossing alert sent as soon as the entity becomes aware of a significant incident, even with limited information available. The 72-hour notification must include an initial assessment of severity, impact and indicators of compromise. The final report, due within one month, must contain a full root-cause analysis, applied mitigations and cross-border impact assessment.
Can management board members be personally fined if an organisation misses the NIS-2 reporting deadlines?
Yes. NIS-2 Article 20(2) requires that Member States allow competent authorities to hold natural persons exercising managerial responsibility personally liable for infringements. Depending on national transposition, this can include financial penalties on individuals and temporary bans from management functions, in addition to fines levied on the entity itself.
What makes an incident significant under NIS-2 versus major under DORA?
NIS-2 uses criteria including operational disruption severity, financial loss and cross-border impact, with detailed thresholds in Commission Implementing Regulation (EU) 2024/2690. DORA uses distinct ESA-specified thresholds covering clients affected, transaction volume, service unavailability duration and data integrity loss. Organisations in both scopes need two separate classification matrices, because the criteria do not map one-to-one.
Why is sovereign, on-premises infrastructure relevant to the 24-hour early warning deadline?
In a public cloud environment, the organisation depends on the provider’s logging pipeline and support processes to retrieve the forensic evidence needed to classify and report. Sovereign infrastructure under the organisation’s own control gives security teams immediate, unrestricted access to SIEM data and network flow records at the moment an anomaly is detected, eliminating the latency introduced by cloud provider escalation paths when 24 hours is the outer limit.