DPDPA Data Breach Notification Obligations — Complete Guide

Personal data breaches carry severe consequences under DPDPA 2023. The Act imposes two distinct obligations on Data Fiduciaries: implementing security safeguards to prevent breaches (Section 8(4)), and notifying authorities and affected individuals when breaches occur (Section 8(6)). The penalty for failing to notify can reach Rs. 250 crore per incident — making breach management one of the highest-risk compliance areas for Indian businesses.

What Counts as a Personal Data Breach Under DPDPA

Section 2(u) defines a "personal data breach" as any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data that compromises the confidentiality, integrity, or availability of personal data.

This includes but is not limited to:

External attacks — Hacking, ransomware, phishing-led data exfiltration, SQL injection, credential stuffing, or any unauthorised external access to systems containing personal data.
Insider incidents — Unauthorised access by employees, deliberate data theft by insiders, or accidental exposure by staff sending data to wrong recipients.
Accidental exposure — Misconfigured cloud storage (public S3 buckets), unprotected APIs, exposed databases, or accidental publication of personal data.
Loss of access — Ransomware that encrypts data (even without exfiltration), hardware failures causing irrecoverable data loss, or deletion of data without backup.
Third-party breaches — Breaches at Data Processors that affect your Data Principals' personal data. The Data Fiduciary remains responsible regardless of where the breach occurred.
Physical breaches — Theft of laptops, hard drives, or paper records containing personal data.

Section 8(6) — Notify the DPB Without Delay

Section 8(6) requires Data Fiduciaries to notify the Data Protection Board and each affected Data Principal of a personal data breach. The standard is "without delay" — the Act does not specify an exact hour count (unlike CERT-In's 6-hour requirement or GDPR's 72-hour requirement).

"Without delay" in legal interpretation means as soon as reasonably possible after becoming aware of the breach. This includes a reasonable time for initial assessment to confirm a breach has occurred, but does not permit extended investigation before notification. Best practice is to notify within 72 hours of confirmation, consistent with international standards.

Key aspects of the notification duty:

Dual notification — Both the DPB AND each affected Data Principal must be notified. These are separate obligations; notifying one does not satisfy the requirement for the other.
Trigger point — The clock starts when the Data Fiduciary becomes "aware" of the breach. Awareness means actual knowledge or when the organisation reasonably should have known (e.g., monitoring systems detected anomalies).
Scope determination — It is acceptable to notify with preliminary information and supplement with details as the investigation progresses, rather than delaying notification until the full scope is known.
All affected principals — Every Data Principal whose data was affected must be individually notified. Mass-mailing is acceptable, but a blog post or website notice alone is insufficient.

Rule 7 — What the DPB Notification Must Contain

Rule 7 of the DPDPA Rules 2025 prescribes the mandatory content of a breach notification to the Data Protection Board. The notification must include:

Nature of the breach — A description of what happened: was it unauthorised access, exfiltration, destruction, loss of availability, or a combination? What systems were affected? How did the breach occur (if known)?
Personal data affected — The categories of personal data compromised (names, email addresses, financial data, health records, etc.). The specificity should match the data actually exposed, not a generic list of all data the organisation holds.
Approximate number of Data Principals affected — An estimate of how many individuals' data was compromised. This can be an approximation at the time of initial notification, with updates as the investigation progresses.
Likely consequences of the breach — An assessment of the potential impact on affected Data Principals: risk of identity theft, financial fraud, discrimination, reputational damage, or other harms.
Measures taken or proposed — What the Data Fiduciary has done or plans to do to mitigate the breach and reduce harm: containment actions, systems patched, affected credentials revoked, affected individuals advised on protective steps.

Notifying Affected Data Principals

The notification to Data Principals has different requirements from the Board notification. The individual notification should:

Be in plain language — Data Principals are not technical experts. Avoid jargon. Clearly explain what happened and what it means for them.
Include protective guidance — Tell individuals what steps they should take: change passwords, monitor bank statements, be alert to phishing attempts, etc.
Provide contact information — A way for affected individuals to reach the Data Fiduciary for further information or assistance.
Not minimise the incident — Be factual and transparent. Downplaying the severity can increase penalties and reputational damage.
Be delivered directly — Use the communication channel most likely to reach the individual (email, SMS, postal mail). A website notice or press release alone is insufficient.

