Back to Blog
DPDP Act 8 min read

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.

Key Takeaways
  • 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.

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?
Yes, there is significant overlap. CERT-In's 2022 Directions require reporting of cybersecurity incidents (including data breaches) within 6 hours of detection. The DPDP Act will add a Board notification requirement (expected 72 hours). You may need to file both. Some companies appoint a single incident response team to manage both notifications, using the CERT-In report as a basis for the Board notification.
What if the breach was caused by a Data Processor (our cloud provider or SaaS vendor)?
The Data Fiduciary remains responsible for notification regardless of which party caused the breach. Section 8(6) places the obligation on the Data Fiduciary. You should have contractual requirements in your Data Processor agreements that: (a) require the Processor to notify you promptly upon discovering a breach, and (b) cooperate in your investigation and notification. Your 72-hour clock may start running from when your Processor notifies you.
Is a phishing attack that compromises employee credentials a notifiable breach?
If the compromised credentials gave the attacker access to personal data of customers or other individuals, yes — it is a notifiable breach under Section 8(6) because personal data was accessed by an unauthorised party. If the compromised credentials only gave access to non-personal internal systems, it may not be a personal data breach. Conduct forensic analysis to determine the scope of personal data exposure.
Can we avoid notification if we immediately contain the breach before any data is exfiltrated?
The Act requires notification of any "personal data breach" — which includes unauthorised access even if no data is confirmed to have been exfiltrated. In practice, if you can demonstrate through forensic evidence that access was immediately terminated before any data could be accessed, the risk to Data Principals is minimal, which would be a strong mitigating factor. However, if there is any uncertainty about the scope of access, notification is the safer course.
How long do we need to retain breach documentation?
The Rules will specify a retention period. Given that Board complaints can be filed retrospectively, retain breach documentation for at least 5 years. Retain incident investigation reports, notification records, and remediation evidence — these are your primary defence in any subsequent Board inquiry.

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