Someone has just told you something has happened. A system is locked. A file went to the wrong person. Customer data may have been compromised. You're not a data protection specialist, you don't know the procedure, and decisions need to be made now. The clock, as you're about to discover, is already ticking.
This article explains what happens next, not as a procedure to follow blindly, but so you understand the process well enough to make good decisions under pressure. Because the enforcement record tells a consistent, uncomfortable story: the thing that determines whether a data breach becomes a manageable incident or a defining crisis isn't what happens on the day. It's all about what you had in place before it happened.
The ICO, the Information Commissioner's Office, doesn't reward a good response. It punishes poor preparation.
Most breaches don't look like what you'd expect
If your image of a data breach is a sophisticated cyber attack, ransomware screens, and hooded hackers in dark rooms, you're picturing the minority. Misdirected email, someone sending a spreadsheet to the wrong person, is the single most common breach type reported to the ICO. It accounts for roughly one in five reports. About 75% of all reported breaches are non-cyber incidents. Lost paperwork counts. An employee looking at records they have no business accessing, counts as a breech. Ransomware that locks your systems without actually stealing any data still counts, because losing access to personal data is an availability breach under the legal definition.
If you've only prepared for a cyber attack, you've prepared for the less likely scenario and missed the most common one.
The legal definition is broad. Under Article 4(12) of UK GDPR, a personal data breach is any security incident leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. It spans three dimensions: confidentiality, integrity, and availability. The law firm DPP Law was hit by a ransomware attack in 2022, with 32.4GB of sensitive criminal defence data stolen. They argued that loss of access to data didn't constitute a breach. The ICO found that reasoning demonstrated a "fundamental lack of understanding." It resulted in their penalty being considerably worse than it need have been.
The first 72 hours, and what's actually happening at each stage
The 72 hours starts when your organisation "becomes aware" that a breach has occurred. That means a reasonable degree of certainty, not absolute confirmation. A brief initial investigation is permitted, but it must be genuinely brief. And here's a detail many business leaders don't always understand: if any employee discovers the breach, regardless of their rank or seniority, the organisation is treated as being immediately aware. The clock doesn't wait for the news to reach the senior management.
The first hour is about containment and preservation. Disable compromised accounts. Isolate affected systems. Recover lost devices, if that's relevant. But don't destroy anything in the process, because the evidence you're preserving now is what the ICO will want to see later. The National Cyber Security Centre explicitly acknowledges this conflict: you need to stop the damage without destroying the forensic trail. Their guidance is clear: capture before you contain. Take forensic images, screenshots, and logs before shutting things down. Start a breach log immediately, recording every action, every decision, and who made it. This documentation is required under Article 33(5) of UK GDPR for every breach, whether or not you end up reporting it to the ICO.
By 24 hours, the picture should be taking shape. What personal data is involved? How many people are affected? What's the likely cause? You'll need your response team assembled, which means IT security, legal, senior management, communications, and your data protection officer or equivalent. If a processor, a third party handling data on your behalf, discovered the breach, they should have notified you by now under Article 33(2). If they haven't, that delay is compressing your already tight window. The LastPass breach in 2022 is a useful example of how this goes wrong. Confusion between the GoTo Business AWS team and a LastPass engineer over who should investigate a security alert created an 18 day delay that left the controller scrambling.
By 72 hours, you need to make the reporting decision. The threshold is whether the breach is "likely to result in a risk to the rights and freedoms" of the people affected. That's a relatively low bar, and if you're in doubt, the ICO's own position is unambiguous: report early, update later. Phased reporting is explicitly permitted. You submit what you know, then provide additional detail as the investigation progresses.
One practical thing worth knowing: the ICO reporting form takes about 30 minutes and cannot be saved or resumed partway through. Gather all the details you have before you sit down to complete it, because starting it and then realising you don't have the details is time you can't afford to waste.
There's also a separate, higher threshold for notifying the individuals affected. If the breach is likely to result in a "high risk" to their rights and freedoms, you must communicate directly with them in clear, plain language. The ICO retains the power to order individual notification even if your own assessment is that it isn't required.
What the ICO actually looks at
Two organisations, both hit by ransomware, both processors handling sensitive data, both operating under the same regulatory framework. The end result, completely different outcomes.
Advanced Computer Software Group was attacked in August 2022. One legacy system, out of an estate where 95% had multi factor authentication, didn't have MFA enabled. That was the entry point. But Advanced notified all 658 customers within 24 hours, dedicated an 18 person team to restoration, and proactively engaged the NCSC and National Crime Agency. The initial penalty was £6.09 million. It was reduced to £3.07 million, a 15% reduction for proactive engagement with national agencies and a 20% voluntary settlement discount. This was the first ever fine against a processor under UK GDPR.
Capita's story reads differently. Attacked in March 2023, but known vulnerabilities had been flagged on at least three previous occasions and not remedied. Their security operations centre was understaffed, falling below target response times for six months before the attack. A high priority security alert fired within 10 minutes of the initial compromise. Capita took 58 hours to quarantine the compromised device, against their own one hour target. Approximately 1TB of data was exfiltrated. 6.6 million individuals affected. Over 90 separate organisations notified the ICO from a single underlying attack. The initial notice of intent proposed approximately £45 million. It settled at £14 million.
Capita actually reported to the ICO within 14 hours of confirming the breach. That prompt notification made no difference to the penalty. The ICO treats prompt reporting as a baseline expectation, not a mitigating factor. What mattered was the three previous occasions someone had flagged the vulnerabilities that let the attackers in. Every organisation thinks prompt reporting will help. It won't. It's what you were doing before the breach that the ICO cares about.
This pattern holds across every major enforcement action of the past two years. The ICO characterised Advanced's full cooperation as "expected, not beyond expected," and therefore not mitigating. It described LastPass's cooperation as "good" but "not beyond what is reasonably to be expected." DPP Law waited 43 days before reporting their breach, and received separate infringement findings for both security failures and late notification, with the ICO finding distinct violations of Articles 32 and 33 in the same penalty notice.
What genuinely reduces penalties is not what many business leaders assume. Proactive engagement with the NCSC and NCA made a measurable difference for Advanced. Meaningful support to affected individuals, such as Capita's credit monitoring and dedicated call centre, earned some recognition. Genuine post incident remediation counts. But routine cooperation, doing what you're supposed to do, earns nothing.
The ICO is not assessing how well you performed under pressure. It is assessing whether your organisation was taking data protection seriously before the event happened. Known vulnerabilities left unpatched. Understaffed security operations. Missing MFA on legacy systems. No formal incident response plan. That is the scrutiny you'll be under, and it's the scrutiny that most organisations are currently failing.
The preparation that actually changes the outcome
The government's Cyber Security Breaches Survey 2025 paints an uncomfortable picture. Only 22% of UK businesses have a formal incident response plan. Board level cyber security responsibility has actually declined, from 38% in 2021 to 27% in 2025. Only 32% have formal guidance on when to report breaches externally, and just 14% review their suppliers' cyber security risks.
Those numbers really stand out when you set them against what the ICO is now looking for. The IBM Cost of a Data Breach Report 2025 found that organisations testing their incident response plans at least twice a year save around £1.2 million per breach. Not because testing makes you better at navigating ICO scrutiny. Because it means the critical decisions that matter most, aren't being made for the first time under extreme pressure.
The preparation that matters most isn't complex. A formal incident response plan, written down, with named roles and at least two contact methods for each. Pre drafted notification templates for the ICO, for affected individuals, and for internal communications, stored somewhere accessible if your primary IT systems are down. Agreed notification timeframes with your processors, written into your contracts, because Article 33(2) says "without undue delay" but prescribes no specific number of hours. If you don't have a number in your contract, you're relying on your processor's interpretation of "undue," and that is not a position you want to be in during a live incident.
The NCSC's "Exercise in a Box" is a free resource offering tabletop exercises accessible to organisations of any size. Use it. Test the plan. Then test it again.
The call will always be stressful
Nobody receives the news that their organisation has had a data breach and feels calm about it. That won't change regardless of how well prepared you are. But the organisations that come through it well aren't the ones with the best crisis instincts. They're the ones that did the preparation work beforehand.
Advanced and Capita faced the same type of attack under the same regulatory framework. The difference was entirely in what each had in place before the call came. Preparation turns "we think we've had a breach" from a crisis into a formal process. And when the ICO examines what happened, that is exactly what they're looking for: whether the breach exposed a failure of governance or just bad luck.
If your organisation doesn't yet have a formal breach response plan, now is the time to build one. Not next quarter. Now, while the clock isn't ticking and nobody is waiting for your answer.
