green back ground with gradient accents. The words "Your AI Agents Are Making Decisions. Can Your Security Team Explain Them?" And a "Download the Guide" button.

Category: Incident & Breach Response

Personal Data Breach

Also known as: Data Breach, Personal Information Breach

Simply put

A personal data breach is a security failure that leads to personal information being accidentally or unlawfully destroyed, lost, altered, disclosed to, or accessed by people who should not have it. It covers more than just data being stolen; losing data or accidentally changing or deleting it can also count. What organizations must do in response depends on where they operate and the nature of the information affected.

Formal definition

Under the EU GDPR, and correspondingly under the UK GDPR as interpreted by the ICO, a personal data breach is defined as 'a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.' The concept therefore encompasses three broad categories of impact: confidentiality breaches (unauthorised or accidental disclosure of, or access to, personal data), integrity breaches (unauthorised or accidental alteration of personal data), and availability breaches (accidental or unlawful loss of access to, or destruction of, personal data). It is important to note that this is a security incident specifically affecting personal data; not every security incident constitutes a personal data breach, and not every personal data breach triggers the same downstream obligations, which under the GDPR framework generally turn on the assessed risk to the rights and freedoms of affected individuals. This EU/UK statutory definition should be distinguished from the varied and non-uniform definitions of 'data breach' used across United States law, where terminology is often narrower and framed in terms of the unauthorized acquisition of personal information, and where obligations arise principally under sector-specific and state-level statutes rather than a single omnibus regime. Because notification thresholds, timelines, and the precise scope of covered data differ substantially by jurisdiction and sector, and because official guidance is periodically updated, readers should verify obligations against the current authoritative text applicable to their circumstances.

Why it matters

A personal data breach is one of the few compliance events that can trigger legally binding, time-sensitive obligations rather than discretionary action. Under the EU GDPR and, correspondingly, the UK GDPR as interpreted by the ICO, an incident that meets the statutory definition can create duties to assess risk, document the event, and in many cases notify a supervisory authority and affected individuals. Getting the classification wrong in either direction carries consequences: treating a reportable breach as a routine IT incident may expose an organization to enforcement, while over-reporting can consume resources and erode credibility with regulators.

The term matters precisely because it is broader than the everyday notion of data being "stolen." The GDPR definition captures accidental or unlawful destruction, loss, alteration, and unauthorised disclosure or access, which means an employee accidentally deleting records or emailing personal data to the wrong recipient can qualify just as a malicious external attack would. This breadth means organizations need internal processes capable of recognizing confidentiality, integrity, and availability incidents alike, not only headline-grabbing cyberattacks.

Equally important is that the concept does not carry a single, universal meaning. The EU/UK statutory definition differs from the varied approaches across United States law, where the term is often framed more narrowly around the unauthorized acquisition of personal information and where obligations arise under sector-specific and state-level statutes rather than one omnibus regime. Because notification thresholds, timelines, and covered-data definitions differ substantially by jurisdiction and sector, and because official guidance is periodically updated, the same underlying event can produce materially different obligations depending on where an organization operates.

Who it's relevant to

Data Protection Officers and Privacy Teams

Those responsible for GDPR and UK GDPR compliance need to distinguish incidents that meet the statutory personal data breach definition from broader security events, and to assess the risk to individuals' rights and freedoms that drives downstream notification and documentation duties. Application to a specific incident requires professional judgment against the applicable current text.

Information Security and Incident Response Personnel

Security teams operationalize breach detection and classification, and must recognize that confidentiality, integrity, and availability incidents can all constitute personal data breaches—not only unauthorized external access. Their assessments feed the legal and privacy analysis that determines an organization's obligations.

Legal Counsel and Compliance Officers

Counsel must navigate the divergence between the EU/UK omnibus definition and the narrower, non-uniform 'data breach' concepts across U.S. federal sector-specific and state-level law. Because thresholds, timelines, and covered-data scope differ by jurisdiction and sector, obligations should be confirmed against the authoritative text applicable to the circumstances.

Processors and Service Providers

Organizations that collect or store personal information on behalf of other businesses have coordination responsibilities. FTC guidance indicates such businesses should notify the businesses on whose behalf they hold the data when a breach occurs, and processors under the GDPR framework have their own defined role distinct from that of the controller.

Inside Personal Data Breach

Breach of security

A personal data breach originates from a security failure that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Under the GDPR, this concept applies to personal data processed by controllers and processors subject to the Regulation; other jurisdictions may define the triggering event differently, so readers should verify against the applicable text.

Confidentiality, integrity, and availability dimensions

A breach may affect one or more of these dimensions: confidentiality (unauthorised disclosure or access), integrity (unauthorised or accidental alteration), and availability (accidental or unlawful loss or destruction of, or loss of access to, personal data). A common example of an availability breach is the loss of access to data, not merely its outright theft.

Accidental and unlawful causes

The definition generally covers both accidental events (for example, sending data to the wrong recipient or losing a device) and deliberate unlawful acts (for example, a cyberattack or malicious insider activity). Intent is not a prerequisite for an event to qualify as a breach.

Notification obligations

Where a breach is notifiable, controllers generally must notify the competent supervisory authority, and in higher-risk cases the affected individuals. The specific triggers, timing, and thresholds are set by the applicable law and depend on the risk to the rights and freedoms of individuals; exact deadlines and content requirements should be confirmed against the current official text.

Controller and processor responsibilities

