DPDP Act Data Breach Notification Requirements India — Complete 72-Hour Guide 2026

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 will require, 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

Commencement — read this first. Section 8(6) of the DPDP Act creates the breach-intimation duty, but expressly leaves the form and manner to be prescribed. Rule 7 of the DPDP Rules 2025 is what prescribes that procedure. The Rules were published in the Official Gazette on 14 November 2025 and, under Rule 1(2), Rules 3 and 5 to 16 — which include Rule 7 — come into force eighteen months after publication, in May 2027. The Rule 7 procedure below is therefore not yet operative. We set it out now because it defines the capability organisations need to build and test during this window. Verify the exact commencement date with your legal adviser before relying on it.

Section 8(6) of the DPDP Act 2023 establishes the breach notification obligation:

“In the event of a personal data breach, the Data Fiduciary shall give the Board and each affected Data Principal, intimation of such breach in such form and manner 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 framework will require notification to both the regulator and every affected individual, with no materiality threshold on the face of the Act or Rule 7.

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. Once Rule 7 commences, every breach — regardless of severity — will require notification 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:

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 prescribes that this notification 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:

1. Description of the breach — nature, extent, and timing in plain language (no technical jargon)
2. Data exposed — what categories of their personal data were compromised
3. Likely consequences — what risks this creates for them specifically (identity theft, financial fraud, phishing risk)
4. Measures taken — what you have done to contain the breach and protect their data
5. Protective steps for them — concrete actions they can take (change passwords, enable 2FA, monitor accounts, freeze credit)
6. 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:

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.

6. Processor Breach Notification to Fiduciary

If the breach occurs at your Data Processor (a cloud provider, SaaS vendor, HR platform), your notification clock still starts from when you become aware — not from when the processor detects it. This creates a critical dependency: your processor must notify you immediately upon detection so you can meet your obligations.

Your Data Processing Agreements must therefore include a processor breach notification clause requiring: immediate notification (within 6 hours of the processor’s detection), a designated contact person, an initial incident report, and ongoing updates. A processor that notifies you 48 hours after detecting a breach may cause you to miss your statutory 72-hour deadline — and you bear the full regulatory consequence.

See our guide on Data Processing Agreements under the DPDP Act for the specific clause language required.

7. The 72-Hour Incident Response Playbook

1. Hour 0–2 — Detect, contain, escalate: Activate incident response team. Isolate affected systems. Escalate to DPO, CISO, legal. Formally declare the incident — this starts your awareness clock. Assign an incident commander with authority to make rapid decisions.
2. Hour 0–6 — CERT-In notification: File cybersecurity incident report with CERT-In (incident@cert-in.org.in). Include incident type, affected systems, timeline, initial scope. This obligation runs concurrently with DPDP Act obligations.
3. Hour 2–12 — Preliminary DPBI notification: File the “without delay” initial alert to the DPBI via the designated portal. Include nature, extent, timing, location of breach, and likely impact. Use what you know — a preliminary notification with incomplete information is better than a late comprehensive one.
4. Hour 6–24 — Data Principal notifications: Draft and send breach notifications to all affected Data Principals via their registered channels. Use plain language. Include all six required elements (see Section 3). Have a customer support team ready for incoming queries.
5. Hour 24–72 — Detailed DPBI report: Compile the full breach report. Engage forensic investigators if needed. Submit before the 72-hour deadline. If more time is needed, proactively request an extension from the DPBI before the deadline expires.
6. Post-72h — Remediation and review: Formal post-incident review. Update security controls, DPA clauses, and incident response procedures. Document all actions. Preserve all evidence and records for at least 7 years — this is your defence evidence in any DPBI proceeding.

8. Penalties for Breach Notification Failures

These penalties are per-contravention, and multiple contraventions arising from the same breach can stack. An organisation that fails to implement security safeguards AND fails to notify the DPBI AND fails to notify affected individuals faces up to ₹650 crore in cumulative penalties from a single incident — before any civil claims from affected individuals.

9. Building DPDP-Ready Breach Response Capabilities

The 72-hour window is short. Organisations that try to build their response capability after a breach has occurred will fail the deadline. Readiness must be built before an incident happens. Key capabilities to build now:

• Incident detection tooling — SIEM, EDR, DLP, and cloud security monitoring configured to detect and alert on data exfiltration and unauthorised access in near real-time
• Documented escalation procedures — clear definition of what constitutes a “personal data breach,” who to escalate to, and how quickly — so the 72-hour clock starts at the right moment
• Pre-approved notification templates — DPBI preliminary notification, DPBI detailed report, and Data Principal notification templates reviewed by legal counsel in advance
• DPO authority and availability — your DPO must have 24/7 reachability and the authority to make breach notification decisions without board approval delay
• Processor notification clauses — all DPAs updated to require immediate (within 6 hours) processor-to-fiduciary breach notification
• Tabletop exercises — annual breach simulation exercises that rehearse the full 72-hour response against the DPDP Act timeline

Frequently Asked Questions: DPDP Act Data Breach Notification

What is the breach notification timeline under the DPDP Act?

Two stages under Rule 7: (1) preliminary notification to the DPBI without delay upon awareness, and (2) detailed report to the DPBI within 72 hours of awareness. Notification to affected Data Principals must also be sent without delay. The DPBI may grant extensions on the detailed report if requested.

Is there a materiality threshold — can we skip notification for minor breaches?

No. The DPDP Act has no materiality threshold. Every personal data breach — regardless of scale, sensitivity, or likely impact — must be notified to the DPBI and every affected Data Principal. This is a major operational difference from GDPR.

When does the 72-hour clock start?

From the moment the Data Fiduciary “becomes aware” of the breach. Not when the breach occurred. Your incident escalation and detection procedures effectively control this trigger — ensure your organisation defines a clear point of “formal awareness.”

What is the difference between CERT-In and DPBI notification?

CERT-In notification (6 hours, IT Act 2000) covers cybersecurity incidents. DPBI notification (without delay + 72 hours, DPDP Act) covers personal data breaches. Both may be triggered by the same incident. They must be filed separately — one does not satisfy the other.

What happens if a Data Processor causes the breach?

The Data Fiduciary bears full regulatory liability under Section 8(1), regardless of which party caused the breach. Your Data Processor must notify you immediately upon detection (via your DPA’s breach notification clause), so you can meet your own DPBI and Data Principal notification obligations on time.

What is the penalty for missing the breach notification deadline?

Failure to notify the DPBI or affected Data Principals carries a maximum penalty of up to ₹200 crore per incident. Combined with penalties for the underlying security failure (up to ₹250 crore), a single poorly-handled breach could result in penalties exceeding ₹400 crore.

Related MYITMANAGER Guides

• DPDP Act Compliance Services — End-to-End Implementation
• Data Processing Agreement Under DPDP Act — Complete Guide
• Consent Manager India — DPDP Act Requirements 2026
• DPDP Act Compliance Checklist India 2026
• DPO as a Service — CIPP/E Qualified
• RBI Cybersecurity Guidelines 2026 — Banks and NBFCs

Could your organisation respond to a personal data breach effectively?