How to Report a Data Breach to the ICO: A Complete UK Guide

If your organisation suffers a personal data breach, UK GDPR requires you to notify the Information Commissioner's Office (ICO) within 72 hours of becoming aware of it — unless the breach is unlikely to result in a risk to individuals' rights and freedoms. Missing that deadline, or handling notification poorly, can result in enforcement action, reputational damage, and fines of up to £17.5 million or 4% of annual global turnover.

This guide walks UK data controllers, DPOs, and IT leaders through exactly how to report a data breach to the ICO — from the moment you detect an incident to closing out the case. It covers legal thresholds, the notification form, timelines, common mistakes, and how to notify affected individuals.

What Counts as a Personal Data Breach Under UK GDPR?

A personal data breach is a security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. It is broader than most people assume — it is not limited to hackers stealing databases.

Under UK GDPR (Article 4(12)) and the Data Protection Act 2018, breaches fall into three overlapping categories:

Confidentiality breach: Unauthorised or accidental disclosure of, or access to, personal data. Example: an email sent to the wrong recipient with client details.
Integrity breach: Unauthorised or accidental alteration of personal data. Example: a database corruption that changes patient records.
Availability breach: Accidental or unauthorised loss of access to, or destruction of, personal data. Example: a ransomware attack encrypting employee files with no backup.

Common real-world examples include lost laptops or USB sticks, misdirected post, phishing compromises, ransomware, insider misuse, and misconfigured cloud storage exposing files to the public internet.

Do You Actually Need to Report the Breach to the ICO?

Not every breach requires notification. You must report a breach to the ICO only if it is likely to result in a risk to the rights and freedoms of individuals. If the risk is unlikely, you don't need to notify — but you must still document the incident internally.

Factors That Indicate Reportable Risk

