Breach Notification
Breach notification is the legal obligation to inform regulators and affected individuals when a personal data breach occurs. Learn the 72-hour GDPR rule, DPDP universal notification, and what timely scope determination requires.
What is Breach Notification?
Breach notification is the legal obligation to inform regulators and affected individuals when a personal data breach occurs. Under GDPR, HIPAA, DPDP, CCPA, and equivalent state and national frameworks, organisations that experience unauthorised access to, disclosure of, or loss of personal data must follow defined notification procedures within specified timeframes. Late notification, incomplete notification, or failure to notify carries direct regulatory penalties.
The 72-hour figure most practitioners know comes from GDPR. But the obligation exists across frameworks. And the hard part isn't the notification itself.
It's the scope determination that has to happen first.
How breach notification works
Notification is the end of a process, not the beginning. Before any regulator or individual can be notified, an organisation must determine what data was involved, how many individuals are affected, what categories of personal data were compromised, and how the breach occurred. That investigation has to happen under time pressure, using whatever evidence exists.
Three requirements define what a breach notification must contain under most frameworks.
Nature of the breach. What happened: unauthorised access, accidental disclosure, ransomware encryption, insider exfiltration. When it happened. How it was discovered.
Scope of impact. Which categories of personal data were involved, approximate number of affected individuals, and approximate number of personal data records. Not exact figures — regulators understand that investigations take time — but credible approximations based on available evidence.
Response actions. What measures the organisation has taken or proposes to take to address the breach, mitigate its effects, and prevent recurrence.
The notification submitted within the legal timeframe doesn't have to be a complete forensic report. It does have to be honest about what's known, what's unknown, and what's being done. Regulators consistently look more unfavourably on delayed notifications than on early ones that acknowledge ongoing investigation.
Breach notification requirements by framework
Framework | Regulator notification | Individual notification | Threshold |
|---|---|---|---|
GDPR | 72 hours of becoming aware | Without undue delay if high risk to individuals | Risk-based: not required if breach unlikely to result in risk |
HIPAA | 60 days of discovery (HHS) | 60 days of discovery | All breaches of unsecured PHI |
DPDP (India) | Board notification required | Affected Data Principals notified | Universal: no risk threshold |
CCPA | No regulator notification | No direct breach notification requirement | Private right of action for affected consumers |
Two distinctions matter practically.
GDPR's threshold is risk-based. A breach unlikely to result in risk to individuals doesn't require individual notification, though it does require internal documentation. Organisations assess the risk and decide. Low-risk breaches — encrypted data breached where the encryption key wasn't compromised, for example — may not require notification beyond internal records.
DPDP has no threshold. Every personal data breach involving Indian citizens' data is notifiable to the Data Protection Board and to affected Data Principals. There is no assessment to perform about whether notification is required. It is always required. That is a material operational difference from GDPR.
Why scope determination is the real challenge
Consider what actually has to happen in the 72 hours after a breach is discovered under GDPR.
The security team identifies an incident. An analyst begins investigation. Simultaneously, the legal and compliance team starts the notification clock. The question they all need to answer immediately is: what data was accessed?
That question is harder than it sounds. The compromised system contained customer records. But which customers? Which fields? Did data propagate from that system to downstream analytics, integrations, or SaaS platforms before containment? Are there backups or copies of that data in other systems that might also have been affected? If an insider exfiltrated data through a legitimate channel, which specific records moved and to where?
Without continuous data lineage, answering those questions requires manual reconstruction across multiple systems, each with partial visibility. That reconstruction takes days. The notification window is 72 hours.
Organisations that go into a breach with continuous lineage tracking, complete data inventory, and immutable audit logs can scope an incident in hours rather than days. They know what data the compromised system contained because it's classified and mapped. They know whether data propagated downstream because the lineage graph shows it. They know what the affected individuals' records include because the inventory reflects it.
That's the direct operational connection between data security capability and breach notification compliance. Not the notification writing. The evidence that makes fast, accurate scoping possible.
Use cases
GDPR notification with partial information. A European retailer discovers an unauthorised access event affecting its customer database. The investigation is ongoing. The legal team needs to notify the supervisory authority within 72 hours. With a current data inventory and lineage records, the team can confidently state: the database contained these categories of personal data for approximately this number of customers, with lineage showing no propagation to downstream systems before containment. The notification is early, accurate, and honest about what remains under investigation. Without those records, the team either delays while reconstructing scope or notifies with figures so approximate they raise regulator questions.
DPDP universal notification. An Indian fintech experiences a breach affecting a subset of its user base. Under DPDP, there's no threshold assessment to perform. Both the Data Protection Board and affected Data Principals must be notified. The company uses continuous personal data discovery to identify every system containing the affected users' data, confirms the scope includes no propagation beyond the primary systems, and submits notification with defensible evidence of scope boundaries within the required timeframe.
Why breach notification matters for CISOs and compliance teams
Breach notification penalties are layered. GDPR fines for failure to notify or late notification can reach €10 million or 2% of global annual turnover at the lower tier. DPDP penalties for failure to notify the Board reach ₹200 crore. HIPAA fines accumulate per violation per day.
But the reputational consequence of a poorly handled notification is often larger than the regulatory fine. A notification that has to be substantially revised because the initial scope was wrong, or that arrives weeks after the discovery deadline because investigation took too long, tells regulators that the organisation's data security programme lacks the visibility to respond effectively.
That's the argument for investing in data security capability before a breach, not after. Fast, accurate breach notification isn't a separate compliance workstream. It's a direct output of having a data inventory that's current, lineage that's tracked, and evidence that's generated continuously.
