# Data breach notice timing: Article 33 72-hour regulator vs 24-hour internal escalation

Rachel Kim · October 17, 2026

> Article 33 gives 72 hours to notify regulators after awareness; set internal escalation within 24 hours of detection to leave 48 hours for response.

| Takeaway | Detail |
| --- | --- |
| Article 33 requires notifying the supervisory authority within 72 hours of becoming aware of a personal data breach. | The 72-hour regulator window starts at awareness. |
| Set the internal escalation deadline at or before 24 hours after detection. | The deadline is logged with a ticket timestamp. |
| Leave at least 48 hours of the Article 33 window after internal escalation. | The 72-hour window minus the 24-hour internal deadline leaves 48 hours. |
| Treat the internal escalation clock as an organizational design choice, not the legal deadline. | It only works if it ends early enough to leave triage and severity classification time. |

This guide compares the 72-hour Article 33 regulator notification window with a 24-hour internal escalation deadline.

It shows how to preserve at least 48 hours for triage and severity classification.

![Data breach notice timing](https://static.mm-ais.com/article-images-ai/data-breach-notice-timing-article-33-72-ai-a5fcff8b.jpg)

## Two Clocks: 72-Hour Legal, 24-Hour Internal

Conflating the two clocks creates the failure mode. A team may treat the internal 24-hour escalation as if it were the compliance endpoint, or assume that completing it pauses or satisfies the Article 33 clock. Completing it does not by itself satisfy the statutory notification duty. The legal clock keeps running while the report moves through internal queues, so an internal deadline treated as the finish line can quietly consume the time needed for triage, severity classification, and filing.

The stacking risk is concrete: if an internal route lets a report sit with a team lead for 24 hours and legal then requests 24 more hours for review, only 24 hours remain to draft and file. To check your own exposure, map each review level in your escalation path, assign it a maximum holding time, and confirm the sum of internal holding times plus drafting and filing still fits inside the 72-hour clock measured from the awareness timestamp.

The practical check is to keep the clocks separate in both language and measurement. State Article 33 as the outer legal boundary, and state the internal escalation deadline as an internal service level with a named owner. Measure the internal deadline from the same awareness event that starts the legal clock, and require every internal review request to be charged against the same 72-hour budget rather than treated as free time.

A useful rule is that the internal escalation clock must be short enough and early enough that legal review and filing still fit inside Article 33. If two internal blocks of 24 hours are allowed to stack, the filing block is reduced to the remainder. The internal clock should therefore be designed as a buffer-preserving control, not as a substitute for the statutory deadline.

![Two Clocks: 72-Hour Legal, 24-Hour Internal — Data breach notice timing](https://static.mm-ais.com/article-images-ai/data-breach-notice-timing-article-33-72-ai-afb9fb15.jpg)

## What Counts as Awareness and Who Logs It

Awareness under Article 33 is an evidentiary fact, not a legal conclusion. The clock starts when the controller has a durable, reviewable indication that a personal data breach may have occurred, not when counsel, the DPO, or senior management signs off. The first durable timestamp is the controlling event; later interpretation can refine severity, but it cannot move the start backward.

The worked trigger sequence is simple and unforgiving: a support agent takes the breach report at 09:14, and the ticket is opened at 09:22. The eight-minute gap is the argument.

 Awareness is evidenced by the ticket timestamp, not by when management learns of the incident, because the ticket is the first artifact that can be retrieved, audited, and defended. If the ticket is the first durable record, awareness plausibly began at 09:22.

| Event | Time | Durable artifact? |
| --- | --- | --- |
| Support agent receives report | 09:14 | No (oral or transient) |
| Ticket opened | 09:22 | Yes (system timestamp) |

To check your own system, take your last three security incidents and locate the earliest artifact for each: ticket, alert, customer email, chat transcript, or system log. That timestamp is when Article 33(1) awareness plausibly began. Compare it with the time escalation actually occurred. If the earliest artifact predates escalation by more than your internal escalation deadline, the process is already failing in practice, even if every later step is well documented.

If no artifact exists, the awareness time is unprovable and the incident record is incomplete. In that case, the first control to fix is intake capture, not legal drafting: require frontline staff to create or reference a ticket before any other action, and make the ticket timestamp system-generated and append-only.

Who logs it matters as much as when. The person or system that creates the first durable artifact owns the timestamp; classification, severity scoring, and legal review come afterward. Keep detection evidence separate from judgment by recording source, reporter, initial description, and system time in the first record, then attach triage notes as later entries rather than overwriting the original.

![What Counts as Awareness and Who Logs It — Data breach notice timing](https://static.mm-ais.com/article-images-pixabay/data-breach-notice-timing-article-33-72-9e4acd7e.jpg)

## Escalation Tiers Compared: Which Wins

Escalation is a routing decision, not a pressure tactic. Each level you reach adds approval authority but consumes 72-hour-window time you cannot recover, so in breach response the 24-hour internal escalation should be a hard gate, not a checkpoint that waits for a complete assessment.

A staged model can be mapped as Tier 1 detection and intake at 0–1 hour, Tier 2 breach-owner or DPO triage by 24 hours, and Tier 3 legal review and Article 33 filing decision by 48–60 hours. Each tier adds authority, but it also moves the decision point later, which is the cost the Redress Compliance pattern warns against.

| Model | Where the 24-hour decision sits | Effect on Article 33 buffer |
| --- | --- | --- |
| Single mandatory escalation to named breach owner | Escalation is logged by 24 hours; legal review starts in parallel at hour 24 | Preserves 48+ hours |
| Staged wait-for-assessment model | Tier 1 at 0–1 hour, Tier 2 by 24 hours, Tier 3 by 48–60 hours | Consumes buffer before filing decision |

The staged model's appeal is procedural neatness: intake, then triage, then legal. But neatness is not recoverable time. Once the 24-hour point passes without a named owner holding the file, the later tiers are working inside a shrinking window.

The winner is the single mandatory 24-hour escalation. It beats the staged model because it does not wait for full assessment before authority is engaged; legal review begins in parallel at hour 24, leaving the 48+ hour buffer intact for triage and severity classification. The escalation should be logged with a ticket timestamp to the named breach owner.

Use this as a design test: if the 24-hour step requires a completed severity assessment before escalation, the model is staged and should be rejected; if escalation is mandatory on detection evidence and legal review starts in parallel, the model is single-tier and satisfies the 24-hour internal deadline.

![Escalation Tiers Compared: Which Wins — Data breach notice timing](https://static.mm-ais.com/article-images-pixabay/data-breach-notice-timing-article-33-72-cbcd1526.jpg)

## Hours That Matter: Buffer Math

The 72-hour Article 33 window is a chain of handoffs, not a single block of time. The schedule below is a planning method, not a statutory timetable; it shows where the 24-hour internal escalation gate has to sit if the later stages are to keep their allotted hours.

Method table (not a sourced statute):

| Stage | Window after detection | Hours |
| --- | --- | --- |
| Detection and intake | 0–1 | 1 |
| Tier 2 classification | 1–24 | 23 |
| Legal assessment and Article 33 risk-of-harm evaluation | 24–48 | 24 |
| Drafting | 48–60 | 12 |
| Filing window (residual buffer) | 60–72 | 12 |
| Total | 0–72 | 72 |

The residual 12 hours are the whole design margin: if drafting finishes at hour 60, filing can occur at any point through hour 72, and every hour drafting slips past 60 consumes that margin one for one. Tier 2 classification by hour 24 is the last point at which the incident can still be treated as an internal matter; after that, legal assessment owns the calendar.

Legal assessment and the Article 33 risk-of-harm evaluation occupy a full day because the notification duty turns on whether the breach is likely to result in a risk to rights and freedoms; that judgment cannot be collapsed into drafting time. Drafting's 12 hours assume a known template and pre-approved wording; if the template is missing, drafting expands and consumes the filing window.

If internal escalation slips to hour 48, legal and drafting are compressed into 12–24 hours; the notice is then drafted under duress or filed after the 72-hour limit, which is an Article 33 failure in its own right.

Set the gate too early and the arithmetic still balances, but the downstream hours fill with unverified alerts; legal capacity is spent on incidents that never reach the Article 33 threshold, crowding out genuine breaches.

The 12-hour filing window is not spare time to decide whether to file; it is the interval for submission, acknowledgement, and correction of a defective notice.

The practical check is to timestamp the ticket at detection and measure escalation against that timestamp; the 24-hour gate is met only if at least 48 hours remain on the 72-hour clock.

![Hours That Matter: Buffer Math — Data breach notice timing](https://static.mm-ais.com/article-images-pixabay/data-breach-notice-timing-article-33-72-dd81a7f4.jpg)

## What the Evidence Does Not Establish

The only legal deadline in this guide is Article 33(1) of the GDPR: notification to the supervisory authority without undue delay and, where feasible, no later than 72 hours after the controller becomes aware of a personal data breach. Everything else here—the 24-hour internal escalation, the ticket timestamp, tier routing, and any residual buffer—is an organizational method chosen for control, not a legal requirement.

The 24-hour internal escalation deadline is this guide's recommended design constant. It is not in Article 33, it is not a GDPR requirement, and it is not a substitute for sector rules. Before applying it, verify any sector or contractual overlay that governs your organization and document which clock actually controls the incident.

Where awareness is disputed—especially when a processor delays telling you—do not treat the guide's general trigger description as dispositive. Check the processor contract's notification clause, the agreed incident-reporting channel, and the EDPB breach notification guidance for how processor-to-controller notice affects the controller's awareness date. Keep the contract clause and the guidance citation in the incident record.

This guide does not establish that a 24-hour internal escalation is legally sufficient, that a ticket timestamp alone proves awareness, or that any single tier model is mandated. It also does not establish your processor's actual notice time or that your own awareness date matches the processor's notice date; both must be evidenced from your logs, tickets, emails, and contractual notices before the 72-hour clock analysis is recorded.

Use this section as a boundary check: statute sets the outer notification duty; method sets internal control. If a regulator, auditor, or customer asks why a step was taken, cite Article 33(1) for the legal duty and your own procedure, contract, and logs for the method. Where the two conflict, the statute and the contract govern; the guide's recommendation yields.

For contested cases, the practical check is simple: write down the source of each date in the incident record—statutory deadline, contractual notice, internal ticket, and any sector overlay—so later reviewers can see which date is law, which is contract, and which is housekeeping.

![What the Evidence Does Not Establish — Data breach notice timing](https://static.mm-ais.com/article-images-pixabay/data-breach-notice-timing-article-33-72-6e0fbe8e.jpg)

## 09:14 Call to Filing

Checkpoint 1 begins at 09:22 on Day 0, when the support agent logs the unauthorized-access report in the ticket. That entry is the awareness artifact for the four-checkpoint timeline; every later deadline is measured from its timestamp, not from a later review or approval.

Checkpoint 2 requires the breach owner to classify severity in the triage log by 09:22 plus 24 hours. Checkpoint 3 requires legal to complete the notifiability assessment and document its reasoning by plus 48 hours. Checkpoint 4 requires the notice to be filed with the supervisory authority by plus 60 to 72 hours. Missing any checkpoint does not merely delay work; it converts the remaining Article 33 time into a shrinking or negative buffer.

Use one append-only escalation log row per suspected breach, created at detection and updated at each checkpoint. The template columns are: Detection timestamp; Ticket ID; Reporting channel; Suspected breach summary; Severity class; Breach owner; Notifiability assessment; Assessment completed at; Filing timestamp; Supervisory authority reference; Buffer status. The detection timestamp is the anchor field and is not edited after entry.

| Detection timestamp | Ticket ID | Reporting channel | Suspected breach summary | Severity class | Breach owner | Notifiability assessment | Assessment completed at | Filing timestamp | Supervisory authority reference | Buffer status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |  |  |  |  |

Set the internal escalation deadline at or before 24 hours after detection and record it with the ticket timestamp. That leaves at least 48 hours of the Article 33 window for triage, severity classification, notifiability assessment, and filing. If a checkpoint is missed, record the actual time and the resulting buffer impact in the same row rather than opening a separate tracker.

Each checkpoint should be evidenced by a timestamped artifact in the same row: the ticket entry, triage log entry, legal assessment note, and filing confirmation. A checkpoint is complete only when its artifact exists and is retrievable; verbal handoffs are not treated as checkpoint completion.

Keep the log in the system of record that already timestamps ticket events, and restrict edits to append-only fields after detection. If a checkpoint is missed, the row should show the actual completion time and the resulting buffer impact without rewriting the original detection timestamp.

## Worked Example: Run the Numbers

Illustration only: a controller detects a suspected personal data breach in a customer database at 09:00 on Day 0 and logs the escalation ticket to the breach owner/DPO at 08:00 on Day 1. The party is the controller, the scenario is unauthorized access to a customer database, and the dates are expressed as Day 0 through Day 3 for this illustration.

Step 1: the internal escalation deadline is detection plus 24 hours, or 09:00 on Day 1. The actual ticket at 08:00 on Day 1 is 23 hours after detection, so it is one hour inside that internal deadline. Step 2: the Article 33 deadline is the awareness anchor plus 72 hours, or 09:00 on Day 3. Step 3: the remaining window after escalation runs from 08:00 on Day 1 to 09:00 on Day 3.

| Illustration step | Timestamp | Hours from detection |
| --- | --- | --- |
| Detection / awareness anchor | Day 0, 09:00 | 0 |
| Internal escalation deadline | Day 1, 09:00 | 24 |
| Actual escalation ticket | Day 1, 08:00 | 23 |
| Article 33 deadline | Day 3, 09:00 | 72 |
| Remaining after escalation | Day 1, 08:00 to Day 3, 09:00 | 49 |

The 49-hour remainder is calculated from the actual ticket timestamp, not from the internal deadline: 24 hours from Day 1 08:00 to Day 2 08:00, 24 hours to Day 3 08:00, plus one hour to Day 3 09:00. If the ticket timestamp were missing, that 23-hour interval could not be demonstrated from the record.

For this illustration, the 23-hour escalation wins because it meets the at-or-before-24-hour rule and leaves 49 hours, above the 48-hour floor. The break-even trigger is a ticket logged at exactly 09:00 on Day 1, which is 24 hours after detection and leaves exactly 48 hours; any later timestamp would leave fewer than 48 hours.

This is an illustration of arithmetic and recordkeeping only. It is not a compliance determination for any specific breach, and it does not replace the separate analysis of when awareness actually began.

## Decision Rules for the 24-Hour Checkpoint

At the moment an incident report arrives, the checkpoint is a set of if/then rules rather than a debate: if a personal data breach is reported or detected, then open a timestamped artifact within one hour and escalate directly to the named breach owner by hour 24, with no team-lead holding layer in between; if hour 24 passes without Tier 2 classification, then treat the incident as notifiable by default and begin drafting the Article 33 notice; if a processor is involved, then check the processor notification clause and start the controller's 72-hour clock analysis.

The one-hour artifact is the control point because it fixes the first durable record and assigns an owner before the report can sit in a queue. Escalation by hour 24 is a routing rule, not a severity decision: the named breach owner receives the ticket even when the facts are still incomplete, because internal uncertainty does not pause the external Article 33 deadline.

The hour-24 default is a bias toward action. If Tier 2 classification has not been reached, the team drafts the supervisory-authority notice while continuing triage. The rule "late-and-wrong beats silent-and-late" means a notice that is later corrected is easier to explain than an unexplained delay, and the draft creates an audit trail of diligence while the facts are still being tested.

Processor involvement adds a contract check before the clock analysis. Read the notification clause, identify the promised notice period, and compare it with the controller's own detection time. The controller then records when its 72-hour analysis began and what evidence supports that start, without assuming the processor's notice date is the controller's awareness date.

| Trigger | Required action | Evidence to retain |
| --- | --- | --- |
| Breach reported or detected | Open timestamped artifact within 1 hour; escalate to named breach owner by hour 24; no team-lead holding layer | Ticket timestamp and escalation record |
| Hour 24 without Tier 2 classification | Treat as notifiable by default; begin drafting Article 33 notice | Classification log and draft notice timestamp |
| Processor involved | Check processor notification clause; start controller's 72-hour clock analysis | Clause reference and clock-start note |

Every branch should leave the same evidence: ticket timestamp, classifier, escalation recipient, and the reason the branch was taken. A reviewer should be able to reconstruct the decision from the ticket alone, including whether the one-hour artifact, hour-24 escalation, default notice, or processor clause check occurred.

## What to do next

| Step | Action | Why it matters |
| --- | --- | --- |
| 1 | Log the detection time and start the 72-hour Article 33 awareness window for notifying the supervisory authority. | The 72-hour regulator window starts at awareness. |
| 2 | Escalate the breach internally at or before the 24-hour internal deadline after detection. | This leaves at least 48 hours of the Article 33 window after internal escalation. |
| 3 | Log the internal escalation deadline with a ticket timestamp. | The timestamp documents the organizational design choice and preserves triage time. |
| 4 | Use the remaining at least 48 hours for triage, severity classification, and legal review before the regulator notice is due. | The internal clock only works if it ends early enough to leave that time. |
| 5 | Submit the Article 33 notice to the supervisory authority within 72 hours of becoming aware. | Article 33 requires notifying the supervisory authority within 72 hours of becoming aware of a personal data breach. |
| 6 | Treat the internal escalation clock as an organizational design choice, not the legal deadline. | The legal deadline remains the 72-hour Article 33 regulator window. |

## Frequently Asked Questions

**When does the regulator notification clock begin?**

The Article 33 regulator window starts at awareness of a personal data breach.

**How should the internal escalation deadline be evidenced?**

The deadline is logged with a ticket timestamp.

**Does completing the internal escalation discharge the notification obligation?**

No, completing it does not by itself satisfy the statutory notification duty under Article 33.

**Is the internal escalation deadline the legal deadline?**

The internal escalation clock is an organizational design choice, not the legal deadline.

**What is the stacking risk when internal queues delay the report?**

Treating internal escalation as the finish line can quietly consume the time needed for triage, severity classification, and filing while the legal clock keeps running.

**Under what condition does the internal escalation design work?**

It only works if it ends early enough to leave triage and severity classification time within the Article 33 window.

## Quick answers

| What does Article 33 require for a personal data breach? | Article 33 requires notifying the supervisory authority within the 72-hour regulator window after becoming aware of a personal data breach. |
| --- | --- |
| When should the internal escalation deadline be set? | The internal escalation deadline should be set at or before the 24-hour internal deadline after detection. |
| How much of the Article 33 window should remain after internal escalation? | Leave at least the 48-hour window after internal escalation. |
| Does completing internal escalation satisfy the statutory notification duty? | Completing internal escalation does not by itself satisfy the statutory notification duty. |
| Why can an internal deadline treated as the finish line be risky? | An internal deadline treated as the finish line can quietly consume the time needed for triage, severity classification, and filing. |

Also worth reading: **Support Ticket Costs: $15.95 Close vs $44.70 Compliance Escalation**: [Support Ticket Costs: $15.95 Close](https://issues.house/blog/support-ticket-costs-1595-close-vs-4470-compliance-escalation.php) · **CFPB Complaint Database 2026: 30-Day Public Disclosure Lag Changes Escalation Timing**: [CFPB Complaint Database 2026: 30-Day](https://issues.house/blog/cfpb-complaint-database-2026-30-day-public-disclosure-lag-changes-escalation-timing.php) · **Issue-Ops Mapping: Semantic Layer vs Middleware for SOX & GDPR**: [Issue-Ops Mapping: Semantic Layer vs](https://issues.house/blog/issue-ops-mapping-semantic-layer-vs-middleware-for-sox-gdpr.php)

### Related reading

- [CFPB Complaint Database 2026: 30-Day Public Disclosure Lag Changes Escalation Timing](https://issues.house/blog/cfpb-complaint-database-2026-30-day-public-disclosure-lag-changes-escalation-timing.php)
- [How to Exit an Issue Fast: 24-Hour Escalation Threshold Ends Delays](https://issues.house/blog/how-to-exit-an-issue-fast-24-hour-escalation-threshold-ends-delays.php)
- [Customer Support Escalation: 12-Hour Service Level Agreement Auto vs Manager Sign-Off](https://issues.house/blog/customer-support-escalation-12-hour-service-level-agreement-auto-vs-manager-sign-off.php)
- [Repeat Audit Findings: 4-Hour Compliance Escalation vs Public Affairs](https://issues.house/blog/repeat-audit-findings-4-hour-compliance-escalation-vs-public-affairs.php)
- [FTC Safeguards Rule Breach Notice: 30-Day Clock Starts at Triage, Not Legal Review](https://issues.house/blog/ftc-safeguards-rule-breach-notice-30-day-clock-starts-at-triage-not-legal-review.php)
- [Support Ticket Costs: $15.95 Close vs $44.70 Compliance Escalation](https://issues.house/blog/support-ticket-costs-1595-close-vs-4470-compliance-escalation.php)

### Latest

- [FTC Safeguards Rule Breach Notice: 30-Day Clock Starts at Triage, Not Legal...](https://issues.house/blog/ftc-safeguards-rule-breach-notice-30-day-clock-starts-at-triage-not-legal-review.php)
- [How to Exit an Issue Fast: 24-Hour Escalation Threshold Ends Delays](https://issues.house/blog/how-to-exit-an-issue-fast-24-hour-escalation-threshold-ends-delays.php)
- [CFPB Complaint Database 2026: 30-Day Public Disclosure Lag Changes Escalation...](https://issues.house/blog/cfpb-complaint-database-2026-30-day-public-disclosure-lag-changes-escalation-timing.php)

Canonical: https://issues.house/blog/data-breach-notice-timing-article-33-72-hour-regulator-vs-24-hour-internal-escalation.php
Markdown: https://issues.house/blog/data-breach-notice-timing-article-33-72-hour-regulator-vs-24-hour-internal-escalation.php/index.md