What is the DPDP breach notification requirement — timelines and obligations
A data breach triggers mandatory notification obligations under DPDP. Here is the complete timeline and what you must tell the Board and data principals.
What constitutes a personal data breach under DPDP?
A personal data breach is any accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. This includes: external cyber attacks (ransomware, SQL injection, credential stuffing); internal incidents (employee accidentally emailing customer data to the wrong recipient; misplacing a laptop with customer data); cloud configuration errors that expose a database to the internet; third-party Processor breaches where your customer data is affected; and physical breaches (stolen hardware, unauthorised physical access to a server room). Near-misses — where a vulnerability existed but no data was actually accessed — may not require notification, but must be documented and assessed.
What must the breach notification to the Board contain?
The breach notification must include: the nature of the breach (how it occurred, what systems were involved); the categories and approximate volume of personal data affected; the categories and approximate number of data principals affected; the likely consequences of the breach (risk of identity theft, financial fraud, reputation damage); the measures taken or proposed to address the breach and mitigate its effects; contact details of the DPO (for SDFs) or grievance officer; and whether data principals have been or will be notified. The Board may request additional information — be prepared to produce technical logs, incident timelines, and forensic reports.
When must data principals be notified of a breach?
Under DPDP, the Board decides whether and when to direct the Fiduciary to notify affected data principals — unlike GDPR where the Fiduciary makes this determination directly. If the Board directs notification, the Fiduciary must notify each affected data principal with: a description of what happened; what personal data was involved; the likely consequences for the individual; what the Fiduciary is doing to address the breach; what steps the individual can take to protect themselves (change passwords, monitor accounts, contact bank); and contact details for further enquiries. Notification must be in the data principal's preferred language.
How do you build a DPDP breach response plan?
Key components of a breach response plan: (1) Detection — what monitoring is in place to detect breaches promptly? (SIEM, DLP, anomaly detection); (2) Escalation — who must be informed internally when a breach is detected? (CISO, DPO, legal, CEO); (3) Assessment — is this a notifiable breach? What data was involved? How many individuals? (4) Notification — Board notification within 72 hours; DPA with relevant Processors; sector regulators if applicable; (5) Containment — stop the breach, revoke compromised credentials, isolate affected systems; (6) Investigation — forensic analysis; root cause identification; (7) Remediation — fix the vulnerability; implement additional controls; (8) Review — update the breach response plan based on lessons learned.
What are the most common DPDP breach notification mistakes?
Common mistakes: delaying notification while 'investigating' — the 72-hour clock starts from awareness, not from completing the investigation; provide initial notification promptly and supplement with further details; under-scoping the breach — assuming a breach is smaller than it is because the full investigation is not complete; over-scoping — panicking and notifying the Board about a minor incident that does not meet the notifiable threshold; failing to notify Data Processors — your DPA must require Processors to notify you promptly so you can assess and meet your notification deadline; and failing to document the decision-making — document why you decided to notify or not notify for every incident.
Does DPDP breach notification apply to near-misses?
A near-miss — a vulnerability that was discovered and patched before any unauthorised access occurred, a phishing email that was reported before any credentials were entered — is not a breach (no personal data was accessed) and does not trigger DPDP notification. However: document near-misses; investigate root causes; implement improvements; and update your incident log. In the event of a later actual breach, a track record of documenting and addressing near-misses demonstrates a functioning security programme, which is a mitigating factor in penalty assessment.
Frequently asked questions
Does DPDP breach notification apply to breaches by our vendors?
Yes. If a vendor (Data Processor) has a breach that affects your customer or employee data, you are the Data Fiduciary and must notify the Board. Your DPA must require the Processor to notify you immediately on becoming aware of an incident — a 24-hour Processor-to-Fiduciary notification obligation is the recommended contractual standard. From the moment you receive the Processor's notification, your 72-hour Board notification clock runs. A DPA that gives the Processor 30 days to notify you is useless for DPDP breach response.
Do we need to notify the Board even if the breach was minor and no harm occurred?
The notification threshold under DPDP will be clarified in the Rules — early indications suggest all personal data breaches must be reported, not only those causing harm. GDPR uses a 'risk to individuals' threshold for supervisory authority notification; DPDP may adopt a similar approach. Until the Rules are clear, adopt a conservative approach: notify the Board of any breach involving personal data, and let the Board determine whether the matter is significant enough to require data principal notification.
How does DPDP breach notification relate to CERT-In's 6-hour reporting?
CERT-In requires cyber incident reporting within 6 hours of awareness. DPDP requires Board notification within 72 hours (expected). These are parallel obligations with different recipients: CERT-In receives the cyber incident report; the Data Protection Board receives the personal data breach notification. The 6-hour CERT-In window is tighter — it is the immediate priority. The 72-hour DPDP window allows for an initial assessment of the personal data impact before notification. Run both processes simultaneously in your breach response plan.
Build your DPDP breach response plan
Niti Bharat's Breach Response Tabletop Exercise Kit includes a DPDP breach response playbook, notification templates, Board notification form, and a tabletop simulation for your incident response team.
Get the Breach Response Kit