Roles differ: a processor that becomes aware of a breach generally must inform the controller, while the controller typically bears the obligation to assess the risk and, where required, notify the authority and individuals. This entry distinguishes these roles rather than treating them as interchangeable.

Documentation and record-keeping

Organisations are generally expected to document breaches, including the facts, effects, and remedial action taken, regardless of whether the breach is ultimately notifiable. This record supports accountability and may be reviewed by a supervisory authority.

Common questions

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

Does a personal data breach only mean a hacker stealing or leaking data?

No. A personal data breach is not limited to malicious external attacks or unauthorized disclosure. Under the GDPR definition, it covers any breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. This means events such as accidental deletion, loss of a device or paper record, sending information to the wrong recipient, or a ransomware event that renders data inaccessible can all qualify, even where no data leaves the organization or is viewed by an outsider. Confidentiality breaches (unauthorized access or disclosure) are one category; availability breaches (loss or destruction) and integrity breaches (unauthorized alteration) also fall within scope.

Does every personal data breach have to be reported to a regulator and to affected individuals?

Not necessarily. It is a misconception that all breaches trigger mandatory notification. Under the GDPR, notification to the supervisory authority is generally required unless the breach is unlikely to result in a risk to the rights and freedoms of individuals, and notification to affected individuals is generally required only where the breach is likely to result in a high risk. These are risk-based thresholds, so the outcome depends on the specific facts, the categories of data involved, and any mitigating measures. Thresholds, timeframes, and interpretations differ across jurisdictions, and sector-specific rules may impose separate obligations, so readers should assess each incident against the applicable law rather than assume a blanket duty.

How should an organization determine whether a breach meets the threshold for regulator notification?

The assessment generally turns on whether the breach is likely to result in a risk to the rights and freedoms of individuals. In most cases this involves evaluating factors such as the type and sensitivity of the data, the volume of records and number of individuals affected, the ease with which individuals could be identified, the potential consequences (for example financial loss, discrimination, or identity fraud), and whether any protective measures such as encryption reduced the impact. This is a documented, fact-specific judgment rather than a mechanical test, and the precise threshold and its interpretation vary by jurisdiction. Application to a particular incident requires professional judgment, and organizations should verify the current requirements against the applicable official text.

What should be recorded when a breach occurs, even if it is not notified?

Under the GDPR, controllers are generally expected to document breaches internally regardless of whether they are notified, including the facts relating to the breach, its effects, and the remedial action taken. This record supports the accountability principle and allows a supervisory authority to verify how notification decisions were reached. Maintaining a consistent internal breach register is widely treated as good practice, but readers should confirm the specific record-keeping expectations under their applicable regime, as details and enforcement practice can differ across jurisdictions.

Who is responsible for notifying when a processor discovers a breach?

Roles differ between controller and processor and should not be conflated. Under the GDPR, a processor that becomes aware of a personal data breach is generally required to notify the controller, typically without undue delay, but the processor is not ordinarily the party that notifies the supervisory authority or affected individuals. The obligation to assess the breach and, where thresholds are met, to notify the authority and individuals generally rests with the controller. Contractual arrangements between the parties usually specify timeframes and cooperation duties, and the allocation should be confirmed against both the applicable law and the governing data processing agreement.

What practical measures help an organization respond within required timeframes?

Because notification obligations can be time-sensitive, organizations commonly establish an incident response plan that defines detection, escalation, and decision-making procedures in advance. This may include clear internal reporting channels, a defined process for assessing risk to individuals, predetermined roles and contact points, and templates to support timely documentation and notification. Preparedness measures of this kind are operational good practice rather than a prescribed legal checklist, and the specific timeframes and procedural requirements they must satisfy vary by jurisdiction and should be verified against the current authoritative source.

Common misconceptions

A personal data breach only occurs when data is stolen by an external attacker.

A breach may also arise from accidental causes and internal events, such as loss of a device, accidental deletion, misdirected correspondence, or loss of access to data. Availability and integrity incidents can qualify even without any external theft or disclosure.

Every personal data breach must always be reported to the authority and to affected individuals.

Whether notification is required generally depends on the risk to the rights and freedoms of individuals. Some breaches may not meet the notification threshold, though they should still be documented. The applicable thresholds, timing, and to whom notification is owed vary by jurisdiction and should be verified against the current official text.

A processor and a controller have the same breach obligations.

The roles are distinct. A processor generally must notify the controller of a breach, while the controller typically carries the responsibility to assess risk and make any required notifications to the supervisory authority and individuals. Contractual arrangements may allocate further responsibilities between the parties.

Best practices

Maintain an internal breach detection, triage, and response procedure that defines roles, escalation paths, and timelines, so that the clock for any applicable notification deadline can be met.

Keep a breach register documenting the facts, effects, and remedial actions for all incidents, including those you assess as not notifiable, to support accountability.

Establish a risk-assessment methodology to evaluate the likely impact on the rights and freedoms of affected individuals, since this generally determines whether and to whom notification is required.

Clarify controller and processor responsibilities in advance through contractual terms, including how and how quickly a processor must inform the controller of a suspected breach.

Verify the specific notification triggers, deadlines, and content requirements against the current authoritative text for each jurisdiction in which you operate, as these differ across regimes and are periodically amended.

Treat availability and integrity incidents, such as data loss, corruption, or ransomware-related loss of access, as potential breaches and assess them under the same procedure rather than focusing only on confidentiality incidents.