Data breach log

The rule: Article 33(5) and every breach, reported or not

Article 33(5) of UK GDPR requires the controller to document every personal data breach, whether or not it is reported: “The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. That documentation shall enable the Commission to verify compliance with this Article” (UK GDPR Article 33). The ICO’s guide to personal data breaches says the same in one line: “You must also keep a record of any personal data breaches, regardless of whether you are required to notify.”

A personal data breach is defined in Article 4(12) of UK GDPR 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”. The ICO’s examples include “sending personal data to an incorrect recipient”, “computing devices containing personal data being lost or stolen” and “loss of availability of personal data”. Most entries in a charity’s or care provider’s log will be of that ordinary kind.

The log sits beside the reporting duty, not under it. Article 33(1) requires a breach to be notified to the regulator “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, unless it “is unlikely to result in a risk to the rights and freedoms of natural persons”. The log is how an organisation shows that it applied that test to every breach, including all the ones it decided not to report.

Two dates matter for anyone reading older material. The regulator formally became the Information Commission on 30 September 2026 – the ICO announced it had “formally transitioned to the Information Commission” – and the UK GDPR text on legislation.gov.uk now refers to “the Commission”. Its guidance is still published at ico.org.uk. And the Data (Use and Access) Act 2025 has been amending UK GDPR in stages, with several ICO pages carrying a notice that they are under review, so check the date on any ICO page you rely on.

What goes in the log: the ICO’s template, and what to add

The ICO publishes a personal data breach log template, linked from its small-organisation guide 72 hours – how to respond to a personal data breach. Its twelve columns are a sound register template for any charity, care provider or small organisation:

1. a reference number, internal or the ICO’s if the breach was reported;
2. when the breach happened, with the date and time if known;
3. what happened and what caused it;
4. the types of personal information affected and how many records – the template’s examples are “names and contact details, health information, educational records, financial details”;
5. how many people are affected;
6. who they are – “patients, staff members, volunteers, customers, children”;
7. the potential impacts on them;
8. the steps taken to contain the breach or limit its impact;
9. the steps taken to avoid a similar incident;
10. whether the people affected were told, “Explain why or why not”;
11. whether the breach was reported to the ICO, “Explain why or why not”;
12. additional comments, including status, related incidents, “any patterns or trends you’ve noticed” and “whether you’ve told any other regulators”.

Five additions make the log stronger in practice:

• When the organisation became aware, as well as when the breach happened. The ICO is explicit: “The clock starts from when you discovered the breach, not when it actually happened.”
• Who assessed it and who decided, with their role and any advice from the data protection officer where the organisation has one, so the decision can be traced to someone with authority.
• The reasoning behind a decision not to report. The ICO says “if you decide you don’t need to report the breach, you need to be able to justify this decision, so you should document it.” “Low risk” is a conclusion, not a reason.
• What containment involved, in specifics. The ICO’s 72-hour guide gives examples: for a misdirected message, “ask them to delete it, send it back securely, or have it ready for you to collect”; for a stolen laptop, “wipe it remotely” if the systems allow; and “You could contain a cyber incident by changing all passwords and making sure your staff do the same.”
• A closure date and the follow-up: when the actions were completed and who checked.

Describe what happened without naming the member of staff who made the mistake. The log is about the data and the response, and it will be read by more people than the staff file.

Near misses, risk assessment and the decision not to report

The ICO’s data protection audit framework, in its section on breach identification, assessment and logging, goes further than the statute. It expects organisations to “Put a breach log in place that records the facts about the personal data breach, its possible effects on the affected people and the measures taken in response”, and also to “Put a process in place to record near-misses that did not result in a personal data breach, but had potential to.” A near miss – the email stopped in the outbox, the file recalled before it was opened – starts no reporting clock, but it shows where the next breach will come from.

The same page lists the factors an assessment should cover, and the log should show each was considered:

• the type of breach – disclosure has different consequences from information becoming unavailable;
• “the type, sensitivity and volume of personal information”;
• “the vulnerability of those affected”;
• the number of people affected;
• whether the incident has been contained, for example information returned or confirmed deleted by the unintended recipient, or a lost device remotely wiped;
• who has had access to the information and whether it could be used maliciously;
• “the consequences of the personal data breach after any mitigation”.

For charities and care providers the vulnerability and sensitivity factors carry most weight. Health information about residents, details of people using a domestic abuse or homelessness service, supporter and donor records with Gift Aid or bank details, and information about children make a risk to the people concerned more likely, and so make reporting more likely. The ICO’s own contrast is useful: the theft of a customer database usable for identity fraud “would need to be notified”, but “you would not normally need to notify the ICO” about “the loss or inappropriate alteration of a staff telephone list”.

The log is also where causes become visible. The ICO says “Human error is the leading cause of reported data breaches”, and recommends “investigating the root causes of breaches and near misses” and a culture in which “employees should feel able to report incidents of near misses”. A log full of misdirected emails is a systems finding, not a run of bad luck.

Charities, care providers and breaches at a supplier

Charities. A significant data breach can also be a serious incident for the Charity Commission. Its guidance How to report a serious incident in your charity lists “significant data breaches/losses” among the incidents to report, says “It is the responsibility of the charity trustees to decide whether an incident is significant and should be reported”, and asks for reports “promptly”, meaning “as soon as is reasonably possible after it happens, or immediately after your charity becomes aware of it”. A report to the Commission is separate from any report to the data protection regulator, and for a cyber attack the same guidance says to report fraud and cyber-crime “to Report Fraud via its online reporting tool, ensuring you obtain a crime reference number”. Charities with income over £25,000 must also “sign a declaration confirming there were no serious incidents during the previous financial year that should have been reported to the Commission but were not” in the annual return. The breach log, reviewed before that declaration is signed, is how trustees know the answer.

