# Personal data breaches When a breach must go to the regulator within 72 hours, when the people affected must be told, and what to record for every incident, reported or not. Source: https://sted.digital/docs/standards/gdpr/personal-data-breaches · Last reviewed 17 October 2026 · Strand Standards and regulations UK GDPR Article 33 requires you to report a personal data breach to the regulator within 72 hours of becoming aware of it, unless it is unlikely to put anyone at risk. Article 34 requires you to tell the people affected without undue delay when the risk to them is high. EU GDPR has the same articles. ## The requirement in plain English A [personal data breach](/docs/glossary/personal-data-breach) is wider than a hack. The UK GDPR defines it 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" ([UK GDPR Article 4(1)(12)](https://www.legislation.gov.uk/eur/2016/679/article/4)). A lost laptop, a ransomware attack that locks a database and an email to the wrong person are all breaches. The same articles apply in EU GDPR. **Reporting to the regulator.** You must report "without undue delay and, where feasible, not later than 72 hours" after becoming aware of the breach, unless it is unlikely to result in a risk to people ([UK GDPR Article 33(1)](https://www.legislation.gov.uk/eur/2016/679/article/33)). The report covers what happened, roughly how many people and records, a contact point, the likely consequences and what you are doing about it (UK GDPR Article 33(3)). You may send it in phases (UK GDPR Article 33(4)). **Telling the people affected.** Where the breach is likely to result in a high risk to people, you must tell them without undue delay, in plain language, with what they can do to protect themselves (UK GDPR Article 34). You need not tell them if the data was encrypted, if later measures removed the high risk, or if individual contact would take disproportionate effort, in which case a public notice does instead (UK GDPR Article 34(3)). **Processors** must tell their controller without undue delay (UK GDPR Article 33(2)). **Every breach**, reported or not, goes in your own breach log with the facts, effects and action taken (UK GDPR Article 33(5)). UK GDPR In the UK you report to the ICO, which became the Information Commission on 30 September 2026 and kept the ICO name. Reports go through the ICO's [breach reporting page](https://ico.org.uk/for-organisations/report-a-breach/), which also explains the reporting routes. Organisations in some sectors, such as communications providers, have separate breach duties of their own on top. EU GDPR In the EU you report to the competent supervisory authority. With a main establishment in the EU, that is normally the lead authority where it sits (EU GDPR Article 33(1)); without one, the European Data Protection Board's guidance expects a report to each authority whose residents are affected. Other EU laws, such as NIS2 for essential and important entities, set their own and shorter clocks alongside. This is guidance to help you understand the requirement, not legal advice. ## What good looks like A 35-person fintech has an incident procedure that names a breach lead (the head of operations), a deputy, and a decision-maker for reporting (the managing director, advised by the privacy lead). Staff know to report any suspected incident at once through one channel, and that reporting a mistake will not be held against them. When a report comes in, the breach lead opens an incident record within the hour, notes the time of awareness, and works through a fixed sequence: contain, establish what data and whose, assess the risk to people, decide on reporting, and record the reasoning either way. The 72-hour deadline is written on the record as a date and time. The decision to report or not uses the same criteria every time: the type and volume of data, how identifiable people are, the likely harm and whether it was contained. After closure, a short review records the cause and the fix, and anything systemic becomes a corrective action. Twice a year the team rehearses a breach using a realistic scenario, timed against the deadline. ## Evidence an auditor expects - **Breach log**: required for every breach, reported or not; the auditor checks it records facts, effects and remedial action, and that near misses are not quietly left out. - **Reporting decisions**: usual; the auditor reads why unreported breaches were judged low risk. - **Regulator notifications**: required where you reported; the auditor checks timing against the recorded time of awareness. - **Notices to individuals**: required where risk was high; the auditor checks content and timing. - **Incident procedure**: usual; the auditor checks it names roles and the 72-hour step. - **Processor contracts**: required; the auditor looks for the processor's duty to tell you without undue delay. - **Exercise records**: usual; they show the procedure has been tested. ## Common mistakes ### Logging only the breaches you report The duty to document covers every breach. A log with three reported incidents and nothing else suggests the rest went unrecorded, not that none happened. ### Starting the clock at the end of the investigation Awareness comes when you are reasonably certain personal data is affected, not when the investigation is finished. Record the time of awareness on the day, and report what you know. ### Waiting for the processor A breach at your processor is your breach to report. If the contract has no prompt notice duty, you may hear too late to meet your own deadline. ### Judging risk by the cause rather than the effect A small mistake can expose sensitive data, and a large attack can touch nothing that matters. Assess what could happen to the people involved, not how the breach happened. ### Missing the other deadlines Sector rules, contracts with customers and cyber insurance policies often require faster notice than the GDPR. List every notification duty in the incident procedure, with its clock. ## How Sted helps Sted's knowledge base includes a Data Protection Incident Record (REC-DPI) under the Incident Management Procedure (PRC-IMP), with ten sections from what happened and whose data was involved, through the risk to people, containment and who had to be told and when, to the root cause and a post-incident review. Records are part of the Full Management System plan. Sted's knowledge base includes a Corrective and Preventive Actions record template, under its Corrective and Preventive Action Procedure. Records are part of the Full Management System plan. Records take file attachments, scanned for malware before download. Sted does not detect breaches, decide whether one must be reported, or notify the ICO, a supervisory authority or the people affected for you. ## Related guides and terms - [Incident response and breach notification](/docs/guides/incident-response-and-breach-notification): the step-by-step response, from first report to closure. - [Personal data breach](/docs/glossary/personal-data-breach): the term defined. - [Processors and data processing agreements](/docs/standards/gdpr/processors-and-contracts): the contract terms that make a processor tell you in time. - [ISO 27001 technological controls](/docs/standards/iso-27001/annex-a-technological-controls): the security measures that prevent and detect breaches. - [UK GDPR and EU GDPR](/docs/standards/gdpr): how breaches fit with security and accountability. - [Records](/docs/product/records): where each incident is recorded in Sted. ## Frequently asked questions Q: Does an email sent to the wrong person count as a breach? A: Yes. It is an unauthorised disclosure of personal data, so it is a breach whatever the cause. Whether you report it depends on the risk: a misaddressed meeting invite is usually recorded only, while a payslip or a medical letter sent to the wrong person usually needs a report. Q: When does the 72-hour clock start? A: When you become aware of the breach, meaning you are reasonably certain a security incident has affected personal data. A short investigation to establish that is allowed, but the clock does not wait for the full picture. Weekends and bank holidays count. Q: What if I do not have all the facts within 72 hours? A: Report what you know within the deadline and send the rest in phases as you learn it. A late report must say why it is late. An incomplete but timely report is better than a complete late one.