Skip to main content
Digital Compliance Bureau
Promotional banner for the pentest readiness checklist
Category: Incident & Breach Response

Data Breach Register

Also known as: Data Breach Documentation, Breach Record, Personal Data Breach Record
Simply put

A data breach register is an internal record in which an organization documents the data breaches it experiences, including details about what happened and how it responded. It serves as a log that helps organizations track incidents and demonstrate that they have met their obligations to record and, where required, report breaches. The specific contents and legal requirement to maintain such a register depend on the jurisdiction and the type of data involved.

Formal definition

A data breach register (also described as data breach documentation) is a maintained record in which an organization documents personal data breaches, where a personal data breach is generally understood as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Under the UK and EU data protection frameworks referenced in the evidence, controllers are generally required to document all such breaches by adding relevant information to this record, irrespective of whether the breach itself must be notified to a supervisory authority; the register supports the accountability principle by enabling authorities such as the ICO or EDPB-aligned supervisory bodies to verify compliance. The precise scope, required fields, and retention expectations are not fully specified in the evidence provided and differ across jurisdictions and sectors (for example, the U.S. HHS/OCR regime for protected health information and FTC breach-response guidance operate under distinct legal bases from the UK/EU personal data regime). Readers should verify current requirements against the applicable authoritative source, as these obligations are jurisdiction-specific and subject to amendment.

Why it matters

A data breach register is a cornerstone of the accountability principle in data protection compliance. Under the UK and EU frameworks, controllers are generally required to document personal data breaches regardless of whether a given breach must be notified to a supervisory authority. This distinction matters: the duty to record is broader than the duty to report. An organization may correctly conclude that a particular incident does not meet the threshold for notification, but it is still expected to log the incident, its effects, and the remedial action taken. The register is the evidence that this assessment happened and was reasoned.

The register also serves an evidentiary function during regulatory scrutiny. It enables authorities such as the UK's Information Commissioner's Office (ICO) or EDPB-aligned supervisory bodies to verify that an organization has met its recording and, where applicable, reporting obligations. Without a maintained record, an organization may find it difficult to demonstrate compliance even where its underlying handling of an incident was sound. In practice, the absence or inadequacy of breach documentation can itself become a point of regulatory concern, separate from the breach that triggered it.

It is important not to treat the register as a single universal obligation. The requirement to maintain such a record, and its precise contents, depend on the jurisdiction and the category of data involved. The U.S. regime for protected health information administered by HHS/OCR, and the FTC's breach-response guidance for businesses, operate under distinct legal bases from the UK/EU personal data regime. Organizations operating across territories should not assume that a register designed for one framework satisfies the obligations of another, and should verify current requirements against the applicable authoritative source.

Who it's relevant to

Data Protection Officers and Privacy Teams
Those responsible for compliance under the UK and EU frameworks rely on the register to document all personal data breaches and to demonstrate adherence to the accountability principle. This includes recording incidents that do not meet the threshold for notification to a supervisory authority, since the duty to document is generally broader than the duty to report.
Controllers Subject to UK/EU Data Protection Law
Controllers are generally required to maintain the record and to add relevant information about each personal data breach. The register supports their ability to show authorities such as the ICO or EDPB-aligned supervisory bodies that recording and reporting obligations have been met. Precise field and retention requirements should be confirmed against current authoritative guidance.
Compliance Officers in Regulated Sectors
Organizations handling specific data categories operate under distinct legal bases. In the United States, breaches of protected health information fall within the HHS/OCR regime, while general business breach response is addressed in FTC guidance. Compliance staff should treat these as separate from the UK/EU personal data regime and align documentation practices with the framework that applies to their data and jurisdiction.
Auditors and Legal Counsel
Those reviewing an organization's compliance posture use the register as evidence of how incidents were assessed, recorded, and remediated. Because obligations are jurisdiction-specific and subject to amendment, counsel and auditors should verify current recording and retention expectations against the applicable authoritative source and apply professional judgment to the specific circumstances.

Inside Data Breach Register

Incident Description
A factual account of each personal data breach, including the nature of the breach, the categories and approximate number of data subjects affected, and the categories and approximate volume of personal data records concerned.
Chronology and Timeline
Key dates and times, typically including when the breach occurred (or the period over which it occurred), when it was discovered, and when any notifications to supervisory authorities or affected individuals were made where applicable.
Cause and Circumstances
The identified or suspected cause of the breach and the circumstances surrounding it, such as whether it resulted from human error, a technical failure, malicious activity, or a third-party incident.
Effects and Consequences
An assessment of the likely or actual consequences of the breach for affected individuals, including potential harms considered when evaluating risk.
Remedial and Mitigating Actions
A record of the measures taken or proposed in response to the breach, including steps to address it and to mitigate its possible adverse effects.
Notification Decisions and Rationale
Documentation of whether the breach was notified to the relevant supervisory authority and/or communicated to affected individuals, and the reasoning behind those decisions—including justification where notification was deemed unnecessary.

Common questions

Answers to the questions practitioners most commonly ask about Data Breach Register.

