Short answer
The regulation does not speak of a register but of documentation: the controller documents any personal data breach, including the facts relating to it, its effects and the remedial action taken. The quality test is set by the second sentence of Article 33(5) GDPR — the documentation must enable the supervisory authority to verify compliance with that article as a whole. That also covers the finding that the decision not to notify a breach was correct. This is why the entries that call for the most content are those concerning breaches the controller did not notify.
Why the question arises at all
A breach register is often kept as a list of cases sent to the supervisory authority. What results is a document that duplicates knowledge the authority already has. It says nothing about the cases resolved internally — and those are the ones later subject to verification.
The second source of confusion is terminological. Article 33(5) GDPR does not use the word “register” and imposes no form. The President of the Personal Data Protection Office (UODO) states expressly that an internal breach register may help in meeting the obligation. Keeping a separate record is not mandatory, however. What matters is that the information is clearly marked and available for inspection. The obligation is therefore an evidential result, not a table.
The third source is organisational and becomes visible only over time. An entry is usually created on the day the case is closed. It then contains a summary sufficient for the people who worked on it. A year later the same entry is read by someone else, most often for the purposes of proceedings. That is when it turns out that what is missing is not facts but reasons.
It is also worth separating two documents that are confused because their names are similar. The record of processing activities under Article 30 GDPR describes what the organisation processes day to day and why. The breach documentation under Article 33(5) describes events and decisions. These are two different obligations with different evidential functions.
What to establish before deciding
What the regulation requires and what it does not
The regulation requires three things.
- Document any personal data breach.
- Cover the facts relating to the breach, its effects and the remedial action taken.
- Ensure that the documentation enables the supervisory authority to verify compliance with Article 33.
It prescribes no form, no system and no template. Nor does it set a retention period. That latitude is sometimes read as leniency on the part of the regulation. The opposite is true — it is the controller who answers for whether the chosen form can carry the evidential function.
The second sentence settles the matter. Verification covers the whole article, so it reaches paragraph 1 and the ground for not notifying as well. That ground rests on a finding that the breach is unlikely to result in a risk to the rights and freedoms of natural persons. It is precisely that conclusion which is reviewed. An entry without its reasoning gives the authority no material to verify and the controller no basis on which to defend itself.
Which events belong in the documentation
The scope is wider than the practice of most organisations suggests. It falls into three circles.
The first circle is breaches identified and notified to the authority. The second is breaches identified and not notified — the documentation obligation covers them in the same way, because the regulation speaks of any breach. The third circle goes beyond the letter of Article 33(5). The President of UODO recommends documenting also those security incidents which the controller has classified as events that are not personal data breaches. The recommendation covers the reasons for that decision in particular.
That recommendation rests on the accountability principle in Article 5(2) GDPR, not on a separate obligation. It carries practical weight nonetheless. Without it, the organisation cannot show that it considered an event the authority knows about from another source.
What a single entry has to contain
The table below combines the elements listed in the regulation with the scope indicated in the guidance of the President of UODO. The third column shows what a given element is for. That is what settles how detailed the record needs to be.
| Element of the entry | Where the requirement comes from | What it is for |
|---|---|---|
| The facts: date and time of occurrence, of becoming aware and of closure; how it was detected; cause and course | Article 33(5) GDPR, UODO guidance | Establishing the moment of becoming aware, from which the notification deadline runs |
| Type and scope of the data, number and categories of data subjects | Article 33(3)(a), UODO guidance | The basis for assessing the severity of the potential impact |
| The effects and the possible effects for data subjects | Article 33(5) GDPR | Telling an effect that materialised from one that is merely possible |
| The reasoning behind the risk assessment | UODO guidance, the accountability principle | The element the authority verifies first |
| Remedial and preventive action | Article 33(5) GDPR | Showing the response and its effect on the risk of recurrence |
| Details of the notification or the reasons for the decision not to notify | Article 33(1), UODO guidance | Verifying the ground for not notifying |
| Details of the communication to data subjects or the reasons for the decision not to communicate | Article 34(3), UODO guidance | Showing which of the three exceptions applied |
The two rows in bold are what separates useful documentation from a list of events. The rest describes what happened. These two describe why the organisation acted as it did.
The reasoning behind a risk assessment is worth recording as reasoning, not as a result. The entry “risk low” says nothing about what the controller took into account. What can be checked is a record setting out the categories of data, the safeguards applied and the likelihood of harm that follows from them. It works even where the authority assesses the case differently.
The template below shows the shape of such a record. It does not describe an actual case; it is a skeleton to be filled in with the organisation’s own data.
The breach covered the first name, surname and e-mail address of [number] data subjects. The data reached a single known external recipient as a result of an addressing error. The recipient confirmed deletion of the message; the confirmation has been retained in the case file. No identifiers enabling impersonation and no special categories of personal data were involved. The likelihood of further dissemination was assessed as low — there is one recipient, that recipient is known and deletion has been confirmed. The severity of the potential impact is limited by the scope of the data, which is contact data.
That record can be checked. It sets out the scope of the data, the circumstance that limits the risk and the conclusion which follows from them. The formula “low risk, case closed” contains none of those three elements.
How the documentation changes over time
An entry is not closed once and for all. Information about a breach arrives in stages, and each new piece may change the risk assessment and the soundness of the earlier decision. The documentation is meant to mirror that and to keep a trace of the change, not only the final state.
This has a direct procedural consequence. A breach assessed at first as not requiring notification may require it once the full scope of the data is established. The moment the decision was taken can then be explained only by documentation showing when the controller learned of the new circumstance.
How long to keep it and what not to put in it
The GDPR gives no period after which information about breaches may be erased. The President of UODO therefore recommends keeping it for as long as possible. A second, less obvious recommendation follows from the first. An internal register is neither required nor recommended to contain personal data — neither of the people affected by the breach nor of those involved in handling the case.
This is the position broken most often in practice. Registers kept in spreadsheets usually contain the names of the people affected and of the authors of the entries. The result is a set of data kept indefinitely, for which a separate legal basis and retention period have to be established. The answer is to separate the layers: the register works with a case identifier and aggregated data, while material containing personal data sits in the case file with its own retention period.
Where personal data does end up in the record after all, the minimisation principle applies to it on ordinary terms.
Who keeps the documentation where processing is entrusted
The obligation under Article 33(5) GDPR is addressed to the controller. The processor notifies the controller of a breach without undue delay and assists the controller in meeting the obligations under Articles 32 to 36, which includes documentation.
The practical conclusion concerns the contract, not the regulation. The controller documents the facts of an event that took place in someone else’s infrastructure. It therefore needs a contractual route to data on the time of detection, the scope and the course of events. A processing agreement providing for notification alone, with no scope for the information to be passed on, leaves the controller with an entry it cannot justify.
Common mistakes
- A register covering notified breaches only. The obligation covers any breach. Entries on cases that were not notified are the ones actually subject to verification.
- A risk assessment recorded as a result. “Low risk” is not a justification. What can be verified is the line of reasoning, not its conclusion.
- Confusing breach documentation with the record of processing activities. These are two separate obligations with different subject matter — Article 30 describes processing, Article 33(5) describes events and decisions.
- Keeping personal data in the register indefinitely. The recommendation to keep things for a long time concerns information about breaches, not data about people. Those two layers have to be separated when the record is designed.
- No trace of events classified as non-breaches. A decision that an event is not a personal data breach calls for a record together with its reason.
- An entry closed on the day of the event. The documentation is meant to be updated, because new information may change the risk assessment and force a notification after a deadline first treated as not running.
Conclusions and next steps
Breach documentation is evidence of a decision-making process, not a record of events. That single premise settles what it contains: an entry has to reconstruct what the organisation knew at a given moment and what conclusion it drew from that. Cases notified to the authority take the least work in this arrangement, because their justification already sits in the notification.
An order of work that proves itself where a register already exists.
- Check whether the record holds entries on breaches that were not notified; their absence means the register does not perform the function under Article 33(5).
- Review the entries for the reasoning behind the risk assessment and complete those that give the result alone.
- Separate the register layer from the case file and remove from the register any personal data that is not needed there.
- Establish where information about breaches at processors comes from and whether the contracts secure it.
- Introduce a rule of updating the entry as information arrives, keeping a trace of the changes.
Documentation in good order also yields material available from no other source: the recurrence of mistakes of the same type. That is the right starting point for designing training matched to roles and processes. It points to the processes in which events actually arise.
Related materials
- Does every data breach need to be reported? — the notification threshold and the risk assessment whose outcome the register preserves.
- What to do after detecting an incident? — the sequence of actions that produces the entry.
- Cybersecurity incident vs personal data breach: what is the difference? — classifying the event before the entry is made.
Sources
- Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR), Article 5(2), Article 24(1), Article 28(3)(f), Article 30, Article 33 and Article 34, consolidated text — EUR-Lex: eur-lex.europa.eu (accessed 19 August 2026)
- President of the Personal Data Protection Office (UODO), “Obligations of controllers relating to personal data breaches”, version of 20 February 2025, chapter 8 — uodo.gov.pl (in Polish, accessed 19 August 2026)
- European Data Protection Board, Guidelines 01/2021 on examples regarding personal data breach notification, version 2.0 adopted on 14 December 2021 — edpb.europa.eu (accessed 19 August 2026)
Check whether your register will defend your decisions
The worth of a register shows only when a decision taken a year ago has to be explained. Putting the assessment of incidents and breaches in order covers a review of the existing entries and settles the scope the organisation is actually able to demonstrate.
This material is general and educational. It is not individual legal advice or a recommendation for any specific organisation. The scope of obligations should be assessed in the light of that organisation’s circumstances.
Legal status: August 2026.