Which Data Breaches Must You Report To The ICO? GDPR Notification Duties In The UK

If you run a small business, a data breach can feel like one of those “surely this won’t happen to us” problems - until it does.

Maybe an employee emails a spreadsheet to the wrong person, a laptop goes missing, your customer database is accessed without permission, or an online form starts collecting more personal data than you intended. The big question quickly becomes: what data breaches do you need to report to the ICO?

Under UK GDPR and the Data Protection Act 2018, you don’t have to report every incident. But when you do need to report, timing and content matter - and getting it wrong can create avoidable legal, operational and reputational risk.

This guide breaks down what you need to know in plain English, from a small business perspective, including when you must notify the ICO, when you should tell affected people, and how to build a practical process that your team can actually follow.

What Counts As A “Personal Data Breach” Under UK GDPR?

Before we tackle which data breaches you need to report to the ICO, we need to be clear on what a “personal data breach” is.

A personal data breach is a security incident that leads to the accidental or unlawful:

• destruction of personal data
• loss of personal data
• alteration of personal data
• unauthorised disclosure of personal data
• unauthorised access to personal data

It’s not limited to “hackers” and cyber-attacks. Many breaches in SMEs are caused by human error, weak access controls, or process gaps. Also, while “breach” often makes people think of data being leaked, UK GDPR also covers incidents affecting availability (for example, personal data being wiped or made inaccessible).

Examples Of Breaches That Often Happen In Small Businesses

• Email errors: sending invoices, HR documents or customer lists to the wrong recipient.
• Lost devices: a laptop, phone or USB containing customer or employee information goes missing.
• Access issues: ex-staff still have access to shared drives, CRM tools, or email accounts.
• Misconfigured systems: cloud storage set to “public” by mistake.
• Phishing: an employee is tricked into disclosing login details.
• Paper records: printed staff files left in an unlocked area or thrown away without shredding.

A useful way to think about it is: if the incident involves personal data (information relating to an identified or identifiable person) and there’s been a security failure affecting confidentiality, integrity and/or availability, you should treat it as a potential personal data breach and assess it properly.

So, Which Data Breaches Must You Report To The ICO?

This is the key test: you must report a personal data breach to the ICO unless it is unlikely to result in a risk to the rights and freedoms of natural persons.

In other words, the default position isn’t “report everything”. It’s “report breaches where, based on what you know, there is a real-world possibility of harm to people”.

So, if you’re asking which data breaches must be reported to the ICO, the practical answer is: breaches that are not ‘unlikely’ to create a risk to individuals’ rights and freedoms.

What Does “Risk To Rights And Freedoms” Mean In Practice?

This doesn’t just mean “financial loss”. The ICO’s risk concept is broader and can include:

• identity theft or fraud
• financial loss (eg bank details exposed)
• damage to reputation
• loss of confidentiality (especially for sensitive matters)
• discrimination
• physical harm or intimidation (rare, but possible)
• significant distress, embarrassment or anxiety

For small businesses, the practical way to apply this is to assess both the likelihood and the severity of potential impact, including:

• What data was involved? Is it just names and business emails, or is it addresses, payroll, bank details, medical info?
• How many people are affected? One customer vs your entire mailing list matters.
• Who got access (or could access it)? A trusted supplier who immediately deletes the file is very different from an unknown third party.
• Was the data protected? Encryption, strong access controls, and secure credential storage can reduce risk.
• What could realistically happen next? Could the data be used to scam, impersonate, expose confidential issues, or cause distress?
• Was availability affected? If personal data is lost, wiped, or inaccessible (eg ransomware), that can still create risk depending on what the data is used for.

Breaches That Are Commonly Reportable

While every case is fact-specific, these are the kinds of incidents that often cross the “risk” threshold and may need reporting to the ICO:

