Article 33(5) breach records: requirements and evidence

What Article 33(5) asks for: a record of every breach, notifiable or not

Article 33(5) requires the controller to document every personal data breach, whether or not it is notifiable to the supervisory authority. The record must cover the facts relating to the breach, its effects and the remedial action taken. The purpose is practical: the supervisory authority cannot verify that you complied with Article 33 unless you can show what happened, what you judged, and what you did about it. A breach you decided not to notify still needs a record, and that record is often the document a regulator asks for first.

The risk this addresses is an unverifiable decision. If a regulator reviews a breach you did not report, the absence of any record leaves you unable to show that you assessed the risk, considered the 72-hour clock and acted on the cause. EDPB Guidelines 9/2022 encourage an internal breach register and say records should capture the causes, what happened, the personal data affected, the effects and the remedial action. The guidelines also note that the GDPR sets no retention period for this documentation, so your retention rule is a decision you must make and justify. A separate register is not required if breach information in your Article 30 record is clearly identifiable and can be extracted on request.

What makes this hard is that breaches are often closed informally. A help desk ticket is marked resolved, a chat thread concludes that nothing left the building, or an engineer emails a colleague the root cause, and no one writes down why the decision was made. Facts end up scattered across ticketing tools, chat, email and logs, and the reasoning is lost. Before you build a register, confirm three things with your privacy and security leads: who opens an entry for every suspected breach, who signs off the notifiable decision, and where the register lives and who can edit it. Then test one closed incident by asking whether someone outside the team could reconstruct it from the record alone.

Which breaches, systems and teams the breach register must cover

Article 33(5) applies to every personal data breach, so the register's scope is set by what counts as a breach and where it can surface, not by whether a notification is due. The cards below cover the scoping decisions that determine how much work the register creates and who has to feed it.

Every breach, notifiable or not

The register must hold each confirmed or suspected personal data breach, including those judged low risk or not notifiable to the supervisory authority. EDPB Guidelines 9/2022 say every breach must be documented whether or not it is notifiable. Check that the intake process records the decision not to notify, with the reasons, so a later reviewer can see the judgment was made and why. Illustrative: a misdirected email to one wrong recipient, closed after recall, still gets an entry.

Breaches where you act as processor

When your organization processes personal data for a customer, breaches in that processing still belong in your register for your own obligations where they apply. The controller carries the notification duty, so your record should capture what you told the controller, when you told them, and what they asked for. Confirm with each customer contract how notice times and content are defined, and keep the processor entries separable from your own controller breaches.

Systems and log sources that reveal breaches

A register is only as complete as the signals feeding it. Map the systems that can show personal data was accessed, altered, lost or disclosed, such as identity providers, database audit logs, file shares, email gateways, backup consoles and SaaS admin logs. Triage alerts from SIEM and EDR into cases so each breach has one record. Confirm that log retention covers the period an investigation may need to reconstruct.

Teams that feed the register

The security operations centre, IT operations, the DPO, legal, and customer success teams all receive signals that may become breaches. Define who opens an entry, who must add facts within a set time, and who signs off the risk judgment. Include helpdesk and sales staff who hear reports of misdirected data. Document the handoffs so no team holds a suspected breach without a register entry.

Sub-processors and third-party reports

Breaches often start at a sub-processor, hosting provider, managed service or support vendor. Contracts should require those parties to report to you without undue delay, and your register should record the third-party notice, its date and the facts they supplied. Ask each vendor for its incident contact and the content it will provide. A vendor report that arrives late should still be logged with the time you became aware.

Records held outside the incident tool

The EDPB notes that a separate register is not required if breach information in the Article 30 record is clearly identifiable and can be extracted on request. Decide whether your incident tool or the record of processing is the register, and test whether an extract can be produced quickly. Confirm the decision with your DPO and document it, because a register split across ticket queues, chat logs and email threads is hard to show to an authority.

How to build a breach register that passes verification

This sequence turns scattered incident tickets into one internal register that records every personal data breach with the facts, effects and remedial action an authority would need to check compliance with Article 33. Each step adds a field, a control or a review so the register stays complete and verifiable over time.

