GDPR breach register template (Article 33(5))

You must keep a record of every personal data breach, including the ones you do not report. Record the facts, the effects and what you did, plus your reasons. Copy the template below.

Article 33(5) of the GDPR says the controller must document any personal data breach: the facts relating to the breach, its effects and the remedial action taken. That record must let the supervisory authority verify that you complied with Article 33 [1][2]. The duty covers every breach, also the ones you decide not to notify [3]. Below is what to record, a template you can copy, and a worked example.

What counts as a breach

The GDPR defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data [2]. So it is wider than hacking. An email sent to the wrong person, a lost laptop, a deleted database without a backup and a ransomware attack can all be breaches. The EDPB adds that data that is temporarily unavailable because of a security incident can also be a breach, while planned maintenance is not [3].

What the law asks you to record

Article 33(5) names three things [1]:

The facts relating to the breach.
Its effects.
The remedial action taken.

Go one step further and record your reasoning for each decision, especially when you decide not to notify, and the reasons for any delay if you notified late. Without the reasoning, an authority cannot verify the decision, and Article 33(1) requires reasons for a late notification anyway [1]. The EDPB guidelines also say you may keep the breach record as part of your Article 30 record of processing activities, but it does not have to be in the same document [3].

A good test: could someone who was not involved read the entry a year later and understand what happened, who was affected, what you decided and why?

Breach register template

Copy this into a document or a spreadsheet. One entry per breach. The fields follow Article 33(3) and 33(5), so the same entry also gives you most of what a notification needs [1].

BREACH REGISTER ENTRY

Reference:               BR-2026-___
Date and time of breach: (when it happened, if known)
Date and time aware:     (when you had reasonable certainty personal data was affected)
Reported internally by:  
Discovered how:          

FACTS
Type of breach:          confidentiality / integrity / availability
What happened:           
Systems or records:      
Categories of people:    (customers, staff, patients, children ...)
Approximate number of people:  
Categories of data:      (contact details, financial, health, ID numbers ...)
Approximate number of records: 
Processor involved:      (name, date they informed you)

EFFECTS
Likely consequences for the people affected:
Risk level:              no likely risk / risk / high risk
Reasoning for risk level:

ACTIONS
Containment steps and dates:
Measures to reduce harm for the people affected:
Measures to prevent a repeat:

DECISIONS
Notify supervisory authority?  yes / no   Reason:
Notified on (date, time, reference):
Notified within 72 hours?      yes / no   Reasons for delay:
Tell the people affected?      yes / no   Reason:
Communicated on (date, channel):

Owner of this entry:     
Last updated:

Worked example

An invented example, to show the level of detail. A web shop's support agent attaches the wrong file to a customer email. The file holds names, email addresses and order histories of 40 customers. The recipient replies within the hour to say they received it and deleted it.

Reference:               BR-2026-007
Date and time of breach: 3 March 2026, 14:05
Date and time aware:     3 March 2026, 14:50 (recipient reply)
Type of breach:          confidentiality
What happened:           Support agent attached export of 40 customer
                         orders to a reply meant for one customer.
Categories of people:    customers
Approximate number:      40
Categories of data:      name, email address, order history (no payment data)
Likely consequences:     Low. Recipient is a known customer, confirmed
                         deletion in writing, no sensitive data.
Risk level:              no likely risk
Reasoning:               Single trusted recipient, written confirmation of
                         deletion, no financial or special category data.
Containment:             14:55 asked recipient to delete; confirmation
                         saved to case file.
Prevent a repeat:        Exports now require a second check before sending.
Notify authority?        no. Breach unlikely to result in a risk.
Tell people affected?    no. No high risk.
Owner:                   Operations lead

Whether a case like this is "unlikely to result in a risk" depends on the facts. The EDPB's book of examples includes several misdirected-mail cases and reaches different answers depending on the data and the recipient [4]. Write down your reasoning either way, because that is what an authority will ask about.

Common mistakes

Only logging notified breaches. Article 33(5) covers all breaches [1]. The small ones are the ones that show whether your process works.
No reasoning. "Low risk" without a reason does not let anyone verify the decision.
Losing the awareness time. The 72-hour deadline runs from when you became aware [1]. If you do not record that moment, you cannot show you met it. See the 72-hour guide.
Keeping the register where everyone can read it. The register describes your weak points and holds details about people. Limit who can open it.
Never updating. Add new facts as you learn them, with dates.

Steps to set it up this week

Pick one place for the register and one owner.
Paste the template above and add an entry for any breach you already know of.
Tell staff and processors who to report a suspected breach to, and how fast. Processors must inform you without undue delay after becoming aware of a breach [1].
Decide who assesses risk and who signs off on notifying. For the people side, see when to notify individuals.
Review the register a few times a year and look for repeats.

Not sure whether a spreadsheet is enough? Read the spreadsheet, tool or consultant comparison.

Related guides

Sources

This guide explains the rules in plain language. It is not legal advice. Check your own country's law and, when in doubt, ask a qualified adviser.