• customer payment details exposed or accessed
• employee payroll data leaked (NI numbers, bank details, salaries)
• passwords disclosed (especially if stored insecurely)
• medical or health information exposed
• large volumes of personal data accessed in a cyber incident
• data sent to the wrong person where there’s a real chance of misuse (and you can’t quickly contain it)
• personal data wiped, encrypted or otherwise made unavailable in a way that could realistically harm individuals (depending on the context)

Breaches That Are Often Not Reportable (But Still Need Managing)

Some incidents may be “unlikely to result in risk” - for example:

• an email sent to the wrong recipient containing minimal data (eg name only), where the recipient confirms deletion
• loss of a fully encrypted device with strong access controls
• brief service disruption where personal data remains protected and individuals are unlikely to be affected in practice (depending on context)

Even if you don’t report, you should still document what happened and why you decided not to notify the ICO (more on that below).

When Do You Need To Tell The Individuals Affected?

ICO reporting and notifying individuals are two separate duties.

If a personal data breach is likely to result in a high risk to individuals’ rights and freedoms, you must also communicate the breach to the affected people without undue delay.

This is a higher threshold than ICO reporting:

• ICO notification: risk
• Individual notification: high risk

What Makes A Breach “High Risk”?

Think of “high risk” as meaning serious potential impact. For example:

• risk of financial fraud (bank details, payment info, identity documents)
• exposure of special category data (health information, biometric data, etc.)
• information that could put someone at personal risk (domestic violence refuges, protected addresses)
• credentials that could allow account takeover (passwords, MFA backup codes)

If you’re notifying individuals, your message should be genuinely helpful and practical - not defensive. Usually this includes what happened, what data was involved, what you’re doing about it, and what they can do (eg password reset, be alert to scams).

When You Don’t Have To Notify Individuals

There are limited situations where a breach might be “high risk” in theory but you may not need to notify individuals - for example if you’ve applied appropriate technical protections (like strong encryption) that make the data unintelligible to unauthorised parties.

This is one reason it’s worth having strong security controls baked into your day-to-day operations, not bolted on after an incident.

What Is The 72-Hour Rule And When Does The Clock Start?

If you do need to report to the ICO, you must do so without undue delay and, where feasible, within 72 hours of becoming aware of the breach.

This part often trips up small businesses, because you might not feel “aware” until you have all the facts. But the legal test isn’t “when you finished investigating” - it’s when you have a reasonable degree of certainty that a breach has occurred (even if key details are still being confirmed).

Practical Example: When Are You “Aware”?

• If your IT provider confirms unauthorised access to an email account on Monday, you’re likely “aware” on Monday.
• If you suspect something on Monday but have no confirmation until Wednesday, awareness might be Wednesday (depending on the facts).

If you can’t submit all details within 72 hours, you can still notify the ICO with what you know and then provide more information later. The key is not to wait too long while you aim for a “perfect” report.

What Information Should An ICO Notification Include?

You’ll generally want to cover:

• What happened (a clear description of the incident)
• When it happened (and when you became aware)
• What data was involved (types of data, approximate volume)
• How many individuals might be affected
• Likely consequences (your risk assessment)
• Mitigation steps you’ve taken (containment, resets, recovery)
• Contact point for follow-up

Having a prepared internal process makes this far easier. Many businesses use a formal Data Breach Response Plan so decisions aren’t being made from scratch in a high-stress moment.

How To Decide If You Must Report: A Simple Risk Checklist For SMEs

If you’re trying to work out which data breaches must be reported to the ICO, it helps to run a quick, structured assessment.

Here’s a practical checklist you can use (and document):

Step 1: Confirm Whether Personal Data Is Involved

• Does it relate to an identifiable individual (customer, employee, supplier contact, patient, member)?
• Is it more than purely anonymous data?

Step 2: Identify The Type Of Data

• Basic identifiers (name, email address, phone number)
• Financial information (bank details, card details)
• Identity data (passport, driving licence, right to work docs)
• Employment data (salary, performance notes, HR records)
• Special category data (health, biometrics, ethnicity, etc.)

