UK GDPR 72-hour Breach Reporting

Start by deciding whether the incident is a personal data breach. Under Article 4(1)(12), that means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. That includes events such as accidental loss, unauthorised disclosure, or other security incidents that affect personal data.

Then decide when the controller became aware of it, and whether it is likely to result in a risk to people's rights and freedoms. If it is notifiable, the controller must report to the ICO without undue delay and, where feasible, within 72 hours of awareness; if reporting is late, record the reasons for delay.

The operating workflow should capture triage, containment, risk assessment, ICO notification, phased updates where facts are incomplete, and any separate decision about informing affected individuals.

Evidence should prove the incident timeline and reporting decision: the first awareness timestamp, breach facts known at each stage, affected data and individuals, rights-and-freedoms risk assessment, containment actions, decision to notify or not notify, ICO submission record, phased update log, and reasons for any delay beyond 72 hours.

Most UK GDPR mistakes happen at the boundary between UK GDPR, DPA 2018, PECR, EU GDPR divergence, IDTA/Addendum transfer rules, children data, and processor/subprocessor duties.

Use this section before approving a new processing purpose, vendor, transfer, profiling flow, DSAR workflow, breach process, or child-facing product change.

Use a UK GDPR workflow that captures role, purpose, lawful basis, special-category status, DPIA trigger, rights/breach/transfer trigger, evidence, owner, and review date.

The output should be a lawful-basis note, DPIA decision, privacy notice update, DSAR record, breach assessment, transfer pack, processor clause map, or ICO response record.