← Insights

Data protection

The 72-hour breach clock, and how not to miss it

July 2026 · 6 min read

A laptop left on a train. An email with the client list attached, sent to the wrong address. A spreadsheet of staff details downloaded by someone who should not have had access. Personal-data breaches are rarely dramatic hacks; most are ordinary mistakes. What makes them stressful is not the incident itself but the deadline that comes with it - because under the UK GDPR, a reportable breach must reach the Information Commissioner's Office within 72 hours of you becoming aware of it.

Seventy-two hours sounds generous until you are inside one. The clock runs continuously, weekends included, and it starts at the moment of awareness, not the moment you finish investigating. The single worst thing you can do is spend the first two days deciding whether it counts.

Not every breach is reportable

The reporting duty is not automatic, and getting the assessment right is the heart of good breach handling. You must notify the ICO only where the breach is likely to result in a risk to people's rights and freedoms. A breach unlikely to cause any real risk - a single internal email recalled within seconds, say - is one you record but need not report. A breach likely to cause a high risk goes further: you must tell the affected individuals as well.

So there are really three outcomes, and knowing which one you are in is the job:

• Log only. Below the risk threshold - you must still keep an internal record, but no notification is required.
• Report to the ICO. Likely to risk people's rights - notify within the 72 hours.
• Report and tell the individuals. Likely high risk to the people affected - notify the ICO and inform them without undue delay.

The important discipline is to make that judgement quickly and record the reasoning either way. Even where you decide not to report, you have to be able to show why - the duty to document every breach, reportable or not, is itself part of the law.

What to do in the first hours

When a breach is detected, the order of operations matters more than speed:

• Contain it first. Stop the bleeding - recall the email, revoke the access, lock the account. Limiting the damage comes before paperwork.
• Record the moment of detection. This is the field the whole clock hangs off. Note the date and time you became aware, because that is when the 72 hours began.
• Capture the facts. What happened, what data was involved, whose data it was, how many people, and what harm could follow.
• Assess the risk. Run the three-way judgement above - log only, report, or report and inform.
• Act on the decision. If it is reportable, notify the ICO before the window closes. If it is high risk, tell the individuals too.

You do not need every fact before you report. The ICO expects that you may not have the full picture inside 72 hours; you can notify with what you have and follow up. Silence past the deadline is the failure, not an incomplete first report.

Why the record has to be defensible

Breach handling is judged after the fact, often long after, and often by someone who was not there. What protects you is a contemporaneous record: what you knew, when you knew it, what you decided, and why. A register that captures each breach - the reference, the time detected, the type, the cause, the data and people involved, the risk and the decision - is the difference between "we handled it properly" as a claim and as a demonstrable fact.

The part worth taking out of human hands is the deadline. In the middle of an incident, counting to a 72-hour mark is exactly the calculation nobody should be relying on their head for. Far better that the record sets the report-by deadline from the moment of detection, counts the hours down, and turns a reportable breach red the instant its window closes without a report logged. That way the register does not just store the history - it actively warns you while there is still time to act.

Two things then work together. A printable single-incident form gives you the clean write-up for one breach; a running register gives you the pattern across all of them, which is its own quiet value - three "wrong recipient" emails in a quarter is a training problem the register will surface long before anyone else spots it.

Breaches will happen; the well-run organisation is not the one that never has one, but the one that contains it, assesses it honestly, decides inside the clock, and can prove all three afterwards.