GDPR data breach: what to do in the first 72 hours

A practical guide to UK GDPR data breach response — what counts as a breach, the 72-hour reporting rule, when to notify the ICO and affected individuals, and a step-by-step runbook for the first day.

A personal data breach is one of the few moments in a compliance programme where the clock genuinely matters. UK GDPR gives controllers 72 hours from awareness to notify the Information Commissioner's Office, and missing that window is itself an enforcement risk separate from whatever caused the breach in the first place.

The recent ICO fines tell the story plainly. Every one of the largest UK GDPR penalties issued in 2025 was for a security failure following a cyber attack — and how each organisation handled the breach in the days after the incident was a significant factor in the size of the fine.

This guide covers what counts as a breach, the 72-hour rule, when individuals must be told, a runbook for the first day, and recent UK enforcement examples.

What counts as a personal data breach

Article 4(12) of the UK GDPR defines a personal data breach as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed".

That definition captures three distinct categories of incident:

• Confidentiality breach — unauthorised or accidental disclosure of, or access to, personal data. A ransomware actor exfiltrates a customer database; an email is sent to the wrong recipient; an employee accesses files they should not have.
• Integrity breach — unauthorised or accidental alteration of personal data. A database is corrupted; records are tampered with; data is silently changed by malware.
• Availability breach — accidental or unauthorised loss of access to, or destruction of, personal data. A laptop is stolen; a server is wiped without backup; a ransomware attack encrypts records the controller can no longer access.

Two implications often missed. First, accidents count. The accountability principle does not distinguish between malicious attacks and human error — losing an unencrypted USB stick is a breach. Second, temporary loss of access can be a breach even where the data is later recovered, particularly where the recovery requires significant time or where the data was needed urgently.

Not every incident is a breach. A failed phishing attempt that did not result in access is not a breach. An attempted intrusion that was blocked by perimeter controls is not a breach. The test is whether security failed in a way that produced one of the three outcomes — destruction, loss, alteration, unauthorised disclosure, or unauthorised access — to personal data.

The 72-hour reporting rule

Article 33(1) of the UK GDPR requires controllers to notify the ICO of a personal data breach "without undue delay and, where feasible, not later than 72 hours after having become aware of it". Where notification takes longer than 72 hours, the controller must explain the reasons for the delay.

Three points need stressing:

The clock starts at awareness, not at the incident

A cyber attack might have happened weeks ago, but the 72-hour window begins when the controller becomes aware that a breach has occurred. "Awareness" means having a reasonable degree of certainty — confirming an incident is a breach takes some investigation, and the ICO accepts that. What it does not accept is delaying the investigation in order to delay awareness.

Weekends and holidays don't pause the clock

The deadline is calendar hours, not working hours. A Friday afternoon discovery means a Monday morning report, not a Wednesday morning one.

Phased reporting is allowed

Article 33(4) explicitly permits the controller to provide information in phases where it is not all available within 72 hours. The first report should contain what is known; later reports should follow as the picture clarifies. Submitting a partial report on time is better than submitting a complete report late.

The notification must include the nature of the breach, the categories and approximate number of data subjects and records affected, the contact point for further information, the likely consequences, and the measures taken or proposed to address it. The ICO has a dedicated breach reporting form on its website.

Processors have a parallel obligation under Article 33(2): they must notify the controller of any breach without undue delay. The processor is not required to notify the ICO directly — that is the controller's responsibility — but the controller cannot meet its own deadline unless the processor moves promptly.

When to notify the ICO

Article 33 requires notification "unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons". That carve-out is narrower than it sounds. The ICO has been consistent that the threshold is unlikely, not no risk — if there is any reasonable doubt, the breach should be notified.

A few scenarios that typically clear the bar for notification:

• Loss or theft of an unencrypted device containing personal data.
• Unauthorised access to a system holding any meaningful volume of personal data.
• Sending personal data to the wrong recipient where the recipient cannot be trusted to delete it without using or disclosing the information.
• A ransomware attack that has affected personal data, even where backups exist and the controller does not intend to pay.
• A confidentiality breach involving special category data, regardless of volume.

Scenarios that may not require notification (but should still be documented):

• A device is lost but the data on it was encrypted with current standards and the key has not been compromised.
• An email is sent to the wrong internal recipient who has confirmed deletion.
• A failed access attempt that did not result in actual unauthorised access.

Article 33(5) requires the controller to document every breach, including the facts, effects, and remedial action taken — whether or not it was notified to the ICO. The internal breach register is a routine ICO audit ask.

When to notify affected individuals

Notification to individuals is governed by Article 34 and the threshold is higher: notification is required when the breach is "likely to result in a high risk to the rights and freedoms" of those individuals.

"High risk" is not the same as "any risk". The ICO's published guidance considers factors including the type of data involved, the ease with which an individual could be identified from it, the severity of the consequences, the volume of data, and any special characteristics of the individuals (children, vulnerable groups). A breach involving banking credentials, special category data, or information that could enable identity theft typically crosses the high-risk threshold. A breach involving an email address alone usually does not.

Where notification is required, it must be made without undue delay, in clear and plain language, with the same content as the ICO notification.

Article 34(3) sets out exemptions: notification is not required where appropriate technical measures (typically encryption) make the data unintelligible to unauthorised parties, where subsequent measures ensure the high risk is no longer likely to materialise, or where individual notification would involve disproportionate effort — in which case a public communication is required instead.

A practical point: where notification to individuals is required, communications teams need to be involved early. The notification should be drafted alongside the ICO report, not weeks afterwards.

A 0–24 hour breach runbook

The first day matters more than any other. A structured approach turns a chaotic incident into a defensible response.

Hour 0–1: Contain and triage.

