72 hours to notify. Six months to detect.

GDPR gives you 72 hours from awareness to notification, and organisations meet it. The number that decides the damage is the other one: breaches routinely run for months before anyone becomes aware. The regulation clock is not the risk clock.

3 min read

Two clocks govern every personal data breach, and privacy programmes have overwhelmingly invested in the wrong one.

The first clock is the famous one, Article 33's 72 hours from awareness to regulator notification. It is drilled, templated and tabletop-exercised, and mature programmes usually meet it. The second clock is the one the regulation does not name: the time between a breach beginning and anyone becoming aware of it. IBM's 2025 Cost of a Data Breach research puts the mean breach lifecycle at 241 days to identify and contain, and the identification share of that lifecycle still runs to roughly six months. The notification clock is measured in hours and managed to the minute. The detection clock is measured in months and, in most organisations, managed by nobody in particular.

The asymmetry, in current numbers

The pressure on both clocks is rising. DLA Piper's January 2026 GDPR survey counted personal data breach notifications across Europe at an average of 443 per day, a 22% jump year on year and the first time the daily average has exceeded 400 since GDPR began. Cumulative fines have passed €7.1 billion, with over 60% of that total imposed since January 2023; enforcement is accelerating, not plateauing.

The honest complication belongs on the table: detection is improving. IBM's 241-day lifecycle is the lowest in nine years, and the report credits AI-powered defence for much of the gain. That trend strengthens the argument rather than weakening it, on two counts. The improvement is concentrated in security tooling, which watches for intrusion; the privacy-specific signals described below are not what got faster. And a clock that has improved to six months is still running some sixty times slower than the 72-hour clock everyone drills. For every breach entering the well-rehearsed notification process, months of undetected exposure preceded it. The data left during the quiet period. The notification period is where the harm gets documented.

Why detection stayed unmanaged

Detection fell into the gap between functions. Security teams run monitoring, but tuned to intrusion and malware, not to the privacy-specific questions: personal data moving to an unusual destination, an access pattern inconsistent with a stated purpose, a processor behaving outside its mandate. Privacy teams own the obligation but historically not the instrumentation; their tooling generation was built for records of processing, consent and assessments. Registers, again, rather than sensors.

The detection problem is, structurally, an anomaly detection and exception routing problem over data flows:

  • Baseline the normal. Which systems access which personal data categories, at what volumes, on which purposes, is learnable from the data the organisation already holds.
  • Detect the deviation early. The export that is ten times the usual volume, the dormant account suddenly reading customer records, the processor query outside its contract scope: each is visible weeks or months before an incident report would name it.
  • Route the exception to an owner. A privacy anomaly that lands in a shared inbox is a future disclosure. One that arrives with context, severity and a named owner is a contained incident, and the containment evidence is exactly what a regulator asks for when the 72-hour letter is eventually written.

Every week cut from detection is a week of exposure that never happens, and it compounds: earlier detection means smaller scope, fewer subjects, lower notification burden, and a defensibly shorter breach narrative.

The privacy function's second AI problem

One more clock has started recently. Privacy teams are increasingly asked to govern the organisation's use of AI on personal data, and simultaneously to adopt AI in their own compliance work. The same discipline applies in both directions: an AI that touches personal data needs monitored, evidenced behaviour, and a privacy function that uses AI to classify, detect or assess needs to be able to show a regulator how the conclusion was reached. A function that builds the detection instrumentation above acquires, almost for free, the evidence habits the AI era will demand of it.

Continuous anomaly detection over personal data flows, with exceptions routed to named owners and the evidence chain kept, is what the Prophesee Compliance Suite's Privacy module provides. Measure your own detection clock. Start here.

New essays land on LinkedIn first. Follow 3RDi to catch them, or get a demo to see Prophesee on your own data.