48-Hour Pre-Deletion Notification (Rule 8(2))

Rule 8(2) introduces a distinct notification obligation that is often confused with breach notification but is entirely separate:

What it is — Before deleting personal data (whether following consent withdrawal, purpose fulfilment, or retention period expiry), the Data Fiduciary must notify the Data Principal at least 48 hours in advance.
Purpose — This gives the Data Principal the opportunity to request a copy of their data or take other action before deletion occurs.
Not a breach notification — This is a routine operational notification, not an incident notification. It applies to planned, lawful deletion of data.
Applies regardless of trigger — Whether deletion is triggered by consent withdrawal, purpose fulfilment, or retention period expiry, the 48-hour notice is required.

Immutable Incident Record Requirements

While DPDPA does not explicitly mandate an incident register, maintaining one is essential for demonstrating compliance:

Timeline documentation — Record when the breach was detected, when management was informed, when the Board was notified, and when Data Principals were notified. Any delay must be justifiable.
Decision log — Document all decisions made during the incident: containment actions, forensic investigation steps, communication decisions, and rationale for each.
Evidence preservation — Maintain forensic evidence, system logs, and communication records. These may be required by the Board during an inquiry.
Immutability — Incident records should be append-only and tamper-evident. The Board will scrutinise any evidence of post-hoc modification of incident records.
Retention — Incident records should be retained for at least the period during which a complaint could be filed with the Board (not yet specified, so at least 3-5 years is prudent).

Penalties for Breach-Related Non-Compliance

DPDPA imposes the heaviest penalties for breach-related failures:

Up to Rs. 200 crore — Failure to implement reasonable security safeguards to prevent a breach (Section 8(4)). This applies even if the breach has not yet occurred — inadequate security is itself a violation.
Up to Rs. 250 crore — Failure to notify the Board and/or affected Data Principals of a breach (Section 8(6)). This is the highest single-violation penalty in DPDPA.
Up to Rs. 50 crore — Other non-compliance (e.g., inadequate incident records, obstructing a Board inquiry).
Up to Rs. 500 crore — Repeat offences. A company with a history of breaches and non-notification faces significantly elevated penalties.

The Board considers aggravating factors: prior breaches, failure to implement recommendations from earlier proceedings, financial gain from the breach, deliberate concealment, and the duration of non-compliance. Mitigating factors include: prompt notification, cooperation with investigation, proactive remediation, and voluntary compensation to affected individuals.

DPDPA vs CERT-In 6-Hour Reporting

Indian businesses face two parallel but distinct cyber incident reporting obligations:

CERT-In Direction (April 2022) — Requires reporting of all cyber security incidents to CERT-In within 6 hours of detection. This is under the IT Act 2000 (Section 70B) and applies to all cyber incidents, not just personal data breaches. The scope is broader (includes DDoS, website defacement, malware) and the timeline is much shorter.
DPDPA Section 8(6) — Requires notification to the Data Protection Board and affected Data Principals "without delay" for personal data breaches specifically. The scope is narrower (only personal data breaches) but the consequence is more severe (up to Rs. 250 crore).

Key differences between the two obligations:

Authority — CERT-In (under MeitY) vs Data Protection Board (under DPDPA)
Timeline — 6 hours vs "without delay" (interpreted as 72 hours best practice)
Scope — All cyber incidents vs personal data breaches only
Penalty authority — IT Act penalties vs DPDPA Schedule penalties (up to Rs. 250 Cr)
Notification recipients — CERT-In only vs DPB + affected Data Principals
Both apply simultaneously — A personal data breach typically triggers both obligations. Reporting to CERT-In does not satisfy the DPDPA notification requirement and vice versa.

DPDPA Shield's Breach Management

DPDPA Shield provides an end-to-end breach incident management system including: automatic severity classification, 72-hour countdown timer for regulator notification, CERT-In format report generation, Board notification format, affected Data Principal notification system, evidence upload to immutable storage with SHA-256 proof hashes, real-time activity timeline, status workflow tracking (from detection through resolution), and Slack integration for war-room coordination on high-severity incidents.