Data breach notification: what has to happen in the first 72 hours
Something goes wrong with personal data and the clock starts immediately, whether anyone in the building has noticed yet or not. UK GDPR gives you 72 hours from the moment you become aware to tell the ICO, if the breach is serious enough to need telling, and the three days move at the same pace whether you spend them investigating or panicking.
Most businesses never test what that actually means until it's already happening. This is the plain version: what counts, what the clock really measures, and what you still have to do even when you decide not to report.
What actually counts as a breach
The word "breach" makes people think of hackers, but the ICO's definition is broader and duller than that. It's any breach of security that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. A laptop left on a train counts. An email sent to the wrong recipient with a spreadsheet of customer details attached counts. A filing cabinet that goes to the wrong skip counts. A cloud account with weak or reused credentials that gets logged into by someone who shouldn't have access counts too, even when nothing was technically "hacked" in the way people picture it.
Most of the personal data breaches a small business will actually have are the boring kind. Someone hits send too fast, someone loses a phone, someone's account gets guessed rather than breached in a dramatic sense. The law doesn't care that it wasn't sophisticated. It cares what happened to the data.
The clock starts before you're ready
Here's the part that trips people up: the 72 hours runs from when you become aware of the breach, not from when you've finished working out what actually happened. The ICO is explicit that you don't get to wait for a complete investigation before the clock starts. If someone tells you on Monday morning that a spreadsheet went to the wrong address, Monday morning is when the timer starts, even if you spend the next two days figuring out exactly what was in it and who it affects.
That feels unreasonable until you notice the law already accounts for it. Article 33(4) allows phased reporting: you can give the ICO what you know now, and add the rest afterwards without undue further delay, rather than needing one finished report inside three days. The mistake most businesses make isn't reporting too little on day one. It's trying to hold off entirely until the picture is complete, which usually means missing the deadline for no good reason.
What the ICO actually wants from you
Not every breach needs reporting. The threshold is whether it's likely to result in a risk to people's rights and freedoms, and working that out is a judgement call, not a formality to wave through. The ICO's self-assessment tool at ico.org.uk walks through the questions that judgement rests on, and the personal data breach advice line on 0303 123 1113 is there for the genuinely unclear cases. If you do need to report, it goes to the ICO directly, with as much detail as you have at the time: roughly what happened, roughly how many people are affected, roughly what categories of data, and what you're doing about it.
Deciding a breach doesn't meet the threshold is a completely valid outcome. What isn't valid is deciding that without being able to show your working afterwards, which is the next section.
When you have to tell people, not just the regulator
There's a second, separate duty that catches people out because it looks like the same thing and isn't. Article 34 requires telling the affected individuals directly, but only when the risk to them is high, a deliberately higher bar than the one that triggers ICO notification. A breach can clear the ICO threshold without clearing this one. Financial details, health information or login credentials that could be reused elsewhere tend to push a breach over that line; an internal document that reached the wrong colleague inside the same organisation usually doesn't.
When it does apply, a general note on your website isn't enough unless contacting people directly would take disproportionate effort. It has to be a direct message, in plain language, describing what happened, the likely consequences, and what you're doing about it. Burying it in a policy update people won't read doesn't meet that standard, and the ICO has been clear about that specifically.
"We decided not to report" isn't the end of it
Whichever way you land on reporting, the ICO's own advice to small organisations is direct: keep a log anyway. Record what happened, who's involved, and what you're doing about it, and write down the decision itself along with your reasoning, whether that decision was to report or not. That log is exactly what you'd need to produce if the ICO ever asked, months later, why a particular breach never reached them. Turning up with nothing written down doesn't prove you made a considered decision. It looks like you didn't make one at all, whether or not that's fair.
The numbers suggest most businesses skip this step. The government's 2025/2026 Cyber Security Breaches Survey found only 40% of businesses reported their most disruptive breach to anyone outside their own organisation, and formal incident response plans, the kind that would normally include a breach log as standard practice, existed at just 25% of businesses surveyed overall. Given that the same survey put the breach rate at 46% for small businesses and 43% across UK businesses generally, scaling to roughly 612,000 organisations a year, a lot of breaches are apparently happening with no paper trail behind the decision either way.
Getting ready before you need to be
None of this works if you can't answer the basic questions fast: what data was actually affected, when did it happen, who had access, and can you prove it from logs rather than best guesses. That's an unglamorous, mostly technical foundation, and it's the same foundation that shows up in insurance underwriting and Cyber Essentials assessments for a reason: EDR that tells you what actually happened on a device, backups that are tested rather than just taken, and access logs that go back further than a week.
Getting the legal call right, whether a specific breach clears the reporting threshold, is a job for a solicitor or a data protection officer, and Alpha IT doesn't do that job or claim to. What we do is make sure the technical evidence exists when that call needs to be made under time pressure. If you're not sure that evidence trail is there today, a free IT health check is the honest way to find out before a Monday morning email forces the question.
Frequently asked questions
What actually counts as a personal data breach?+
More than a hack. The ICO's own definition covers any breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. That includes a laptop left on a train, an email sent to the wrong address with a client list attached, a filing cabinet that goes to the wrong skip, or a supplier account that gets compromised and used to read your customer records. None of those need a hacker. Most of the reportable breaches a small business will actually have are the ordinary kind: someone made a mistake, not someone broke in.
Do we have to report every breach to the ICO?+
No. You only have to report it if it's likely to result in a risk to people's rights and freedoms, and that's a judgement call you have to make and be able to defend, not skip. The ICO publishes a self-assessment tool at ico.org.uk to help you work through it, and there's a personal data breach advice line on 0303 123 1113 if you're genuinely unsure. Deciding not to report is a valid outcome. Deciding without writing down why is the part that gets picked apart later.
When does the 72-hour clock actually start?+
From when you become aware, not from when you've finished working out what happened. That catches people out. The ICO is explicit that you can't wait for a full investigation before the clock starts, and Article 33(4) lets you send what you know now and add detail in phases afterwards, provided each update goes without undue further delay. Waiting three days to file one complete report, instead of an incomplete one on day one, is the wrong instinct.
What if we can't finish investigating within 72 hours?+
You're not expected to. Phased reporting is built into the law for exactly this reason -- the ICO's guidance recognises that a full picture often isn't possible in three days. File what you know at the 72-hour mark: roughly what happened, roughly how many people, roughly what data. Then follow up as the picture clarifies. An honest partial report on time beats a complete one that's late.
When do we have to tell the people affected, not just the ICO?+
Only when the risk to them is high, which is a noticeably higher bar than the one that triggers ICO notification -- Article 34 uses the word "high" deliberately. Financial details, health data or credentials that could enable identity theft tend to clear that bar; an internal memo that went to the wrong colleague usually doesn't. When it does apply, it has to be a direct message in plain language explaining what happened and what people should do, not a line buried on a website, unless contacting people directly would take disproportionate effort.
What happens if we get this wrong?+
The ICO can fine up to £8.7 million or 2% of global annual turnover for the standard tier of infringement, rising to £17.5 million or 4% for the more serious tier -- whichever figure is higher in each case. In practice, penalties well below that ceiling are far more common, and organisations that act in good faith, respond promptly and cooperate tend to come off lighter than ones that sit on a breach and hope it goes away. The government's 2025/2026 breaches survey found only 40% of businesses reported their most disruptive breach to anyone outside the organisation at all, which is the gap that turns an awkward Tuesday into a regulatory one.
If we decide not to report, do we still need to do anything?+
Yes, and this is the step most businesses skip. A minimal log covers four things: what happened, when you found out, who's affected, and why you concluded it didn't clear the reporting threshold. Five minutes in a shared document is enough. Nothing written down isn't neutral, though, it reads as though no real assessment happened, which is a worse position to be in than a wrong-but-documented judgement call.
Can Alpha IT handle ICO reporting for us?+
No, and we wouldn't want to overstate that we could. We're not a law firm or a data protection officer, and the call on whether a breach clears the reporting threshold is a legal judgement for you, your DPO or your solicitor to make. What we can do is the technical side that makes that 72-hour window survivable: knowing what was actually affected, when, and how, from logs and backups that exist and were actually tested. Our Professional and Complete plans cover EDR, managed backup and log retention that this depends on. A free IT health check will tell you honestly whether that evidence trail exists today, before you need it in a hurry.