What Is a Data Breach Under the DPDP Act? 72-Hour Rule Explained

What Is a Personal Data Breach Under the DPDP Act?

Section 2(t) of the Digital Personal Data Protection Act 2023 defines a personal data breach as any breach of security safeguards leading to accidental or unlawful:

• Destruction of personal data
• Loss of personal data (loss of control or possession)
• Alteration of personal data (unauthorised modification)
• Unauthorised disclosure of personal data (access by unintended parties)
• Unauthorised access to personal data (any access without authorisation)

In plain terms: if something goes wrong with your security controls and personal data is affected — in any of the five ways above — you have a personal data breach under the DPDP Act.

Examples that clearly qualify as a DPDP breach

• A ransomware attack that encrypts customer records — this is destruction and loss of access
• A database left exposed to the internet, accessible without authentication — unauthorised access and disclosure
• An insider copying customer data to a personal device before leaving — unauthorised access and disclosure
• A third-party vendor breach exposing personal data you shared with them — disclosure via a Data Processor failure
• A phishing attack giving an attacker access to an employee email account containing customer data — unauthorised access
• Accidental exposure of a file containing customer records due to a misconfigured cloud storage bucket — unauthorised disclosure

What is NOT a data breach under the DPDP Act

• Processing personal data that a Data Principal explicitly consented to — lawful processing is not a breach
• Internal access by authorised personnel carrying out their normal duties
• Incidents involving only anonymised data — data that cannot be re-identified is not personal data under the Act
• System outages or downtime that do not result in data exposure, loss, or corruption

What Is the 72-Hour Breach Notification Rule Under the DPDP Act?

The 72-hour clock starts the moment the Data Fiduciary becomes aware of the breach — not from when the breach occurred, which may have been days, weeks, or months earlier.

Within 72 hours of becoming aware, you must notify:

1. The Data Protection Board of India — the supervisory authority established under the DPDP Act
2. Affected Data Principals — every individual whose personal data was involved in the breach

Both notifications must happen within the 72-hour window. The draft DPDP Rules 2025 are expected to specify the exact notification format and the portal through which Board notifications are submitted.

Key numbers at a glance

What Must a DPDP Breach Notification Include?

A breach notification to the Data Protection Board — and to affected Data Principals — must contain sufficient information to allow the recipient to understand what happened and what it means for them. Based on the DPDP Act and emerging regulatory guidance, a complete notification must address:

• 01
  Nature of the breach

  What happened — how the breach occurred, which systems were involved, and what security failure allowed it. Be specific: a ransomware attack is different from an accidental misconfiguration, and the Board needs to understand the mechanism.

• 02
  Categories and types of personal data affected

  What kinds of personal data were involved — names, contact details, financial records, health data, government IDs, passwords, biometric data. Sensitive data categories require emphasis. Also specify the approximate volume of data records affected.

• 03
  Approximate number of Data Principals affected

  How many individuals' personal data was involved in the breach. An exact number is not required in an initial notification — an honest estimate is acceptable, with a commitment to provide the precise figure in your follow-up notification.

• 04
  Likely consequences of the breach

  What harm could result for the affected individuals — identity theft risk, financial fraud exposure, reputational damage, physical safety concerns. This assessment must be honest; understating consequences is a compliance failure in itself.

• 05
  Remedial measures taken or proposed

  What you have done — or will do — to contain the breach, recover affected data, close the vulnerability, and prevent recurrence. Demonstrating a concrete remediation plan is a mitigating factor in any subsequent Board investigation.

• 06
  Contact point for the Data Protection Board

  A named individual and contact details within your organisation — typically the Data Protection Officer if you have one, or a designated senior manager — who the Board can reach for follow-up enquiries.

Partial initial notification is expected. If full information is not available within 72 hours — which is common in the early stages of a major breach — you file an initial notification with what you know and commit to a follow-up notification with complete details as your investigation matures.

What Happens If You Fail to Report a Data Breach Under the DPDP Act?

The DPDP Act's penalty structure for breach notification failures is severe and deliberately structured to make non-disclosure more costly than disclosure.

• ₹200 crore (approximately $24 million USD) — penalty for failure to notify the Data Protection Board of a personal data breach
• ₹250 crore (approximately $30 million USD) — penalty for failure to implement adequate security safeguards that led to the breach occurring in the first place
• Both penalties can be imposed simultaneously — total maximum exposure of ₹450 crore for a single breach that was inadequately secured and not reported

The Data Protection Board's investigation process works as follows: the Board receives a complaint (from a Data Principal, a third party, or its own monitoring) or acts suo motu (on its own initiative). It issues a show cause notice, conducts an adjudication, and issues an order that may include a financial penalty, a direction to remediate, and a requirement for a compliance audit. There is an appeals process to the Telecom Disputes Settlement and Appellate Tribunal (TDSAT).

The penalty structure is designed to ensure that the cost of hiding a breach is always higher than the cost of disclosing it. ₹200 crore for non-notification, on top of whatever reputational damage emerges when the breach becomes known anyway, leaves no rational business case for concealment.

Who Must You Notify — The Board, Individuals, or Both?

Both. Always both.

Unlike GDPR, which gives organisations flexibility to skip individual notification for breaches "unlikely to result in risk" to Data Principals, the DPDP Act's current framework does not contain this exemption. The baseline obligation is to notify both the Data Protection Board and affected Data Principals for every personal data breach.

