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

Breach Notification

Also known as: Data Breach Notification, Breach Notification Rule, Personal Data Breach Notification
Simply put

Breach notification is a legal duty to inform affected individuals, and often regulators, when a security incident exposes their personal or sensitive information. The specific triggers, deadlines, and recipients depend on which law applies and where the affected people are located. It is not a single universal rule but a requirement that appears in several different regulations across sectors and jurisdictions.

Formal definition

Breach notification refers to a set of statutory and regulatory obligations requiring covered organizations to notify affected data subjects, supervisory or enforcement authorities, and in some cases the public or the media, following a qualifying security incident involving protected information. The scope, thresholds, timelines, and content of notice vary by the governing instrument. Under the EU GDPR, a 'personal data breach' is defined as a breach of security leading to the accidental or unlawful destruction, loss, alteration, or unauthorized disclosure of, or access to, personal data, with distinct obligations for controllers and processors; readers should note the roles and their differing duties are not interchangeable. In the United States, sector-specific rules apply rather than a single federal standard: the HIPAA Breach Notification Rule (45 CFR §§ 164.400-414) obligates covered entities and their business associates to provide notification following a breach of unsecured protected health information; the FTC's Health Breach Notification Rule reaches vendors of personal health records and related entities not covered by HIPAA; and the FCC has updated data breach notification rules applicable to telecommunications carriers regarding breaches of customer PII. Because triggers frequently turn on whether the information was 'unsecured,' on risk assessment, and on data category, applicability is fact-specific. This entry does not cover every state breach notification statute or non-U.S./non-EU regimes, and specific deadlines, penalty provisions, and effective dates should be verified against the current official text of the relevant law, as these rules are periodically amended.

Why it matters

Breach notification obligations convert a security incident into a set of enforceable legal duties, often on tight timelines and with defined recipients. For compliance and legal teams, the consequences of a mishandled notification can extend beyond the underlying incident itself: failure to notify affected individuals or regulators when required, or notifying in a manner that does not meet statutory content and timing requirements, can create independent exposure. This is why breach notification is typically treated not as an afterthought to incident response but as a workflow that must be planned before an incident occurs.

A central challenge is that there is no single universal breach notification standard. The applicable rule depends on which law governs, the category of information involved, and where the affected people are located. Under the EU GDPR, the trigger is a 'personal data breach' — a breach of security leading to the accidental or unlawful destruction, loss, alteration, or unauthorized disclosure of, or access to, personal data — and the duties differ depending on whether an organization acts as a controller or a processor. In the United States, sector-specific regimes apply instead of one federal rule: the HIPAA Breach Notification Rule reaches covered entities and business associates handling unsecured protected health information, the FTC's Health Breach Notification Rule reaches vendors of personal health records and related entities outside HIPAA's scope, and the FCC has updated rules addressing breaches of telecommunications customer PII.

Because many of these obligations turn on fact-specific questions — whether information was 'unsecured,' the outcome of a risk assessment, and the data category involved — organizations frequently cannot determine their notification duties without first analyzing the specific incident against the specific instruments that apply to them. Overlapping regimes may impose parallel duties for a single event, and this entry does not cover every U.S. state breach notification statute or non-U.S./non-EU regime. Deadlines, penalty provisions, and effective dates should be verified against the current official text, as these rules are periodically amended.

Who it's relevant to

