A data breach is no longer just a technical crisis — under India’s DPDP Act 2023 and DPDP Rules 2025, it is a regulatory emergency with a hard 72-hour clock, dual notification obligations, and penalties of up to ₹200 crore for missing the deadline. For organisations that are also subject to the IT Act’s CERT-In Directions, the first clock starts even earlier — at 6 hours.
This guide gives you the complete breach notification framework under the DPDP Act: what Rule 7 requires, the two-stage DPBI process, how it interacts with CERT-In obligations, what to include in each notification, and a step-by-step 72-hour response playbook you can operationalise now — before the May 13, 2027 enforcement deadline.
1. The Legal Basis: Section 8(6) and Rule 7
Section 8(6) of the DPDP Act 2023 establishes the breach notification obligation:
“Each Data Fiduciary shall give the Board and each affected Data Principal intimation of personal data breach in such manner and to such extent as may be prescribed.”
Rule 7 of the DPDP Rules 2025 operationalises this into a two-stage process. Unlike GDPR’s 72-hour notification to supervisory authorities (with a separate, risk-conditional obligation to notify individuals), the DPDP Act requires notification to both the regulator and every affected individual — with no materiality threshold.
The Critical Difference from GDPR
Under GDPR Article 34, notification to data subjects can be skipped if the breach is “unlikely to result in a high risk” to their rights and freedoms. No such exception exists in the DPDP Act. Every breach, regardless of severity, must be notified to both the DPBI and affected Data Principals. This is one of the most operationally significant distinctions for organisations transitioning from GDPR compliance.
2. The Two-Stage DPBI Notification Process
Stage 1: Initial Notification — “Without Delay”
Upon becoming aware of a personal data breach, the Data Fiduciary must send a preliminary notification to the DPBI “without delay.” This is not the 72-hour deadline — this is an immediate alert. In practice, this means within hours of formal organisational awareness, not the next business day.
The initial notification must include, at minimum:
- The nature of the breach (unauthorised access, ransomware, accidental disclosure, insider threat, etc.)
- The extent — number of Data Principals estimated to be affected
- The timing — when the breach occurred (if known) and when it was detected
- The location — which systems, data stores, or services were compromised
- The likely impact on Data Principals
Stage 2: Detailed Report — Within 72 Hours
Within 72 hours of awareness (or a longer period if the DPBI grants an extension), the Data Fiduciary must submit a comprehensive breach report. Rule 7 specifies the content:
| Required Element | What to Include |
|---|---|
| Broad facts and root cause | How the breach occurred, technical details of the vulnerability or failure exploited |
| Mitigation measures | Actions taken to contain the breach and prevent further exposure |
| Responsible parties | Whether the breach was caused by external attackers, insiders, or vendor failure |
| Recurrence prevention | Security improvements implemented or planned to prevent a repeat |
| Data Principal notification summary | How many individuals were notified, through which channels, and when |
The 72-Hour Clock: When Does It Start?
This is the most critical operational question. The clock starts from when the Data Fiduciary “becomes aware” — not from when the breach occurred. A breach may have started weeks earlier, but your notification obligation is triggered at the moment of formal organisational awareness.
Practically, this means your incident detection and escalation process determines when the clock starts. If a security analyst detects an anomaly on Monday but doesn’t escalate to the incident response team until Wednesday, the clock arguably started Monday. Your incident response procedures must define a clear escalation trigger that constitutes “organisational awareness.”
3. Notifying Affected Data Principals
Simultaneously with the DPBI notification, you must notify every affected Data Principal. Rule 7 requires this notification to be in “concise, clear and plain language” delivered through the individual’s registered communication channel (email, in-app notification, SMS, or similar).
The Data Principal notification must include:
- Description of the breach — nature, extent, and timing in plain language (no technical jargon)
- Data exposed — what categories of their personal data were compromised
- Likely consequences — what risks this creates for them specifically (identity theft, financial fraud, phishing risk)
- Measures taken — what you have done to contain the breach and protect their data
- Protective steps for them — concrete actions they can take (change passwords, enable 2FA, monitor accounts, freeze credit)
- Contact information — a named person or team they can contact with questions about the breach
Language requirement: If affected Data Principals have indicated a preferred Indian language, notifications must be provided in that language. The DPDP Act’s language accessibility obligation extends to breach notifications.
4. The Dual Obligation: CERT-In + DPBI
Most real-world data breaches — ransomware, unauthorised access, system compromise — simultaneously trigger two separate notification obligations under two different laws:
| Dimension | CERT-In (IT Act 2000) | DPBI (DPDP Act 2023) |
|---|---|---|
| Legal basis | CERT-In Directions, April 2022 | Section 8(6), DPDP Act + Rule 7 |
| Deadline | 6 hours from detection | Preliminary: without delay; Detailed: 72 hours from awareness |
| Who to notify | CERT-In (incident@cert-in.org.in) | Data Protection Board of India (portal TBC) |
| Scope | Any cybersecurity incident | Any personal data breach |
| Individual notification required | No | Yes — every affected Data Principal |
| Penalty for non-compliance | Up to ₹1 crore (IT Act) | Up to ₹200 crore (DPDP Act) |
| Enforceable from | Currently enforceable | May 13, 2027 (full enforcement) |
These are parallel obligations, not alternatives. Filing with CERT-In does not discharge your DPBI obligation, and vice versa. A single ransomware attack that encrypts customer data triggers: CERT-In notification within 6 hours + DPBI preliminary notification without delay + DPBI detailed report within 72 hours + individual notifications to every affected customer.
If you are in a regulated sector (banking, insurance, payments), you may also have sector-specific breach notification obligations to the RBI, IRDAI, or SEBI — each with their own timelines and formats. Your incident response plan must address all applicable obligations simultaneously.
5. What Counts as a “Personal Data Breach”?
The DPDP Act does not define “personal data breach” with the same specificity as GDPR. Based on the Act’s framework, a personal data breach is any event that results in:
- Unauthorised access to personal data (external hacker, misconfigured cloud storage, insider access beyond authorisation)
- Accidental disclosure of personal data to unintended recipients (wrong email recipient, publicly exposed database, misconfigured API)
- Loss or destruction of personal data (ransomware encryption without backup, accidental deletion)
- Alteration of personal data without authorisation (data manipulation, falsification)
The threshold question many organisations ask is: “Does this require notification?” Under the DPDP Act, the answer is almost always yes if personal data was involved. The absence of a materiality filter means your incident classification and notification decision framework needs to be conservative — when in doubt, notify.