Personal Data Breach: What a Small Business Must Do
A personal data breach has just happened. Here is the calm, step-by-step plan to follow before you ever need it.
The short version
- Contain first: stop the leak, recover what you can, and limit the damage before anything else, then write down what happened while it's fresh.
- The 72-hour rule: if a breach is likely to risk people's rights, you must report it to the ICO without undue delay and, where feasible, within 72 hours of becoming aware.
- Not every breach is reportable: you only need to tell the ICO if there's a likely risk to people, but you must record every breach internally, reportable or not.
- Tell the people affected when the breach is likely to be a high risk to them, so they can protect themselves (for example, watch for fraud).
It’s the phone call no small-business owner wants. A laptop’s gone missing. An email with a customer list went to the wrong address. A spreadsheet of staff details turned up somewhere it shouldn’t. Your stomach drops, and the first instinct is to panic.
Don’t. A personal data breach is stressful, but it is manageable, and the law gives you a clear sequence to follow. The businesses that handle a breach well aren’t the ones that never have one. They’re the ones who decided in advance what to do. This is that plan.
What counts as a personal data breach
A personal data breach is a security incident that affects the confidentiality, integrity or availability of personal data, and it covers far more than hacking.
The ICO’s definition is “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.” Read that slowly and you’ll see how wide it is. It isn’t only about a criminal stealing data. It includes data being lost, changed, made unavailable, or seen by the wrong person, whether by accident or on purpose.
Everyday examples that all count:
- A work phone or laptop lost or stolen, with personal data on it.
- An email or letter sent to the wrong recipient.
- Records deleted by mistake with no backup.
- A spreadsheet of customers shared more widely than intended.
- Ransomware that locks you out of your own files.
That last one matters: losing access to personal data is a breach too, even if nobody else ever sees it. If you weren’t sure your missing-laptop moment “counted,” now you know. It almost certainly does.
The first hour: contain and recover
Before you think about reporting, stop the bleeding: limit the damage and recover what you can.
Containment comes first because it changes everything that follows. The faster you act, the smaller the harm and the easier the rest of your decisions become.
Work through the practical steps. Can you recall that misdirected email or ask the recipient to delete it without reading? Can you remotely wipe the lost device, or change the passwords it could reach? Can you restore deleted files from a backup? If a system’s been accessed, lock it down and reset the credentials that were exposed. Whatever the incident, the question is the same: what can I do right now to make this smaller?
Start a breach log straight away
Don't wait until you know whether it's serious. Open a simple document the moment you become aware and note what happened, when, what data and people are involved, and what you're doing about it. You may decide later it didn't need reporting, but the ICO expects you to record every breach internally, reportable or not. A running log is also your best friend if you do have to report.
Assess the risk to people
The single question that decides what you must do next is: how likely is this to harm the people whose data was involved?
Once it’s contained, you assess the likely risk to people’s rights and freedoms. That’s the legal test, and it’s about the affected individuals, not about embarrassment to your business.
Think about what could actually happen to them. Could someone be defrauded or have their identity stolen? Could they suffer financial loss, distress, or damage to their reputation? A leaked list of email addresses is one thing. A leaked list of bank details, health information, or home addresses for vulnerable people is far more serious. The type of data, the number of people, and how easily someone could misuse it all push the risk up or down.
Not every breach has to be reported. You only need to notify the ICO if the breach is likely to result in a risk to people’s rights and freedoms. If you can genuinely show it’s unlikely to, you don’t report it, but you still write it down.
This is the step where a calm, honest judgement matters most. Don’t talk yourself out of reporting because it’s inconvenient, and don’t fire off a report for every trivial slip. Record your reasoning either way.
When you must report to the ICO
If the breach is likely to risk people’s rights, you must tell the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it.
The 72-hour clock starts when you become aware of the breach, not when it first happened. That’s an important distinction. It’s a generous deadline if you act promptly, and a tight one if you sit on the news.
A few things ease the pressure. You don’t need every fact before you report. If you can’t pin down the full picture in time, the ICO would rather you reported what you know inside the deadline, explained why information is missing, and followed up in phases as you learn more. Reporting late means giving reasons for the delay, so it’s far better to send a partial report on time.
You report through the ICO’s website, and they have a self-assessment tool that walks you through whether your breach is notifiable. If you’re a small organisation and unsure, the ICO also runs a personal data breach advice line you can call.
When you must tell the people affected
When a breach is likely to be a high risk to the people involved, you must tell them directly, in plain language, without undue delay.
There are two different thresholds here, and it’s worth keeping them straight. Reporting to the ICO is triggered by a likely risk. Telling the individuals is triggered by a high risk, a more serious bar.
If there’s a real chance someone could have their identity stolen, be defrauded, or otherwise come to genuine harm, they deserve to know so they can protect themselves. A good notification is honest and useful: tell them what happened, what data was involved, what you’re doing about it, and the practical steps they can take, such as changing a password, watching their bank statements, or staying alert to scam calls that reference the leaked details.
It feels exposing to send that message. But people generally respond far better to a business that owns a problem early and helps them than to one that hopes they never find out.
Writing your plan before you need it
The best time to decide how you’ll handle a breach is on a quiet afternoon, long before one happens.
A breach plan doesn’t have to be a thick document. One page that answers a handful of questions is enough for most small businesses: who is in charge when something goes wrong, who can wipe a device or reset a password, where the breach log lives, who decides whether to report, and how you’d reach the ICO. Pin it somewhere your team can find it under pressure.
Getting these basics in place is part of wider good data-protection housekeeping. If you’d like a broader grounding, our guide to GDPR for small businesses covers the foundations, and the GDPR policy starter pack walks through the documents most small businesses actually need. It’s also worth knowing how a breach connects to other data rights, for instance how you’d respond if an affected person then asked to see their data via a subject access request.
SecurSentry is building tools to make this kind of ongoing data-protection work feel less daunting for small businesses. For now, the most useful thing you can do is the simplest: write your one-page breach plan this week, while everything is calm. The hour you spend now is the hour you’ll be grateful for when the phone rings.