Data protection officers and privacy teams (EU/GDPR)
Organizations subject to the GDPR must be able to recognize a 'personal data breach' and act on the distinct obligations that attach to controllers and processors. Because these roles carry different duties, privacy teams should map which capacity the organization occupies for a given processing activity before an incident arises. Specific timelines and content requirements should be verified against the current text of the GDPR.
HIPAA covered entities and business associates
Healthcare providers, health plans, healthcare clearinghouses, and their business associates fall under the HIPAA Breach Notification Rule (45 CFR §§ 164.400-414), which requires notification following a breach of unsecured protected health information. Whether a duty is triggered turns in part on whether the information was 'unsecured,' making the underlying safeguards and any applicable risk assessment central to the analysis.
Vendors of personal health records outside HIPAA
Vendors of personal health records and related entities that are not covered by HIPAA may instead fall under the FTC's Health Breach Notification Rule, which requires notifying consumers following a breach involving unsecured information. Organizations handling health-related consumer data should determine which of these regimes — HIPAA, the FTC rule, or potentially both across affiliated entities — governs their activities.
Telecommunications carriers
Telecommunications carriers are subject to the FCC's updated data breach notification rules, which require notice when a consumer's PII is breached. Compliance teams in this sector should confirm the current scope and effective dates of the FCC rules against the official text, as these were recently updated and are subject to change.
Legal counsel and incident response leaders
Because a single incident may implicate multiple overlapping regimes with different triggers, deadlines, and recipients, legal counsel and incident response leaders need to coordinate the notification analysis across jurisdictions and sectors. Given that applicability is fact-specific and rules change, application to a particular incident requires professional judgment and verification against current authoritative sources rather than reliance on a general definition.

Inside Breach Notification

Triggering Event
The occurrence that starts a notification obligation, generally a confirmed or reasonably suspected compromise of the confidentiality, integrity, or availability of protected data. What qualifies as a triggering event, and whether a risk of harm threshold applies, varies by jurisdiction and by the specific regulation involved (for example, personal data breaches under the GDPR versus protected health information incidents under HIPAA in the United States).
Notification Deadline
The timeframe within which affected parties must be informed. Deadlines differ across regimes and may run from discovery, from confirmation, or from the point a breach is deemed to have occurred. Because specific hour or day counts vary by jurisdiction and are periodically amended, readers should verify the applicable period against the current official text rather than assume a universal deadline.
Recipients of Notification
The parties who must be notified, which may include a supervisory or regulatory authority, affected individuals (data subjects), and, in controller–processor relationships, the controller. Which recipients apply, and whether individual notification is required at all, generally depends on the assessed level of risk to those individuals and on the governing regime.
Content of the Notification
The information a notification is generally expected to convey, which may include the nature of the incident, the categories and approximate number of records or individuals affected, likely consequences, and measures taken or proposed to address the breach. Specific content requirements differ by jurisdiction.
Role-Based Obligations
Notification duties differ by role. Under the GDPR framework, a processor generally must notify the controller without undue delay, while the controller bears responsibility for notifying the supervisory authority and, where required, affected individuals. Conflating these roles can lead to missed or misdirected notifications.
Documentation and Record-Keeping
Many regimes expect organizations to document breaches, including those not reported externally, together with the facts, effects, and remedial action. Such records support the ability to demonstrate compliance, though the precise expectations vary by jurisdiction and should be confirmed against the applicable text.

Common questions

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

