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 reportable personal data breach must be notified to the ICO without undue delay and, where feasible, within 72 hours of awareness. Not every breach requires notification, but every breach must be documented, including the assessment of risk to individuals.

ICO enforcement examples show why security controls and incident response both matter. The 2025 cases below concern specific failures identified in investigations; a cyber attack does not automatically establish non-compliance or determine a 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

Three types of personal data breach — CIA taxonomy

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

72-hour breach response timeline

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 72 hours include weekends and holidays. For example, awareness at 3 pm on Friday reaches 72 hours at 3 pm on Monday. Notify without undue delay rather than treating the full period as a waiting allowance.

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

Should I notify the ICO — decision tree

Notify unless the breach is unlikely to result in a risk to people's rights and freedoms. Assess the likelihood and severity of harm, record the reasoning and use the ICO's reporting guidance if uncertain. Neither an internal incident label nor the absence of confirmed misuse resolves that assessment.

Examples requiring a prompt risk assessment include:

  • 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.
  • Disclosure of special category information, where even a small number of affected people may face serious harm.

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 blocked attack with no loss, alteration, disclosure or unauthorised access to personal data is a security incident rather than a personal data breach; keep the appropriate security records.

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.

Assess the likely impact in context, including sensitivity, identifiability, vulnerability and possible consequences. Banking credentials or health information can create high risk, but a seemingly simple email address may also reveal sensitive associations. Avoid deciding solely from the field name or number of records.

Tell affected people without undue delay in clear, plain language. Describe the nature of the breach, provide the DPO or other contact point, explain the likely consequences and the measures taken or proposed, including steps people can take to protect themselves. This is not identical to every field in the ICO report.

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

This illustrative runbook helps organise the first day. Adapt its timing to the incident and act immediately where needed; the suggested hourly stages are not statutory waiting periods.

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.
  • Appoint a response lead with appropriate authority. Involve the DPO where designated, while preserving their independent advisory and monitoring role.

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 Article 33: is the breach unlikely to result in a risk to people's rights and freedoms? If it is not unlikely, notify the ICO. Record the facts and reasoning behind the assessment.
  • 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.

  • Where notification is required, report without undue delay and, where feasible, within 72 hours of awareness. Give available information, explain any delay and provide missing details in phases without undue further delay.
  • Issue individual notifications where required.
  • Begin remediation: fixing the underlying vulnerability, retraining staff, updating policies, revising supplier arrangements.
  • Plan the post-incident review.

Prepare the response plan in advance, assign responsibility and test it at intervals suited to the risks and changes in the organisation. An annual exercise can be a useful practice, but UK GDPR does not prescribe that universal frequency.

Recent UK breach examples

The following dated 2025 cases illustrate findings about security and response. They are examples, not a complete ranking of all enforcement action.

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)

LastPass UK was fined £1,228,283 following 2022 incidents affecting up to 1.6 million UK users. The ICO found inadequate technical and organisational security measures. It stated that there was no evidence that the hackers had decrypted customer passwords; this should not be described as a finding that all vault contents were exposed in readable form.

These decisions concerned the organisations' specific security obligations and failings. Reviewing access controls, detection and response together helps address the kinds of weaknesses identified.

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

How to prevent future breaches

Reported incidents include mistaken disclosures and lost information as well as malicious attacks. Select preventive controls for the information, systems and risks involved, and review how incidents actually occur in your organisation.

Depending on the risks, appropriate technical measures can include:

  • Multi-factor authentication, especially for remote, privileged and other higher-risk access, with suitable recovery controls.
  • Encryption at rest and in transit where appropriate, together with secure management of keys and access.
  • 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 incident plan and exercises at a frequency proportionate to the risks and operational changes.
  • Access to suitable incident-response expertise, internally or through an external provider, based on the organisation's capability and risks.
  • 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. Notify the ICO unless a breach is unlikely to result in a risk to people's rights and freedoms. Document every personal data breach and the reasons for the reporting decision, including those not notified.

What happens if I miss the 72-hour deadline?

Report without undue delay, explain the reasons for any delay beyond 72 hours and supply missing information in phases if needed. A failure to meet the legal reporting requirements can lead to enforcement, but a fine is not automatic.

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, failing to comply with Article 33 can attract enforcement and the standard-tier maximum of £8.7 million or 2% of worldwide annual turnover, whichever is higher. Reporting is required without undue delay and, where feasible, within 72 hours; the ICO considers the circumstances and reasons for delay.

Make sure your team knows how to recognise, contain and report a personal data breach.

Explore the GDPR & Data Protection Course →

Sources & references

Mark McShane
Mark McShane
Health & Safety Training Specialist, Online CPD Academy

Mark writes about GDPR, data protection and accredited online training for GDPR & Data Protection Course, part of Online CPD Academy.