GDPR breach register: a template and what goes in it

Why the register exists

Article 33(5) GDPR requires the controller to document every personal data breach: the facts relating to it, its effects and the remedial action taken. The supervisory authority uses that documentation to verify compliance with Article 33. It covers every breach — including the ones judged unlikely to result in a risk to people, which were therefore not notified.

That last part is the point. Notified breaches are on file with the authority anyway. The register is where the controller shows why the others were not notified, and that the decision was taken in time, by someone, for a reason. When an authority investigates a later incident, or a complaint, the register is one of the first things it asks for.

The UK GDPR carries the same requirement, and the ICO expects the same record.

What counts as a breach

A personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data (Art. 4(12)). In practice, three kinds:

• Confidentiality — data seen by someone who should not see it: an email to the wrong recipient, a misconfigured storage bucket, a stolen laptop.
• Integrity — data altered without authority.
• Availability — data lost or inaccessible: ransomware, a deletion without a backup, an outage that makes records unavailable when they are needed.

Most entries in a real register are small: a misdirected email, a lost phone with a locked screen. They still go in the register. Deciding they need no notification is exactly what the register records.

The clock

The deadlines run from the moment the controller becomes aware of the breach, not from when it happened:

• Controller to supervisory authority: without undue delay and, where feasible, not later than 72 hours after becoming aware (Art. 33(1)). A later notification must come with the reasons for the delay.
• Processor to controller: without undue delay after becoming aware (Art. 33(2)). A processor does not notify the authority; it notifies the controller, who decides.
• Controller to the people affected: without undue delay, where the breach is likely to result in a high risk to their rights and freedoms (Art. 34(1)). Not required where an exception in Art. 34(3) applies — for example, the data was encrypted and unintelligible to whoever accessed it, or measures taken afterwards mean the high risk is no longer likely.
• Information in phases: if not everything is known within 72 hours, the notification can be made with what is known and completed later (Art. 33(4)).

"Aware" means having a reasonable degree of certainty that a security incident has compromised personal data. A short investigation to establish that is allowed; it cannot be used to delay the start of the clock.

A client that is also under NIS2 runs a second, separate clock for a significant incident: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month (Art. 23 NIS2), to its NIS2 authority — which is often not the data protection authority. Member states can set their own details. The two reports are made separately, even for the same event.

What to record

One entry per breach. The fields below cover what a notification contains under Article 33(3) and what Article 33(5) requires, so the same entry serves both.

Field	What goes in it
Reference	The client's own number for the breach
Became aware	Date and time; the start of every deadline
How it was discovered	Who noticed, how, and when it happened if known
What happened	Nature of the breach: confidentiality, integrity or availability
Data and people	Categories and approximate number of data subjects and of records concerned
Special categories	Whether health, biometric or other Art. 9 data is involved
Role	Controller or processor for the processing affected
Contact	The DPO or other contact point for the authority
Likely consequences	For the people affected
Measures	Taken or proposed to address the breach and mitigate its effects
Risk assessment	Unlikely, risk, or high risk — and why
Authority notified?	Yes: when, which authority, reference. No: why the risk is unlikely
People notified?	Yes: when and how. No: why not — no high risk, or which Art. 34(3) exception
NIS2 reports	Early warning, notification, final report: date sent, if NIS2 applies
Decided by	Who took each decision, and when
Lessons	What changes as a result
Closed	When the entry was closed

A worked example

A support agent at a client sends a customer's export — name, email address, order history — to the wrong customer by email.

• Became aware: the wrong recipient replies to say so, Tuesday 10:40.
• What happened: unauthorised disclosure; one recipient.
• Data and people: one data subject, one export; no special categories.
• Measures: recipient asked to delete and confirm; confirmation received Tuesday 12:05; the agent's process changed to use the ticket's own address.
• Risk assessment: unlikely to result in a risk: a single recipient, a business customer, confirmed deletion, no financial or sensitive data.
• Authority notified: no — reasoning as above, recorded Tuesday 14:00 by the DPO.
• People notified: no — not a high risk.

Two lines of reasoning, written the same day. That is what the authority wants to see if it ever asks.

Mistakes the register catches

• The clock starting late. "Became aware" is when the client had reasonable certainty — not when the investigation report was finished.
• A No without a reason. A breach that was not notified, with no recorded reasoning, is the weakest position to defend.
• The processor that notified the authority. A processor tells the controller, promptly, and helps; the controller decides.
• Two regimes, one report. A NIS2 significant incident that is also a personal data breach needs both reports, to two authorities, on two clocks.
• Details that are themselves personal data. Record categories and numbers, not copies of the leaked records or screenshots of the data.

Keeping it

The GDPR sets no fixed retention period for the register. Keep it long enough to demonstrate compliance — an authority can look back years — and state the period in the client's retention schedule so it is a decision, not an accident. Many practices keep incident records for several years.

Access to the register should be limited to the people who handle breaches. It describes weaknesses, and sometimes names staff.

Deciding the level of risk

The notification decisions turn on risk, and the register should show how it was assessed. The factors supervisory authorities look at, drawn from the European Data Protection Board's guidelines on breach notification:

• Type of breach: a confidentiality breach where data is published carries different risks from a temporary loss of availability.
• Nature and sensitivity of the data: health data, financial data, identity documents, data about children, and location data raise the stakes.
• Volume: how many people and how many records.
• Ease of identification: whether the data identifies people directly or only with other information.
• Severity of consequences: identity theft, fraud, discrimination, financial loss, damage to reputation, physical harm.
• Special characteristics of the people affected: children, vulnerable adults, employees.
• Special characteristics of the controller: a health provider or a bank handles data where a breach tends to matter more.

Write the assessment in two or three sentences using these factors. "Low risk" without reasons is not an assessment. The outcome is one of three: unlikely to result in a risk (record only), a risk (notify the authority), or a high risk (notify the authority and the people affected).

Revisit the assessment when new facts arrive. A breach first judged unlikely to cause harm can turn out to involve more records, or more sensitive data, than the first hours suggested; the register should show both assessments and when the second changed the decision.

A template to copy

Copy the table above into a spreadsheet, one row per breach, with the field names as columns. Add a column for each deadline — authority, people, NIS2 early warning, notification and final report — with the due time computed from "became aware", and a column for the time each was met. Review open entries at least weekly, and close each one with a date.

In clausebench

The workspace already calculates each regime's notification deadlines by code, per client and per country. A per-client breach register built on those deadlines — the clock running from "became aware", a reminder before each one falls due, and the reasoning required before an entry can say "not notified" — is in design. Until then, the template above is what we recommend.