We've had a breach. Do we have to tell the ICO?

England and Wales: This page sets out the position in full. Scotland: the same data protection position — it is a reserved matter, so UK GDPR, the DPA 2018 and the ICO apply identically; only the charity-regulator section below differs, because OSCR runs no serious incident regime. Northern Ireland: the same data protection position, reserved in exactly the same way; the charity-regulator section below names the Northern Ireland route.

Not every data breach has to be reported

On the ICO’s guidance, you do not have to report a data breach unless a risk to people is likely. Start with that test, because it saves the most time.

The test is the same under UK GDPR in England and Wales, Scotland and Northern Ireland. This test is for the manager or trustee your data protection policy names to handle breaches.

If the charity has no policy yet, write your data protection policy first. A personal data breach is not automatically a matter for the ICO. The ICO’s own guide says:

“When a personal data breach has occurred, you need to establish the likelihood of the risk to people’s rights and freedoms. If a risk is likely, you must notify the ICO; if a risk is unlikely, you don’t have to report it.”

The ICO gives an example of a breach that need not be reported: “the loss or inappropriate alteration of a staff telephone list.” A charity that reports everything wastes its own time, and the ICO’s.

Not reporting is still a decision, though. It has to be made and written down. The section on recording every breach explains the log.

Two tests, and they are not the same test

Most guidance runs these together. The law keeps them apart. The second is expressly higher.

If…	Then	Who you tell
A risk to people’s rights and freedoms is likely	Notify the ICO	The regulator
A high risk to people’s rights and freedoms is likely	Tell the people affected, directly and without undue delay	The individuals

The ICO’s guidance says: “If a breach is likely to result in a high risk to the rights and freedoms of individuals … you must inform those concerned directly and without undue delay … A ‘high risk’ means the requirement to inform individuals is higher than for notifying the ICO.”

So you can have a breach you report to the ICO without writing to the people affected. You cannot sensibly have the reverse. Take the two decisions separately. Record each one with its reason.

The clock starts when you find out

The window for notifying the ICO starts when the charity becomes aware of the breach, not when it happened. A breach that took place months ago and came to light this morning starts its clock this morning.

You do not need the full facts to report. On the ICO’s guidance: Article 33(4) permits PHASED reporting — notify what you know within 72 hours, then supplement without undue further delay, explaining the gap and the expected timeline.

Incomplete facts are not a reason to wait. They are a reason to file what you have and say what is still missing. The report covers:

• the nature of the breach, with approximate numbers of people and records
• a contact point
• the likely consequences
• what you have done or plan to do about it

Record every breach — including the ones you do not report

Article 33(5) of UK GDPR requires every breach to be documented: the facts, the effects and what you did about it. That applies whether or not you reported it. On the ICO’s guidance, that record is how it checks whether you applied the reporting test properly.

So the breach log is not paperwork. It is your evidence. The most valuable column in it is the one most logs leave out:

• Whether you reported it to the ICO — yes or no, and why
• Whether you told the individuals — yes or no, and why

A charity that reports nothing and cannot show its reasoning has a second problem on top of the first.

The case to learn from is a CC field

Central YMCA sent one email about an HIV support and exercise programme to its participants. The addresses were in the CC field instead of BCC. Anyone receiving it could infer the others’ HIV status. The ICO fined the charity £7,500 for failing to keep the data secure.

The contributing failures the ICO named were all mundane:

• no written email-security policy
• a secure sending tool the charity already had, but did not use
• training that was assigned, but whose completion nobody checked

Those are the fixes that make this page worth acting on. None of them costs money.

Breach, serious incident, safeguarding: separate tests, separate regulators

A data breach is a data protection event. It may also be something else. The tests for each are separate.

In England and Wales, the Charity Commission’s guidance defines a serious incident as an adverse event, actual or alleged. The event causes, or risks, significant harm to people, loss of money or assets, damage to property, or harm to the charity’s work or reputation. “Significant” means significant in the context of your charity.

On the Commission’s guidance you should report one promptly — as soon as is reasonably possible after it happens, or immediately after the charity becomes aware of it. A breach that exposes sensitive information about beneficiaries can meet that test as well as the ICO’s.

In Scotland, OSCR runs no equivalent serious incident regime. In Northern Ireland, the Charity Commission for Northern Ireland uses the same name. The duty is on trustees, and reports go through its general concerns form.

The regulators are not sequential. Reporting to the ICO does not report to the Charity Commission. Waiting for one does not pause the other. Where a breach also raises a safeguarding concern, that is a third route with its own rules.

The reporting hub has a step for each: recognise a serious incident, then make a serious incident report.

Safeguarding reports are covered in the people hub’s step make the reports — and know which are legal duties. A tool is also planned: Is this a serious incident? (planned).

Name who decides out of hours

Breaches do not wait for the next trustee meeting. The window runs over weekends and bank holidays. It starts from the moment someone in the charity knows.

So the deliverable has three parts:

1. A short procedure — contain it, assess it, apply the two tests, notify if needed, record it.
2. A breach log with the “why / why not” columns above.
3. A named person who can make the reporting decision out of hours, with a named deputy. This is the part charities miss.

One more duty sits next to this one. Since 19 June 2026, people have had a statutory right to complain to your charity directly about how it handles their data. After a breach, some will. The complaints route belongs in your data protection policy.

The fixes in the Central YMCA case are security basics. The next step, assess your cyber security baseline, sets out which basics a charity has to have.

Common mistake: reporting every breach — or merging the two notification tests into one

It comes from caution, and from guidance that runs the tests together. Not every breach is reportable: the ICO’s own example is the loss of a staff telephone list. Where “risk is likely”, tell the ICO. Where there is a “high risk”, tell the individuals. The second test is expressly higher.

Common mistake: waiting for the full facts before notifying

Nobody wants to file an incomplete report. But the clock starts on awareness. Article 33(4) allows phased reporting. Notify what you have within the window, explain the gap and when you expect to fill it, then add the rest. Incomplete facts are not an excuse for a late report.

Common mistake: not recording the breaches you decided not to report

If it was not reportable, it can feel as if it did not happen. Article 33(5) requires every breach to be recorded, whether or not it was reported. The record covers the facts, the effects and what you did about it. That record, with the reasoning, is how the ICO checks the reporting decision itself.

Common mistake: treating a CC-instead-of-BCC email as too mundane to be a breach

It happens constantly and rarely causes visible harm. Central YMCA sent one email about an HIV support programme with recipients in CC. That revealed their health status by inference. The charity received a monetary penalty. The failures the ICO named were all mundane: no written email-security policy, a secure tool available but unused, training completion unmonitored.

Worked example

Saltmarsh Trust sends an update to members of a health-condition support group with every address in the CC field. A recipient points it out on a Saturday morning.

The named out-of-hours lead takes it. The clock started when the charity became aware — that morning. She applies the two tests separately.

Membership of the group reveals a health condition by inference. So a risk to people is likely. On the ICO’s own guidance, the ICO must be notified within the window. The same inference makes a high risk likely. So the recipients are told directly and without undue delay.

She does not wait for the full picture. The recipient count is still being checked. So she notifies in phases: what is known now, what is missing, and when she expects to have it. She logs the breach, both decisions and the reasons, whatever the outcome.

On Monday the trustees consider a separate question. They decide whether this is also a serious incident for the Charity Commission. That is a different test, taken on its own terms.

The outcome:

• a breach log entry with the decision and reasoning
• the ICO notified and the recipients told
• a named person able to take the decision out of hours
• the mundane fixes actioned and minuted: an email-security policy, the secure sending tool in use, training completion monitored