The draft DPDP Rules 2025 are expected to introduce a classification of "significant" breaches that trigger enhanced Board reporting — more detail, faster timelines, or additional escalation requirements. But this is expected to layer on top of the baseline dual-notification obligation, not replace it.

Notifying Data Principals — what this means in practice

Notification to affected individuals must be in plain language — not legal boilerplate. It should explain:

• What happened and when
• What personal data was affected
• What risks the individual may face as a result
• What steps they should take to protect themselves (change passwords, monitor accounts, etc.)
• What you are doing to address the breach
• Who to contact with questions

Individual notification must reach the actual affected individuals — mass media notification (press releases, website banners) does not satisfy the DPDP individual notification obligation unless the Board specifically approves this method where direct contact is not feasible.

Does the DPDP Act Cover Third-Party Vendor Breaches?

Yes — and this is one of the most practically important aspects of the DPDP breach framework for Indian businesses.

If a Data Processor (a vendor, contractor, or cloud provider) suffers a breach affecting personal data that you — as Data Fiduciary — shared with them under contract, the notification obligation falls on you. The Data Processor has no direct DPDP Act obligation to notify the Data Protection Board; their obligation runs to you through your contract.

This has two critical operational implications:

1. Your vendor contract must require immediate breach notification to you. If your vendor discovers a breach affecting your data at 9pm, they must notify you immediately — not the next business day. Your 72-hour clock runs from when you learn of the breach, but courts and regulators may take a dim view if your contracts allowed your vendor 48 hours to tell you before you even knew to start the clock.
2. Your 72-hour clock may already be running before your vendor tells you. Under a strict reading, if a vendor was aware of a breach for 48 hours before notifying you, a regulator could argue that your 72-hour window was effectively down to 24 hours by the time you found out. This underlines the urgency of contractual breach notification requirements and regular vendor security monitoring.

What Is a 72-Hour DPDP Breach Response Plan?

A 72-hour breach response plan is the operational playbook your organisation follows from the moment a potential breach is detected to the moment your Board notification is filed. The five phases below reflect the DPDP Act's requirements and the realities of incident response.

• 01
  Hours 0–12 — Detection & Triage

  Confirm and scope the breach

  • Confirm the incident is a genuine breach — not a false positive or a drill
  • Identify which systems and data stores are affected
  • Determine what categories of personal data are involved
  • Preserve evidence — do not wipe logs or affected systems before forensics
  • Activate your incident response team
• 02
  Hours 12–24 — Assessment & Escalation

  Assess scope and brief leadership

  • Determine how many Data Principals are affected (estimate if necessary)
  • Assess the likely consequences — what harm could individuals face?
  • Brief your legal team, security leadership, and senior management
  • Begin drafting your Board notification
  • Identify your contact point for the Data Protection Board
• 03
  By Hour 72 — Board Notification

  File initial notification with the Data Protection Board

  • Submit initial notification — partial information is acceptable at this stage
  • Commit to a follow-up notification with complete details
  • Notify affected Data Principals simultaneously (or immediately after Board notification)
  • Individual notification must be in plain language and actionable
• 04
  Ongoing from Hour 1 — Containment

  Stop the bleeding

  • Isolate affected systems from your network
  • Revoke and reset compromised credentials
  • Close the specific vulnerability that was exploited
  • Implement compensating controls where a permanent fix takes time
  • Engage a forensics firm if the breach scale or complexity warrants it
• 05
  72 Hours+ — Remediation & Follow-up

  Restore, remediate, and report

  • Complete your Board notification with full details as facts become clear
  • Provide Data Principals with additional guidance as your investigation matures
  • Conduct a root cause analysis to understand how the breach happened
  • Implement permanent fixes and document them
  • Update your risk register and security controls based on lessons learned

How Does DPDP Breach Notification Compare to GDPR?

For organisations already operating under GDPR, the DPDP breach notification framework will feel familiar in structure but has meaningful differences in scope.

The most significant operational difference: under GDPR, organisations can make a risk-based assessment and decide not to notify individuals for low-risk breaches. The current DPDP Act framework does not clearly provide this exemption — individual notification appears required for all personal data breaches involving your data. The final DPDP Rules may introduce nuance here, but do not plan on a low-risk exemption until it is explicitly codified.

What Breach Prevention Measures Does the DPDP Act Require?

Section 8(5) of the DPDP Act requires every Data Fiduciary to implement reasonable security safeguards to prevent personal data breaches. "Reasonable" is deliberately undefined — it is assessed relative to the nature, volume, and sensitivity of the personal data being processed.

In practice, industry standards serve as the reference point for what "reasonable" means:

• ISO 27001 — information security management system standard, widely recognised as the baseline for systematic security controls
• SOC 2 Type II — audit-backed validation of security, availability, and confidentiality controls, particularly relevant for cloud and SaaS organisations
• NIST Cybersecurity Framework — the identify-protect-detect-respond-recover framework used globally as a breach prevention reference

Key preventive measures the Board is likely to assess after a breach:

• Encryption of personal data at rest and in transit
• Access controls and least-privilege principles — was the breached account more privileged than needed?
• Multi-factor authentication on systems that hold personal data
• Regular vulnerability assessments and penetration testing
• Security monitoring and alerting — how long did the breach go undetected?
• Employee security awareness training
• Vendor security assessments and contractual controls
• Incident response plan — was there one, and was it followed?

Significant Data Fiduciaries face additional scrutiny through mandatory Data Protection Impact Assessments (DPIAs) and independent data audits, which effectively require them to demonstrate adequate safeguards on a periodic basis — not just after a breach occurs.