You detect an intrusion. Files containing personal data have been accessed. You don't yet know how the attacker got in, how much data they touched, or whether anything was copied out.
That uncertainty doesn't pause the clock. Under UK GDPR, the 72-hour notification deadline starts the moment you become aware of the breach - not once you've confirmed it, not once you understand its scope, and not once you've fixed it.
If your crisis response plan assumes an investigation phase before the clock starts, it's built on a misreading of the rule, and that gap tends to surface at the worst possible moment.
What the 72 hours actually requires
The ICO's own guidance is more forgiving than most organisations assume — but only if you know how to use that flexibility.
Article 33(4) of the UK GDPR explicitly recognises that you won't always be able to fully investigate a breach within 72 hours. It allows you to notify in phases, as long as any further information is provided without undue delay. What it does not allow is silence. You still have to notify within 72 hours of becoming aware, even with an incomplete picture, and follow up as the investigation develops.
The ICO's own example makes the shape of this clear: you detect an intrusion, you know personal data was accessed, but you don't yet know the entry point, the extent of access, or whether data was exfiltrated. You notify within 72 hours, explain what you don't yet know, and tell the ICO when you expect to have more. Once the investigation produces answers, you send them on — without further delay.
That's a materially different task than "write and submit a complete breach report." It's "assemble and send a partial, honest, well-evidenced first submission, fast, while an investigation continues in parallel." Most crisis plans are built for the former. Almost none are built for the latter.
What has to be in that first submission
Even a phased or partial notification needs to address four things:
- The nature of the breach — including, where possible, the categories and approximate number of individuals affected, and the categories and approximate number of personal data records involved.
- A named contact point — your DPO's name and contact details, or another point of contact who can provide more information.
- The likely consequences of the breach.
- The measures taken or proposed — what you've done, or plan to do, to deal with the breach and mitigate its effects.
Notice what's on that list: contact details for a specific person, and a description of measures either taken or proposed. Both of those are things you can prepare before you're ever in this situation. Neither should depend on whoever happens to be reachable at 2am on the day it happens.
Where the clock actually gets eaten
In practice, organisations rarely blow the 72-hour window because the legal drafting is hard. They blow it - or scrape in late and under-prepared - because of coordination failures that have nothing to do with the law:
- Confirming the incident is real takes longer than it should, because the people who need to make that call can't get a clear, verified account from IT quickly.
- The response team can't reach each other. If the incident involves your primary network - email, Teams, VPN - and that's also where your breach-response team would normally coordinate, you're now trying to run a time-critical legal process over the same channel the attacker may be watching, or that may simply be down.
- Sign-off stalls. Legal, the DPO, and an executive typically all need to approve what gets submitted. If nobody knows who's reachable, or there's no pre-agreed channel to reach them on, that approval loop can eat most of your 72 hours before a word reaches the ICO.
None of these are legal problems. They're communication and coordination problems that happen to have a legal deadline attached.
What "good" looks like
A compressed but realistic timeline:
- T+0 - Breach detected and confirmed internally.
- T+2h - Core response group (IT, legal, DPO, relevant exec) convenes on a channel independent of the affected systems.
- T+12h - Preliminary facts established: what's known, what isn't, rough scope.
- T+48h - Draft notification circulated for legal and DPO sign-off, using the pre-approved template.
- T+68h - Submission sent to the ICO, with an explicit note on what remains unknown and when further detail will follow.
Every deadline in that timeline is hit before the investigation is finished. That's the point.
What to have ready before an incident, not during one
A pre-drafted notification template, with the four mandatory fields already structured and the DPO/contact-point details filled in and kept current.- A named, reachable escalation path — DPO, legal, and an accountable executive — that doesn't depend on the primary network being up.
- An independent channel for the response group to coordinate on, so a network compromise doesn't also take out your ability to organise the breach response itself.
- A rehearsed run-through. A tabletop exercise that specifically tests the notification timeline — not just "can we detect and contain," but "can we get a compliant first submission out inside 72 hours" — will surface gaps in the approval chain long before a real incident does.
The deadline doesn't move for you
"Undue delay" is judged against what you could reasonably have done - not against what your systems allowed you to do on the day. A crisis plan that only works when your normal tools are working isn't a crisis plan.
If the 72-hour clock is going to survive contact with an actual incident, it needs a communication path that survives it too.
A scope note: this article covers UK GDPR and ICO notification requirements specifically. Organisations that also process EU personal data should note that EU GDPR carries the same 72-hour standard, but notification goes to the relevant EU supervisory authority rather than the ICO.
