Skip to main content
DataRidge
Category: Breach and Risk Assessment

Breach Register

Also known as: Breaches Register, Breach Log, Personal Data Breach Register
Simply put

A breach register is a documented log an organization keeps to record personal data breaches, including what happened, who was affected, the consequences, and what was done in response. It serves as an internal record so the organization can track incidents and demonstrate that breaches were identified and handled. It is a record-keeping tool and is distinct from any obligation to notify regulators or affected individuals, which is governed separately.

Formal definition

A breach register is an internal, maintained record documenting 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 (ICO, in the UK context). Typical entries capture the nature of each breach, categories and approximate numbers of affected individuals, the likely consequences, and the remedial or mitigating actions taken. The register functions as accountability evidence rather than a compliance guarantee: maintaining one supports an organization's ability to demonstrate breach handling, but it does not itself satisfy any external notification duty. Notification thresholds, timelines, and recipients differ by regime and jurisdiction (for example, sectoral U.S. state breach notification laws and separate regulator-facing obligations under data protection regimes), and this entry does not cover those mechanics, retention periods, or enforcement consequences. The register is an operational and governance artifact and should not be conflated with the broader question of whether a given incident is reportable, which depends on context, applicable law, and a risk assessment.

Why it matters

A breach register is a core accountability artifact. Under data protection regimes that operate on an accountability principle, an organization is generally expected to be able to demonstrate that it identified, assessed, and responded to personal data breaches, not merely to assert that it did so. A maintained register provides that demonstrable evidence: a documented log of what happened, who was affected, the likely consequences, and the remedial actions taken. Without such a record, an organization may struggle to show, after the fact, that a given incident was recognized and handled appropriately.

The register is also an operational tool that helps an organization spot patterns across incidents, track whether remediation was completed, and maintain institutional memory that survives staff turnover. It should not, however, be treated as a substitute for external obligations. Maintaining a register does not itself satisfy any duty to notify a regulator or affected individuals; those notification thresholds, timelines, and recipients are governed separately and differ by regime and jurisdiction. In the United States, breach notification is governed by state-level laws that impose their own disclosure requirements, and in the UK the ICO frames breaches around a specific security-based definition, so what triggers an external notification is a distinct question from what belongs in the internal log.

A common expert-level error is to assume that logging an incident equals compliance, or that every recorded breach is automatically reportable. Whether an incident is reportable depends on context, applicable law, and a risk assessment. The register supports that assessment and preserves evidence of it, but it does not answer the reportability question on its own, and it does not cover retention periods or enforcement consequences.

Who it's relevant to

Data protection officers and privacy leads
Those responsible for demonstrating accountability rely on the register as evidence that breaches were identified, assessed, and acted upon. They should treat it as distinct from the separate, jurisdiction-specific decision about whether and when an incident must be notified to a regulator or affected individuals.
Incident response and security teams
Teams handling security incidents contribute the factual record of what happened and what mitigating actions were taken. Because a personal data breach is defined in terms of a breach of security affecting personal data, security and data protection functions overlap here, but recording an entry in the register does not by itself resolve the separate question of external reportability.
Compliance and information governance teams
These teams use the register to track patterns across incidents and to maintain a defensible record supporting the organization's accountability posture. They should note that a register is an operational artifact and does not, on its own, satisfy notification duties, address retention rules, or determine enforcement outcomes, all of which are governed separately.
Legal counsel
Legal advisors assess whether a logged incident triggers notification obligations, which under U.S. state breach notification laws and under separate regulator-facing obligations in data protection regimes vary by jurisdiction. The register informs that assessment but does not replace the legal analysis of reportability, which depends on context and applicable law.

Inside Breach Register

Incident Identification Details
A reference identifier, description of the incident, and the date and time the breach was discovered or became known to the organisation, distinguishing discovery from the point of occurrence where these differ.
Nature and Categories of Data Affected
A record of the categories of personal data involved and the approximate number of data subjects and records affected, noting where special category or sensitive data may be implicated, as this typically influences the risk assessment.
Risk Assessment and Impact
An assessment of the likely consequences to affected individuals and the level of risk, which generally informs whether notification obligations to a supervisory authority or to data subjects are triggered under the applicable regime.
Remedial and Mitigation Measures
A record of the measures taken or proposed to address the breach and to mitigate its possible adverse effects, supporting the accountability requirement to demonstrate action rather than merely state intent.
Notification Decisions and Rationale
Documentation of whether the breach was notified to a supervisory authority and/or affected individuals, and where it was not, the reasoning supporting that decision, so the outcome is defensible on review.
Roles and Accountability
Identification of the parties involved in handling the incident. Where a data processor detects a breach, it generally must inform the relevant data controller, which typically bears the primary obligation to assess and notify.

