Data Breach Notification Under the DPDP Act: A Step-by-Step Guide for CISOs

Most CISOs have internalised one number about the DPDP Act: 72 hours. It is the wrong anchor.

Under the DPDP Act 2023 and the DPDP Rules 2025 (notified 13 November 2025), the clock that matters starts the moment your organisation becomes aware of a breach — not when your investigation closes. And the first hard external deadline is not 72 hours at all. For most enterprises it is 6 hours, set by a completely different regulator.

This guide breaks down what a breach is under DPDP, who you must notify and when, how the DPDP timeline collides with CERT-In's, and an 8-step response playbook you can operationalise before an incident hits.

What Counts as a Personal Data Breach Under DPDP

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

Two features of this definition trip up incident response teams that are used to thinking in GDPR or US-state-law terms.

1. Availability is in scope. "Loss of access" is explicitly listed. A ransomware lockout that encrypts your customer database — with zero exfiltration — is a reportable breach under DPDP because it compromises availability. So is an accidental deletion. You do not need data to leave the building for the obligation to trigger.

2. There is no harm threshold and no de-minimis exemption. The definition contains no materiality filter. A single misdirected email, one mis-scoped S3 bucket, an internal access-control slip — all meet the definition. As notified, DPDP requires you to report everything.

The Two-Stage Notification Timeline

Section 8(6), operationalised by Rule 7 of the DPDP Rules 2025, splits your obligation into two audiences — the Data Protection Board and the affected Data Principals — and the Board notification itself happens in two stages.

This is where the "72 hours" misconception does real damage. Let's separate the threads.

Stage 1 — "Without Delay" to the Board

On becoming aware of a breach, you must notify the Board without delay. There is no fixed hour count for this initial intimation. Rule 7 requires you to give the Board:

• the nature of the breach
• its extent
• its timing
• its location
• the likely impact

This is a fast, factual first flag — not a forensic report. It tells the Board an incident has occurred while you are still working the response.

Stage 2 — The 72-Hour Detailed Report

You must then provide the Board with a detailed report within 72 hours of becoming aware of the breach. This window is extendable, but only on written request to the Board with reasons.

The Stage 2 report is the substantive one. Under Rule 7 it must cover:

• the facts and circumstances, including the cause of the breach
• the mitigation measures taken
• who caused the breach, where known
• the remedial measures implemented to prevent recurrence
• a summary of the notifications sent to affected Data Principals

Notifying Affected Data Principals

Separately, you must inform each affected Data Principal without delay — in their own interest, in clear and plain language. Per Rule 7, that notification must include:

• a description of the breach: its nature, extent, and timing
• the likely consequences for that individual
• the mitigation measures you have implemented
• the safety measures the individual can take to protect themselves
• business contact details of a person able to respond to queries

DPDP vs CERT-In — the Dual-Reporting Trap

Here is the trap that catches Indian enterprises. The DPDP timeline is not your first external deadline. CERT-In's is.

Under the CERT-In Directions of 28 April 2022 (issued under Section 70B(6) of the IT Act 2000), organisations must report specified cyber incidents to CERT-In within 6 hours of noticing them. This is a separate obligation, to a different body, on a tighter clock — and it runs in parallel with DPDP, not instead of it.

The two regimes also carry fundamentally different teeth:

	DPDP Act	CERT-In Directions
Reporting body	Data Protection Board	CERT-In
First deadline	"Without delay" (Stage 1)	6 hours from noticing
Liability type	Civil only	Criminal (IT Act §70B(7))
Maximum consequence	₹200 crore (notification failure)	Imprisonment up to 1 year and/or fine

Because CERT-In carries criminal liability and the tightest clock, the 6-hour CERT-In deadline is the binding outer constraint on your first external report. Plan your incident response around 6 hours, and the DPDP "without delay" obligations fall comfortably inside it.

The Four-Channel Problem for BFSI

RBI-regulated entities face a third parallel channel. Depending on the applicable RBI Master Direction, critical incidents must be reported to the RBI — often within 2 to 6 hours. For a regulated fintech or bank, a single incident can therefore generate up to four parallel filings:

1. CERT-In — within 6 hours
2. RBI — per the applicable Master Direction (often 2–6 hours)
3. DPB Stage 1 + affected Data Principals — without delay
4. DPB Stage 2 — within 72 hours

This stacking is acute for BFSI. We cover it in depth in our guide to DPDP for fintech companies.

A Step-by-Step DPDP Breach Response Playbook

When an incident lands, run these eight steps in order. Steps 1–6 happen in parallel with the clock already running; Step 7 is the external-notification sequence.

1. Detect and triage. Confirm the event meets §2(u) — and remember that an availability event (ransomware, lockout, accidental deletion) qualifies even without exfiltration. If §2(u) is met, the breach is reportable; do not wait for "is it serious enough."