Is a data breach register the same as notifying the supervisory authority when a breach occurs?
No. These are distinct obligations that should not be conflated. Under the GDPR, the internal record of breaches (often called a breach register or breach log) is a separate documentation duty from the obligation to notify the competent supervisory authority, and from the obligation to communicate to affected data subjects. The register must generally document all personal data breaches, including those that are not reportable, whereas notification to the authority is generally required only where a breach meets the applicable risk threshold. Maintaining the register does not by itself satisfy any notification requirement, and notifying an authority does not remove the need to record the breach internally. Verify the precise scope and thresholds against the current official text of the applicable regulation.
Does a breach only need to be entered in the register if it was serious enough to report?
Not generally. A common misconception is that only reportable or high-risk breaches belong in the register. Under the GDPR's accountability approach, the documentation obligation typically extends to all personal data breaches regardless of whether they cross the threshold for notifying the supervisory authority or informing individuals. Breaches assessed as unlikely to result in risk should still be recorded, together with the reasoning behind that assessment, so the organization can demonstrate its decision-making. This entry describes the GDPR context; documentation expectations differ in other jurisdictions and sectors, and readers should confirm the requirements applicable to their circumstances against the relevant authoritative source.
What information should each entry in a data breach register generally contain?
As an informational matter, entries commonly capture the facts of the breach, its effects, and the remedial action taken. In practice this may include the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, the mitigating measures taken or proposed, and the reasoning behind any risk assessment and notification decision. The aim is generally to allow the organization to demonstrate how it evaluated and responded to each incident. Specific field requirements can vary by jurisdiction and by internal policy, so the exact contents should be aligned with the applicable regulatory text and professional judgment rather than treated as fixed.
Who within an organization is typically responsible for maintaining the register?
Responsibility varies by organizational structure and is a matter of internal governance rather than a prescribed role in most cases. In many organizations the data protection officer, where one is appointed, oversees or has visibility of the register, but accountability for the underlying obligation generally rests with the controller. Some organizations assign day-to-day maintenance to security, privacy, or incident response functions while retaining oversight at a compliance or legal level. Where processors are involved, they generally have their own obligations to record and report incidents to the controller. Roles should be defined in internal policy and verified against applicable requirements.
How long should breach register records generally be retained?
This entry does not state a fixed retention period, as authoritative sources may not prescribe a single universal duration and practice can differ by jurisdiction. As a general principle, records should be kept long enough to demonstrate accountability and to support any supervisory review, while remaining consistent with data minimization and the organization's broader retention policies. Because the register itself may contain personal data, retention should be justifiable and time-limited rather than indefinite. Organizations should confirm any applicable retention expectations against the current official text and, where necessary, obtain professional advice for their specific situation.
Can the register be maintained in a spreadsheet, or is a dedicated system required?
The format is generally not prescribed. Regulations such as the GDPR typically focus on the substance of what must be documented and the ability to demonstrate accountability, rather than mandating a particular tool. A structured spreadsheet, a database, or a dedicated incident management platform may all be acceptable provided the records are complete, accurate, secure, and available to the supervisory authority on request. The choice often depends on the volume of incidents, the need for access control, and integration with wider incident response processes. Whatever format is used should itself protect any personal data it contains and align with the applicable requirements.

Common misconceptions

A breach register only needs to record breaches that were reported to a regulator.
Under regimes such as the EU and UK GDPR, the internal documentation obligation generally extends to all personal data breaches, including those assessed as unlikely to result in a risk to individuals and therefore not notified externally. The register records the breach and the rationale for any decision not to notify, so that the accountability principle can be demonstrated. Specific obligations vary by jurisdiction and should be verified against the current official text.
Maintaining a data breach register is a voluntary best practice rather than a legal requirement.
Where a regulation such as the GDPR applies, documenting personal data breaches is a binding obligation, not merely a voluntary standard. However, the precise form, retention period, and content requirements are not identical across the EU, the UK, the United States, and other jurisdictions, and some frameworks address it only as good practice. Practitioners should confirm which regime governs their processing.
A data breach register is the same as a broader security incident log.
A data breach register specifically concerns breaches of personal data and the regulatory obligations attached to them, whereas a security incident log may capture a wider range of technical events that do not involve personal data. The two serve related but distinct purposes and should not be conflated, though information may flow between them.

Best practices

Record every personal data breach in the register, including those that are not externally notified, together with the reasoning supporting each notification or non-notification decision, to demonstrate accountability.
Capture the core elements consistently for each entry—facts of the breach, its effects, and the remedial action taken—using a standardized template so records remain comparable and audit-ready.
Log key dates promptly, including discovery and any notification timestamps, since the assessment of breach handling often depends on how quickly the organization responded.
Confirm the specific documentation, content, and retention requirements against the current authoritative text of the regulation governing your processing, as these differ across jurisdictions and are periodically amended.
Restrict access to the register and protect it appropriately, given that it may itself contain sensitive information about affected individuals and organizational vulnerabilities.
Periodically review the register with relevant stakeholders to identify recurring causes and inform improvements, and involve qualified professionals when applying obligations to specific circumstances.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.