A controller reports a personal data breach to the ICO unless it is unlikely to risk people's rights and freedoms. The deadline is without undue delay and, where feasible, within 72 hours of awareness.
Use this guide for implementation planning, not as a substitute for checking the consolidated UK GDPR, applicable Data Protection Act 2018 provisions, current ICO guidance, contracts, and the facts of the processing.
Structured answer sets in this page tree.
Cited legal and guidance references.
The 72-hour rule is not a requirement to report every cyber event. It applies when a controller becomes aware of a unless that breach is unlikely to result in a risk to people's rights and freedoms. The controller must notify the ICO without undue delay and, where feasible, within 72 hours; processors notify their controller without undue delay, not on a separate 72-hour ICO clock.
First decide whether the event is a : a security breach that causes accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Confidentiality, integrity, and availability incidents can qualify; an unsuccessful attack that does not compromise personal data does not.
Record when the controller had a reasonable degree of certainty that personal data had been compromised. That awareness starts the 72-hour period. An internal escalation delay does not reset the clock, so processors and frontline teams need immediate reporting routes.
Assess likely harm to people, not only damage to the organisation. Consider the data, identifiability, number and characteristics of people affected, exposure, possible misuse, duration, and whether measures such as effective encryption make harmful consequences unlikely.
The controller owns the ICO decision. Security, legal, privacy, operations, communications, and the relevant processor may supply facts, but the record must identify one decision owner and an alternate. Preserve the first alert, awareness rationale, risk assessment, containment evidence, submission receipt, phased updates, and individual-notice decision.
A processor tells its controller without undue delay; the controller applies the Article 33 threshold and ICO deadline. If the same event affects processing subject to another regime or another jurisdiction, assess those notification duties separately.
Article 34 uses a higher threshold than ICO reporting. Direct notice is not required where appropriate protection made the data unintelligible, later measures removed the likely high risk, or direct notice would require disproportionate effort and an equally effective public communication is used.
The ICO's examples show why the facts control: disclosure of patient records is likely to create high risk because of the sensitivity and confidentiality of the information; deletion of alumni contact details later restored from backup is unlikely to create high risk; and medical records sent to another professional who immediately alerts the sender and securely deletes them may be unlikely to create a risk. These are examples, not automatic classifications.
The initial report may be incomplete, but it should state what is known, what remains under investigation, and when updates are expected. Keep the filed version and submission confirmation with the underlying breach record.
Article 33 requires the controller to document the facts, effects, and remedial action for every . Add the awareness analysis, notification threshold, reasons for delay, and Article 34 decision so the ICO can verify the process.
Assign awareness timing, risk assessment, ICO reporting, phased updates, individual notice, and the breach record.
Create scoped reporting questions, evidence fields, and review tasks.
Use Research Copilot to answer follow-up questions with cited source material.
Review scope, evidence, owners, and the next compliance actions with Sorena.