Step 3: Consider Who Accessed It (Or Could Access It)

• Trusted internal recipient who immediately reported it
• Known third party (supplier) with an obligation to delete/return it
• Unknown third party or malicious actor

Step 4: Look At Security Measures

• Was it encrypted?
• Was it password protected?
• Was access limited by permissions?
• Is there an audit trail showing what was actually accessed?

Step 5: Decide Whether Risk Is “Unlikely”

If risk to individuals is unlikely, you may not need to report to the ICO.

If there is a likely risk, you should report.

If there is a likely high risk, you should report and notify affected individuals.

Even if you decide not to notify the ICO, you should still keep a breach log. This is part of being able to demonstrate compliance if the ICO ever asks.

How To Reduce Your Breach Risk (And Put Yourself In A Better Position If One Happens)

You can’t guarantee your business will never have an incident. But you can put reasonable protections in place so that:

• breaches are less likely to happen, and
• if they do happen, they’re less likely to be reportable (because the risk is lower).

1) Get Your GDPR Foundations Right

Strong privacy compliance tends to reduce breach impact. For many SMEs, that means having the right documents and processes in place early, such as a clear Privacy Policy that reflects what you actually do with personal data.

If you’re building or scaling, a structured GDPR package can help pull the key legal pieces together (instead of trying to patchwork it later).

2) Make Sure Your Supplier Contracts Cover Data Incidents

If you use payroll providers, CRMs, cloud hosting, marketing tools, booking platforms, or outsourced IT, you may be sharing personal data with third parties.

In many cases, you’ll want a Data Processing Agreement (or appropriate data processing terms) so responsibilities are clear - including how quickly they must tell you if they suffer a breach affecting your customers or staff.

3) Reduce Human Error With Simple Policies

For small businesses, accidental disclosure is a major cause of breaches. You can reduce this with practical, readable internal rules like an Acceptable Use Policy covering basics such as:

• password practices
• using personal devices for work (BYOD)
• when files can be emailed externally
• how data should be stored and shared
• what to do if something goes wrong (reporting internally straight away)

If your team uses AI tools for drafting emails, processing CVs, summarising customer interactions or analysing documents, you should also think about how data is handled and whether staff may paste personal data into third-party platforms. A Generative AI Use Policy can help set boundaries that reduce your breach exposure.

4) Train Your Team On “Breach Spotting”

Your reporting timeline depends on when you become “aware”, so you want staff to escalate quickly. A short quarterly reminder can go a long way:

• Report suspected phishing immediately
• Report mis-sent emails immediately
• Don’t try to “fix it quietly” first
• Preserve evidence (screenshots, logs, email headers)

5) Have A Plan Before You Need It

When an incident happens, you’re juggling customer communications, operational disruption, IT fixes and internal stress - which is not the ideal time to design a process.

A documented response plan (with roles, checklists, notification templates and escalation contacts) helps you move faster and make more consistent decisions.

Key Takeaways

• A “personal data breach” under UK GDPR includes accidental loss, alteration, disclosure or unauthorised access to personal data - and can also include loss of availability (like deletion or ransomware), not just cyber-attacks.
• If you’re asking which data breaches must be reported to the ICO, the key legal test is whether the breach is unlikely to result in a risk to people’s rights and freedoms (if it’s not “unlikely”, you should usually notify).
• You must generally notify the ICO within 72 hours of becoming aware of a reportable breach, even if you need to provide further details later.
• If the breach is likely to result in a high risk to individuals, you may also need to notify the affected people without undue delay.
• You should document all breaches (even ones you don’t report) including what happened, your risk assessment, and your reasons for the decision.
• Having the right GDPR foundations, supplier agreements, internal policies and a breach response plan can reduce both the chance of a breach and the likelihood it becomes reportable.

If you’d like help tightening up your data breach process or your wider GDPR compliance, you can reach us at 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.