GDPR Breach Notification vs NIS2 and DORA: One Incident, Multiple Clocks

A ransomware intrusion at a mid-sized financial entity encrypts customer records and disrupts a payment service. By the time the security team has confirmed what happened, three regulatory clocks are running — and they do not measure the same thing, do not point to the same authority, and do not stop at the same time.

This article maps the three breach and incident reporting regimes — GDPR, NIS2, and DORA — side by side: what triggers each, what each demands, and how to run all three from a single internal incident record without contradicting yourself. For how the three regimes intersect more broadly, start with GDPR, NIS2 and DORA: How the Three EU Regimes Intersect.

This is not legal advice. National NIS2 transpositions vary on reporting specifics, and the proposed Digital Omnibus would change parts of this picture — both noted below.

Three regimes at a glance

	GDPR	NIS2	DORA
What it covers	Personal data breaches	Significant incidents	Major ICT-related incidents
Trigger	Awareness of a personal data breach	Awareness of a significant incident	Classification as a major incident
Reports to	Data protection authority	National CSIRT / competent authority	Financial competent authority
First deadline	72 hours (to authority)	24 hours (early warning)	Short window after classification (initial notification)
Later stages	— (plus communication to individuals where high risk)	72-hour notification, 30-day final report	Intermediate report, 1-month final report
Notify individuals?	Yes, where high risk to their rights	Inform service recipients where relevant	Inform clients where relevant

Three different trigger concepts. Three different first deadlines. The single most common error is assuming they align — they do not.

GDPR breach notification — Articles 33 and 34

GDPR concerns the personal data breach — defined in Article 4(12) as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

Notification to the supervisory authority — Article 33

The controller must notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, not later than 72 hours after becoming aware of it — unless the breach is unlikely to result in a risk to the rights and freedoms of individuals.

Two features matter. First, the risk filter: a breach posing no risk to individuals need not be notified to the authority, though it must still be documented internally. Second, awareness: the clock starts when the controller becomes aware that a personal data breach has occurred — a reasonable degree of certainty that a security incident has compromised personal data.

If notification is not made within 72 hours, it must be accompanied by reasons for the delay.

Communication to the data subject — Article 34

Where a breach is likely to result in a high risk to the rights and freedoms of individuals, the controller must also communicate the breach to the affected individuals, without undue delay. This is a separate, additional obligation — and a higher threshold than authority notification.

Article 34(3) provides exemptions: communication to individuals is not required if the controller has applied appropriate measures rendering the data unintelligible — notably strong encryption — or has taken subsequent measures ensuring the high risk is no longer likely, or where individual communication would involve disproportionate effort (in which case a public communication suffices).

What goes in a GDPR notification

Article 33(3) specifies the content: the nature of the breach including categories and approximate numbers of data subjects and records concerned; the name and contact details of the DPO or other contact point; the likely consequences; and the measures taken or proposed. Information may be provided in phases where it is not all available at once.

NIS2 incident reporting — Article 23

NIS2 concerns the significant incident — an incident that has caused or is capable of causing severe operational disruption or financial loss, or that has affected other persons by causing considerable material or non-material damage.

The cadence is the 24-72-30 model: a 24-hour early warning, a 72-hour incident notification, and a final report within one month. The clock starts on awareness of the significant incident. The full mechanics — including the trust service provider derogation and national variations — are in NIS2 Incident Reporting: The 24-72-30 Day Timeline.

The critical contrast with GDPR: NIS2's trigger is a significant incident, not a personal data breach. An availability incident — a ransomware attack that disrupts a service but exfiltrates no personal data — can be a NIS2 significant incident while not being a GDPR personal data breach at all. Conversely, a small unauthorised disclosure of personal data can be a GDPR breach while falling below the NIS2 significance threshold.

DORA incident reporting — Articles 17 to 23

DORA concerns the major ICT-related incident. An ICT-related incident is classified against criteria in the Commission Delegated Regulation — client impact, data losses, geographic spread, duration, economic impact — and where it meets the threshold for major, reporting is triggered.

The DORA cadence is initial notification, intermediate report, and final report. A distinctive feature: DORA's reporting clock starts on classification as major, not simply on awareness — classification is itself a required step. The DORA reporting mechanics, and how they differ from NIS2's timing, are covered in NIS2 vs DORA: Key Differences and DORA ICT Risk Management Framework Explained.

Three clocks, one keyboard. Photo: Christopher Gower / Unsplash.

The three clocks, compared

The clocks are the source of most operational confusion. A precise comparison:

GDPR — 72 hours, from awareness of a personal data breach. A single deadline to the authority, plus a separate high-risk communication to individuals. No mandatory staged follow-up, though phased information is permitted.

NIS2 — 24 hours, then 72 hours, then 30 days, from awareness of a significant incident. A staged cadence. The first deadline (24h) is sooner than GDPR's (72h).

DORA — short initial window, then intermediate, then 1 month, from classification as major. A staged cadence, but the clock starts at a different event — classification — than the other two regimes.

The implication: an incident that is simultaneously a GDPR breach, a NIS2 significant incident, and a DORA major incident produces a 24-hour deadline (NIS2 early warning), a 72-hour deadline (GDPR notification and NIS2 notification — close but not identical in content), and two separate 30-day / 1-month final reports. The compliance team must hit the earliest deadline first and work outward, while keeping the content consistent across all submissions.

