DPDP Act Data Breach Notification: 72-Hour Rule Explained
How the DPDP Act 2023 data breach notification obligation works — who to notify, within what timeframe, what information to include, and how to build an incident response plan.
- Section 8(6) requires Data Fiduciaries to notify the Data Protection Board and affected Data Principals of every personal data breach.
- The expected notification timeframe is 72 hours (to be confirmed in Rules) — comparable to GDPR's 72-hour rule.
- Failure to notify attracts a penalty of up to ₹200 crore — separate from the penalty for inadequate security.
- Notification must go to both the Board and the affected individuals — there is no "low risk" exception in the Act.
- Building a documented incident response plan before a breach occurs dramatically reduces both response time and regulatory exposure.
In this guide
The Statutory Breach Notification Obligation
Section 8(6) of the DPDP Act imposes a mandatory breach notification obligation on Data Fiduciaries. Every personal data breach must be notified to the Data Protection Board and to each affected Data Principal "in such form and manner as may be prescribed." This is not a risk-based threshold — unlike some older breach notification regimes, there is no "unless the breach is unlikely to result in risk" exception in the statute.
The obligation applies to all Data Fiduciaries regardless of size or sector. A startup with 10,000 users that suffers a breach of personal data must notify the Board and affected users just as a major financial services company must. The notification format and timeline will be specified in the Rules.
The penalty for failing to notify — up to ₹200 crore — is separate from and in addition to the penalty for failing to implement adequate security safeguards (up to ₹250 crore). A company that suffers a breach due to inadequate security and then fails to notify can face both penalties simultaneously.
What Constitutes a "Personal Data Breach"
"Personal data breach" is defined in Section 2(u) 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 is a broad definition. It covers: ransomware attacks that encrypt personal data (loss of availability); SQL injection attacks that exfiltrate customer records (unauthorised acquisition); employee accidentally emailing a spreadsheet to the wrong distribution list (accidental disclosure); misconfigured cloud storage bucket exposing personal data (accidental sharing); and insider theft of customer data (unauthorised use).
It also covers accidental internal events: a production database backup accidentally deleted without a recoverable copy (destruction or loss of access), or a software bug that corrupts personal data records (loss of integrity). The notification obligation is not limited to external attacks.
The 72-Hour Notification Timeline
The DPDP Act itself does not specify a numerical timeframe — it says notification must occur "in such form and manner as may be prescribed." The Draft DPDP Rules 2025 indicate a 72-hour initial notification requirement to the Data Protection Board, with a more detailed report to follow within a further period.
Seventy-two hours runs from the point at which you become "aware" of the breach — not from when the breach occurred. This distinction is significant: a breach that occurred three weeks ago but was detected today triggers the 72-hour clock from today. Your ability to meet the 72-hour timeline depends entirely on how quickly your detection and alerting systems surface breach events to responsible personnel.
GDPR experience has shown that the 72-hour timeline is difficult even for large, well-resourced organisations. Indian companies must invest in: security monitoring and alerting; clear internal escalation paths; pre-approved notification templates; and pre-identified breach response teams who know their role before a crisis occurs.
Who to Notify and What to Include
Board notification (the initial 72-hour report) is expected to include: a description of the nature of the breach; the categories and approximate volume of personal data and Data Principals affected; the likely consequences of the breach; and the measures taken or proposed to address it, including to mitigate its possible adverse effects.
The notification form will be specified by the Board once constituted. Expect an online portal submission process similar to that used by other regulators (SEBI, RBI, CERT-In). Note that CERT-In already has a 6-hour reporting requirement for cybersecurity incidents under its 2022 Directions — your CERT-In notification and Data Protection Board notification may both be triggered by the same incident.
A subsequent, more detailed report — sometimes called an "Article 33(3) equivalent" in GDPR parlance — will likely be required within a further period (possibly 30-72 days) with full forensic details, root cause analysis, and completed remediation evidence. Preserve all incident investigation documentation.
Notifying Affected Data Principals
Section 8(6) requires notification not just to the Board but to "each Data Principal" affected by the breach. This individual notification obligation is resource-intensive for breaches affecting large numbers of individuals. The Rules will specify the required content and delivery method.
Individual notifications are expected to include: a description of what data was exposed; the likely consequences; what the individual can do to protect themselves (e.g., change passwords, monitor financial accounts); and how to contact the Data Fiduciary for further assistance. Notifications must be in a language the individual can understand.
Pre-build your notification infrastructure before you need it. Maintain clean contact records (email, mobile number) for all Data Principals. Draft notification templates for different breach scenarios — account data exposure, payment data exposure, health data exposure — and have them legally reviewed. A mass notification to 500,000 affected users with 72 hours of a breach is only possible with pre-built infrastructure.
Building Your Incident Response Plan
An Incident Response Plan (IRP) for DPDP Act compliance must address: detection (how you find out about a breach), triage (how you assess severity and scope), containment (how you stop ongoing damage), notification (how you meet the 72-hour obligation), investigation (how you determine root cause), and remediation (how you prevent recurrence).
Define clear roles: who declares an incident, who leads the technical investigation, who handles regulatory notification, who communicates with affected users, and who updates the Board with follow-up reports. Include legal counsel, communications, and senior management in your IRP — a major breach is not just a technical event.
Test your IRP with a tabletop exercise at least annually. Run through a realistic scenario — a credential-stuffing attack that compromises 50,000 user accounts — and check: did the detection system alert within minutes or days? Did the escalation chain work? Could you produce a Board notification within 72 hours? Identify gaps and fix them before a real incident.
Maintaining a Breach Log for Compliance
Every personal data breach — even minor incidents that do not require Board notification — should be logged internally. Your breach log should record: date detected, date of incident (if known), nature of breach, data categories affected, number of individuals affected, whether notification was made and when, and post-incident remediation steps.
The Board may request your breach log during an inquiry. A well-maintained log demonstrates a mature security culture and the ability to detect, track, and learn from incidents. A company that has never documented a breach — even minor ones — may be viewed less favourably than one that shows proactive incident management.
AuditPath integrates breach log maintenance into your DPDP compliance dashboard, allowing you to track incident documentation as a control evidence item alongside your security safeguard controls and consent records.
Frequently Asked Questions
Does the DPDP Act notification obligation overlap with CERT-In's reporting requirements?
What if the breach was caused by a Data Processor (our cloud provider or SaaS vendor)?
Is a phishing attack that compromises employee credentials a notifiable breach?
Can we avoid notification if we immediately contain the breach before any data is exfiltrated?
How long do we need to retain breach documentation?
Automate your compliance today
AuditPath runs 86+ automated checks across AWS, GitHub, Okta, and 14 more integrations. SOC 2 and DPDP Act. Free plan available.
Start for free