Quick answer: Contain the breach first. Assess the risk second. If it's likely to put people's rights or freedoms at risk, you have 72 hours to notify the ICO from the moment you became aware of it. If the risk is high, tell the affected individuals too, without delay. And write down every decision as you go. The ICO wants to see your reasoning, not just your outcome.
A personal data breach is any security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. That's a wider net than most people expect.
It's not just hackers breaking into a database. It's an email sent to the wrong person. A lost laptop. A misconfigured cloud storage bucket. An employee looking at records they had no reason to open.
Scale doesn't decide whether something is a breach. One email with one person's details, sent to the wrong address, is still a breach under UK GDPR. What scale changes is the risk, and how much you're obliged to do about it.
Confidentiality breaches get most of the attention, but availability and integrity breaches count too. Losing the only copy of a customer database in a ransomware attack, or accidentally overwriting records so they're no longer accurate, both qualify. If you're only watching for "was data stolen," you're missing a chunk of what UK GDPR actually covers.
The first hour matters more than almost anything else in a data breach response. Your job is to stop the damage, not fill in a form. Revoke access. Isolate the affected systems. Pull back or delete data that was sent somewhere it shouldn't have gone. Change any credentials that might be compromised.
Once that's under control, move to assessment. What data was involved? How many people are affected? Was any of it sensitive? How did it happen? This is usually where whoever holds the DPO role steps in to coordinate IT, legal, and leadership, rather than leaving it to whoever happened to spot it first.
Speed matters because the 72-hour notification clock, where it applies, starts the moment you become aware of the breach, not the moment your investigation wraps up. Waiting for the full picture before you start that clock is one of the most common, and most costly, mistakes businesses make.
Not every breach needs reporting. UK GDPR only requires you to notify the ICO where the breach is likely to put people's rights and freedoms at risk. No likely risk, no obligation to notify the regulator, though you should still log the breach internally and be ready to explain why you didn't report it.
Working out risk comes down to a handful of proportionate, consistent questions: how sensitive is the data, how identifiable is it to a specific person, how many people are affected, has it already been misused (or is it likely to be), and what have you already done to limit the damage. A spreadsheet of names and email addresses is a different risk to a spreadsheet of health records or bank details, and your response should reflect that.
The bar for telling individuals directly is higher again. You only need to do that if the breach is likely to cause a high risk to their rights and freedoms, think identity theft, financial loss, or discrimination.
Where notification is required, UK GDPR sets a hard 72-hour deadline from the point you became aware of the breach, under Article 33 of the UK GDPR. It's one of the few genuinely fixed deadlines in data protection law, and an ongoing investigation doesn't buy you more time.
If you don't have every detail within 72 hours, you're allowed to notify in phases. Tell the ICO what you know now, and flag that more will follow as the investigation continues. A partial notification sent on time beats a complete one sent late, every time.
Your notification needs to cover what happened, roughly how many people and records are affected, the likely consequences, and what you've done (or plan to do) to fix it and limit harm. Reading the ICO's guidance on breach reporting before you ever need it is a much better use of your time than reading it for the first time mid-incident.
If the breach is likely to cause a high risk to the people involved, you have to tell them without undue delay, in language they'll actually understand. This is not the moment for legal hedging. They need to know what happened, what of theirs was involved, and what to do about it, whether that's changing a password or watching their bank statement.
There are narrow exceptions, for example if the data was properly encrypted and unreadable to anyone unauthorised, or if contacting people individually would take disproportionate effort and a public notice would do the same job. These exceptions get stretched further than the law actually allows more often than you'd think, and that becomes its own problem if it's ever challenged.
Every breach, reportable or not, should be logged. What happened, when you found out, the risk assessment you ran, who made the call, and what you did about it. If you decide not to notify the ICO, write down why. That's exactly what a regulator will ask to see if the breach ever resurfaces, whether through a complaint, a subject access request, or an audit years later.
This is where having an actual system, rather than a trail of emails and Slack messages, earns its keep. A proper incident log turns a stressful scramble into something repeatable, and gives you a straight answer when a customer, investor, or regulator asks how you actually handle incidents.
Once the incident is contained and reported, the job isn't done. A proper root cause analysis asks why it happened, not just what happened. Was it a technical failure, a gap in a process, a training gap, or a supplier problem? Fix the symptom without fixing the cause, and you'll be writing this same report again in a few months.
This is also the point to check whether your controls, policies, and supplier arrangements need updating. If a supplier was involved, revisit the due diligence you did on them and whether their contract actually holds up. If the cause sat inside your own business, the training gaps usually become pretty obvious pretty fast.
Set a realistic timeline for this work and stick to it. It's tempting to close the file the moment the ICO notification is sent, but the root cause review is what stops the same breach happening again with a different name on it. A month later, with the pressure off, is exactly when this work tends to slip.
A few patterns show up again and again in breaches that go badly.
No. You only need to notify the ICO if the breach is likely to put people's rights and freedoms at risk. No likely risk, no requirement to report, but log it internally and record your reasoning anyway.
The ICO can still take enforcement action if you notify late without good reason, and it's a factor in how the ICO decides to respond to any breach. If you genuinely can't make the deadline, notify with a clear explanation and send the rest of the detail as soon as you have it, rather than waiting until everything is confirmed.
In practice, that's usually your DPO or whoever holds that responsibility, working with IT and legal. It should never be one person's judgement call, made under pressure, with no process behind it. A defined risk assessment process, agreed before an incident happens, makes this decision far more consistent.
No. Most reported breaches don't result in a fine. The ICO's guidance is clear that a fine is one tool among several, and how promptly and transparently you responded matters alongside how severe the breach was. Businesses that notify on time, cooperate fully, and can show reasonable steps taken beforehand are treated very differently to those that can't.
A plan worth having names who coordinates the response, sets out the containment and risk assessment steps, includes a ready-to-use ICO notification template, and defines how and when you'll tell individuals if needed. Have this ready in advance, and 72 hours feels controlled instead of chaotic.
There's no single fixed retention period set out in UK GDPR, so keep breach records for as long as you might reasonably need to demonstrate compliance, which in practice often means several years. Investors, insurers, and regulators can all ask about historic incidents, so a breach log you can search and point to years later is worth far more than a folder of scattered emails.
A data breach doesn't test your intentions, it tests whether your processes actually hold up. The businesses that handle this well are almost always the ones that know who should take ownership of the response process, already had a way to assess risk quickly, and already had somewhere to log decisions as they made them. None of that needs to be complicated. It just needs to exist before you need it.
Trust Keith's incident management support is built for exactly that gap: somewhere to log an incident the moment it happens, a proportionate way to work through the risk assessment, and a dedicated privacy expert who can help you make the notification call with confidence instead of guesswork.
Worth reading next: how to prepare for an ICO investigation, what the hidden costs of getting data protection wrong actually look like, and what a DPO actually does day to day, incident response included. If you're weighing up whether you need dedicated support for this, these pieces on DPO support with 24/7 availability and ongoing compliance support without a full-time DPO are good places to start.
If any of this still feels uncertain, or you'd just like to talk it through with someone who's handled it before, you're welcome to book some time with our team.