Define the register fields
Agree the fields the register must hold before any incident is logged: the facts and timeline, the causes, the categories of personal data and data subjects affected, the likely effects, the notification decision with the reasons for it, the remedial action taken, a named owner, and the key dates. Write each field as a question the register must answer, so an entry can be checked without asking the incident team what they meant. The output is a signed field specification that the privacy lead and security lead both accept.
Set the intake trigger for every ticket
Configure the incident process so that every ticket that might involve personal data creates a register entry, including incidents later judged to be non-notifiable and near misses that turned out to involve no data loss. The trigger should fire at ticket creation, not at the point someone decides the incident is serious, because EDPB Guidelines 9/2022 expect every breach to be documented whether or not it is notifiable. The output is a documented rule and a ticket category that feeds the register automatically.
Assign an owner and a privacy review
Name one accountable owner for each register entry, usually the incident commander or a privacy lead in the security team, and require a second review by the DPO or privacy lead before an entry is closed. The reviewer checks that the notification decision follows from the recorded facts and effects, and that the reasons are written down. Where the organization has no DPO, the reviewer should be a named privacy lead with documented independence from the incident response decision. The output is a review record on every closed entry.
Link each entry to its evidence
Attach or reference the evidence behind each entry, including log extracts, forensic notes, containment records, communications to the supervisory authority and to affected individuals, and any processor notices received under Article 33(2). Store the references in the register rather than copying the evidence, and record the hash or location of material that must remain unchanged. The output is an entry where every stated fact can be traced to a source a verifier can open. Case management tools such as DFIR-IRIS can hold these links, though the organization should confirm the features it needs in its own environment.
Record the notification decision and its reasons
For each entry, record whether the breach was notified, not notified, or partly notified, and state the reasons in plain language tied to the risk assessment and the facts. Where a notice was sent late, record the reasons for the delay alongside the notice. The EDPB guidelines stress that the documentation must allow the supervisory authority to verify compliance with Article 33, so an entry that says only that the breach was not notifiable will not meet that test. The output is a decision record that a verifier can read without the original incident team.
Run a periodic gap review
Schedule a recurring review of the register that compares it against the ticket queue, the processor notices, and the notification records to find incidents that were never logged or entries that were closed without a decision or remedial action. Record the findings, assign corrective actions, and keep the review record itself as evidence. The GDPR sets no retention period for breach documentation, so the organization should set and document its own schedule and confirm it with its legal or DPO function. The output is a signed review record that shows gaps were found, tracked and closed.

How an assessor tests the breach register

This table sets out how a supervisory authority or assessor would test the internal breach register, what they would ask to see, and the findings that most often lead to questions. Read each row as a test the register must pass, with the evidence that lets the organization answer it quickly.

Test area	Test approach and evidence requested	Common findings
Completeness	Sample incident and helpdesk tickets over a period, then check that each security incident involving personal data has a register entry, including incidents judged not notifiable. Ask for the full register export and the ticket reference for each entry.	Only notifiable breaches are logged, or minor incidents exist in tickets but never reached the register.
Accuracy of facts and effects	Compare register entries against the incident timeline, forensic notes and logs. Check that the categories of data, number of data subjects, and described consequences match what the evidence shows, and that later corrections are dated.	Entries were written once at first detection and never updated, so scope in the register contradicts the final investigation.
Documented reasoning for notify or no-notify	For each entry, ask for the risk assessment that supports the decision, who approved it, and when. Look for the reasons behind the decision, not only the outcome.	Decisions recorded as a single word with no reasoning, or the reasoning post-dates the decision by weeks.
Remedial action tracked to closure	Trace each recorded action to a change ticket, configuration record or training record, and confirm it was completed. Check that open actions have owners and due dates.	Actions listed as planned with no evidence of completion, or fixes that cannot be linked to the incident.
Retrieval speed on request	Ask the organization to produce all entries for a given period, or a specific entry with its supporting files, within a short working window agreed in advance. Test whether the register can be filtered by date, system, data category and decision.	Entries are spread across mailboxes and shared drives, so the response takes days and some records cannot be found.
Retention	Ask what the retention rule is, who approved it, and how records are protected from deletion or alteration during that period. Confirm the rule matches legal and internal policy, since the GDPR sets no fixed period for breach documentation.	No retention rule exists, records are deleted with ticket cleanup, or the register cannot show when an entry was last changed.

Which breach records satisfy Article 33(5) and how to keep them current

Article 33(5) is verified from records, not from memory. The cards below cover the artifacts an assessor or supervisory authority is likely to ask for, from the register itself down to the proof that remedial action was closed. Each artifact should link to the others so one breach can be traced end to end.

Breach register export

The register is the index of every personal data breach, notifiable or not. Each row should carry the facts of the breach, the personal data and data subjects affected, the causes, the effects, the remedial action and the decision reference. Check that the export can be produced on request in a readable form and that every row has an owner and a date of discovery. A register that only exists as scattered tickets will fail the verification test in practice, even if each ticket is complete.

