Do I Need to Notify the ICO of a Data Breach? A Plain-English Guide for UK Founders

A personal data breach isn't just a hack. Sending payroll figures to the wrong inbox, losing an unencrypted laptop, or a software bug that lets one customer see another customer's order history can all count. If it happens in your business, UK data protection law gives you a short window to work out whether you need to tell the Information Commissioner's Office (ICO), and sometimes the people affected too.

Here's how to work through that decision, what a report needs to cover, and what to keep on file even when you decide not to report.

What this covers

• What counts as a personal data breach, and when you have to tell the ICO
• The 72-hour notification clock, what a report needs to include, and when you also have to tell affected individuals directly
• What to keep on file, what a supplier breach means for you, and what getting it wrong can cost

What counts as a personal data breach

A personal data breach is a security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. It falls into three broad types, and one incident can involve more than one:

• Confidentiality: personal data is disclosed to, or accessed by, someone who isn't authorised to see it. Example: a customer complaint email sent to the wrong recipient.
• Integrity: personal data is changed incorrectly or without authority. Example: an attacker alters customer bank details or delivery addresses.
• Availability: personal data is destroyed, lost, or made inaccessible when it's needed. Example: ransomware locks the only copy of your employee records.

It doesn't have to be malicious. Employee mistakes, a misconfigured system, or an accidental publication can all qualify. A security incident that doesn't involve personal data isn't a personal data breach for these purposes, though it's still worth logging as a near miss, and it may trigger other reporting duties of its own.

Do you have to tell the ICO?

Not every breach needs reporting. The test is whether the breach is unlikely to result in a risk to the rights and freedoms of the people affected. If, after a prompt and documented assessment, you can't reasonably conclude that's the case, you should notify. If you decide not to notify, you need a clear, contemporaneous record of why you concluded the risk was unlikely.

"Rights and freedoms" covers more than money. Relevant harms include identity theft or fraud, financial loss, discrimination, distress or humiliation, reputational damage, loss of control over personal data, safeguarding or safety risks, and loss of access to an essential service.

Working out where a breach sits usually comes down to a handful of factors:

• The nature and sensitivity of the data. Financial, health, or authentication details carry more risk than a name and business email, and breaches involving health data or other special category information are generally treated as higher risk from the outset.
• How many people are affected, and how identifiable they are.
• What's likely to happen as a result, and how likely that is.
• Whether the data was encrypted or otherwise protected, or already public.
• How vulnerable the people affected are.
• The nature of your own business and how it handles data.
• What containment steps you've already taken, such as remote wipes, revoked links, or reset credentials.

Containment can lower the risk going forward, but it doesn't erase what already happened. If someone had unauthorised access before you locked things down, your assessment needs to account for that access, not just the state of things afterwards. It's worth recording your containment steps either way.

The 72-hour clock

If notification is required, it has to happen without undue delay and, where feasible, within 72 hours of becoming aware of the breach. Regulatory guidance treats you as "aware" once you have a reasonable degree of certainty that personal data has been compromised, not just a vague suspicion. A credible tip-off still starts a duty to investigate promptly, and poor internal escalation won't protect you if it causes an avoidable delay in recognising and responding to what's in front of you.

There's no general extension for weekends, staff being away, or an investigation that isn't finished. If you're going to be late, the answer is to notify as soon as you can and explain the delay, not to wait until you have every detail. If some information genuinely isn't available yet, you can report in phases: an initial notification with what you know, followed by updates without further undue delay.

Practically, that means recording when the first alert came in, when it was escalated, and when you reached the point of reasonable certainty, so you can show your timeline if asked.

What a report should cover

At minimum, a notification to the ICO needs to include:

• A description of the breach, including the categories and approximate number of people affected, and the categories and approximate number of records involved.
• A contact point who can give further information.
• The likely consequences for the people affected.
• What you've done, or plan to do, to contain the breach and mitigate the effects.
• If you're notifying later than 72 hours, your reasons for the delay.

It's also worth including when and how the breach was discovered, even though that's practical context rather than a strict requirement. You're allowed to distinguish facts from estimates. Don't hold off on an initial report just because you don't have a final headcount or a completed forensic review.

When you also have to tell the people affected

Telling the ICO is a lower bar than telling the individuals whose data was involved. Direct notification is only required where the breach is likely to result in a high risk, meaning the potential harm is more serious, more likely, or both, than the general risk threshold that triggers ICO notification. That higher bar means any breach serious enough to need direct notification will also need to be reported to the ICO, though the reverse isn't true. You can end up notifying the ICO without notifying anyone else.

Signs that point toward high risk include exposed passwords or authentication tokens that could enable account takeover, payment details combined with identifying information, sensitive health or safeguarding information, or unencrypted data taken by a hostile actor, though none of these automatically decides the outcome on their own.