Common questions

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

Does logging a breach in the register mean I have to notify the supervisory authority every time?
No. Recording an incident in the breach register is an internal accountability activity and is distinct from the separate question of whether external notification is required. Under the EU GDPR and UK GDPR, notification obligations generally turn on an assessment of the risk to individuals, and not every recorded breach meets the threshold for notifying a supervisory authority or affected data subjects. The register typically documents all personal data breaches, including those you assess as not notifiable, along with the reasoning behind that assessment. Treating every register entry as a trigger for notification conflates documentation with the risk-based decision that notification requirements actually depend on.
Isn't a breach register the same thing as our records of processing activities or our data inventory?
No. A breach register documents personal data breaches and how the organization responded, whereas records of processing activities describe ongoing processing operations, and a data inventory or catalog maps where data resides. These are separate governance artifacts serving different purposes, and maintaining one does not satisfy the others. A breach register is generally an accountability and evidentiary tool for demonstrating how incidents were identified, assessed, and handled, rather than a description of routine processing. Conflating them risks leaving gaps in the specific documentation each is intended to provide.
What information is typically captured for each entry in a breach register?
Entries generally include the facts of the incident, its effects, and the remedial action taken, and in practice organizations often record details such as when and how the breach was discovered, the categories and approximate volume of data and individuals affected, the nature of the compromise, the risk assessment performed, notification decisions and their rationale, and containment or mitigation steps. The specific fields depend on the applicable regime and internal policy. This answer does not prescribe a mandatory schema or field list under any particular instrument; the exact content should be aligned to the obligations that apply to your organization.
Who should be responsible for maintaining the breach register?
Responsibility is typically assigned to a defined role or function, and in many organizations the data protection officer, where one is appointed, has visibility over the register, though the DPO's role is generally advisory and oversight-focused rather than owning the underlying processing. Accountability for the register commonly sits with the controller as part of its overall accountability obligations, and operational upkeep may be delegated to a privacy or information governance team. What matters for accountability is that ownership is clear and that the record can serve as demonstrable evidence, not merely stated intent.
Should near misses or incidents affecting only non-personal data be recorded in the breach register?
This depends on how your organization defines the register's scope. A breach register focused on personal data breaches will generally capture incidents involving personal data, while security incidents affecting non-personal data or near misses may be more appropriately tracked in a broader security incident log. Some organizations choose to record near misses to support trend analysis and continuous improvement, but that is an implementation choice rather than a documentation requirement flowing specifically from personal data breach obligations. Clarifying scope avoids conflating information security incident management with the narrower personal data breach record.
How does the breach register support demonstrable accountability?
The register functions as evidence that the organization identified, assessed, and responded to personal data breaches in a structured way, which supports the accountability principle that generally requires organizations to be able to demonstrate compliance rather than simply assert it. To serve this purpose, entries typically need to be contemporaneous, consistent, and detailed enough to reconstruct the decision-making, including the rationale for notification decisions. The register on its own does not establish that the response was adequate or that notification obligations were correctly met; its evidentiary value depends on the quality and completeness of what is recorded.

Common misconceptions

A breach register is only required to log incidents that were reported to a supervisory authority.
Under regimes such as the EU GDPR, the expectation is generally to document all personal data breaches, including those assessed as not requiring notification, together with the reasoning for that assessment, so the decision not to notify can be demonstrated.
A breach register is the same as, or interchangeable with, the records of processing activities.
They are distinct records serving different purposes. A records of processing activities obligation documents processing operations, while a breach register documents security incidents and the organisation's response; neither is simply a data inventory tool, and maintaining one does not satisfy the other.
If affected data was encrypted or tokenized, the breach does not need to be recorded.
Encryption or tokenization does not make data non-personal, and it does not remove the incident from scope. Such controls may reduce the assessed risk and influence notification decisions, but the incident should still generally be recorded along with the rationale for how those controls affected the assessment.

Best practices

Log every personal data breach, including incidents assessed as low risk that are not notified, and record the reasoning behind each notification decision so the outcome is demonstrable on review.
Capture the date and time of discovery separately from the point of occurrence, and record the timeline of response actions to support accountability.
Document the categories and approximate volume of data and data subjects affected, flagging where special category or sensitive data may be involved, as this typically affects the risk assessment.
Establish clear roles so that where a processor detects a breach it promptly informs the controller, and record which party carried out each step of the assessment and response.
Keep the register distinct from, but consistent with, the records of processing activities, and avoid treating either as a substitute for the other.
Retain evidence of remedial and mitigation measures taken, recognising that accountability requires demonstrable action rather than stated intent; note that this register does not itself cover retention rules, cross-border transfer mechanics, or enforcement penalties, which are governed separately under the applicable regime.