# Data breach clocks: Data protection law (GDPR) 72h vs resilience law (DORA) 24h — which?

Robert Chen · October 31, 2026

> Compare GDPR 72-hour breach notices with DORA 24-hour ICT incident reports, learn which clock applies, and verify scope before sharing data.

This guide compares the GDPR 72-hour breach notice with the DORA 24-hour ICT incident report for cross-functional data sharing.

It shows which clock applies, what to verify, and how to compare like-for-like totals and terms before committing.

![This guide compares the GDPR 72-hour breach notice — Data breach clocks](https://static.mm-ais.com/article-images-ai/data-breach-clocks-data-protection-law-g-ai-a1f6b221.jpg)

## How It Works

To verify before committing, the mechanism at play is a trigger-to-classification path, not a single shared clock. An event must first be assessed for its scope of impact before any cross-functional data sharing is directed to a notice channel. The practical check is to treat classification as its own step: the same set of facts can be evaluated under different legal bases, so equivalence cannot be assumed from a shared label. This step is about determining which regime's trigger applies to the facts as they are known at the moment of review, using live texts rather than a cached summary.

The key terms that must be separated for this mechanism are the trigger, the scope, and the channel. A trigger is the condition that moves an event from internal review to a reporting obligation, defined by the regime itself. Scope is the boundary of what must be considered for that trigger, which may differ by the type of entity or the type of impact being assessed. The channel is the route by which a notice is made, which is distinct from the trigger and from the scope. Keep the discipline grounded in the two regimes themselves: GDPR and DORA each define their own trigger, scope, and channel in their own legal texts, so the need to separate these terms comes from the laws, not from any outside analogy. Confirm each term against the regime's current text before acting.

For the classification itself, the check is to map facts to each term separately. First, confirm the trigger definition for the regime in question against its current text. Second, confirm the scope definition for that same regime against its current text, since a fact that falls outside one scope may fall inside another. Third, confirm the channel definition for that regime against its current text, since the path for sharing can be constrained by the channel even if a trigger and scope are met. None of these are interchangeable, and skipping any one of them breaks the mechanism.

Finally, the mechanism requires a live verification point at the moment of cross-functional data sharing. Before committing to route information, confirm that the classification used is the one tied to the specific regime being considered, and that the terms above were applied to that regime's current definition. This is a method check only: the validity of the path depends on applying separate definitions, not on collapsing them into one shared measure.
![How It Works — Data breach clocks](https://static.mm-ais.com/article-images-ai/data-breach-clocks-data-protection-law-g-ai-188c403f.jpg)

## Key Factors to Consider

When verifying before committing to cross-functional data sharing, the first decision criterion is applicability. The question is not which regime is more common, but which one matches the exact scope of the event you have just classified. A scope check must be done against the live, complete text for that event type, because a small shift in scope can change which path is binding without changing the same set of facts.

The second decision criterion is channel exclusivity. Before directing any data to a notice channel, confirm whether the same facts are meant to satisfy one path or both. This is not a matter of speed alone, but of whether sharing for one path can be used for the other or must be kept separate. Do not assume they are interchangeable, and do not merge them by default.

The third decision criterion is proof readiness. For the path you believe applies, have only the verifiable facts that justify it, and be able to point to where each fact comes from. If you cannot point to a specific item in the live text to justify the path, the readiness check fails regardless of how complete the rest of the file appears to be.

As for numbers that matter, the only safe approach is to treat any stated hour count as an unverified value until pulled from the live, complete instrument in force at commit time. The priority here is regulatory, not academic: measure what the live legal text in force actually says, not what a teammate remembers from a training slide. If the live text cannot be retrieved, treat the hour count as unverified and escalate.

 If the live text cannot be fully retrieved for the exact trigger, block cross-functional data sharing until it can be, with no substitution of a cached count.

Finally, if a numeric total is used to justify priority between paths, only use figures that appear in that retrieved live text for the exact scope you verified. Do not add unrelated counts, do not round from memory, and do not compare a confirmed number from one path to an unconfirmed number from the other. The decision is to match the binding number to the binding scope, not to pick the smaller number by assumption.

## Common Mistakes

This section alone covers the pitfalls with concrete examples. The first pitfall is conflating the audience with the gate. In practice, a containment group may draft one full incident write-up and push the entire document into a broad cross-functional channel the moment it begins coordination. For example, a technical team attempting to contain an access issue could post raw system context into a general channel meant for wider review, not realizing that the act of sharing is separate from the trigger itself. The check here is strict: intended recipients must be verified against specific data items, not against the fact that coordination has started.

The second pitfall is the "single packet" fallacy. Copying the same unaltered packet to every function assumes the required content is identical across regimes, when the necessary information for one channel is not automatically necessary for another. A concrete example of this is pulling diagnostic logs that are only relevant to a narrow technical review into a much broader share, expanding the pool of people with that content without confirming its justification. To avoid this, treat each intended recipient as its own scope, and withhold any item that cannot be tied to that specific recipient's verified purpose.

A third pitfall is mistaking silence for approval. The principle here comes from the reporting regimes themselves: neither GDPR nor DORA treats silence from other functions as satisfying a notice obligation, so approval must be actively confirmed against the verified recipient list before sharing.

 Just because no function has objected does not mean every item has clearance to be shared. Treating "no pushback" as consent is one of the quickest ways to expand cross-functional data sharing beyond what has been verified.

The final pitfall is post-hoc justification. If the reason for sharing is "we may need it later", that is not a verification at the moment of commitment. The only reliable method is to list recipients and items at the time of action, and to share only what passes that list. Without that live check, the default becomes maximum distribution, which is the exact outcome a verify-before-you-commit approach is meant to prevent.

## Insider Tactics

One non-obvious strategy I rely on is to treat the act of cross-functional data sharing as its own decision, separate from drafting any notice. Before any data set leaves its original channel, I run a "share gate" check: confirm the exact recipient role for that specific data, not the general function. The point is not to slow the response, but to avoid expanding the audience before the live option is known. By keeping the share action distinct, the choice of path can remain open without forcing a premature commitment.

A timing tip that has proven useful is to build a minimal fact packet for classification, but hold any broader logs in reserve. Instead of merging every available record at the first handoff, I only release what is needed for the immediate classification step. This keeps the option to see which regime applies without creating a single bundle that could lock the response into one path. The discipline is to release in layers, not all at once.

When pressure starts to build, the process check is straightforward: pause rather than file under the wrong clock. If I cannot state the exact share in one sentence at the moment of handoff, that is enough reason to verify the live channel before moving anything further.

 That check is not about the regulations themselves, but about the person making the call. If I cannot state the exact share in one sentence at the moment of handoff, that is enough reason to pause and verify the live channel before moving anything further.

Another check I use is to ask the receiving function what action they must take right now, not what they might need later. This forces a direct link between the data and the task. Both GDPR and DORA base their obligations on what the incident is, not on what a team might need later, so the operating principle is to limit cross-functional exposure to what is necessary for the immediate classification and reporting step.

 The goal is precision, not withholding for its own sake.

Finally, before committing to any cross-functional share, I verify the live recipient list at that moment, not from a saved list. If that list cannot be confirmed on the spot, I do not expand it. This is the only new discipline this section offers: treat the share itself as the action that must be verified, and use timing to protect the option to choose the correct path without over-sharing.

## Comparison

Compare the two clocks on one event record, not on policy summaries. Put the same trigger time, the same affected data set, the same recipient list, and the same evidence bundle beside each option; only then does a “winner” mean anything.

| Dimension | GDPR notice path | DORA report path | Winner rule |
| --- | --- | --- | --- |
| Applicability | Personal data breach notifiable to a supervisory authority | Major ICT incident reportable to a competent authority | Only compare options that are actually triggered |
| Clock start | Awareness of the breach | Awareness of the incident | Use one verified start time for both |
| First external checkpoint | 72 hours | Verify the live initial-report deadline | Earlier applicable and complete checkpoint |
| Evidence | Same incident facts and scope | Same incident facts and scope | Do not file either until the shared package is complete |

GDPR wins as the governing external notice when the event is a personal data breach and DORA is not triggered or not applicable to the entity or function involved. DORA wins the internal escalation timeline when it is applicable and its checkpoint is earlier; if both apply, run both clocks, but let the earlier checkpoint set the war-room cadence.

Do not compare a 72-hour headline with a shorter headline unless the denominators match: same start time, same scope, same affected data, and same evidence. A faster clock with a narrower scope is not a substitute for the broader notice.

Commit only to the option that is both applicable and complete. If the live text, scope, or evidence is incomplete, treat the comparison as unresolved and escalate to legal or compliance rather than filing under the more convenient clock.

## What to do next

| Step | Action | Why it matters |
| --- | --- | --- |
| 1 | Map your data flows: For each cross-functional data sharing path, classify it as either a GDPR personal-data breach or a DORA ICT incident. | Prevents assuming a single obligation covers both regimes. |
| 2 | Confirm the governing regime: For each classified flow, verify which law applies to it, not which team is handling it. | Cross-functional sharing does not merge the two clocks, so the regime must be determined separately. |
| 3 | Both clocks are triggered by different conditions, so the start time must be verified for each. |  |
| 4 | Compare like-for-like: On the comparison table above, isolate only the obligations that match the same incident type before committing to any action. | Prevents relying on partial or mismatched coverage between the two regimes. |
| 5 | Verify the live, complete option: For each regime, confirm the current, full reporting requirements from the official source for that law before committing. | Ensures you're acting on up-to-date obligations, not outdated assumptions. |
| 6 | Document the split: Record which flow falls under which clock, along with the verification used for each. | Creates a clear audit trail for two separate obligations that must never be conflated. |

## Frequently Asked Questions

**Which clock applies first when an event is under review?**

The applicable clock is determined by a trigger-to-classification path, not a single shared clock.

**What must happen before cross-functional data sharing is directed to a notice channel?**

An event must first be assessed for its scope of impact.

**Can the same facts be treated as equivalent under both regimes because they share a label?**

Equivalence cannot be assumed from a shared label because the same set of facts can be evaluated under different legal bases.

**What should be used to determine which regime's trigger applies to the facts?**

The determination should use live texts rather than a cached summary.

**What are the three key terms that must be separated in this mechanism?**

The key terms that must be separated are the trigger, the scope, and the channel.

**How is scope defined in this mechanism?**

Scope is the boundary of what must be considered for that trigger, which may differ by the type of entity or the type of impact being assessed.

## Quick answers

| Is there a single shared clock between the GDPR 72-hour breach notice and the DORA 24-hour ICT incident report? | No, the mechanism at play is a trigger-to-classification path, not a single shared clock. |
| --- | --- |
| What must be assessed before cross-functional data sharing is directed to a notice channel? | An event must first be assessed for its scope of impact. |
| Why can equivalence not be assumed between the two regimes? | Because the same set of facts can be evaluated under different legal bases, so equivalence cannot be assumed from a shared label. |
| Which three key terms must be separated for this mechanism? | The trigger, the scope, and the channel. |
| How should the applicable regime be determined? | By determining which regime's trigger applies to the facts as they are known at the moment of review, using live texts rather than a cached summary. |

Also worth reading: **DORA Register of Information: 3 Ways to Map 3rd-Party Lineage**: [DORA Register of Information: 3](https://opensilo.co/blog/dora-register-of-information-3-ways-to-map-3rd-party-lineage.php) · **GDPR Audit Prep: Centralized vs Federated May Cut Time 40%**: [GDPR Audit Prep: Centralized vs](https://opensilo.co/blog/gdpr-audit-prep-centralized-vs-federated-may-cut-time-40.php) · **Data Sharing Controls: Trace 1 Source or Verify Authority**: [Data Sharing Controls: Trace 1](https://opensilo.co/blog/data-sharing-controls-trace-1-source-or-verify-authority.php)

### Related reading

- [2026 edge hardware procurement: NXP Q3 beat vs Q4 miss, 19% YoY growth—buy now or wait?](https://opensilo.co/blog/2026-edge-hardware-procurement-nxp-q3-beat-vs-q4-miss-19-yoy-growthbuy-now-or-wait.php)
- [Data catalog audit-prep: open source vs proprietary for 1,000 tables in 2026](https://opensilo.co/blog/data-catalog-audit-prep-open-source-vs-proprietary-for-1000-tables-in-2026.php)
- [Strava API Restrictions: A Verify-Before-You-Commit Comparison Guide](https://opensilo.co/blog/strava-api-restrictions-a-verify-before-you-commit-comparison-guide.php)
- [Duplicate metric definitions: 90-day cross-team query reuse vs human curation](https://opensilo.co/blog/duplicate-metric-definitions-90-day-cross-team-query-reuse-vs-human-curation.php)
- [Databricks vs Snowflake audit evidence: 2026 SOX ITGC sampling thresholds](https://opensilo.co/blog/databricks-vs-snowflake-audit-evidence-2026-sox-itgc-sampling-thresholds.php)
- [Snowflake vs Databricks governance 2026: Unity Catalog 3-part namespace vs Horizon tag masking in audits](https://opensilo.co/blog/snowflake-vs-databricks-governance-2026-unity-catalog-3-part-namespace-vs-horizon-tag-masking-in-audits.php)

### Latest

- [2026 edge hardware procurement: NXP Q3 beat vs Q4 miss, 19% YoY growth—buy now...](https://opensilo.co/blog/2026-edge-hardware-procurement-nxp-q3-beat-vs-q4-miss-19-yoy-growthbuy-now-or-wait.php)
- [Data catalog audit-prep: open source vs proprietary for 1,000 tables in 2026](https://opensilo.co/blog/data-catalog-audit-prep-open-source-vs-proprietary-for-1000-tables-in-2026.php)
- [Strava API Restrictions: A Verify-Before-You-Commit Comparison Guide](https://opensilo.co/blog/strava-api-restrictions-a-verify-before-you-commit-comparison-guide.php)

Canonical: https://opensilo.co/blog/data-breach-clocks-data-protection-law-gdpr-72h-vs-resilience-law-dora-24h-which.php
Markdown: https://opensilo.co/blog/data-breach-clocks-data-protection-law-gdpr-72h-vs-resilience-law-dora-24h-which.php/index.md