Data Breach Reporting: When You Must Tell the ICO Within 72 Hours

## The short answer

If you suffer a personal data breach that is likely to result in a risk to people's rights and freedoms, you must report it to the Information Commissioner's Office (the ICO) without undue delay and, where feasible, within 72 hours of becoming aware of it. If the breach is likely to result in a *high* risk to those individuals, you must also tell the affected people themselves. Crucially, the 72 hours is a tight, fixed window — and it includes weekends and holidays — so you need to know how you will respond before a breach ever happens.

Not every incident requires a report. A breach that is unlikely to result in any risk to people does not have to be reported to the ICO, though you must still record it internally.

## What counts as a personal data breach

A breach is broader than a hacker stealing data. It is any security incident leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Examples include:

- An email with customer details sent to the wrong recipient

- A lost or stolen laptop or phone holding personal data

- A misconfigured system exposing records online

- Ransomware that encrypts and locks your records

- An employee accessing data they had no business reason to view

Notice that loss of *availability* — for instance, data made inaccessible by ransomware — counts, not just theft.

## The risk assessment that decides everything

The moment you discover a breach, you must assess the likely risk to the people whose data is involved. Consider:

- **The type of data** — sensitive data (health, financial, special category) raises the risk sharply.

- **The volume** — how many people are affected.

- **The ease of identification** — could individuals be identified from what leaked?

- **The potential consequences** — fraud, distress, discrimination, physical harm.

- **Mitigating factors** — was the data encrypted and the key safe?

This assessment drives the two key decisions: report to the ICO, and whether to notify individuals.

## The three possible outcomes

1. **No real risk:** Record it in your internal breach log. No external notification required, but the log is mandatory.

2. **Risk to individuals:** Report to the ICO within 72 hours.

3. **High risk to individuals:** Report to the ICO *and* notify the affected people without undue delay, in clear plain language.

## What to include in an ICO report

Even if you do not have every detail within 72 hours, report what you know and follow up later. The report should describe:

- The nature of the breach and categories and approximate number of people and records affected

- The likely consequences

- The measures you have taken or propose to take

- Contact details for your data protection point of contact

Reporting in phases is acceptable — it is better to notify on time with partial information than to be late while you gather everything.

## Notifying affected individuals

When the risk is high, the people involved need enough information to protect themselves. Tell them in plain language what happened, what data was involved, what they should do (for example, change passwords or watch for suspicious activity), and how to contact you. Avoid jargon and corporate hedging — clarity builds trust at exactly the moment it is most fragile.

## Preparing before a breach happens

The 72-hour clock is unforgiving, so preparation is everything:

- **Maintain a breach response plan** with named roles and clear escalation steps.

- **Keep an internal breach log** for every incident, reportable or not.

- **Train staff to report incidents immediately** — "aware" can mean the moment any employee knows.

- **Know your reporting route** to the ICO in advance.

- **Reduce risk in advance** through encryption and access controls, which can downgrade the severity of a breach if one occurs.

This is precisely the kind of resilience we design in when building enterprise-grade products at neart.ai: assume incidents will happen and make the response fast and rehearsed rather than improvised.

## Practical takeaway

Decide today who would take charge of a breach, how staff would raise the alarm, and where the breach log lives. Treat the 72-hour window as starting the moment anyone in your organisation becomes aware. A short, rehearsed plan turns a frightening incident into a managed process — and the difference between an on-time report and a late one can be the difference between a routine notification and a serious problem.