DPDP Breach Notification: The 72-Hour Rule Explained
Almost every article on DPDP breach notification in India leads with “you have 72 hours.” That framing is wrong, and it is the kind of wrong that costs money.
Rule 7 of the DPDP Rules 2025 sets two clocks running from the same moment, and the shorter one has no number attached to it at all. Understanding which obligation carries which deadline is the difference between a defensible response and a second penalty stacked on top of the first.
DPDP breach notification: two clocks, not one
| Obligation | Who receives it | Deadline |
|---|---|---|
| Intimation of the breach | Every affected Data Principal | Without delay |
| Initial intimation | Data Protection Board | Without delay |
| Detailed report | Data Protection Board | Within 72 hours, or longer if the Board permits |
“Without delay” is not 72 hours. It is not “as soon as reasonably practicable” either. It is the strictest standard in the Rule, and it applies both to telling affected individuals and to the first alert to the Board. The 72 hours applies only to the comprehensive report that follows.
The clock starts when you become aware that a personal data breach has occurred — not when the incident happened, not when forensics concludes, and not when legal signs off.
What counts as a personal data breach
The Act defines it broadly: any unauthorised processing of personal data, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access, that compromises the confidentiality, integrity or availability of personal data.
Three consequences follow, and each surprises someone:
- Availability counts. A ransomware event that encrypts personal data without exfiltrating it is still a breach.
- Internal misuse counts. An employee accessing customer records outside their authorisation is unauthorised processing.
- There is no materiality threshold. Unlike the GDPR, which allows you to skip notifying the supervisory authority where a breach is unlikely to result in risk, Rule 7 contains no risk-based carve-out. A misdirected email containing one person’s data is, on the text, notifiable.
That last point is the single biggest divergence from a GDPR-shaped playbook, and it is why importing a European runbook wholesale is a mistake. We cover the wider divergence in GDPR vs the DPDP Act.
What you must tell affected Data Principals
Rule 7 requires intimation to each affected individual, through their registered contact method or user account, in clear and plain language. It must include:
- a description of the breach — its nature, extent and timing;
- the likely consequences relevant to that individual;
- the measures implemented and being implemented by you to mitigate risk;
- safety measures the individual can take to protect themselves;
- business contact information of a person able to respond to their questions.
Point five ties back to Rule 9 and the DPO contact requirement, which already requires you to publish that contact. If you have not named one, you will be inventing it during an incident — which is exactly when you cannot afford to.
Note “relevant to that individual.” A generic bulletin sent to your whole user base does not satisfy a requirement framed around consequences for the affected person.
What you must tell the Board
Immediately, without delay: the nature, extent, timing and location of the occurrence, and the likely impact.
Within 72 hours — or a longer period the Board permits on a reasoned written request:
- the broad facts, circumstances and reasons leading to the breach;
- risk mitigation measures implemented and proposed;
- findings regarding the person who caused the breach;
- remedial measures taken to prevent recurrence;
- a copy or summary of the intimations given to affected Data Principals.
Two things worth flagging. First, “findings regarding the person who caused the breach” has no GDPR equivalent — it presumes an attribution exercise inside 72 hours, which drives your forensic readiness requirements. Second, the extension is available but must be requested with reasons, in writing. It is not automatic and it is not retroactive.
The penalty exposure
| Default | Maximum penalty |
|---|---|
| Failure to take reasonable security safeguards | ₹250 crore |
| Failure to notify the Board or affected Data Principals | ₹200 crore |
| Breach of Significant Data Fiduciary obligations | ₹150 crore |
| Non-compliance with Board directions | ₹50 crore |
These are separate defaults. One incident can produce a safeguards failure, a notification failure and a direction failure — each of which the Data Protection Board can penalise. Appeals go to TDSAT within 60 days, and to the Supreme Court on questions of law. Full detail in DPDP Act penalties explained.
A 72-hour DPDP breach notification playbook
Hour 0 to 1 — Establish awareness
Record the timestamp at which a responsible person became aware that personal data was involved. That timestamp is the anchor for every subsequent deadline, and you will be asked to evidence it. Convene the incident team and appoint a single owner for regulatory communications.
Hour 1 to 6 — Scope and send the first Board intimation
You do not need the full picture. You need nature, extent, timing, location and likely impact — as currently understood. Send it. A short, accurate, clearly provisional intimation filed early is far better than a complete one filed late. State explicitly that details may be revised.
Hour 6 to 24 — Identify and notify affected individuals
This is where most organisations fail, because “without delay” collides with not knowing exactly who was affected. Work from your data map. If you cannot identify affected individuals from your own RoPA and data inventory within a day, that is the gap to fix before an incident, not during one.
Hour 24 to 60 — Contain, attribute, remediate
Containment evidence and attribution findings both feed the 72-hour report. Preserve logs. Document every decision with a timestamp — the report asks for circumstances and reasons, and reconstructed narratives read as reconstructed narratives.
Hour 60 to 72 — File the detailed report
Cover all five required elements. Attach the individual intimation template you actually used. If you genuinely cannot complete it, request an extension in writing with reasons before the deadline passes.
After — Prevent recurrence
The report commits you to remedial measures. The Board can ask what you did about them. Track them like audit findings, not like good intentions.
What to prepare before you need it
- A named regulatory-communications owner and a deputy, with authority to file without waiting for a committee.
- Pre-drafted templates for the Board intimation, the 72-hour report, and the Data Principal notice — reviewed by counsel in calm conditions.
- A current data map. Without one, “who was affected” takes days you do not have.
- Log retention sufficient to support attribution.
- Processor clauses requiring your vendors to notify you fast enough that you can still meet your own clock. A processor who tells you at hour 70 has consumed your entire window. See vendor risk management under DPDP.
- A tabletop exercise against a 72-hour clock, at least annually. Fold the findings into your wider DPDP compliance checklist.
How this interacts with CERT-In
DPDP breach notification does not replace your existing obligations. CERT-In directions impose their own reporting duty on a much shorter timeline for specified cyber incidents, and sectoral regulators — RBI, SEBI, IRDAI — impose their own. An incident involving personal data at a regulated entity can therefore trigger three or four separate reporting obligations with different deadlines, recipients and formats. Map them once, in advance, into a single trigger matrix. Sector-specific context in our guides for BFSI, hospitals and SaaS.
When does DPDP breach notification become enforceable?
Rule 7 sits in the tranche of obligations that take effect 13 May 2027, 18 months after the Rules were notified in November 2025. That is preparation time, not dormancy: an organisation that has not run a tabletop exercise before then will discover its gaps during a real incident. Full sequencing in our DPDP Rules 2025 timeline.
A worked example
A mid-sized Indian lender discovers at 9:40 pm on a Friday that a misconfigured storage bucket exposed loan application files. Here is where the clocks land.
Friday 21:40 — awareness. A security engineer confirms personal data is in the exposed bucket. That is the anchor timestamp. Not Monday morning when the CISO is briefed.
Friday 22:30 — first Board intimation. Nature: unauthorised access to a cloud storage bucket. Extent: approximately 40,000 loan applications, under investigation. Timing: exposure window under review, discovered 21:40 IST. Location: cloud storage in the Mumbai region. Likely impact: exposure of identity documents and financial details. Filed as provisional.
Saturday 08:00 to 16:00 — identification. The lender queries its data inventory to map application IDs to registered contact details. Because the RoPA was current, this takes eight hours. Without it, the same exercise routinely takes four to five days — which would have breached the “without delay” obligation for the individual intimations by a wide margin.
Saturday 18:00 — Data Principal intimation. Sent by SMS and email to registered contacts, in the language each applicant used at onboarding, describing the exposure, the specific documents involved, the credit-monitoring step the lender is funding, advice on watching for identity fraud, and a named contact.
Sunday to Monday — attribution and containment. Logs establish the misconfiguration date, the access pattern, and that a third-party integrator changed the bucket policy during a migration. That finding goes into the report.
Monday 20:00, hour 70 — detailed report filed. Circumstances, cause, the integrator’s role, containment, remediation including a policy-as-code control to prevent recurrence, and a copy of the individual intimation used.
The lender’s exposure is still real — a safeguards failure occurred. But it has not added a notification default on top, and it can evidence every decision with a timestamp. That is the achievable outcome.
Where DPDP breach notification actually fails
- Delayed awareness. The clock starts at awareness, so weak detection does not buy time — it just means the breach ran longer before the clock started, which the Board will read as a safeguards failure.
- Waiting for certainty. Teams sit on the first Board intimation until forensics is complete. “Without delay” does not admit that. File provisionally and revise.
- No way to identify affected individuals. The most common blocker. If your data map cannot answer “whose data was in this system” in hours, fix that first.
- Escalation that stalls out of hours. Most incidents are discovered outside business hours. If filing requires a committee that meets on Tuesdays, you have already missed.
- Processor silence. Vendor contracts that say “notify promptly” instead of “notify within 12 hours of awareness” hand your window to someone else.
- Generic notices. One bulletin to the whole user base does not describe consequences relevant to the individual.
- Remediation that never happens. The report is a commitment. Track it.
Template outlines
Have these drafted and legally reviewed before you need them. Fill-in-the-blank beats blank-page drafting at 2am.
Initial Board intimation — organisation and Data Fiduciary details; named contact; nature of the breach; extent, with numbers marked as provisional; timing of occurrence and of awareness; location; categories of personal data involved; likely impact; immediate containment; a statement that details may be revised.
72-hour detailed report — everything above, confirmed; broad facts and circumstances; root cause; findings on who caused the breach; risk mitigation implemented and proposed; remedial measures to prevent recurrence with owners and dates; the number of Data Principals intimated, when, and by what channel; a copy of the intimation text.
Data Principal intimation — plain language, no legal hedging; what happened and when; exactly which of their data was involved; likely consequences for them; what you have done; what they should do, with specific steps; the named contact and how to reach them; where to find updates.
Keep the individual notice under 400 words. Long notices do not get read, and an unread notice does not reduce harm.
Frequently asked questions
Is the DPDP breach notification deadline 72 hours?
Partly. Intimation to affected Data Principals and the initial intimation to the Board are both due “without delay.” The 72-hour deadline applies only to the detailed report to the Board.
When does the clock start?
On becoming aware that a personal data breach has occurred — not when the incident began, and not when investigation concludes.
Do we have to notify small breaches?
Rule 7 contains no materiality threshold and no risk-based exemption. On the text, every personal data breach is notifiable to the Board and to affected individuals.
Can we get an extension?
The Board may permit a longer period for the detailed report. Request it in writing with reasons, before the 72 hours expire. There is no extension for the “without delay” obligations.
What if our vendor caused the breach?
You remain the accountable Data Fiduciary. The obligation to notify is yours, and the report must include findings on who caused it. Build the notification timeline into your processor contracts.
Does DPDP notification replace CERT-In reporting?
No. They are parallel obligations with different timelines and recipients, and sectoral regulators may add more.
Can your team evidence hour zero? DPDP breach notification is won or lost on preparation. ProtectComply’s breach module runs Board notification and the 72-hour report against SLA timers, with the audit trail attached. Book a walkthrough, or see how breach readiness sits inside a full programme in our comparison of the best DPDP platform in India.