Category: Incident Response and Skimming

Breach Notification

Also known as: Data Breach Notification, Breach Notification Rule

Simply put

Breach notification is the practice of informing affected individuals, and often regulators, when their personal or sensitive data has been exposed, lost, or accessed without authorization. Various laws set out who must send these notices, how quickly, and to whom. The goal is to make sure people are told promptly so they can take steps to protect themselves.

Formal definition

Breach notification refers to the legal and procedural obligations, imposed under a range of regulatory frameworks, to notify affected data subjects and, where required, supervisory authorities following a security incident involving personal or otherwise protected data. The specific triggers, timelines, thresholds, and required recipients vary by governing regime: under the 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; HIPAA's Breach Notification Rule requires covered entities to notify patients when unsecured protected health information (PHI) is impermissibly used or disclosed; the FTC's Health Breach Notification Rule applies to certain businesses and nonprofits not covered by HIPAA; and sector-specific rules, such as the FCC's data breach notification rules for carriers handling consumer PII, impose their own requirements. Because obligations differ by jurisdiction, sector, and data type, organizations should determine which regime or regimes apply to a given incident and validate requirements against the current text of the applicable rule.

Why it matters

Breach notification obligations turn a security incident from a private technical event into a matter of legal and public accountability. When personal or protected data is exposed, lost, or accessed without authorization, affected individuals often cannot take protective steps unless they are told. Timely notification is intended to give people the opportunity to monitor accounts, change credentials, watch for fraud, or otherwise mitigate harm, while giving regulators visibility into incidents affecting the populations they oversee.

For organizations that handle payment or personal data, breach notification is one of the most consequential compliance areas because the applicable rules differ substantially by jurisdiction, sector, and data type. The GDPR defines a personal data breach broadly as a breach of security leading to the accidental or unlawful destruction, loss, alteration, or unauthorized disclosure of, or access to, personal data. HIPAA's Breach Notification Rule addresses unsecured protected health information held by covered entities, the FTC's Health Breach Notification Rule reaches certain businesses and nonprofits not covered by HIPAA, and rules such as the FCC's data breach notification requirements govern carriers handling consumer PII. A single incident may implicate more than one of these regimes at once.

Because triggers, timelines, thresholds, and required recipients vary across these frameworks, misreading which rule applies can lead either to unnecessary disclosure or to a failure to notify when required. Organizations should determine which regime or regimes govern a given incident and validate the specific obligations against the current published text of the applicable rule, rather than assuming a uniform standard. Note that PCI DSS is a separate framework focused on protecting cardholder data; it is not itself a breach notification law, and payment card breach reporting to card brands is governed separately by network and brand rules.

Who it's relevant to

Compliance and Privacy Officers

These teams must map which breach notification regimes apply to their organization's data holdings and geography, since a single incident can trigger GDPR, HIPAA, FTC, FCC, or other obligations simultaneously. They are responsible for validating triggers, timelines, and required recipients against the current text of each applicable rule.

Incident Response and Security Teams

When an incident is identified, these teams determine whether it constitutes a reportable breach under the relevant definitions, such as unauthorized access to personal data under the GDPR or impermissible disclosure of unsecured PHI under HIPAA. Their assessment and documentation feed directly into notification decisions and timelines.

Healthcare Covered Entities and Health-Data Businesses

Covered entities are subject to HIPAA's Breach Notification Rule, which requires notifying patients when their unsecured PHI is impermissibly used or disclosed. Certain businesses and nonprofits not covered by HIPAA may instead fall under the FTC's Health Breach Notification Rule, so these organizations should confirm which framework governs their handling of health information.

Telecommunications Carriers

Carriers handling consumer PII are subject to the FCC's data breach notification rules, which require providing notice when a consumer's PII is breached. These organizations should track the specific requirements and effective terms of the applicable FCC rules against their current text.

Merchant Risk and Payment Operations Teams

Teams handling payment and personal data need to recognize that breach notification laws are distinct from PCI DSS and from card brand reporting obligations. When personal data is exposed, they should coordinate with compliance and legal functions to identify all applicable notification regimes rather than assuming payment-specific processes cover the requirement.

Inside Breach Notification

Trigger event definition

The circumstances that initiate a notification obligation, typically the confirmed or suspected unauthorized access, acquisition, or disclosure of protected data. In the payment context this may involve cardholder data or sensitive authentication data, though the precise trigger depends on applicable laws, contractual obligations, and card brand or network rules that vary by jurisdiction and change over time.

Notification recipients

The parties that must be informed, which can include affected individuals, regulators or supervisory authorities, acquirers, payment brands, law enforcement, and, for service providers, their merchant or processor customers. The specific recipients and reporting channels are defined by regulation and by contractual and network requirements rather than by PCI DSS alone.

Timing and deadlines

The window within which notification must occur after discovery or confirmation of an incident. Deadlines differ across regulatory regimes and card brand rules; practitioners should confirm applicable timeframes against the current governing law and network requirements rather than assuming a single fixed deadline.

Content of the notice

The information conveyed to recipients, which may describe the nature of the incident, the categories of data potentially involved (for example, whether PAN, cardholder name, or other cardholder data elements were affected), the approximate scope, remediation steps, and points of contact. Required content elements vary by law and by recipient.

Relationship to incident response

