From When the Reporting Deadline Clock Really Starts Ticking

7 min read

Four hours. That’s all the time DORA gives a financial firm to report a major IT incident to regulators. NIS2 allows 24, GDPR 72. Three frameworks, three clocks-and the critical question almost no one asks in time: When exactly does the countdown start?

Key Takeaways

Clearly tiered: DORA requires the initial report within 4 hours, NIS2 the early warning within 24, and GDPR the notification within 72. DORA is the strictest clock.
The starting point matters: NIS2 and GDPR count from the moment of incident awareness, while DORA starts the clock at classification as severe. Misjudge the trigger, and you lose hours.
One incident, multiple timers: A ransomware attack involving customer data can trigger NIS2, DORA, and GDPR simultaneously. Deadlines run in parallel, not sequentially.
The first hour belongs to process: If you’re still deciding who classifies and reports when the crisis hits, you’ve already missed the fastest deadline.

Three Deadlines Side by Side

Anyone working in a regulated company is usually familiar with the individual deadlines. Rarely do they sit neatly side by side on the table. This oversight comes back to haunt you in a crisis, when three regulatory frameworks kick in simultaneously-each with its own stopwatch.

What is the reporting deadline for a security incident? This refers to the legally defined timeframe within which a company must report a relevant incident to the competent authority. The clock starts ticking at a legally defined trigger, depending on the regulation-either the moment of awareness or the classification of the incident. The attack itself doesn’t start the countdown.

Regulation	Initial Deadline	Clock Starts When	Recipient
DORA	4 hours	Classified as severe	BaFin
NIS2	24 hours (early warning)	Incident awareness	BSI
GDPR	72 hours	Awareness of data breach	Data protection authority

Behind each initial deadline lies a cascade. NIS2 requires a full report within 72 hours after the 24-hour early warning, followed by a final report after one month. DORA follows the same pattern: an interim update within 72 hours and a final report after a month. The first deadline isn’t the finish line-it’s the starting gun for a multi-stage reporting process.

Whether an incident even falls under one of these timelines depends on the scope. NIS2 applies to essential and important entities across eighteen sectors, from energy to healthcare to digital services. DORA targets the financial sector and its ICT service providers. GDPR applies regardless of industry, as long as personal data is affected. Many companies underestimate that they may be subject to multiple regimes at once. A payment service provider must comply with all three, while a hospital must adhere to NIS2 and GDPR.

When the Clock Starts Ticking

This is where most plans falter. The countdown doesn’t begin with the first suspicious log entry. It starts at a legally defined moment. For NIS2 and GDPR, that’s the point of *awareness*-the moment a company knows with sufficient certainty that a reportable incident has occurred. For DORA, it’s the classification of the incident as severe, which must happen promptly after discovery.

The distinction may sound academic, but in a crisis, it costs real time. A security team spotting an anomaly at 2:00 AM hasn’t yet reached “awareness” in the legal sense. Once the analysis confirms the incident, the clock starts-and there’s no turning it back. Delaying classification to buy time risks accusations of late reporting during an audit.

In practice, this means: The definitions of *awareness* and *classification* must be established in writing beforehand, with clear thresholds and a designated decision-maker. Addressing this only during an incident burns the very minutes DORA doesn’t allow in the first place.

When Multiple Clocks Start Ticking at Once

The worst-case scenario isn’t the rare one. A ransomware attack on a payment service provider encrypts systems and exfiltrates customer data. The moment the team detects and classifies the incident, three clocks begin counting down simultaneously: DORA due to the severe ICT incident, NIS2 because of the disruption to essential services, and GDPR because of the affected personal data.

The deadlines run in parallel, each with its own pace and reporting to different authorities. Coordinating multiple separate reports from different teams under time pressure is the surest way to miss at least one deadline. A smarter approach is a single internal trigger that simultaneously initiates all three reporting processes and pre-fills the required fields for each.

What often gets overlooked in the chaos is documentation. Every regulator expects a traceable timeline later: when the incident was discovered, when it was classified, and when it was reported. Anyone reconstructing this timeline after the fact will quickly find themselves struggling to explain delays. A log that runs from the first minute provides the best protection against accusations of delayed reporting and delivers the evidence that will inevitably be requested during an audit.

The Workflow for the First Hour

The strictest clock sets the pace. If you’re prepared for DORA’s 4-hour deadline, you’ll meet the others by default. Four steps should be practiced in advance-long before an actual incident occurs.

Immediate classification by a designated role. A predefined person decides, based on clear thresholds, whether an incident is reportable and severe. Under DORA, this classification starts the clock; under NIS2 and GDPR, it records the moment of awareness. This ensures the countdown begins at a documented point in time.
Keep reporting channels ready. Access to the BaFin reporting portal, BSI platform, and data protection authority should be prepared before an incident occurs, complete with contact details and templates for mandatory fields.
One trigger for all regimes. An internal process automatically checks, for every confirmed incident, which of the three obligations apply and initiates the appropriate reports.
Initial report before completeness. The first report doesn’t require a full analysis. A timely, honest brief update beats a late, perfect one. Details can follow in subsequent reporting steps.

This is practiced in a tabletop exercise where the clock runs in real time. Only then does it become clear whether classification can be done in minutes-or whether the team is still debating as the DORA deadline expires. The lesson from most exercises is the same: It’s not the technology that’s lacking, but the practiced decision-making.

Frequently Asked Questions

When does the NIS2 24-hour deadline start?

The clock starts at the point of knowledge of a significant security incident-that is, the moment the company has sufficient certainty that a reportable incident has occurred. The early warning must then be submitted to the BSI within 24 hours.

Why is DORA’s 4-hour deadline so strict?

DORA targets the financial sector, where an IT outage can quickly have systemic consequences. That’s why it requires the initial report to BaFin within 4 hours of classifying an incident as severe-significantly tighter than NIS2’s 24-hour window.

Do I have to report the same incident multiple times?

Yes, if it triggers multiple regimes. A ransomware attack with data exfiltration could affect DORA, NIS2, and GDPR simultaneously. Reports go to different authorities and should be initiated in parallel through a coordinated internal process.

What counts as the starting point-awareness or discovery?

Legally, NIS2 and GDPR count confirmed awareness-the moment analysis confirms the incident. A mere suspicion isn’t enough. Under DORA, the key factor is the classification as severe, which must happen promptly after discovery and cannot be delayed.

What happens if I miss a deadline?

Missed reporting deadlines can result in fines and, under NIS2, even personal liability for management. Regulators typically view delayed or omitted reports more harshly than an openly reported incident.