A personal data breach starts a clock the moment you discover it — not the moment you're ready to deal with it. This guide walks through the exact steps for gdpr data breach notification under UK GDPR, from the 72-hour ICO deadline to notifying the people affected.
Why this matters
Most breaches aren't hacks. They're a misdirected email, a lost laptop, or a spreadsheet shared with the wrong client.
Under UK GDPR, a "personal data breach" covers any security incident that leads to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. That's a wide net, and in 2026 the ICO expects organisations to know within hours whether they're inside it.
Get the notification wrong — too slow, too vague, or skipped entirely — and the penalty sits separately from any fine for the breach itself. The ICO can act on the failure to report alone.
What you'll need
- A named person or small team who owns breach response (even at a 10-person company, someone has to be it)
- Your record of processing activities — you need to know what data you hold before you can say what was exposed
- A breach log template: date discovered, data affected, number of people, cause, containment steps, decision on notification
- Contact details for your ICO registration (your registration number speeds up the report)
- Legal or DPO sign-off on the risk assessment, even informal, before you notify or decide not to
The steps
1. Contain it first, document second
Stop the bleeding before you write anything down. Revoke access, isolate the affected system, or recall the email — whatever containment looks like for this incident.
Record the exact time you contained it. The ICO's 72-hour clock starts at discovery, not containment, but containment timing shows you acted fast, which matters for the narrative you'll give later.
Common mistake: teams spend hours debating whether it's "serious enough" to count as a breach instead of containing it immediately. Contain first, classify second.
2. Establish exactly what happened
Work out what data was involved, how many people are affected, and whether the cause was accidental (misdirected email) or malicious (unauthorised access). Vague answers here slow down every later step.
Check logs, ask the person who spotted it what they saw, and pull the relevant record from your data inventory. If you don't have a working record of processing activities, this step takes days instead of hours — build one before you need it, not during an incident.
Expected outcome: a one-paragraph factual summary you could read to a regulator without editing.
3. Assess the risk to individuals
This is the step that decides everything downstream. Ask: does this breach create a risk to the rights and freedoms of the people whose data was exposed?
Consider the type of data (financial and health data raise the risk sharply), the number of people affected, and whether the data is encrypted or otherwise unusable to whoever accessed it. A lost laptop with full-disk encryption and no other access is a different risk profile than an unencrypted spreadsheet emailed to a stranger.
Common mistake: treating every breach as automatically notifiable. Low-risk incidents — for example, encrypted data with no evidence of access — often don't require ICO notification at all, but you still need to document why.
4. Report to the ICO within 72 hours if it's notifiable
If the breach is likely to result in a risk to individuals, you must notify the ICO within 72 hours of becoming aware of it. Use the ICO's online reporting service and be ready to provide:
- Nature of the breach and categories of data involved
- Approximate number of individuals and records affected
- Likely consequences
- Measures taken or proposed to address the breach
You don't need every fact locked down before you report. UK GDPR allows phased reporting — submit what you know at 72 hours, then follow up with detail as your investigation continues.
Expected outcome: a submitted ICO report with a reference number, even if some fields say "investigation ongoing."
5. Notify affected individuals if the risk is high
If the breach is likely to result in a high risk to people's rights and freedoms, you must also tell them directly, without undue delay. This is a higher bar than the ICO notification threshold — not every breach reported to the ICO needs individual notification.
Write the notification in plain language: what happened, what data was involved, what you've done about it, and what they should do (change a password, watch for phishing attempts, freeze a card). Skip the legal hedging — people need to know what to actually do.
Common mistake: burying the risk in corporate language so nobody acts on the warning. If someone's card details are exposed, say that in the first sentence.
6. Log the decision, not just the breach
Every decision — to notify, not to notify, to notify individuals or not — needs a documented reason. The ICO can ask you to justify a decision not to report months after the fact.
Your breach log should show discovery time, containment time, risk assessment, decision, and who signed off. This is the record that protects you if the ICO ever investigates.
Expected outcome: a breach log entry that stands on its own without anyone needing to explain it verbally.
7. Run the post-incident review
Once contained and reported, go back through what happened and what would have caught it sooner. Was it a training gap, a process gap, or a technical control that didn't fire?
A structured tabletop exercise for incident response run every 6-12 months catches the gaps a live breach exposes the hard way. Fix the actual cause, not just the symptom you saw this time.
Common mistake: closing the incident without updating the process that let it happen. The same breach tends to repeat within a year if the root cause never gets fixed.
Get breach response built into your compliance
OneClickComply automates evidence collection so incident logs are ready before the ICO asks.
Troubleshooting
We're past 72 hours and haven't reported yet. Report now with a note explaining the delay — a late report with a clear reason is treated far better than no report at all.
We're not sure if it's "notifiable." Default to documenting the risk assessment even if you decide not to report. An unwritten decision looks like no decision at all if questioned later.
The breach came from a supplier, not us. You're still the data controller in most cases, and the notification duty sits with you, not the processor. Chase your supplier's incident report but don't wait on it to start your own clock.
We don't know how many people are affected yet. Report an estimate at 72 hours and update the ICO with the confirmed number once you have it — phased reporting is allowed.
Legal wants to review before we notify individuals. Fine, but set a hard internal deadline. "Without undue delay" doesn't leave room for a week of sign-off cycles.
Tools and resources
- A current record of processing activities so you know what data exists before an incident forces you to find out
- A completed GDPR data protection impact assessment for any high-risk processing, so risk thresholds are already defined
- GDPR compliance software for UK small businesses if breach logging and evidence collection still lives in spreadsheets
- The ICO's online breach reporting portal, bookmarked before you need it — not searched for during an incident
- A breach log template shared across your team, not owned by one person who might be on leave when it happens
What to do next
Most businesses only think about breach response once they're mid-incident, which is the worst time to build a process. Set the log template, name an owner, and run a tabletop exercise before 2026 ends — not after your first real breach forces the issue.
Frequently asked questions
One last thing
The organisations that handle breaches well aren't the ones with the biggest security budgets — they're the ones with a breach log template already sitting in a shared folder before anything happens. Build that in an afternoon in 2026, and the next incident becomes a process instead of a panic.