2. Contain. Isolate affected systems, revoke compromised credentials, cut off the attacker's path. Containment limits both harm and your eventual penalty exposure under §33(2).

3. Preserve evidence and start the clock. Record the exact "time of becoming aware" — this single timestamp starts your 72-hour Board clock and your 6-hour CERT-In clock. Preserve logs and forensic artefacts before they roll off or are overwritten.

4. Assess scope. Determine what categories of personal data were affected, how many Data Principals are involved, and the likely consequences for them. This feeds both the Board report and the individual notifications.

5. Legal and privacy review. Confirm every parallel obligation that applies: CERT-In (6h), RBI if regulated, the DPB, and the affected Data Principals. Decide here whether forensic work should be routed through legal counsel (see the privilege note below).

6. Draft notifications. Prepare two distinct versions — the Board report and the Data Principal notice — each populated against its Rule 7 content schema. They are not interchangeable; the Board report is forensic, the individual notice is protective and plain-language.

7. Notify externally, in sequence:

   • CERT-In — within 6 hours
   • DPB Stage 1 — without delay
   • Affected Data Principals — without delay
   • DPB Stage 2 — the detailed report within 72 hours

8. Remediate and document. Implement and record the measures that prevent recurrence. This documentation directly populates the "remedial measures" field of your 72-hour Stage 2 report and demonstrates the mitigation the Board must weigh under §33(2).

What Every Notification Must Contain

Two audiences, two content schemas under Rule 7. Keep them separate.

To the Data Protection Board (Stage 2 detailed report):

• Facts and circumstances, including the cause of the breach
• Mitigation measures taken
• Who caused the breach, where known
• Remedial measures implemented to prevent recurrence
• A summary of the notifications sent to affected Data Principals

To affected Data Principals (without delay):

• Description of the breach — nature, extent, and timing
• Likely consequences for that individual
• Mitigation measures you have implemented
• Self-protection steps the individual can take
• Business contact details for queries

Before the Breach — What CISOs Must Set Up Now

Breach response is won before the breach. Put these five things in place now:

• A named Incident Commander with the authority to start the clock and authorise external notifications out of hours.
• A registered CERT-In point of contact so the 6-hour filing has a clear owner and a known channel.
• Log retention of at least 180 days — CERT-In Directions mandate it, and it is also what lets you reconstruct scope under time pressure.
• Pre-drafted notification templates — separate Board and Data Principal versions, mapped to the Rule 7 fields, ready to populate.
• An evidence-preservation protocol that triggers automatically on detection, before logs roll off.

Penalties — the Two Stacking Heads

DPDP penalties for a breach come from two separate entries in the Act's Schedule, and a single incident can trigger both:

Failure	Section	Maximum penalty
Failure to take reasonable security safeguards	§8(5)	₹250 crore
Failure to notify the Board and affected Data Principals	§8(6)	₹200 crore

If a breach happened because your safeguards were inadequate (₹250 crore) and you then failed to notify properly (₹200 crore), the theoretical exposure from one incident is ₹450 crore.

DPDP has no GDPR-style safe harbour that exempts you from notifying if data was encrypted. But two levers reduce your exposure:

• Mitigation is a mandatory §33(2) factor. The speed and quality of your containment, notification, and remediation directly reduce the penalty quantum. This is why the playbook's Steps 2, 7, and 8 are not just operational — they are financial.
• Section 32 voluntary undertaking. Accepting a voluntary undertaking can bar proceedings altogether for the matters it covers.

Note the contrast with CERT-In: DPDP is civil only. The criminal exposure on a breach sits with the CERT-In and RBI channels, which is another reason not to treat DPDP as the whole picture.

DPDP vs GDPR — the Key Differences

If your incident response was built around GDPR, recalibrate. The regimes diverge on every line that matters for breach.

	GDPR	DPDP
Authority clock	72h from awareness	"Without delay" initial + 72h detailed report — two stages
Individual notification	Only if "high risk" to the individual	Always, without delay — no risk filter
De-minimis threshold	Yes (Art. 33(1))	No — report everything
Maximum penalty	€20m / 4% of global turnover	₹250cr safeguards / ₹200cr notification (fixed rupee caps)
Parallel regulators	DPA-centric	DPB + CERT-In (6h) + RBI / sectoral

The two most dangerous assumptions a GDPR-trained team carries into DPDP: that there is a risk-based filter on individual notification (there isn't), and that the data protection authority is the only regulator in the loop (CERT-In's 6-hour criminal-liability clock says otherwise).

For more on these divergences across the whole Act, see DPDP Act vs GDPR — key differences.

Frequently Asked Questions

Breach notification is one obligation in a much larger framework. For the full section-by-section picture of what the DPDP Act requires, read our plain-English DPDP Act guide.