Individual breach records with timelines

Each breach needs its own record that reconstructs what happened and when. Record the time the controller became aware, the time detection tools first flagged the event, and the times of containment and recovery. A consolidated timeline built from alerts, logs and analyst notes lets the organization show how facts emerged. Where the timeline is incomplete, the record should say so and state what is still being investigated.

Documented risk and notify decision

For every entry, keep a written decision that records whether the breach was likely to result in a risk to individuals, whether it was notified to the supervisory authority and whether individuals were told. Record the reasoning, the people who approved the decision and the date. A breach judged not notifiable still needs this record, because the decision itself is what the authority will test. Ask the legal and privacy owner to sign off on the wording before it becomes evidence.

Remedial action tickets with closure proof

Each corrective step, such as revoking credentials, patching a system, restoring data or retraining staff, should exist as a tracked ticket with an owner, a due date and a closure note. Closure proof means the change record, configuration output or test result that shows the action was completed. Tickets closed without evidence leave the register describing intentions rather than effects, so review closed tickets before the register is exported.

Links to notifications and communications sent

Where a notification to the supervisory authority or a communication to affected individuals was made, store a copy of the submitted content, the submission reference, the date and time and the recipients. Link each copy to its breach record so the timeline and the notification can be compared. Where a notification was phased, keep each phase as a separate dated item. Confirm with your supervisory authority which submission channel and reference format it uses.

Register review log and self-hosted tooling

A register review log records who checked the register, when, and what changed, so the record stays current after the breach is closed. Self-hosted tools can hold much of this. DFIR-IRIS (LGPL-3.0-or-later) keeps each case as one record of assets, IOCs, tasks and evidence with a full audit trail, builds a consolidated investigation timeline and generates reports from case data. CISO Assistant (AGPL-3.0-only) tracks compliance assessments against GDPR among its frameworks. Confirm with your own process whether these tools fit how your organization handles breach records, and whether retention and access rules can be applied to them.

How long to keep breach records when the GDPR sets no period

The GDPR does not set a retention period for breach documentation, so the organization must set its own rule and be able to defend it if the supervisory authority asks how it verifies compliance with Article 33. EDPB Guidelines 9/2022 add that a separate breach register is not required if the breach information held in the Article 30 record of processing is clearly identifiable and can be extracted on request. The practical decision is therefore whether breach entries live in the existing record of processing or in a dedicated register, and the choice should be made with the DPO before the first breach is logged. Whichever option is chosen, the register must hold the causes, the personal data affected, the effects and the remedial action for every incident, notifiable or not, and the organization should test that it can produce a complete extract for a single incident within a short, defined time.

Retention should follow the organization's existing record retention schedule, so that breach entries are kept as long as the supporting material they reference, such as incident tickets, forensic reports and correspondence with the authority. Ask the DPO and counsel to confirm the period in writing, and check whether any sector rule adds a longer minimum for security incident or operational records. Where the organization operates in regulated sectors, its incident records may also fall under obligations such as those in DORA or NIS2, and those obligations can set a different minimum. Document the rule in the retention schedule with a named owner, and configure the system holding the register so that disposal happens only through that owner's approval.

Retention clocks should stop when they would otherwise expire during a legal hold or an open investigation. A breach that is still under investigation, subject to a regulator inquiry, or involved in litigation or a claim should be flagged so the scheduled deletion is suspended until the matter closes, and the flag should be reviewed on a fixed cycle. Backups and log stores that hold copies of breach evidence need the same treatment, otherwise the register may be retained while its underlying evidence is deleted. Ask your implementation partner and your DPO to confirm how the chosen platform handles holds and deletion before you rely on it, because the feature set differs between tools.

What the breach register costs in money and effort

This table compares the cost components of an Article 33(5) breach register, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to shape a written scope and to ask each provider for the same line items. No figures are given because fees follow from the scope you agree.

Cost component	One-time or recurring	What drives it and how to reduce it
Register design and template	One-time	Driven by how many incident types, systems and business units feed the register. Reduce it by reusing the fields EDPB Guidelines 9/2022 list (causes, facts, data affected, effects, remedial action).
Tooling or licenses	Recurring	Open-source tools remove license spend, but hosting, patching, backups and administration remain. Ask whether the quote covers installation, upgrades and access control for the register.
Intake integration with the incident process	One-time	Driven by how many ticketing, SIEM or case tools must hand off to the register. Reduce it by defining one mandatory intake step in the existing incident workflow.
Ongoing entry and review by incident and privacy teams	Recurring	Driven by alert volume and how many minor incidents are logged. Reduce it with clear entry criteria, pre-filled fields and a fixed review slot per month.
Evidence upkeep and periodic review	Recurring	Driven by how often the register is checked against incident records and retention rules. Ask what the provider will verify, how often, and who signs off.
External review by a DPO or consultant	Optional, recurring or per review	Driven by the scope of each review and whether the reviewer must be independent of the team. Ask for a fixed-scope review with stated deliverables and a named reviewer, and note that an external review does not replace the controller's own responsibility.

