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

If your organisation has suffered a personal data breach, UK GDPR gives you just 72 hours to notify the Information Commissioner's Office (ICO). Missing that deadline, or misreporting the incident, can result in significant fines and reputational damage. This guide walks you through exactly how to report a data breach to the ICO, what information you'll need, and how to handle the process professionally.

What Is 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 doesn't only mean external hacks — it also includes internal mistakes like emailing a spreadsheet to the wrong recipient or losing an unencrypted laptop.

The ICO recognises three categories of breach:

Confidentiality breach — unauthorised or accidental disclosure of, or access to, personal data.
Integrity breach — unauthorised or accidental alteration of personal data.
Availability breach — accidental or unauthorised loss of access to, or destruction of, personal data (for example, ransomware).

When Must You Report to the ICO?

You must notify the ICO of any personal data breach that is likely to result in a risk to the rights and freedoms of individuals. If the breach is unlikely to pose such a risk (for example, a lost device with strong encryption and no evidence of compromise), you don't need to report it — but you must still document it internally.

The 72-Hour Rule Explained

Under Article 33 of the UK GDPR, controllers must notify the ICO "without undue delay and, where feasible, not later than 72 hours after having become aware of it." The clock starts when you have a reasonable degree of certainty that a breach has occurred — not necessarily when it was first suspected.

If you cannot provide all the required information within 72 hours, you can submit a partial report and follow up in phases. The ICO explicitly allows this, provided you explain the reason for the delay in your submission.

What Counts as "Becoming Aware"?

You are considered "aware" of a breach when you have a reasonable degree of confidence that a security incident has led to personal data being compromised. A brief period of investigation to confirm this is acceptable, but you must act promptly. The ICO will not accept indefinite fact-finding as an excuse for late reporting.

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

Follow this seven-step process to ensure your report is complete, timely, and compliant.

Contain the breach. Before reporting, take immediate steps to stop the incident from spreading — isolate affected systems, revoke compromised credentials, or recall misdirected communications.
Assess the risk. Determine what personal data was involved, how many individuals are affected, and the potential consequences (identity theft, financial loss, reputational harm, discrimination).
Decide if reporting is required. If there's a risk to individuals' rights and freedoms, you must report. If in doubt, err on the side of reporting.
Gather the required information. Collect facts about the nature of the breach, categories of data, number of records, likely consequences, and mitigation measures.
Submit the report. Use the ICO's online reporting portal at ico.org.uk or call the ICO helpline on 0303 123 1113 for guidance.
Notify affected individuals. If the breach is likely to result in a high risk to individuals, you must also inform them directly and without undue delay.
Document everything. Keep an internal breach log detailing the incident, your assessment, decisions taken, and lessons learned — even for breaches you didn't report.

How to Use the ICO's Online Reporting Tool

The ICO provides a dedicated online form on its website. It's the preferred channel for most breaches and is available 24/7. During office hours (Monday to Friday, 9am to 5pm), you can also call the helpline for urgent or complex cases.

Information You'll Need to Provide

Prepare the following before starting your submission:

Your organisation's name, ICO registration number, and contact details for the Data Protection Officer (DPO) or lead contact.
Date and time the breach occurred and was discovered.
A description of what happened, including how the breach was detected.
Categories and approximate number of data subjects affected.
Categories and approximate number of personal data records concerned.
The likely consequences of the breach.
Measures taken or proposed to address the breach and mitigate harm.
Whether affected individuals have been notified, and if not, why not.

Comparing Reporting Channels

The ICO offers several ways to make contact depending on the urgency and complexity of your incident.

Channel	Best For	Availability	Response Time
Online form	Standard breach notifications	24/7	Acknowledgement within a few days
Telephone (0303 123 1113)	Urgent or complex breaches, guidance	Mon–Fri, 9am–5pm	Immediate
Live chat	Quick questions before submitting	Business hours	Immediate
Post	Documentary evidence follow-ups	Any time	Slowest — not recommended for initial report

When You Must Notify Affected Individuals

If a breach is likely to result in a high risk to the rights and freedoms of individuals, Article 34 of the UK GDPR requires you to inform those individuals directly. High-risk factors include exposure of financial data, health records, login credentials, or special category data.

Your notification to individuals must use clear, plain language and include:

The name and contact details of your DPO or another contact point.
A description of the likely consequences of the breach.
Measures you have taken or plan to take to address the breach.
Practical advice on how they can protect themselves (for example, changing passwords or monitoring bank accounts).

When You Don't Need to Notify Individuals

You are exempt from directly notifying individuals if:

The personal data was rendered unintelligible (e.g., encrypted with a secure key that wasn't compromised).
You've since taken measures that ensure the high risk is no longer likely to materialise.
Direct notification would involve disproportionate effort — in which case you must issue a public communication instead.

Common Mistakes to Avoid

Even well-intentioned organisations make avoidable errors when reporting to the ICO. Here are the most common:

Waiting to have all the answers. A phased report is better than a late one. Submit what you know within 72 hours.
Under-reporting scope. Guessing low on affected records or downplaying severity can be seen as misleading the regulator.
Failing to log non-reportable breaches. The ICO can request your internal breach register during audits. Missing records suggest poor governance.
Neglecting to inform data subjects. If risk to individuals is high, reporting only to the ICO isn't enough.
Poor internal communication. Ensure staff know how to escalate potential breaches to the DPO immediately, not days later.

What Happens After You Report?

Once your submission is received, the ICO's case officers assess it against their regulatory action policy. In most cases involving prompt reporting and good cooperation, the outcome is advisory — not punitive. The ICO may:

Acknowledge the report and take no further action.
Request additional information or clarifications.
Ask for evidence of remedial measures.
Open a formal investigation for serious or systemic breaches.
Issue enforcement notices, reprimands, or monetary penalties in the most severe cases.

Fines under UK GDPR can reach up to £17.5 million or 4% of global annual turnover — whichever is higher — but the ICO typically reserves such penalties for cases involving negligence, repeat offences, or failure to cooperate.

Reducing the Risk of Future Breaches

Reporting is only one part of a mature data protection posture. Preventing breaches in the first place is the real goal.

Practical Preventive Measures

Encrypt data at rest and in transit. Encrypted data that is lost may not need to be reported at all.
Enforce multi-factor authentication (MFA). Most credential-based breaches can be stopped by MFA.
Train staff regularly. Human error causes the majority of UK data incidents; short, frequent training beats annual marathons.
Limit access on a need-to-know basis. Role-based access controls minimise the blast radius when something goes wrong.
Audit third-party links and integrations. Marketing links, tracking pixels, and shortened URLs can leak referrer data if you don't control them. Tools like Lunyb let you create branded, privacy-respecting short links with analytics you own, reducing reliance on third parties that log user data.
Test your incident response plan. Run tabletop exercises so your team knows the 72-hour clock isn't the time to be figuring out who does what.

For more on choosing privacy-conscious tools, see our Best URL Shorteners Reviewed and Compared: 2026 Buyer's Guide and our honest review of Lunyb.

Special Considerations for Processors and Joint Controllers

If your organisation is a data processor rather than the controller, you don't report directly to the ICO. Instead, you must notify the controller "without undue delay" after becoming aware of a breach. The controller then decides whether an ICO report is necessary.

For joint controllers, your data-sharing agreement should specify which party leads on ICO notification. Absent an agreement, both are jointly liable — and delays caused by disputes over responsibility are viewed unfavourably by the regulator.

Sector-Specific Reporting Duties

Some organisations have parallel obligations beyond the ICO:

Telecoms and ISPs must report certain breaches under the Privacy and Electronic Communications Regulations (PECR) within 24 hours.
Financial services may need to notify the FCA or PRA.
Health and care providers must use the NHS Data Security and Protection Toolkit incident reporting tool.
Operators of essential services under the NIS Regulations may need to notify the relevant competent authority.

These duties run in parallel with — not instead of — the ICO 72-hour rule.

Frequently Asked Questions

How do I report a data breach to the ICO after 72 hours?

You should still report it, and include an explanation for the delay in your submission. Late reporting is a breach of Article 33 and can attract regulatory action, but failing to report at all is worse. Be honest about why the deadline was missed and what you're doing to prevent recurrence.

Do I need to report a data breach if no one has been harmed?

You must report any breach that is likely to result in a risk to individuals' rights and freedoms — actual harm doesn't need to have occurred yet. If the risk assessment concludes it's unlikely to cause any impact, you don't need to notify the ICO, but you must record the incident internally.

Can individuals report a data breach to the ICO themselves?

Yes. If a member of the public believes their data has been mishandled and the organisation hasn't responded adequately, they can raise a concern with the ICO directly via the ICO website. This may trigger an investigation into the organisation involved.

What's the difference between reporting a breach and a personal data complaint?

A breach notification is submitted by the data controller under Article 33. A complaint is raised by an affected individual or third party. Both are handled by the ICO but through different processes and forms.

Will the ICO always fine my organisation for reporting a breach?

No. The ICO's own guidance emphasises that fines are a last resort. Prompt reporting, honest engagement, and demonstrable remedial action typically result in advice or, at most, a reprimand. Fines are reserved for serious, systemic, or wilful failures.

Final Thoughts

Reporting a data breach to the ICO is stressful, but it doesn't have to be catastrophic. The regulator rewards transparency, speed, and evidence of good governance. Build a clear internal process now — before you need it — and you'll be able to move from "we've been breached" to "we've notified the ICO" within hours, not days. That readiness alone can be the difference between a manageable incident and a headline-making one.