If direct notification is required, it must be in clear, plain language, and cover the nature of the breach, a contact point for more information, the likely consequences, and the measures you've taken or plan to take to address it and limit the damage, not just practical tips for the people affected. There are three situations where you can skip direct notification. You'd already applied protection, such as encryption, that made the data unintelligible to the wrong person. You've since taken action that means the high risk no longer applies. Or contacting each person individually would take disproportionate effort, in which case you make an equally effective public announcement instead. Even where you conclude direct notification isn't needed, the regulator can disagree with your assessment and require you to notify people directly anyway, so this is a decision worth documenting carefully.

Keep a record, even if you don't report

Every personal data breach needs to be documented internally, whether or not you notify the ICO. Your record should cover the facts, the effects, and what you did about it, in enough detail that a regulator could check your reasoning later, and the ICO can ask to inspect these records at any time. That typically means: dates and discovery details, who was affected, your assessment of risk, your decision and the reasons for it, containment steps, and any lessons learned.

There's no fixed retention period set out in law, so adopt a proportionate written policy rather than a rule of thumb, and don't treat this as licence to keep the file forever. Keep it access-restricted, since it will usually describe your security weaknesses in some detail.

It's also worth keeping a broader log of security incidents and near misses that don't rise to the level of a personal data breach. It won't satisfy the documentation duty on its own, but if it captures the same facts, effects, and remedial action for an actual breach, it can help show a pattern of vigilance if a regulator ever asks.

If a supplier loses your customers' data

Most startups run on a stack of SaaS tools, and a breach at one of your suppliers doesn't let you off the hook. If your CRM, payroll, or analytics provider suffers a breach involving your customers' data, the supplier, where it's acting as your processor for that data, has to tell you without undue delay. Unlike you, the supplier doesn't need to weigh up the risk before notifying you. It just needs to establish that a breach happened and let you know promptly. You, as the controller, still have to make your own risk assessment and decide whether to notify the ICO.

A few points worth knowing before this happens to you:

• Your 72-hour clock generally starts running once the supplier notifies you, so treat that notice as the trigger rather than waiting for its own investigation to finish.
• A supplier telling you about the breach under your contract doesn't itself satisfy your regulator obligations.
• The same supplier can be a processor for one dataset and an independent controller for another, such as its own fraud prevention, so check what role it played for the data involved, not just what the contract calls it.

It's worth agreeing upfront, in your supplier contracts, exactly how and how quickly a processor must tell you about a breach, rather than leaving it as a vague obligation to notify.

Getting it wrong is expensive

The ICO can investigate, issue a reprimand, an enforcement notice, or a penalty notice, and affected individuals can claim compensation if the breach amounts to an infringement that causes them material or non-material damage, including distress, though a breach alone doesn't automatically entitle anyone to a payout, and a business can defend a claim by showing it wasn't in any way responsible for what happened. In practice, awards for distress have tended to be modest, and there's ongoing debate about whether very minor, quickly-fixed incidents clear the bar for a claim at all.

Penalties are tiered by what's been breached, not just by the fact that a breach occurred. A failure to notify the ICO or affected individuals generally sits in the lower of the two tiers. A failure to have had appropriate security in place to begin with, the underlying obligation that a breach often reveals was missing, sits in the higher tier. Since most incidents involve both a security gap and a notification decision, it's the higher figure that's often the more realistic exposure, not just the one attached to reporting itself. The regulator also takes into account factors like how the breach happened, whether you cooperated, and how quickly you contained it.

For a small business, acting fast, reporting honestly even in phases, and showing a credible remediation plan tend to be the sort of things the regulator weighs when deciding what action to take, even though they don't excuse the underlying failure.

A quick way to check where you stand

Before you decide, run through this in order:

• Has personal data, including login or authentication details, been destroyed, lost, altered, disclosed, or accessed without authority?
• Is it unlikely that this could result in any risk to the rights and freedoms of the people affected? If you can't reasonably reach that conclusion, you'll generally need to notify the regulator, within 72 hours of being reasonably certain a breach occurred.
• Is the breach likely to result in a high risk to those people, rather than just a risk? If so, you'll generally need to tell them directly too, unless an exception applies.
• Whatever you decide, write down what happened, what you considered, and why.

If you're not sure which box you're in, that uncertainty is itself a reason to get advice quickly rather than wait out the clock.

Key takeaways

• A personal data breach covers far more than a hack. Misdirected emails, lost devices and software bugs can all qualify if personal data is involved.
• You only have to notify the ICO if the breach is not unlikely to result in a risk to people's rights and freedoms, and you have 72 hours from becoming aware to do it, in phases if needed.
• Direct notification to affected individuals is a higher bar than notifying the ICO, and the regulator can override your decision not to notify people directly.
• Every breach must be documented internally, whether or not it's reported, and the ICO can ask to inspect those records.
• A supplier's breach doesn't excuse you from your own obligations, and the underlying security failure behind a breach can carry a higher penalty tier than the notification decision itself.

Plumlaw is a UK legal consultancy for founders and growing businesses, offering the kind of practical, general counsel thinking startups need without the cost of hiring one in house. If you're working through a data incident, or want your breach response plan sorted before you need it, get in touch.