Who runs the breach register: your team, a partner and the auditor

Your organization is the controller, so it owns the breach register and every entry in it. Article 33(5) places the documentation duty on the controller, which means the people accountable for the register are internal: the security lead who logs incidents, the incident commander who records facts as they emerge, and the DPO or privacy lead who reviews the reasoning behind each decision. The register must record the facts of each breach, its effects and the remedial action taken, whether or not the breach was notified. Internal staff also decide whether a breach is notifiable and whether a notification was made, and they own the remedial actions and their follow-up.

Register owner: a named role accountable for completeness, consistency and access to the record.
Decision record: the reasons for notifying or not notifying, written at the time of the decision.
Remedial actions: the fixes, owners and due dates, tracked until closed.
DPO or privacy review: documented sign-off on the risk assessment behind each decision.
Retention decisions: the period you keep entries, set by policy because the EDPB guidelines note the GDPR sets no retention period for breach documentation.

Confirm internally who holds each role and whether the register sits inside your Article 30 record or as a separate log.

Where breach registers fall short in review and how to close each gap

Breach registers usually fail review for reasons that have little to do with the incidents themselves. The gaps below recur in Article 33(5) documentation, and each one undermines the supervisory authority's ability to verify compliance with Article 33. Each card names the gap and gives one closing action.

Non-notified breaches never recorded

Teams often log only the breaches they reported to a supervisory authority, so the register looks clean while minor incidents disappear. Article 33(5) applies to every personal data breach, whether or not it was notifiable. EDPB Guidelines 9/2022 say each breach must be documented on that basis. Close it by making the register entry mandatory at triage, before any risk decision is made. Illustrative check: a misdirected email with no risk to individuals still needs an entry.

Decisions recorded without reasons

A register that says a breach was not notifiable, with no explanation, gives the authority nothing to verify. Reviewers look for the facts and reasoning behind the risk assessment and the choice to notify or not. Without that reasoning, a later inquiry cannot tell whether the controller acted reasonably. Close it by requiring a short written rationale for every notify or do-not-notify decision, signed by the person who made it.

Facts changed after closure without history

Breach facts often change as forensics continues: the number of affected individuals rises, or the data categories turn out to be broader than first thought. If the register overwrites earlier entries, the record no longer shows what the controller knew at each point. Close it by keeping version history with dated entries, so each change shows what was known and when. Confirm your tool keeps an audit trail of edits before you rely on it.

Remedial actions without closure evidence

Many registers list the remedial action planned but never record that it was completed or that it worked. Article 33(5) asks for the remedial action taken, so a plan alone does not show compliance. Reviewers expect a link from each action to evidence such as a patch record, a revoked credential or a retrained process. Close it by assigning an owner and a closure check to every action, with the evidence reference stored in the entry.

Records scattered across tickets

When breach details sit in helpdesk tickets, chat threads, email and forensic folders, no one can produce the complete picture on request. A single register with one identifier per breach lets the controller answer an authority's questions from one source. EDPB guidance also accepts breach information held in the Article 30 record if it is clearly identifiable and can be extracted. Close it by naming one system of record and linking every related ticket and evidence item to that breach identifier.

Retention rules deleting open cases

Automatic deletion schedules can remove breach entries while an investigation or an authority inquiry is still open. The GDPR sets no retention period for breach documentation, so the controller must choose and justify one. A deletion job that runs on creation date, without checking case status, can destroy the only record of a breach. Close it by setting the retention rule to start at case closure and blocking deletion while any investigation or inquiry is open.

Questions buyers ask about the breach register before hiring help

Does a breach that we do not notify still have to be recorded?

Yes. Article 33(5) requires the controller to document every personal data breach, whether or not it is notifiable to the supervisory authority. The record must capture the facts of the breach, its effects and the remedial action taken, so that the authority can verify that you assessed the incident and complied with Article 33. EDPB Guidelines 9/2022 say the same and encourage an internal breach register. A decision not to notify is itself something you must be able to justify later, so the record should show the risk assessment behind that decision.

How much effort does running a breach register take?

