Tag: UK GDPR breach reporting
The 72 Hour Rule for UK GDPR Breach Reporting
The 72 Hour Rule for UK GDPR Breach Reporting: A Plain English Guide for SMEs

When a personal‑data breach occurs, there are two key questions:
- When must we notify the regulator?
- How should we handle things internally to reduce risk, cost and reputational damage?
Lately, it feels like data breaches are never out of the headlines. From Marks & Spencer’s loyalty leak to Jaguar Land Rover’s ransomware hit, UK businesses are being tested on how fast and how well they respond.
For SMEs, understanding the 72‑hour rule under the UK GDPR isn’t just about avoiding fines it’s your fire drill, your buffer, your business continuity plan.
What is a “personal data breach”?
A personal data breach under the UK GDPR is any security incident that results in:
- Accidental or unlawful destruction or loss of personal data
- Loss of availability, for example through ransomware or system failures
- Alteration or corruption of data that makes records inaccurate
- Unauthorised disclosure of, or unauthorised access to, personal data
It doesn’t take a hacker, mis-sent emails, misplaced USB drives, or wrongly configured cloud folders all qualify.
The “72-hour rule” – what it really means
The law doesn’t give you three full days to get your act together. It says:
“Without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach.”
That means:
- If you can report sooner, you should.
- If you miss the deadline, you must justify why.
- And no – “we were still checking with IT” won’t cut it.
Step-by-step: what SMEs should do
✅ Recognise the incident
Use monitoring, logging, and staff escalation to detect breaches fast.
✅ Assess the risk
Ask: what is the risk to the individual, is there a risk of identify fraud, financial or physical harm or distress. We provide more guidance on this below.
✅ Decide whether to report to the ICO
Ask; what is the harm to the individual(s)? And decide if you need to report the breach. If you are not reporting, you must keep a log, with clear reasoning.
✅ Notify the regulator if likely to result in a risk of harm to individuals
Use the ICO breach reporting form and include:
- What happened
- What data and the number of people affected
- Consequences
- What you have done to reduce the risks
- DPO or contact point
✅ Notify individuals (if high risk)
If the breach presents a high risk to the people affected (e.g. financial, reputational or emotional harm), you must tell them directly – without undue delay. This could be where there is an immediate risk of financial or physical harm to an individual.
✅ Remediate and document
Do a root-cause review to be clear about why it happened and how you will prevent it happening again. Update controls. Train staff. Write it all down.
Is the breach reportable? How to decide
Not every breach needs to be reported to the ICO – but many are. And the line between “notify” and “log it internally” isn’t always obvious.
Under the UK GDPR, a breach must be reported to the regulator if it is:
“likely to result in a risk to the rights and freedoms of individuals.”
This includes risks like:
- Identity theft or fraud
- Financial loss
- Loss of confidentiality
- Discrimination or reputational harm
- Distress, particularly where vulnerable people are affected
But what does “likely” mean in practice?
That’s where judgment, experience, and knowledge of ICO enforcement comes in. You’ll need to assess:
- What kind of data was involved? (Basic contact details or sensitive health, financial, or identity data?)
- How exposed was it? (Sent to one person or published online?)
- How long was it accessible?
- Is there evidence it was accessed or misused?
- Could individuals suffer harm or distress as a result?
This isn’t a binary “yes/no” — it’s a context-led risk decision. And it’s one the ICO expects you to document thoroughly.
💡 If you decide not to report, you still need to record:
- The nature of the breach
- The decision-making process
- Why you believe notification wasn’t required
- Any steps taken to contain or prevent recurrence
📚 Many SMEs benefit from looking at recent ICO cases, guidance, and fines. These real-world examples show how risk is interpreted — and where organisations got it wrong by waiting too long, misjudging impact, or failing to document decisions.
🗂️ Bottom line: if you’re unsure, log your reasoning and seek advice. Whether you notify or not, the ICO cares most about whether you acted promptly, documented clearly, and protected individuals’ rights.
Common SME mistakes
- No breach detection tools in place
- Waiting too long to decide what to do
- Not documenting decisions
- Assuming “we’re too small to be a target”
- Launching new systems without updating privacy notices or contracts
Why SMEs should care
📣 From M&S to Jaguar Land Rover, breaches are everywhere.
But the risk isn’t just for corporates:
- SMEs are common stepping stones in larger supply chains
- Many attacks fly under the radar but cause huge disruption
- The ICO doesn’t care how small you are if you’re unprepared
💥 Capita was fined £14m for poor breach handling.
🧾 Don’t wait for yours to become a headline.
SME breach-response checklist
- Do you have a documented, tested response plan?
- Are your logs and alerts functioning?
- Have staff been trained on what to do?
- Do your contracts cover breach reporting?
- Do you review and record every incident, even the “minor” ones?
Related on Athlex: Prevent insider risk
Most breaches start from inside your business.
📘 Read: Insider Risk — 7 GDPR Controls for SMEs
Final word
The 72-hour rule is not just a regulatory tick-box it’s your first defence.
Plan it. Test it. Use it.
And when a breach happens, act fast and document everything.
Contact us if you need help: hello@athlex.co.uk
Our Free UK GDPR Compliance Checklist is coming soon.