The type of data involved (special category data, financial data, or children's data raises the risk significantly).
The volume of records affected.
Ease of identifying individuals from the exposed data.
Severity of consequences (identity theft, fraud, discrimination, physical harm, reputational damage).
Whether the data was encrypted or otherwise rendered unintelligible.
Special vulnerabilities of the individuals affected (e.g. patients, minors).

Quick Decision Table

Scenario	Report to ICO?	Notify Individuals?
Encrypted laptop lost, strong password, no data accessed	Usually no	No
Email with 200 client names/addresses sent to wrong recipient	Yes	Likely yes
Ransomware encrypting customer database, no exfiltration confirmed	Yes	Case-by-case
Health records exposed on public web server	Yes (urgent)	Yes (high risk)
Internal typo corrected within minutes, no external exposure	No	No

If in doubt, err on the side of reporting. The ICO explicitly states it prefers over-reporting to under-reporting, and late notification is treated far more seriously than a marginal case reported in good faith.

The 72-Hour Rule: When Does the Clock Start?

The 72-hour countdown begins the moment your organisation becomes "aware" of the breach — meaning you have a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised. It does not start when the breach actually happened, nor when it is fully investigated.

Practical implications:

Awareness can be triggered by an employee report, an automated alert, a customer complaint, or a third-party notification.
A short initial investigation to confirm a breach has occurred is acceptable and doesn't start the clock.
The 72 hours includes weekends and bank holidays.
If you miss the deadline, you must still notify — and provide reasons for the delay.

Step-by-Step: How to Report a Data Breach to the ICO

Step 1: Contain and Assess the Breach

Before notifying anyone, take immediate steps to stop the breach spreading. This might mean isolating affected systems, revoking access credentials, recalling misdirected emails via Microsoft 365, or taking a public-facing service offline. Preserve evidence — logs, screenshots, and forensic images — because you'll need them for both the ICO and any subsequent investigation.

Step 2: Convene Your Incident Response Team

Assemble your DPO (if appointed), IT/security lead, legal counsel, and a senior decision-maker. Document who is doing what and when. A written incident log created from minute one is invaluable — the ICO may request it.

Step 3: Assess Risk to Individuals

Using the risk factors above, determine whether notification is required. Document your reasoning either way. This documented risk assessment is a legal requirement under Article 33(5) UK GDPR.

Step 4: Choose Your Reporting Channel

The ICO offers several ways to report:

Online form: The primary route, available at ico.org.uk. It walks you through structured questions and is the fastest option.
Telephone: Call the ICO breach helpline on 0303 123 1113 (option 3). Useful outside office hours or for urgent high-risk breaches.
Post: Only recommended for supplementary information, not initial reports.

Step 5: Complete the Notification Form

The ICO's online form asks for:

Your organisation's details and ICO registration number.
Contact details of your DPO or breach point of contact.
Date and time you became aware of the breach and, if known, when it occurred.
The nature of the breach (confidentiality, integrity, availability).
Categories and approximate number of individuals affected.
Categories and approximate number of records affected.
Description of likely consequences.
Measures taken or proposed to address the breach and mitigate harm.
Whether you have notified — or plan to notify — the affected individuals.

Step 6: Submit a Phased Report if Necessary

If you don't yet have all the information within 72 hours, submit what you know and clearly mark it as a phased notification. UK GDPR explicitly allows this. Provide updates "without undue further delay" as your investigation progresses.

Step 7: Notify Affected Individuals if Required

If the breach is likely to result in a high risk to individuals, you must inform them directly, without undue delay. The communication must be in clear, plain language and include:

The nature of the breach.
Name and contact details of your DPO or point of contact.
Likely consequences.
Measures taken and recommended steps individuals can take (e.g. change passwords, monitor bank statements).

Step 8: Document Everything

Whether reported or not, every breach must be recorded in your internal breach register. Record the facts, effects, and remedial action. The ICO can request this register during any investigation or audit.

Common Mistakes That Trigger ICO Enforcement

Analysis of ICO enforcement notices over the past several years reveals recurring failures. Avoiding these dramatically reduces regulatory risk:

Late reporting without justification. Missing 72 hours without explaining why is a significant aggravating factor.
Under-reporting the scope. Downplaying the number of affected individuals or the sensitivity of data.
Failing to notify individuals. Reporting to the ICO but not telling the people at risk when required.
No documented risk assessment. Being unable to explain why you decided a breach didn't need reporting.
Poor security hygiene. The underlying cause (unpatched systems, no MFA, weak access controls) often attracts more criticism than the breach itself.
Ignoring processor breaches. If a supplier notifies you of a breach, the 72-hour clock starts for you as the controller.

What Happens After You Report?

Once submitted, the ICO acknowledges the report and assigns a case reference. Possible outcomes range from a simple closure with no further action, to informal advice, to a formal investigation and enforcement action including reprimands, enforcement notices, or monetary penalties.

The ICO's response typically depends on:

The severity and scale of the breach.
Whether your security measures were reasonable.
How quickly and transparently you responded.
Your history of prior breaches or complaints.
Steps taken to prevent recurrence.

Cooperating fully, providing timely updates, and demonstrating genuine remediation efforts materially improve outcomes. The ICO is a regulator that rewards transparency.

Preventing the Next Breach

Notification is a reactive process. The best data protection strategy prevents breaches in the first place. Practical steps include:

Implementing multi-factor authentication across all business-critical systems.
Encrypting devices, backups, and data in transit.
Running regular phishing simulations and staff training.
Maintaining a patching schedule with defined SLAs.
Conducting Data Protection Impact Assessments (DPIAs) for high-risk processing.
Reviewing supplier and processor security annually.
Using secure link-sharing tools with expiry dates and access controls for any personal data shared externally — for example, when sending a one-time report link to a client, tools like Lunyb allow you to create short links with expiry and click limits, reducing the risk of a link being forwarded or indexed indefinitely.
Testing your incident response plan with tabletop exercises at least annually.

If you regularly share sensitive documents or reports externally, consider how your link-management practices affect breach risk. Our 2026 buyer's guide to URL shorteners compares features like link expiry, password protection, and analytics that matter for privacy-conscious teams.

Special Considerations for Specific Sectors

Healthcare and Social Care

Breaches involving health data are almost always high risk. NHS organisations must also report via the Data Security and Protection Toolkit incident reporting tool, which forwards notifications to the ICO automatically.

Financial Services

FCA-regulated firms may have parallel obligations under Principle 11 and SUP 15.3 to notify the FCA of material incidents. Consider both regulators simultaneously.

Telecoms and ISPs

Providers of public electronic communications services must report breaches under PECR within 24 hours, using a separate notification process.

Education

Schools and universities handling children's data must give particular weight to the vulnerability of data subjects when assessing risk — the threshold for "high risk" is lower.

Frequently Asked Questions

What is the penalty for failing to report a data breach to the ICO?

Failure to notify the ICO within 72 hours when required can attract fines of up to £8.7 million or 2% of annual global turnover, whichever is higher. This is separate from any fine for the underlying breach itself, which can reach £17.5 million or 4% of turnover.

Do I need to report a breach if the data was encrypted?

Generally no, provided the encryption is strong, the decryption key was not compromised, and you have backups if availability is affected. Encrypted data that is genuinely unintelligible to unauthorised parties is unlikely to result in a risk to individuals — but you must still document the incident.

Who is responsible for reporting — the controller or the processor?

The data controller is legally responsible for reporting to the ICO. Data processors must notify their controller "without undue delay" after becoming aware of a breach, and the controller's 72-hour clock starts when they receive that notification. Contracts should specify processor notification timeframes (often 24 hours).

Can I withdraw a breach report if I later discover it wasn't reportable?

You can contact the ICO to update or clarify a report if new information shows the risk was lower than initially assessed. The ICO will generally welcome accurate updates and may close the case without further action. Never delete internal records of the incident.

How long should I keep records of data breaches?

The UK GDPR doesn't specify a retention period for breach records, but the ICO expects you to keep them long enough to demonstrate compliance and identify trends. Most organisations retain breach records for at least six years, aligning with the limitation period for civil claims under English law.

Final Thoughts

Reporting a data breach to the ICO is not just a legal obligation — it's an opportunity to demonstrate accountability, protect affected individuals, and strengthen your organisation's security posture. Preparation is everything: a rehearsed incident response plan, a documented risk assessment framework, and clear escalation paths turn a chaotic 72 hours into a controlled, defensible process.

Treat every breach as a lesson. The organisations that fare best under ICO scrutiny are those that report promptly, communicate honestly, remediate genuinely, and use each incident to raise the bar for next time.