DPDPA Breach Notification: The 72-Hour Requirement, What Must Be Reported, and How Tokenisation Changes Your Exposure

Section 8(6) of the Digital Personal Data Protection Act 2023 requires Data Fiduciaries to implement reasonable security safeguards and to notify the Data Protection Board and affected Data Principals in the event of a personal data breach.

DPDPA defines a personal data breach 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 captures:

• External attacks: ransomware, data exfiltration, unauthorised access by third parties
• Internal incidents: employee accessing data without authorisation, accidental sharing of files with incorrect recipients
• System failures: unintended data exposure due to misconfigured access controls, database errors that make data publicly accessible
• Physical breaches: theft of devices containing personal data, loss of paper records containing personal data

Notably, DPDPA does not include GDPR's materiality threshold — the Act does not limit notification obligations to breaches "likely to result in a risk to rights and freedoms." Any breach that compromises confidentiality, integrity, or availability of personal data triggers the obligation.

The DPDP Rules 2025 set a 72-hour window for notification to the Data Protection Board following a personal data breach. The critical question is when the clock starts — awareness of the breach, or the time the breach actually occurred.

The Rules are clear: the clock starts from the point the Data Fiduciary becomes aware of the breach. This is operationally important — a breach that occurred three weeks ago but was only discovered today starts the 72-hour clock today, not three weeks ago.

What "becomes aware" means in practice:

• Your security operations team flags an anomalous exfiltration event — clock starts
• A third-party processor notifies you of a breach affecting your data — clock starts on receipt of their notification
• A Data Principal reports that their data appeared in a public leak — clock starts on receipt of the report
• Automated monitoring alerts indicate unauthorised access — clock starts on the alert, not when a human reviews it

The 72-hour window is tight. Organisations that don't have a pre-built DPB notification workflow will struggle to meet it — particularly for incidents that occur outside business hours.

Under DPDPA, breach notification flows in two directions: to the Data Protection Board and to affected Data Principals.

Notification to the Data Protection Board: The 72-hour window applies to DPB notification. The notification must go to the Board's digital platform (once operational) and must contain the specific information prescribed by the Rules.

Notification to Data Principals: Affected individuals must also be notified, but the Rules do not specify that this must happen within 72 hours. Best practice is to notify individuals promptly after the DPB has been notified — ideally within 24–48 hours of the DPB notification. The individual notification must be in plain language, must describe the breach and the data affected, and must tell individuals what steps they should take to protect themselves.

A critical operational point: you need to be able to identify which Data Principals were affected by a given breach. If your data architecture doesn't support efficient individual-level breach impact assessment, you'll either over-notify (sending notifications to everyone whose data you hold, creating unnecessary alarm) or under-notify (missing affected individuals, creating enforcement exposure).

The DPDP Rules 2025 specify the content requirements for breach notifications to the Data Protection Board. The notification must include:

• Nature of the breach: What type of incident occurred — exfiltration, ransomware, accidental exposure, insider access
• Data categories affected: What categories of personal data were compromised — financial data, health data, contact information, authentication credentials
• Number of Data Principals affected: An estimate of how many individuals' data was compromised, with a note that this is an estimate if the investigation is ongoing
• Likely consequences of the breach: What harm could result from the breach — identity theft, financial loss, reputational harm
• Measures taken or proposed: What the Data Fiduciary has done or is doing to contain the breach and prevent recurrence
• Contact details of the DPO (for SDFs) or the responsible officer for the Data Protection Board to contact

Preparing these notifications in 72 hours while simultaneously managing the incident response is operationally demanding. Pre-built notification templates and a clear internal workflow are prerequisites for meeting the timeline.

Not all breaches are equal under DPDPA. The notification obligation is triggered by a breach that "compromises the confidentiality, integrity or availability of personal data." If the data that was exfiltrated or exposed is not personal data — because it has been tokenised — the breach may not trigger the notification obligation at all.

Tokenisation replaces sensitive personal data with non-sensitive tokens before the data is stored, processed, or transmitted. The token has no meaning outside the tokenisation system — it cannot be used to identify an individual, cannot be used to access their accounts, and reveals nothing about them. If a tokenised database is exfiltrated, the attacker has acquired meaningless tokens, not personal data.

Privault by OpenBlockAI provides PII, PHI, and PCI tokenisation at the point of data ingestion — before data is stored in your databases, analytics systems, or transmitted to processors. For organisations that have tokenised their sensitive data stores, a database breach may not require DPB notification or individual notification because the exfiltrated data is not personal data within the meaning of DPDPA.

This is not a legal loophole — it is the correct application of the law. Tokenisation doesn't just reduce breach notification exposure; it reduces the actual harm to individuals from a breach, which is the underlying purpose of the notification requirement.

A DPDPA-ready incident response plan has specific components that GDPR-era plans may lack:

• A 72-hour notification workflow with pre-assigned roles, pre-built DPB notification templates, and a defined escalation path that doesn't require a management meeting to activate
• A breach impact assessment tool — a way to quickly identify which Data Principals were affected, what data categories were compromised, and how to contact them
• An individual notification template library in multiple languages, since affected Data Principals may not be English speakers
• A post-incident documentation protocol that creates the audit trail the Board may request — timeline of discovery, notification timestamps, containment actions taken
• A tabletop exercise schedule — run the breach response plan at least twice a year to ensure everyone knows their role when a real incident occurs

The 72-hour window is unforgiving. The organisations that will meet it are the ones that have built and rehearsed the workflow before they need it, not the ones that assemble a task force when the incident occurs.