GDPR Article 33: the 72-hour clock and when it starts

A clock with a soft start

GDPR Article 33 is one of the most cited deadlines in regulation, and most people remember it as a single number. Seventy-two hours to tell the supervisory authority about a personal-data breach. The number is real. It is also the least interesting part of the rule, because the genuinely hard question is not how long the clock runs. It is when it starts.

The Article does not start the clock when the breach happens. It starts it when the controller becomes aware of the breach. "Without undue delay and, where feasible, not later than 72 hours after having become aware of it." Awareness, not occurrence. A breach can sit undetected for weeks, and the seventy-two hours do not begin until the organization has a reasonable degree of certainty that a breach has occurred. That single word, awareness, is where compliance is won or lost, because it is the field everything else counts from.

What the rule actually checks

Once you see that, the rule writes itself, and it writes itself as the deadline primitive: a starting event, a count of hours, a check that a second event landed in time.

{
  "rule_id": "DP-BREACH-EU-001",
  "title": "Personal-data breach not notified within 72 hours of awareness",
  "jurisdiction": "eu",
  "source": "GDPR Article 33(1)",
  "severity": "block",
  "expected_outcome": {
    "action": "review",
    "message": "Awareness of a notifiable breach was recorded more than 72 hours before the supervisory authority was notified. Article 33 requires notification without undue delay and, where feasible, within 72 hours. Document the reasons for delay or notify immediately."
  },
  "conditions": [
    { "type": "deadline_window", "from": "breach.aware_at", "to": "breach.authority_notified_at", "max_hours": 72 }
  ],
  "deterministic": true,
  "validation_status": "expert_reviewed"
}

The check reads two timestamps and a limit. It does not interpret. The interpretation, the genuinely human judgment about when awareness was established, happens upstream, when the aware_at field is set, and that act is recorded with its own reasoning. The rule does not pretend to decide when awareness began. It decides, given an awareness time, whether the notification met the window. That separation is deliberate. The soft, judgment-laden part is captured as a recorded fact. The hard-edged part, the deadline, is computed.

Why determinism matters here specifically

Article 33 also carries a clause that punishes vagueness: where notification is not made within 72 hours, it must be accompanied by the reasons for the delay. A regulator is therefore not just asking whether you notified. They are asking whether you notified in time, and if not, whether you can account for it, against the awareness moment you yourself recorded. This is exactly the situation a probabilistic answer cannot survive. "The system was fairly confident the notification was timely" is not a sentence you say to a data-protection authority. Timely or not is a matter of two timestamps and a limit, and the answer has to be exact, and it has to be the same answer every time the case is examined.

And when the awareness timestamp is missing or unreadable, the rule does not assume the deadline was met. It says it could not verify, and the case goes to a person. An unverifiable breach clock is not a clock you can clear, because in this domain a false "notified in time" is a finding waiting to be made by someone else.

The point

Article 33 looks like a number and is actually a definition. The seventy-two hours are trivial to check. The whole obligation hinges on the moment of awareness, which is a judgment that must be made by a human and then recorded as a fact the deadline can count from. Encode it that way, with the judgment captured and the arithmetic deterministic, and the 72-hour clock stops being a source of anxiety and becomes a line the system can prove you stayed inside, or tell you, loudly, that you did not.