What happens in the first sixty minutes after a security team realizes something has gone badly wrong? That question sits at the heart of three European rulebooks that now overlap, contradict, and occasionally trip over one another. NIS2, DORA, and the GDPR all demand that organizations report incidents and all three impose serious fines for getting it wrong. Yet they count time differently, define incidents differently, and expect different things from the people on the phone at 2 a.m.
By 2027, national NIS2 transposition should be largely settled and DORA’s first full reporting cycle complete. That makes now the right moment to map the workflow differences rather than the legal text. This article focuses on how the clocks, forms, and penalty structures actually behave in practice, and where teams most often stumble.
Why Three Regimes Feel Like Three Different Jobs
The GDPR has been live since 2018. NIS2 entered into force on 16 January 2023, with Member States required to transpose it by 17 October 2024. DORA has applied since 17 January 2025. Each regime grew from a different concern: data protection, critical infrastructure resilience, and financial-sector operational resilience.
That origin story matters. Because the three were built for different problems, they do not share a single definition of an “incident,” a single reporting portal, or a single deadline. An organization that is a financial entity and also handles personal data can find itself running three parallel reporting workflows from one event.
The practical lesson from teams that have already been through this: do not build one incident process and bolt on compliance fields. Build a triage layer that decides which regimes are triggered, then run separate tracks from that decision point.
The Clock Problem: 24, 72, and One Month
The single most misunderstood area is time. People hear “72 hours” and assume all three regimes work the same way. They do not.
Under NIS2 Article 23, reporting is a three-stage flow. An early warning is due within 24 hours of becoming aware of a significant incident. An incident notification follows within 72 hours. A final report is due within one month.
Under the GDPR Article 33, breach notification to the supervisory authority is due within 72 hours of becoming aware, but only where there is a risk to rights and freedoms. There is no 24-hour early warning stage and no fixed final-report deadline. Article 34 separately requires informing data subjects “without undue delay” where there is a high risk.
DORA does not use a simple 24/72-hour clock at all. It uses an initial notification, an intermediate report, and a final report, with the precise deadlines set in regulatory technical standards rather than the Regulation itself. Teams that assume DORA mirrors NIS2 timing tend to discover the error during their first real incident, which is the worst possible time.
| Regime | First deadline | Second deadline | Final report | Fixed clock in the law? |
|---|---|---|---|---|
| NIS2 | Early warning, 24 hours | Notification, 72 hours | One month | Yes, in Article 23 |
| DORA | Initial notification | Intermediate report | Final report | No, set in technical standards |
| GDPR | 72 hours to authority | Data subjects “without undue delay” if high risk | None specified | Partly |
The workflow consequence is significant. NIS2 forces a very fast, low-detail first message. GDPR gives you three days but asks for a substantive assessment of risk. DORA asks for classification first, then notification, which means someone has to make a severity call before anything is submitted.
What Counts as an Incident Under Each Regime
Definitions drive everything downstream. If an event does not meet a regime’s threshold, no clock starts. Get the threshold wrong in either direction and you either over-report or, worse, miss a mandatory notification.
NIS2 covers significant incidents affecting network and information systems, with significance tied to severity, impact, and the likelihood of causing substantial operational disruption or financial loss. GDPR is triggered by a personal data breach, which is a much narrower concept focused on confidentiality, integrity, and availability of personal data. DORA covers ICT-related incidents with a material impact on financial services.
A ransomware attack that encrypts a customer database can hit all three. A misconfigured internal server with no personal data and no financial service impact may hit none. A phishing email that exposes staff credentials but no customer records may hit NIS2 and DORA while leaving GDPR untouched.
In practice, the useful habit is to build a decision tree that asks three questions in sequence: was personal data involved, was a regulated service disrupted, and was the impact material? The answers route the event, and the routing determines which clocks start. Teams that skip this step often default to “report everything to everyone,” which burns goodwill with supervisors and buries real incidents in noise.
Penalties: Three Very Different Fine Structures
Fines are where the regimes diverge most sharply, and where boards pay attention.
Under the GDPR Article 83(5), the ceiling is up to €20 million or 4% of global annual turnover, whichever is higher. That is a well-known number by now, and it applies to the most serious infringements.
Under NIS2 Article 34, essential entities face at least €10 million or 2% of global turnover, and important entities at least €7 million or 1.4%. The phrase “at least” is doing real work here: these are minimums Member States must adopt, so national caps vary considerably across the EU. A subsidiary in one country may face a different exposure than its sibling in another for the same incident.
DORA does not harmonize penalties in the Regulation itself. It relies on Member States’ administrative penalties and measures, which means the financial consequences depend heavily on national implementation. That is a meaningful difference from the GDPR’s single headline figure.
| Regime | Headline penalty | Basis | Harmonized across EU? |
|---|---|---|---|
| GDPR | Up to €20m or 4% of global turnover | Article 83(5) | Yes |
| NIS2 | At least €10m or 2% (essential); €7m or 1.4% (important) | Article 34 | No, national minimums |
| DORA | Set nationally | Member State law | No |
The workflow implication is that penalty exposure cannot be assessed centrally with a single number. Legal teams need a country-by-country view, and that view should feed into how incidents are prioritized when resources are stretched.
Where the Regimes Collide
The genuinely hard cases are the overlaps. A financial entity suffering a breach that is simultaneously a DORA ICT incident and a GDPR personal data breach faces two reporting tracks with different deadlines, different audiences, and different content requirements. Supervisory practice on coordinating the two is still developing, which means organizations are effectively writing the playbook as they go.
There is also a duplication risk in content. The same facts get written up three times in three formats for three audiences. Smart teams maintain a single incident record as the source of truth and generate regime-specific submissions from it, rather than drafting each notification from scratch under time pressure.
This is the same pattern that shows up in tooling decisions elsewhere: the workflow, not the feature list, determines whether things actually work. Teams comparing platforms often find the real differences in how handoffs and state changes are handled, which is why breakdowns like Airtable vs notion workflow differences understand 2027 resonate with operations leads. The same logic applies to Rabbitmq vs kafka workflow differences understand 2027 when engineering teams need to guarantee that incident events are not lost between systems.
Building a Reporting Workflow That Survives All Three
What actually works in practice tends to look unglamorous. Here is the sequence that holds up.
- Create a single triage gate. One person or rotation owns the decision on which regimes are triggered. This decision is logged with a timestamp, because every clock depends on it.
- Separate “awareness” from “confirmation.” NIS2’s 24-hour early warning runs from awareness. Teams that wait for full confirmation before starting the clock routinely miss it.
- Pre-draft the early warning. A template with placeholders for what is known, what is not, and what is being done can go out in minutes. Detail comes later.
- Keep one incident record, generate three outputs. The record holds facts; the outputs are formatted per regime.
- Map penalty exposure by country. Do not rely on a single EU-wide figure for NIS2 or DORA.
- Rehearse the DORA classification step. Because DORA requires classification before notification, the severity call is a bottleneck. Practice it.
A common mistake is treating the 72-hour GDPR deadline as generous. It is not, once you account for forensic scoping, legal review, and sign-off. Another is assuming the supervisory authority wants completeness at 72 hours. Most would rather have an honest partial picture than a polished report that arrives late.
Engineering teams building the underlying detection and logging pipelines face a related question about how much to standardize. The tradeoffs in Rust vs c workflow differences understand 2027 mirror the compliance dilemma: stricter guarantees reduce certain failure modes but slow delivery, and the right answer depends on what you are protecting.
For teams modernizing the developer tooling that supports incident response, the same handoff questions appear. Comparisons such as Cline vs cursor workflow differences understand 2027 and Kiro vs cursor workflow differences understand 2027 are useful because they focus on where work changes hands, which is exactly where compliance evidence tends to get lost.
Common Mistakes That Show Up Again and Again
Several failure patterns repeat across organizations.
The first is clock confusion between regimes. Someone applies the GDPR’s 72 hours to a NIS2 early warning and misses the 24-hour window entirely. The fix is a visible timer per regime, not a single incident timer.
The second is treating DORA deadlines as fixed numbers. Because they live in technical standards, they can be revised. Teams that hard-code them into runbooks without a review cadence get caught out.
The third is underestimating national variation. NIS2 penalty floors are minimums, and DORA penalties are national. A group-level policy that assumes uniformity will misprice risk.
The fourth is no evidence trail for the triage decision. Regulators increasingly ask not just what was reported but why something was or was not reported. A logged decision, with reasoning, is worth more than a perfect report.
The fifth is drafting in isolation. Three teams writing three documents from memory produce three inconsistent accounts of one event. That inconsistency is itself a finding.
What Changes by 2027
By 2027, national NIS2 transposition should be largely complete, which means the penalty floors become real rather than theoretical. DORA’s first full reporting cycle will have closed, giving supervisors actual data on how well entities classify and report. That is likely to sharpen expectations around the classification step in particular.
What is less clear is whether coordination between DORA and GDPR reporting will be formalized. As of late 2026, supervisory practice on running both tracks for a single event remains a work in progress. Organizations should plan for the awkward overlap rather than wait for guidance that resolves it.
The broader trend is toward evidence over narrative. Regulators want timestamps, decisions, and reasoning. A workflow that captures those by default will satisfy all three regimes far more easily than one that reconstructs them afterward.
Conclusion
NIS2, DORA, and the GDPR are not three versions of one rule. They are three different instruments that happen to point at the same events. NIS2 runs a fast 24-hour early warning into a 72-hour notification and a one-month final report. GDPR runs a single 72-hour clock tied to risk, with a separate duty to inform individuals. DORA runs a classification-first sequence whose deadlines live in technical standards and whose penalties are set nationally.
The organizations that handle this well do not memorize the legal text. They build a triage gate, keep one incident record, generate regime-specific outputs, and rehearse the steps that are easy to get wrong. They also map penalty exposure country by country, because the headline numbers are not the whole story.
By 2027, the compliance question will be less about knowing the rules and more about proving the workflow. That is a build problem, not a reading problem, and it is better solved now than during the next 2 a.m. call.
What is the main difference between NIS2 and GDPR incident reporting?
NIS2 uses a three-stage flow: an early warning within 24 hours, a notification within 72 hours, and a final report within one month. The GDPR uses a single 72-hour deadline to notify the supervisory authority where there is a risk to rights and freedoms, with no 24-hour early warning and no fixed final-report deadline. The GDPR also separately requires informing affected individuals without undue delay in high-risk cases.
Does DORA use the same 24/72-hour clock as NIS2?
No. DORA uses an initial notification, an intermediate report, and a final report, with the precise deadlines set in regulatory technical standards rather than in the Regulation itself. Teams that assume DORA mirrors NIS2 timing often discover the difference during a live incident. The classification step before notification is also a distinctive DORA feature.
How large are the fines under each regime?
The GDPR allows up to €20 million or 4% of global annual turnover, whichever is higher. NIS2 requires Member States to set minimums of at least €10 million or 2% of global turnover for essential entities, and at least €7 million or 1.4% for important entities, so national caps vary. DORA does not harmonize penalties in the Regulation and relies on Member State administrative penalties.
Can one incident trigger all three regimes at once?
Yes. A ransomware attack affecting a financial entity’s customer database could simultaneously be a DORA ICT incident, a NIS2 significant incident, and a GDPR personal data breach. Each regime has its own threshold, deadline, and audience, so the organization must run parallel reporting tracks from a single incident record. Supervisory practice on coordinating DORA and GDPR reporting is still developing.
What is the most common reporting mistake organizations make?
Applying one regime’s deadline to another. The most frequent error is treating the GDPR’s 72 hours as the timeline for a NIS2 early warning, which is actually due within 24 hours of becoming aware. A related mistake is failing to log the triage decision itself, which regulators increasingly ask about when reviewing why something was or was not reported.
How should a team prepare its workflow before 2027?
Build a single triage gate that decides which regimes are triggered and logs the timestamp. Pre-draft the NIS2 early warning so it can go out in minutes. Keep one incident record as the source of truth and generate regime-specific submissions from it. Map penalty exposure country by country, and rehearse the DORA classification step, since it is the bottleneck that delays every downstream notification.