Does every data breach trigger a mandatory notification obligation?
No. Not all security incidents meet the threshold for notification. Under many regimes, notification duties are tied to the likelihood or severity of risk to affected individuals. For example, some frameworks require notification to supervisory authorities only where a breach is likely to result in a risk to individuals' rights and freedoms, and notification to individuals only where the risk is high. Whether an incident qualifies is fact-specific and depends on factors such as the data categories involved, whether the data was encrypted or otherwise rendered unintelligible, and the potential consequences. The applicable threshold and terminology vary by jurisdiction and sector, so you should assess each incident against the specific instrument that governs it and verify the current official text.
Is there a single universal deadline, such as 72 hours, for reporting all breaches?
No. There is no single global deadline. Different regimes impose different timing requirements, and those requirements may differ depending on whether you are notifying a regulator, affected individuals, or another party such as a controller you process data for. Some regimes frame the obligation around notifying 'without undue delay' and may reference a specific outer limit; others use different language or different clocks entirely. Sectoral rules and jurisdiction-specific laws in the EU, the United States, the United Kingdom, and elsewhere can each set their own timelines. Because these deadlines and how enforcement authorities interpret them can differ and change, confirm the exact requirement against the specific law or framework that applies to your situation.
Who is responsible for notifying when a breach occurs at a processor rather than a controller?
Responsibilities generally differ by role. In many regimes the entity that determines the purposes and means of processing (often called the controller) carries the primary duty to notify authorities and, where required, affected individuals, while a service provider processing data on its behalf (often called the processor) is generally required to notify that controller. The precise allocation of duties, the terminology, and the timing each party must observe depend on the applicable law and on the terms of the contract between the parties. Because roles and obligations can vary across jurisdictions and arrangements, review both the governing instrument and your contractual commitments to confirm who must do what.
What information is typically expected in a breach notification to a regulator?
Notifications generally describe the nature of the incident, the categories and approximate number of individuals and records affected where known, the likely consequences, and the measures taken or proposed to address the breach and mitigate its effects. Some regimes also expect contact details for a point of responsibility, such as a designated data protection contact. The specific content, format, and whether information may be provided in phases can vary by regime and by regulator. Consult the relevant authority's current published requirements or reporting form, as these are periodically updated.
What should an organization do if it does not yet have all the details when a notification deadline approaches?
Several regimes contemplate that full information may not be available immediately and allow notification to be provided in stages, with initial information followed by further details as an investigation progresses. Where this is permitted, an organization would generally provide what it reasonably knows within the applicable timeframe and supplement it as facts are established. Whether phased notification is allowed, and how it operates, depends on the governing instrument and the practice of the relevant authority. Verify the mechanism against the current official text rather than assuming it is available in every jurisdiction.
How does documenting a breach relate to the decision not to notify?
Many regimes expect organizations to keep internal records of breaches, including those they conclude do not require external notification, together with the reasoning behind that conclusion. This documentation can support the organization's ability to demonstrate that it assessed the incident and reached a defensible decision. The scope and form of any record-keeping obligation depend on the applicable regime and on how enforcement authorities approach such records, which may evolve over time. Because these expectations differ across jurisdictions and sectors, confirm the specific record-keeping requirements that apply to you.

Common misconceptions

Every data breach must always be reported to a regulator and to affected individuals.
Notification obligations are generally fact-specific and often depend on the assessed risk to affected individuals. Under some regimes, incidents unlikely to result in a risk to individuals may not require external notification, though internal documentation may still be expected. The applicable threshold depends on the governing regulation and jurisdiction.
There is a single, universal breach notification deadline that applies everywhere.
Deadlines and the events that start the clock differ across the EU, the United States, the United Kingdom, and other jurisdictions, and across sector-specific regimes. Because these periods are set by binding law that is periodically amended, practitioners should verify the specific timeframe against the current official text for each applicable regime.
The organization that suffers the breach always carries the same notification duties regardless of its role.
Obligations are role-dependent. In a controller–processor structure, a processor generally notifies the controller, while the controller handles notification to authorities and, where required, individuals. Treating these roles as interchangeable risks misdirected or omitted notifications.

Best practices

Maintain a documented incident response and breach notification procedure that maps each applicable regime's triggering events, deadlines, recipients, and required content, and review it as regulations are amended.
Establish an internal escalation and detection process so that the point of discovery or confirmation can be reliably identified and recorded, since many notification clocks run from that point.
Clarify controller and processor roles in advance, including contractual notification timelines, so that role-based obligations are met without confusion during an incident.
Conduct and record a risk assessment for each incident to determine whether external notification to authorities or individuals is required under the applicable threshold.
Keep documentation of all breaches, including those not externally reported, capturing the facts, effects, and remedial measures to support demonstrable compliance.
Verify specific deadlines, content requirements, and role obligations against the current official text of each governing regime, and involve qualified legal or compliance professionals for application to particular circumstances.
Digital advertisement promoting the whitepaper “The State of Application Security in Modern Software,” showing the cover f the whitepaper and text highlighting AppSec risks, AI code threats, API vulnerabilities, and a button to download the whitepaper.