Most organisations keep good records of the breaches they report to a regulator and almost none of the ones they decide not to report, which is exactly the record GDPR Article 33(5) requires. Article 33(5) obliges every controller to document any personal data breach, comprising the facts relating to the breach, its effects and the remedial action taken, in a way that lets the supervisory authority verify compliance with Article 33. This template gives [Organisation] a ready-to-use internal breach register: the fields, their definitions, worked example rows for a notifiable and a non-notifiable breach, and the rules for keeping it. It is for data protection officers, privacy teams and incident responders working under the EU GDPR or UK GDPR, and it complements the Data Breach Notification Checklist, which covers the notification decision itself.
How to use this template
- One row per breach, every breach. Log every personal data breach, including those that are unlikely to result in a risk and are never notified. A short entry is fine; a missing entry is the failure.
- Build it where you can control access. A spreadsheet, privacy management tool or case management system all work. The register holds sensitive detail, so restrict it to the privacy team and named incident leads.
- Columns marked Art 33(5) are the legal minimum. Columns marked Recommended are what supervisory authorities usually ask for next and what makes the register useful for trend analysis.
- Record the reasoning, not just the outcome. "Not notified" is not enough; write why the breach was judged unlikely to result in a risk.
- Replace the brackets. Text such as [Organisation], [DPO] and [72 hours] is a placeholder for your names and values.
- Link it to the incident record. The register summarises; the incident ticket holds the evidence. Use the Security Incident Report Form Template for intake.
1. Purpose
This register is [Organisation]'s record of personal data breaches under Article 33(5) of the GDPR and UK GDPR. It records the facts, effects and remedial action for every breach, the decision on whether to notify the supervisory authority and data subjects, and the reasons for that decision. It demonstrates accountability under Article 5(2), supports notification within the Article 33(1) deadline, and provides the evidence the supervisory authority may ask for.
2. Scope
- All personal data breaches affecting personal data for which [Organisation] is controller, including breaches that occur at processors acting for [Organisation].
- Breaches in any form: electronic and paper, deliberate and accidental, internal and caused by third parties.
- All three breach types: confidentiality (unauthorised disclosure or access), integrity (unauthorised alteration) and availability (accidental or unlawful loss of access or destruction).
- Where [Organisation] acts as processor, it records breaches it reports to its controllers in a separate section (section 7.4), because Article 33(2) requires a processor to notify the controller without undue delay after becoming aware.
3. Definitions
- Personal data breach: as defined in GDPR Article 4(12), 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.
- Security incident: any event that may compromise information security. Not every incident is a personal data breach; every personal data breach is an incident.
- Awareness: the point at which [Organisation] has a reasonable degree of certainty that a security incident has led to personal data being compromised. The 72-hour clock in Article 33(1) runs from awareness.
- Notifiable breach: a breach that is likely to result in a risk to the rights and freedoms of natural persons, which must be notified to the supervisory authority.
- High-risk breach: a breach likely to result in a high risk to those rights and freedoms, which must also be communicated to the affected individuals under Article 34, unless an Article 34(3) condition applies.
4. Roles and responsibilities
| Role | Responsibility for the register |
|---|---|
| [Data Protection Officer or privacy lead] | Owns the register; makes or advises on the notification decision; signs off each entry |
| [Incident lead or CSIRT] | Opens the entry when an incident may involve personal data; supplies facts, timeline and containment actions |
| System and data owners | Confirm the data categories, data subjects and volumes affected |
| [Legal counsel] | Advises on notification to authorities in other jurisdictions and on privilege for the investigation file |
| [Procurement or vendor management] | Ensures processor contracts require prompt breach notice and the details needed for the register |
| All staff and contractors | Report suspected breaches immediately through [reporting channel] |
5. Register fields
5.1 Each entry must contain the fields below. Fields marked Art 33(5) satisfy the legal documentation duty; fields marked Art 33(3) are what the notification itself must contain, so recording them here makes the notification quick to write.
| # | Field | What to record | Basis |
|---|---|---|---|
| 1 | Breach reference | Unique ID, linked to the incident ticket number | Recommended |
| 2 | Date and time of breach | When the breach occurred or started, or "unknown" with the best estimate | Art 33(5) facts |
| 3 | Date and time of awareness | When [Organisation] became aware, and how (staff report, processor notice, alert, third party) | Art 33(1), 33(5) facts |
| 4 | Description of what happened | Plain-language account: cause, systems, route of disclosure or loss | Art 33(5) facts; Art 33(3)(a) |
| 5 | Breach type | Confidentiality, integrity, availability (one or more) | Recommended |
| 6 | Root cause category | Human error, misdirected email, lost device, phishing, stolen credentials, misconfiguration, malware, processor error, physical | Recommended |
| 7 | Categories of personal data | For example contact details, financial, health, credentials, identity documents; flag special category data (Art 9) and criminal offence data (Art 10) | Art 33(5) facts; Art 33(3)(a) |
| 8 | Categories and approximate number of data subjects | Customers, employees, patients, children; number or best estimate | Art 33(5) facts; Art 33(3)(a) |
| 9 | Approximate number of records | Number or best estimate | Art 33(3)(a) |
| 10 | Likely consequences for individuals | For example identity fraud, financial loss, discrimination, distress, loss of control of data; or "none identified" with reason | Art 33(5) effects; Art 33(3)(c) |
| 11 | Risk assessment result | No risk likely, risk, or high risk, with the factors weighed (see section 6) | Art 33(5), to verify compliance |
| 12 | Containment and remedial action | Actions taken to stop the breach and mitigate effects, with dates (recall email, revoke credentials, remote wipe, reset passwords) | Art 33(5) remedial action; Art 33(3)(d) |
| 13 | Supervisory authority notified? | Yes or no; authority name; date and time; reference number | Art 33(1) |
| 14 | Reason for not notifying, or for late notification | Why the breach was judged unlikely to result in a risk, or reasons for any delay beyond 72 hours | Art 33(1), 33(5) |
| 15 | Individuals informed? | Yes or no; date; method; or the Article 34(3) condition relied on | Art 34 |
| 16 | Other notifications | Other regulators (for example NIS2 CSIRT, financial regulator), police, insurers, controllers, card schemes | Recommended |
| 17 | Processor involved | Name of processor and date it notified [Organisation] | Recommended; Art 33(2) |
| 18 | Decision maker and contact | Who decided; DPO or contact point name | Art 33(3)(b) |
| 19 | Preventive actions and lessons | Changes to prevent recurrence, owner and due date | Recommended |
| 20 | Status and closure date | Open, monitoring, closed; date closed and approver | Recommended |
5.2 Where facts are not yet known, record what is known with the time it was recorded, and update the entry. Article 33(4) allows information to be provided to the authority in phases where it cannot all be provided at once; the register should show the same progression.
6. Risk assessment and notification decision
6.1 For each breach, the [DPO] must assess the likelihood and severity of risk to individuals and record the factors considered:
- Type of breach: confidentiality breaches usually carry more risk to individuals than short availability losses with a working backup.
- Nature, sensitivity and volume of data: special category data, financial data, credentials and identity documents raise the risk; a small amount of sensitive data can still be high risk.
- Ease of identification: whether the data identifies people directly or only with other information.
- Severity of consequences: including whether the data is in the hands of someone with malicious intent.
- Special characteristics of individuals: children and other vulnerable people.
- Mitigation: strong encryption with an uncompromised key, prompt recall confirmed by a trusted recipient, or data that was already public can reduce the risk.
6.2 Decision table:
| Assessed risk | Supervisory authority | Individuals | Register |
|---|---|---|---|
| Unlikely to result in a risk | Not notified | Not informed | Full entry including field 14 reasoning |
| Risk | Notify without undue delay and, where feasible, within 72 hours of awareness | Not required; consider voluntary notice | Full entry with notification reference |
| High risk | Notify as above | Inform without undue delay unless an Article 34(3) condition applies | Full entry with communication date and method, or the condition relied on |
6.3 Article 34(3) conditions are: the data was protected by measures such as encryption that render it unintelligible to anyone not authorised to access it; subsequent measures ensure the high risk is no longer likely to materialise; or individual communication would involve disproportionate effort, in which case a public communication or similar measure is used instead. The condition relied on must be recorded.
6.4 If the assessment changes as facts emerge (for example, a lost laptop turns out to be unencrypted), the decision must be revisited, the change recorded with its date, and notification made if now required.
7. Worked examples
7.1 Non-notifiable breach (example):
| Field | Entry |
|---|---|
| Reference | PDB-[2026]-014 (INC-[4471]) |
| Breach and awareness | [Date] 10:12 UTC; aware [same day] 10:40 UTC when sender reported the error |
| What happened | A payroll officer emailed one employee's payslip to a colleague with a similar name in the same HR team |
| Type and cause | Confidentiality; human error, misdirected email |
| Data and subjects | Name, salary, tax code, pension contribution; 1 employee |
| Likely consequences | Minimal: recipient is bound by confidentiality, works in HR, deleted the email and confirmed in writing at 11:05 UTC |
| Risk result | Unlikely to result in a risk |
| Remedial action | Written deletion confirmation obtained; employee informed as a courtesy; email recall attempted |
| Authority notified | No. Reason: single trusted internal recipient under confidentiality, deletion confirmed within one hour, no financial or special category data |
| Prevention | Enable recipient warning for external and similar-name addresses in [mail platform]; owner [HR systems], due [date] |
7.2 Notifiable high-risk breach (example):
| Field | Entry |
|---|---|
| Reference | PDB-[2026]-021 (INC-[4520]) |
| Breach and awareness | Started [date] (estimated from logs); aware [date] 16:30 UTC when the SOC confirmed exfiltration |
| What happened | An attacker used a leaked cloud access key from a public code repository to read a customer support database backup |
| Type and cause | Confidentiality; stolen credentials (non-human identity) |
| Data and subjects | Names, email addresses, phone numbers, partial card numbers, support notes; approximately [48,000] customers |
| Likely consequences | Targeted phishing and fraud using support history; distress |
| Risk result | High risk |
| Remedial action | Key revoked [date] 17:05 UTC; backup bucket access restricted; repository secret scanning enabled; other keys rotated |
| Authority notified | Yes, [supervisory authority], [date] 11:00 UTC (within 72 hours), reference [number]; further information provided [date] under Article 33(4) |
| Individuals informed | Yes, email [date] with phishing guidance. See the Customer Breach Notification Letter Template |
7.3 Notice that the non-notifiable entry is short but complete: it states the facts, effects and remedial action, and gives a reason a regulator can test.
7.4 Processor section: where [Organisation] is processor, record the controller notified, the date and time of notice, the information supplied and any follow-up requested.
8. Retention, access and review
- Entries must be retained for [at least five years] after closure, or longer where litigation, regulatory investigation or contractual terms require. Record the retention basis in the [Data Retention Policy].
- Access is limited to [DPO, privacy team, CISO and named incident leads]. Changes must be logged, with the author and date of each update.
- Personal data in the register is minimised: describe affected individuals by category and number, not by name, unless a name is needed to manage the breach.
- The [DPO] must review open entries [weekly] and report breach volumes, causes and notification outcomes to [the security governance committee or board] each quarter.
- The register must be made available to the supervisory authority on request.
9. Compliance
9.1 Failure to document breaches is itself an infringement. On 17 December 2024 the Irish Data Protection Commission fined Meta EUR 251 million over a 2018 breach, a figure that included EUR 3 million for infringing Article 33(5) by failing to document the breach adequately, alongside EUR 8 million for infringing Article 33(3). Infringements of Article 33 fall under the Article 83(4) fine tier.
9.2 Staff who fail to report a suspected breach, or who conceal one, are subject to [disciplinary procedure].
Implementation guidance
- Set up the register before you need it. Create the fields in your tool, assign the owner and test that incident responders can open an entry out of hours.
- Connect intake. Add a "personal data involved?" question to every incident ticket so the privacy team is alerted automatically. Many breach entries start as tickets that nobody flagged.
- Agree the awareness rule. Write down who can declare awareness and how it is timestamped, because the 72-hour deadline runs from it.
- Back-fill the last 12 months. Review incident tickets, lost device reports and misdirected email logs for breaches that were never logged, and add them. This is usually where the gaps are.
- Cover processors. Check processor contracts require notice within a fixed period (for example [24 or 48 hours]) with the fields in section 5.
- Measure it. Track: breaches logged per quarter by cause; percentage of entries with a recorded risk rationale; median hours from awareness to decision; percentage of notifications made within 72 hours; repeat causes; open preventive actions past due.
- Test the register in exercises. Include a non-notifiable breach in tabletop exercises and check the entry is completed. See the Tabletop After Action Report Template.
Common failure patterns to avoid: logging only notified breaches; recording "low risk" with no reasoning; using the date the investigation finished instead of the awareness date; one entry per incident when several data sets are affected differently; never updating entries when the facts change; and storing full copies of the breached data in the register itself. Leaked machine credentials are a frequent cause of large breaches, so make "stolen or leaked credential or key" a distinct root cause; see the Breach Notification Laws by Country Guide for obligations outside the GDPR.
Related NHI Mgmt Group resources: Data Breach Notification Checklist · GDPR Compliance Guide for Security Teams · Record of Processing Activities (ROPA) Template · Incident Response Policy Template. This guide summarises GDPR and UK GDPR breach documentation requirements and is not legal advice.