₹200 crore is the penalty for failing to notify the Data Protection Board of India within 72 hours of becoming aware of a personal data breach. Not 72 hours from when the breach occurred. 72 hours from when your systems detected it.
Most organizations are focused on the wrong variable. The 72-hour window is not the problem. “The Detection Gap” is: the time between when a breach occurs and when your monitoring infrastructure identifies it. A detection system that identifies breaches 5 days late does not give you 72 hours to notify. It gives you negative 48 hours.
What you will master in this guide:
- What constitutes a personal data breach under DPDP and what triggers the notification obligation
- How the 72-hour window is calculated and what starts the clock
- The difference between DPBI notification and CERT-In notification
- What the breach notification to the DPBI must contain
- The engineering controls that make 72-hour compliance operationally achievable
For the full penalty framework, read what are the penalties under the DPDP Act: the full 2026 schedule.
What Is a Personal Data Breach Under DPDP and What Triggers Notification?
The DPDP Act does not define “personal data breach” with a precise technical specification. Based on the Act’s text and comparable global frameworks, a personal data breach under DPDP includes any incident that results in:
- Unauthorized access to personal data → Including internal access by individuals without authorization, not just external attackers
- Unauthorized disclosure of personal data → Including accidental exposure through misconfigured storage, API responses, or shared reports
- Unauthorized alteration or destruction of personal data → Including ransomware-induced data modification or deletion
- Loss of availability of personal data where restoration is delayed or impossible → Including database failures that cause personal data to be inaccessible to authorized users
The notification obligation under Section 8(6) is triggered as soon as your organization “becomes aware” of any such incident. The word “aware” is the operative term. It means detected, not confirmed, not fully investigated.
Waiting for root cause analysis before notifying is not permitted under the Act. If your monitoring system flags a potential breach, the 72-hour clock starts at the moment of that flag.
Every potential breach must be treated as a confirmed breach for notification purposes until the investigation proves otherwise.
How Is the 72-Hour Window Calculated Under DPDP?
The 72-hour window is calculated from the moment your organization becomes aware of the breach. Not from when the breach occurred.
This creates the scenario most compliance teams misunderstand. A breach occurs on Day 1. Your monitoring infrastructure detects it on Day 4. The 72-hour clock starts on Day 4. You have until Day 7 to notify the DPBI. But your breach is already 72 hours old before you even start the notification process.
Here’s the thing: “The Detection Gap” is the real compliance variable. A detection system that catches breaches within 24 hours gives you 48 hours to prepare and submit a notification. A detection system that catches breaches at the 72-hour mark gives you zero hours.
The engineering implication is direct:
- Automated anomaly detection on Unity Catalog audit logs is not optional governance → Without it, your detection window is whatever your manual review cycle is
- Breach monitoring must run continuously, not on a scheduled scan → A daily security scan provides a 23-hour detection gap at best
- Alerts must route to the breach response team immediately upon flagging → An alert that sits in a queue until Monday morning is not a detection system
The 72-hour rule is not a notification challenge. It is a detection and automation challenge.
What Is the Difference Between DPBI Notification and CERT-In Notification in 2026?
India has 2 breach reporting frameworks that apply simultaneously to organizations processing personal data.
CERT-In (Indian Computer Emergency Response Team): Under the CERT-In Directions of 2022, organizations must report cybersecurity incidents to CERT-In within 6 hours of becoming aware. CERT-In’s scope is broader than DPDP: it covers all cybersecurity incidents affecting systems, not just those involving personal data.
DPBI (Data Protection Board of India): Under DPDP Section 8(6), organizations must notify the DPBI within 72 hours of becoming aware of a personal data breach. DPBI notification is specific to incidents involving personal data of data principals.
| Requirement | CERT-In | DPBI (DPDP) |
|---|---|---|
| Scope | All cybersecurity incidents | Personal data breaches only |
| Timeline | 6 hours from awareness | 72 hours from awareness |
| Governing body | Ministry of Electronics and IT | Data Protection Board of India |
| Target of notification | CERT-In portal | DPBI portal or designated channel |
| Principal notification | Not required | Required, as soon as possible after DPBI |
| Penalty for non-compliance | Prescribed under IT Act | Up to ₹200 crore per Section 8(6) |
An incident involving personal data is subject to both frameworks simultaneously. Your breach response process must trigger both notification workflows at detection. The CERT-In 6-hour window is the tighter constraint operationally.
Every personal data breach triggers both CERT-In and DPBI notification obligations. Your breach response workflow must handle both in parallel.
What Must a DPDP Breach Notification to the DPBI Contain?
The DPDP Rules specify the required content for breach notifications. Most other guides stop at listing the requirements. This one maps each requirement to what your team must have ready before a breach occurs.
Identity and contact details of the Data Fiduciary Your organization’s legal name, registration details, and the contact information of your designated Data Protection Officer or grievance officer. → This must be pre-populated in your notification template. There is no time to gather it during a breach.
Nature of the personal data breach A factual description of what occurred: the type of data accessed, altered, disclosed, or destroyed; how the breach occurred; and the systems or datasets involved. → Your breach classification workflow should auto-populate this field from the incident record the moment a breach is confirmed.
Categories and approximate volume of data principals affected An estimate of how many data principals were affected, segmented by data category where possible. Precision is not required at the 72-hour notification stage. Reasonable estimates are acceptable. → This is why the PII scope resolution capability in your Databricks estate matters at the time of a breach, not just during rights fulfillment.
Likely consequences of the breach An assessment of the potential harm to affected data principals: identity theft risk, financial harm, discrimination risk, reputational damage, or other impacts.
Measures taken or proposed to address the breach What your organization has done or is doing to contain the breach, prevent further exposure, and remediate affected systems.
Contact for further information A named individual and contact details for the DPBI to follow up with.
The notification does not need to be a complete post-incident report. The 72-hour submission is a preliminary notification. Full investigation details follow separately. Submit a preliminary notification at 72 hours rather than miss the deadline while preparing a complete report.
What Engineering Controls Make 72-Hour Compliance Achievable?
The 72-hour rule is operationally achievable only if the following controls are in place before a breach occurs.
Control 1: Automated PII Access Anomaly Detection Configure Unity Catalog audit logs to stream to a SIEM or Databricks monitoring job that alerts on anomalous patterns: bulk data exports, unusual query volumes, off-hours access to PII-tagged tables, access from unrecognized service principals. → This is the detection layer. Without it, your breach awareness depends on manual review.
Control 2: Breach Classification Workflow A pre-built Databricks workflow that activates on a breach alert, queries the affected tables to determine whether personal data was involved, estimates the scope of affected data principals, and classifies the incident as DPBI-notifiable or below threshold. → This converts a raw alert into a structured incident record with the data needed for the DPBI notification form.
Control 3: Pre-Approved Notification Template A legally reviewed DPBI notification template, pre-approved by your legal team, that requires only the incident-specific fields to be populated at the time of notification. This template eliminates the drafting time that burns through the 72-hour window. → The legal review happens before the breach. The form is filled after.
Control 4: Breach Response Runbook A documented, tested runbook that defines: who is notified internally when a breach is detected, who owns the DPBI submission, who owns the CERT-In submission, and who communicates to affected data principals. The runbook is not drafted during a breach. It is executed.
Control 5: Immutable Breach Log Every breach event, including detection timestamp, classification, notification submission timestamp, and response actions, is written to an immutable audit log. This is the DPBI audit evidence that demonstrates compliance with the 72-hour rule.
| Control | Without It | With It |
|---|---|---|
| Automated anomaly detection | Detection in days, zero hours remaining | Detection in hours, notification window preserved |
| Breach classification workflow | Manual investigation before notification can begin | Structured incident record auto-generated at detection |
| Pre-approved notification template | Drafting under time pressure, legal delays | Template ready, only incident fields to populate |
| Breach response runbook | Decisions made during a breach, coordination delays | Runbook executed, no decisions required |
| Immutable breach log | No audit evidence for DPBI compliance | Timestamped evidence ready on request |
72-hour breach notification compliance is not achieved by fast drafting. It is achieved by pre-built systems that execute a tested process automatically.
Final Verdict
The DPDP breach notification requirement is not primarily a legal question. It is an engineering question. ₹200 crore in exposure is available to the DPBI the moment your organization’s awareness timestamp exceeds the 72-hour notification deadline. Most organizations are already past that deadline before they have a draft notification in hand.
Closing the notification gap requires automated detection, pre-built breach classification workflows, legal-approved templates, and a runbook that executes without requiring decisions to be made under time pressure. None of these exist in a standard Databricks deployment without deliberate configuration.
The organizations that build their breach response infrastructure before the first incident are the ones that meet the 72-hour window. The organizations that build it after are the ones explaining their delay to the DPBI.
FAQ: DPDP Breach Notification Requirements
The 72-hour clock starts from the moment your organization “becomes aware” of a personal data breach under Section 8(6) of the DPDP Act. Awareness means detection, not confirmation or full investigation. A monitoring alert that flags anomalous PII access starts the clock, regardless of whether the root cause has been identified.
The Data Protection Board of India must be notified within 72 hours. Affected data principals must be notified as soon as possible after the DPBI notification. Both notifications are required under Section 8(6). Notifying one without the other triggers the ₹200 crore penalty.
CERT-In requires notification within 6 hours of all cybersecurity incidents under the 2022 Directions, covering all system-level incidents regardless of personal data involvement. DPBI requires notification within 72 hours of personal data breaches specifically. Both obligations apply simultaneously to incidents involving personal data.
The Act does not specify a materiality or severity threshold for notification. Any incident meeting the definition of a personal data breach triggers the notification obligation. Organizations should err on the side of notification rather than delay while assessing severity.
The notification must include: identity of the Data Fiduciary, nature and description of the breach, categories and approximate volume of data principals affected, likely consequences for those principals, measures taken to address the breach, and contact details for follow-up. A complete post-incident report is not required at the 72-hour stage.
The Act does not provide for an extension of the 72-hour notification window. Partial or preliminary notifications are acceptable where investigation is ongoing. Submitting a preliminary notification at the 72-hour mark and following up with additional details is better than missing the deadline pending a complete report.
Unity Catalog audit logs capture every access event on personal data tables. Automated anomaly detection configured on those logs (unusual query volumes, bulk exports, off-hours access) can identify potential breach events within minutes. The detection speed determines how much of the 72-hour window remains for notification preparation.
Automated DPDP Breach Detection & Evidence Logging by Sinki.ai
Sinki.ai’s DPDP compliance suite includes automated breach detection configured on your Unity Catalog audit logs, pre-built notification workflows, and immutable breach evidence logging, all natively inside your Databricks workspace.