The effort is mostly recurring and scales with how many incidents you log and how well your detection and ticketing tools already capture the facts. Most of the work is writing a short, consistent entry for each incident and keeping it updated as the investigation develops. Ask any partner to estimate the effort from your incident volume and your current tooling, and to show that estimate in the written scope. No reliable duration can be stated without knowing those inputs.

What drives the cost of setting up a breach register?

Cost has two parts: one-time setup and recurring operation. Setup covers defining the register fields, linking it to incident response, and testing that it can be produced for an authority. Recurring cost covers keeping entries complete, reviewing them and retaining the records. The main cost drivers are the number of systems in scope, how many incidents you expect to log, whether the register is built on existing tools, and how much of the work your internal team can absorb. When requesting a quote, ask for each component to be priced separately and for the deliverables to be listed in writing.

How long should we keep breach records, and why does the GDPR not say?

The GDPR does not set a retention period for breach documentation. EDPB Guidelines 9/2022 note this gap. Because the authority can ask to verify compliance at any time after an incident, most organizations set a period in their own retention schedule and align it with their legal counsel's view of limitation periods and any sector rules that apply. Confirm the period with your data protection officer or legal team, document the reasoning, and make sure deletion is applied consistently to breach records that also contain personal data.

Can we skip a separate register if our Article 30 record can be extracted?

Possibly. The EDPB guidelines state that a separate register is not required if breach information kept in the Article 30 record of processing is clearly identifiable and can be extracted on request. The test is practical: can you produce, quickly and completely, every breach with the facts, effects and remedial action in a form the authority can read? If the answer depends on manual searching across documents, a dedicated register is the safer choice. Test the extraction before relying on it.

Can self-hosted open-source tools hold our breach records?

They can hold the records, but they do not decide what must be recorded. DFIR-IRIS, under LGPL-3.0-or-later, keeps each case as one record of assets, indicators, tasks and evidence with an audit trail, and can build an investigation timeline and generate reports from case data. It can serve as the working record for an incident. CISO Assistant, under AGPL-3.0-only, supports GDPR as one of its frameworks and can track compliance assessments. Confirm each tool's fit against your required fields in your own environment, because the register must cover the Article 33(5) content, not only what the tool stores by default.

What does the work need from our internal team?

Your team owns the facts. Someone must make sure each incident is logged when it is detected, that the affected personal data, causes and remedial actions are recorded accurately, and that the risk assessment behind any non-notification decision is written down and approved. Your data protection officer or privacy lead typically reviews entries, and your security team supplies technical evidence such as logs and timelines. Ask any implementation partner to list these roles in the written scope so responsibilities are clear before work starts.

Can a consultant or partner issue a compliance certificate for our breach register?

No. Under the GDPR, no audit, attestation or certificate is required, and only independent auditors, assessors or certification bodies issue reports or certificates. An implementation partner, including DeployOpen, can plan, configure and document the register and prepare the evidence. It cannot issue an audit report or certificate. Certification under Article 42 is voluntary, is issued by accredited bodies or supervisory authorities, and does not reduce your responsibility for compliance.

How DeployOpen builds and evidences a breach register

DeployOpen prepares the breach register as a working system inside your own infrastructure, so every incident is recorded with its facts, effects and remedial action. Your organization owns the register and decides what counts as a breach, and we set up the tooling, workflow and records that let your supervisory authority verify your compliance.

How we scope

We agree in writing which systems, teams and incident sources feed the breach register before work starts.
The written scope names who maintains each register entry, who approves it and who holds the Article 30 records it may draw on.
Engagements are fixed-scope, and ongoing support for register upkeep is available as a retainer.

How we build

We deploy a self-hosted case platform such as DFIR-IRIS so each incident is one record with facts, affected data, causes and actions.
We configure fields for personal data categories, effects on individuals and remedial steps so entries follow the EDPB Guidelines 9/2022 content list.
We test that a register entry can be extracted and filtered for an authority request within a timeframe your team confirms in advance.

How we hand over

We deliver written procedures explaining when an event becomes a register entry, including events that are judged not notifiable.
We provide the configuration, access model and a walkthrough so your staff can add, amend and close entries without us.
We document the retention period your organization sets, since the GDPR does not fix one for breach documentation, and confirm it with counsel.

How we support

We can review register entries after each incident to check that causes, effects and remedial actions are complete and consistent.
We help prepare evidence packs that show how the register supports the Article 33 compliance your authority may ask about.
Upgrades, backups and documentation of the platform can be covered under a retainer, with scope agreed in advance.