• Acknowledge the incident through whatever route surfaced it — security alert, employee report, third-party notification, ransom note.
• Identify the immediate steps to stop the breach extending — isolating affected systems, disabling compromised accounts, blocking outbound data flows.
• Establish a single owner for the response. For most organisations, this is the DPO or a named incident commander.

Hour 1–4: Establish the facts.

• What happened? When? How was it discovered?
• What personal data is affected? Categories, volume, sensitivity.
• Whose data is affected? Customers, employees, third parties.
• Is the breach ongoing, or has containment been achieved?
• Identify external parties to involve — incident response provider, legal counsel, insurer.

Hour 4–12: Assess and document.

• Apply the Article 33 risk test: is this breach likely to result in a risk to rights and freedoms? Document the assessment, including the factors considered.
• Apply the Article 34 high-risk test for the individual notification decision.
• Start the breach register entry: facts, effects, measures.
• Brief senior leadership and the data protection function.

Hour 12–24: Prepare the notifications.

• Draft the ICO notification, using the regulator's online form. If the picture is still emerging, plan for phased reporting under Article 33(4).
• Draft the individual notification, if required, in plain language. Coordinate with communications and customer service teams.
• Brief the regulator-facing team on likely follow-up questions.
• Confirm next steps for the next 24 hours — completing the technical investigation, finalising notifications, beginning remediation.

Hour 24 and beyond.

• Submit the ICO notification within 72 hours of awareness. Where the full picture is not available, submit what is known and follow up.
• Issue individual notifications where required.
• Begin remediation: fixing the underlying vulnerability, retraining staff, updating policies, revising supplier arrangements.
• Plan the post-incident review.

The runbook should be written down before an incident happens, tested at least annually, and owned by a named person. Organisations that improvise on the day of a breach almost always miss something.

Recent UK breach examples

The 2025 enforcement record sets a useful benchmark. The four largest UK GDPR fines all related to security failures, and in each case the breach handling itself was a material factor in the outcome.

Capita group companies — £14 million (2025)

The ICO fined two Capita group entities a combined £14 million after a ransomware attack in March 2023 led to the unauthorised access of personal data of approximately 6.6 million people. The ICO's investigation found that Capita had failed to implement appropriate technical and organisational measures and that aspects of the response — particularly the time taken to identify the scope of the breach — fell below the expected standard.

Advanced Computer Software — £3.07 million (2025)

Advanced provided IT services to the NHS and other clients. A ransomware attack in 2022 disrupted NHS 111 services and resulted in unauthorised access to personal data of approximately 79,000 people, including details of vulnerable individuals. The ICO found security failures including insufficient multi-factor authentication coverage.

23andMe — £2.31 million (2025)

The genealogy company was fined after a credential stuffing attack in 2023 affected the personal data — including ancestry information — of around 155,000 UK users. The ICO found multiple security failures, including the absence of mandatory multi-factor authentication and inadequate response to early warning signs.

LastPass UK — £1.23 million (2025)

The password manager was fined following an incident in 2022 that exposed encrypted password vaults and customer information. The ICO's findings highlighted shortcomings in security controls and in transparency with affected users.

The pattern across these is consistent: the underlying cyber attack was the trigger, but the ICO's fines reflected systemic security failures and shortcomings in incident response, not just the breach itself.

For the wider context on enforcement and how fines are calculated, see our GDPR fines guide.

How to prevent future breaches

Most reported breaches are not novel attacks. They are familiar failures — phishing, weak credentials, missing multi-factor authentication, unpatched systems, misconfigured cloud storage, lost devices. Reducing them is well-understood territory.

The technical controls the ICO consistently looks for:

• Multi-factor authentication on all accounts with access to personal data.
• Encryption of personal data both at rest and in transit.
• Patching cadence for known vulnerabilities, particularly in internet-facing systems.
• Access controls based on least privilege.
• Logging and monitoring sufficient to detect anomalous activity.
• Secure backup and tested restore procedures.

The organisational controls that matter just as much:

• Staff training on phishing, credential management, and breach reporting.
• A documented breach response plan, tested at least annually.
• An incident response retainer with an external provider — most organisations cannot resource their own forensic capability.
• Supplier assurance for processors and sub-processors holding significant personal data.
• A clear retention policy that limits the volume of data at risk in the first place. See our data retention guide.

Processors carry their own obligations under Article 28 and Article 32. Where a breach occurs within a processor's environment, the controller still bears the public-facing responsibility. The relationship and contractual terms matter — see our controller and processor guide.

Frequently asked questions

What is a personal data breach?

A breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. The definition covers confidentiality, integrity, and availability breaches — including incidents caused by human error, not just cyber attacks.

Do I have to report all breaches to the ICO?

No. Notification is required where the breach is likely to result in a risk to the rights and freedoms of individuals. Where it is unlikely to result in any risk, notification is not required — but the breach still has to be documented internally under Article 33(5).

What happens if I miss the 72-hour deadline?

The notification must explain the reasons for the delay. Late notification is itself an infringement and can lead to enforcement action, separate from any sanction for the underlying breach.

What information should be in a breach notification?

The nature of the breach, the categories and approximate number of individuals and records affected, the contact point for further information, the likely consequences, and the measures taken or proposed to address it. Where not all of this is available within 72 hours, phased reporting under Article 33(4) is permitted.

Do I have to tell affected individuals?

Only where the breach is likely to result in a high risk to their rights and freedoms. This is a higher threshold than the ICO notification test. Where notification is required, it must be in clear and plain language and made without undue delay.

Can I be fined for not reporting a breach?

Yes. Failure to notify the ICO within 72 hours is itself an infringement, falling into the standard tier of fines (up to £8.7 million or 2% of global turnover, whichever is higher). The ICO has issued several reprimands and fines specifically for late or absent breach notification.