Care providers. A breach involving residents’ or service users’ health information is likely to meet the reporting threshold more often than most, and may also be a safeguarding matter or a reportable incident in its own right. Providers that use the Data Security and Protection Toolkit report through its incident reporting tool, which makes the initial notification to the ICO and the Department of Health and Social Care; the ICO then manages the case. The care home data protection guide explains the route.

Breaches at a supplier. When a supplier that handles personal data for the organisation – a CRM provider, a payroll bureau, a care planning system – suffers a breach, it is still the organisation’s breach to assess and log. The ICO’s guide says that if a processor suffers a breach, “under Article 33(2) it must inform you without undue delay as soon as it becomes aware”, and that “the requirements on breach reporting should be detailed in the contract between you and your processor, as required under Article 28.” Log the supplier’s notification, the date it reached you (your 72 hours run from your awareness), what data of yours was involved and what you decided.

Schools and academies follow the same law with Department for Education guidance alongside it, covered in the school data breach guide.

Who keeps the log, who sees it, and how long it is kept

The audit framework sets out what good governance of the log looks like, and most of it applies to a small organisation as readily as a large one:

• One log. “Seek assurance that all personal data breaches and near misses are captured centrally (eg there are no locally held breach logs).” A care group with a log in each home, or a charity with one per project, cannot see its own pattern.
• Restricted access. “Only give access to the breach log to staff who need it.” The log itself contains personal data about the people affected.
• Senior review. “Regularly review the breach logs (or relevant reports) at a senior strategic level.” For a charity that means the trustees or a committee of the board, at least annually; for a care provider, the registered manager and the provider’s board.
• Trend analysis. “Carry out trend analysis of breach logs as part of strategic level reporting.” Significant themes belong on the organisation’s risk register.
• A retention period. “Set out a retention period for breach logs that contain personal information and establish a lawful basis for their retention”, and “Take steps to periodically reduce the personal information held in breach logs”.

UK GDPR sets no fixed retention period for a breach log. Choose one in the organisation’s retention schedule, long enough to cover the period in which a complaint, a claim or a regulator’s enquiry about the breach could realistically arise, and minimise the personal data in older entries so that the record of the decision survives longer than the details of the people involved.

The breach that is first reported in a message

The log is written by whoever handles the breach, from what they know. The difficulty is that the first report of a breach rarely arrives as a form. It arrives as a message to the manager on a Saturday morning from a support worker who has realised she sent a client’s address to the wrong family. It is a text from a volunteer who left a bag with the visiting list on the bus. It is a care worker’s message in the staff group asking whether anyone else got a photo of a resident’s medication chart by mistake.

Each of those messages fixes the moment the organisation became aware, which is the moment the 72 hours began, and some are the breach itself: personal data sent where it should not have gone, in an app the organisation does not run. When those conversations sit on personal phones in an end-to-end-encrypted consumer app, the organisation cannot itself retrieve or delete the message and cannot produce the thread later. The log entry records the time someone remembers being told, and the description someone recalls.

That is not a reason to discourage staff from raising the alarm by message; a quick message is exactly what the organisation wants. It is a reason to know where those messages land. The question for the next trustee or leadership meeting is a practical one: for the last three entries in our breach log, could we show from our own systems when we first became aware, or would the answer come from somebody’s phone?

Questions people ask

What is a data breach log?

A data breach log is an organisation’s record of every personal data breach it has had, required by Article 33(5) of UK GDPR: the facts of each breach, its effects and the remedial action taken, whether or not the breach was reported to the regulator. The ICO publishes a free template log with twelve columns.

Are all data breaches reported to the ICO?

No. A personal data breach must be reported only if it is likely to result in a risk to people’s rights and freedoms; the ICO puts it as “If a risk is likely, you must notify the ICO; if a risk is unlikely, you don’t have to report it.” Every breach must still be recorded in the organisation’s own log, with the reasons for not reporting.

How long do I have to report a data breach to the ICO?

Without undue delay and, where feasible, within 72 hours of becoming aware of the breach, under Article 33(1) of UK GDPR. The ICO says “The clock starts from when you discovered the breach, not when it actually happened”; a late report must give reasons for the delay, and information can be provided in phases.

Who is responsible for a data breach under the GDPR?

The controller – the organisation that decides why and how the personal data is used – is responsible for assessing, reporting and logging a breach, even when the breach happened at a supplier. A processor that suffers a breach must tell the controller “without undue delay” under Article 33(2).

What causes most data breaches?

People, more than technology: the ICO says “Human error is the leading cause of reported data breaches”. Its examples of breaches include sending personal data to an incorrect recipient and lost or stolen devices, and it recommends training, a “check twice, send once” principle and investigating the root causes of breaches and near misses.

Do charities have to report data breaches to the Charity Commission?

A significant data breach should be reported to the Charity Commission as a serious incident, separately from any report to the data protection regulator; the Commission’s guidance lists “significant data breaches/losses” and says it is for the trustees to decide whether an incident is significant. Charities with income over £25,000 confirm in their annual return that no serious incident went unreported.

Where to read the official guidance, and your next step

The ICO’s guide to personal data breaches is the authority on the reporting test and the record, and its 72-hour guide for small organisations links the template log. Its audit framework page on breach identification, assessment and logging sets out what an auditor would expect. Charities should also read the Charity Commission’s serious incident guidance. The text of Article 33 is on legislation.gov.uk. Quotations are from those pages as read on 3 October 2026.

This guide is a practical summary, not legal advice about a particular breach. On a live incident, involve whoever handles data protection at once, and take advice before deciding not to report something serious.

Then do one thing: open your breach log and check that every entry from the last twelve months has the date of awareness and a written reason for the reporting decision. If there is no log, start one today from the ICO’s template.