One record, three notifications. Photo: Adeolu Eletu / Unsplash.

Running it from one incident record

The defensible operational model is one internal incident record, multiple parallel reporting workflows.

The single incident record

From the moment an incident is detected, maintain one authoritative internal record: timeline, affected systems, affected data, affected individuals, containment actions, root cause as it emerges, decisions taken and by whom. This record is the single source of truth. Every external report draws from it.

The reason this matters is contradiction risk. If the GDPR notification, the NIS2 report, and the DORA report are each drafted independently by different people from different notes, they will diverge — different affected-record counts, different timelines, different root-cause framing. Authorities cross-reference. A regulated entity whose three reports tell three slightly different stories has handed every one of its regulators a reason to look harder.

Parallel reporting workflows

From the single record, pre-built templates feed each regime:

• GDPR template — Article 33(3) content, oriented to risk to individuals
• NIS2 template — the three-stage Article 23 content, oriented to service disruption
• DORA template — the classification assessment and the three-stage content, oriented to operational resilience

Each template is owned by a named person with a named deputy. Each has its own deadline tracked from the start of the incident. The team works the earliest deadline first.

Pre-establish the authority relationships

Three regimes mean potentially three authorities — the DPA, the CSIRT, the financial supervisor. An entity that has never contacted one of them before the incident loses time establishing the channel. Pre-register, pre-identify the portals, pre-store the contact details in the incident runbook. This is nearly free and saves hours under pressure.

Genuine differences to keep straight

Beyond the clocks, four substantive differences:

1. Different triggers. GDPR: a personal data breach. NIS2: a significant incident. DORA: a major ICT-related incident. One event can be one, two, or all three — or trigger only one.
2. Different risk lenses. GDPR assesses risk to individuals. NIS2 assesses disruption to services. DORA assesses impact on operational resilience. The same incident is assessed three ways.
3. Encryption has different effects. Under GDPR, strong encryption of breached data can remove the obligation to notify individuals. Under NIS2 and DORA, encryption is a baseline control and does not switch off the reporting obligation.
4. The individual-notification step is GDPR-specific. Only GDPR has a structured obligation to communicate the breach to affected individuals (Article 34). NIS2 and DORA have narrower obligations to inform service recipients or clients where relevant.

The Digital Omnibus on the horizon

The proposed Digital Omnibus would change parts of this picture. It proposes a single EU incident-reporting entry point — "report once, share many" — routing notifications across NIS2, GDPR, DORA, eIDAS, and CER through one platform with common templates. It also proposes, for GDPR specifically, limiting breach notification to breaches posing a high risk to individuals and extending the deadline from 72 to 96 hours.

If adopted and built, this would materially reduce the multi-clock friction described above. But it is a proposal — subject to the ordinary legislative procedure, with the GDPR elements expected to be among the most contested. The analysis is in Report Once, Share Many: What the Digital Omnibus Actually Changes. Until it is adopted, the present three-regime, three-clock model is the operative reality.

Frequently asked questions

If an incident exposes personal data, do I report under GDPR or NIS2? Potentially both. If you are a NIS2 entity and the incident is also a significant incident, you report under both — to the DPA under GDPR and to the CSIRT under NIS2. They are separate obligations.

Is the GDPR deadline 72 hours like NIS2? The numbers coincide partly but the clocks differ. GDPR's authority notification is 72 hours. NIS2's first deadline is a 24-hour early warning, with the 72-hour notification as its second stage. Do not assume one 72-hour clock.

Does encryption remove my reporting obligation? Under GDPR, strong encryption can remove the obligation to notify affected individuals (Article 34), though not necessarily the authority. Under NIS2 and DORA, encryption is a baseline control and does not remove the reporting obligation.

What if I'm a financial entity — does DORA replace GDPR breach notification? No. DORA is lex specialis relative to NIS2, not GDPR. A financial entity reports ICT incidents under DORA and personal data breaches under GDPR.

Can I send the same report to all three authorities? Not as-is — the content requirements and orientations differ. But all three should draw from one internal incident record so the facts are consistent.

When does the clock start? GDPR and NIS2 both start on awareness — of a personal data breach and of a significant incident respectively. DORA starts on classification of an incident as major. Three start events.

The bottom line

Three takeaways:

1. One incident, up to three regimes, three non-aligned clocks. Hit the earliest deadline first; the 24-hour NIS2 early warning usually comes before everything else.
2. One incident record, parallel reporting workflows. A single source of truth prevents the contradiction risk that hands regulators a reason to dig.
3. The triggers genuinely differ. A personal data breach, a significant incident, and a major ICT-related incident are three different things — an event can be any combination of them.

For the broader three-regime picture, see GDPR, NIS2 and DORA: How the Three EU Regimes Intersect. For the NIS2 reporting detail, NIS2 Incident Reporting: The 24-72-30 Day Timeline.

---

Sources & further reading

• Regulation (EU) 2016/679 — GDPR — Article 4(12) (definition), Articles 33 and 34 (breach notification and communication)
• Directive (EU) 2022/2555 — NIS2 — Article 23 (incident reporting)
• Regulation (EU) 2022/2554 — DORA — Articles 17 to 23 (ICT-related incident management and reporting)
• European Data Protection Board (EDPB) — Guidelines on personal data breach notification
• European Commission — Digital Strategy: NIS2 directive — Digital Omnibus Package and incident-reporting harmonisation