Breach notification is one output of a broader incident response process. PCI DSS addresses maintaining an incident response plan as a control area, but the notification obligation itself is largely governed by external law, contract, and card brand rules. Readers should confirm the relevant PCI DSS requirement wording against the current published version, as numbering and language differ between versions.

Data type distinctions in disclosure

Notices may need to distinguish cardholder data (such as PAN, cardholder name, expiration date, service code) from sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks). Because sensitive authentication data must not be stored after authorization, its exposure in a breach can indicate a storage or logging failure and may carry distinct reporting implications.

Common questions

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

Does PCI DSS itself define the timeline and recipients for breach notification?

No. PCI DSS addresses incident response readiness, but the legal obligation to notify affected individuals, regulators, and others is set by separate laws and regulations that vary by jurisdiction. Card brand and acquirer contractual rules impose their own notification and forensic obligations, which are distinct from statutory breach notification laws. Treat these as separate regimes: satisfying one does not automatically satisfy the others, and you should confirm requirements against the specific laws, contracts, and current published standards that apply to your situation.

If exposed data was encrypted or tokenized, are we automatically exempt from notifying anyone?

Not necessarily. Some breach notification laws provide a safe harbor or exception when affected data was rendered unreadable, but the conditions differ by jurisdiction and often depend on whether the keys or the ability to reverse the transformation were also compromised. Encryption, tokenization, truncation, masking, and hashing transform data differently, and their effect on any notification obligation depends on the specific law and the implementation, not on the label alone. Confirm the exact conditions of any applicable exemption rather than assuming exposure of protected data removes all duties.

What triggers our obligation to begin the breach notification process?

The trigger is typically defined by the applicable law or contract rather than by internal judgment alone. Statutory triggers often turn on unauthorized access to or acquisition of defined categories of personal or account data, while card brand and acquirer obligations may be triggered by a suspected or confirmed compromise of cardholder data. Because definitions of a reportable event vary by jurisdiction and agreement, map your triggers in advance and document who decides when a suspected incident becomes a notifiable event. Confirm the specific triggering conditions against the current governing text.

How should breach notification obligations be built into our incident response plan?

Incorporate notification as a defined workstream within incident response, with pre-identified roles, decision-makers, and escalation paths. Maintain an inventory of the laws, regulatory bodies, card brand rules, and contractual obligations that may apply, along with their respective recipients and any timing expectations, and validate this inventory periodically because rules change and vary by region. Coordinate legal, compliance, security, and communications functions, and align notification steps with forensic investigation so that evidence handling is not compromised. Confirm current requirements before relying on any previously documented timeline.

Who typically needs to be notified after a payment-related security incident?

Potential recipients can include affected individuals, one or more regulators or supervisory authorities, and, under card brand and acquirer rules, your acquirer and the relevant payment networks. The exact list depends on the categories of data involved, the jurisdictions of the affected parties, and the applicable contracts and laws. Because obligations to statutory regulators are separate from contractual obligations to acquirers and card brands, identify each audience separately and confirm the specific recipients and any regional variations against the governing requirements at the time of the incident.

How does breach notification interact with an ongoing forensic investigation?

Notification and forensic investigation run in parallel and can be in tension: some obligations expect prompt notice, while forensic work may still be establishing the scope of what data was accessed and how. Coordinate the two so that notification content reflects verified findings where possible and does not misstate scope, while preserving evidence and following any investigation requirements set by card brands, acquirers, or engaged forensic investigators. Document decisions and their timing, and confirm what forensic obligations apply under the relevant contracts and current standards rather than assuming a fixed sequence.

Common misconceptions

PCI DSS defines all breach notification deadlines and recipients.

PCI DSS is a data security standard and addresses incident response preparedness as a control area, but the obligation to notify, who must be notified, and by when are primarily set by data protection and breach laws, contractual terms, and card brand or network rules. These vary by region and change over time and are separate from the PCI DSS standard itself.

If exposed data was encrypted, no notification is ever required.

Encryption may qualify for safe-harbor or reduced-obligation treatment under some laws, but this depends on the specific statute, the strength and management of the encryption, and whether keys were also compromised. It is not a universal exemption, and it does not change the rule that sensitive authentication data must not be stored after authorization even when encrypted.

One notification satisfies every obligation for an incident.

A single event can create multiple, parallel obligations to different parties, such as affected individuals, one or more regulators, acquirers, and payment brands, each with its own timing, content, and channel requirements. Meeting one requirement does not automatically satisfy the others.

Best practices

Maintain and regularly test an incident response plan that includes a documented notification workflow, mapping each obligation to its governing source (applicable law, contract, and card brand or network rules) rather than relying on a single assumed deadline.

Confirm the current PCI DSS requirement wording for incident response against the published version in force, since requirement numbering and language differ between versions.

Identify in advance the full set of potential notification recipients, including affected individuals, regulators, acquirers, payment brands, and, for service providers, downstream customers, and keep contact and reporting-channel details current.

Establish a process to classify affected data quickly, distinguishing cardholder data elements from sensitive authentication data, so that notices accurately reflect what may have been exposed and any storage or logging failures are surfaced.

Coordinate legal, compliance, and security functions before drafting notices so that content, timing, and channels meet the varying requirements of each obligation, and confirm applicable timeframes against current governing rules rather than assuming a fixed window.

Preserve evidence and document the discovery, investigation, and notification timeline to support regulatory, acquirer, and card brand reporting and to enable post-incident review.