DPDP Act Breach Notification: Reporting to the Data Protection Board and Data Principals
Unlike GDPR, the DPDP Act has no risk threshold — every personal data breach must be notified to affected data principals and the Data Protection Board of India. This guide covers the 72-hour detailed report, CERT-In's parallel 6-hour rule, and how to build the incident workflow.
What Counts as a Personal Data Breach Under the DPDP Act
The DPDP Act defines a personal data breach broadly: any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data that compromises its confidentiality, integrity or availability. The definition covers the full CIA triad, so a ransomware incident that encrypts data without exfiltrating it is a breach, as is a misdirected email, a misconfigured storage bucket, or an insider accessing records beyond their authorisation.
The feature that distinguishes the Indian regime from almost every other major privacy law is what happens next: there is no risk-of-harm threshold. Under GDPR, a controller notifies the supervisory authority unless the breach is unlikely to result in a risk to individuals, and notifies the individuals themselves only when the risk is high. The DPDP Act contains no such filter. Every personal data breach must be notified — to the Data Protection Board of India and to each affected Data Principal — regardless of severity.
This notify-everything model changes the economics of incident response. Under GDPR, a significant share of incident response effort goes into risk assessment that determines whether notification is required at all. Under the DPDP Act, that assessment still matters for remediation and communication, but it no longer gates the notification decision. The operational question shifts from whether to notify to how quickly and completely you can.
One scoping note: the obligation sits with the Data Fiduciary. A Data Processor that suffers a breach does not notify the Board or Data Principals directly — it must inform the fiduciary, who owns the regulatory notification. This makes the escalation clauses in your processor contracts a load-bearing part of your compliance, a point we return to below.
Notifying Affected Data Principals: Without Delay, in Plain Language
The DPDP Rules require the Data Fiduciary, on becoming aware of a breach, to intimate each affected Data Principal without delay, in a concise, clear and plain manner, through their user account or the contact details registered with the fiduciary.
The Rules specify the content of the notice: a description of the breach including its nature, extent, and the timing and location of its occurrence; the likely consequences for the Data Principal; the measures the fiduciary has implemented or is implementing to mitigate risk; the safety measures the Data Principal can take to protect their own interests; and contact information for a person able to respond to their queries. The safety-measures element is worth emphasising — the notice must be useful, telling people to rotate passwords, watch for phishing that references the leaked data, or contact their bank, as the facts warrant.
Because the obligation applies to every breach without a severity filter, template preparation matters more than under GDPR. Draft notice templates in advance for your common scenarios — credential compromise, exfiltration, accidental disclosure, availability loss — with placeholders for the incident-specific facts. Prepare them in the languages your user base actually reads; a plain-language obligation is hard to satisfy in a language your users do not understand, and the Act's broader notice provisions set a clear multilingual expectation.
Also plan the delivery mechanics. Notifying millions of users through in-app messages and email at short notice is an engineering problem: rate limits, bounce handling, proof of delivery, and a support channel scaled for the query volume the notice will generate. Organisations that have rehearsed a mass-notification run will execute in hours; those that have not will discover their email provider's throttling policies mid-incident.
Notifying the Data Protection Board: Intimation, Then the 72-Hour Report
Notification to the Data Protection Board of India runs on a two-stage clock under the DPDP Rules. Stage one: on becoming aware of the breach, the fiduciary must inform the Board without delay, describing the breach in summary — its nature, extent, timing and location, and the likely impact. This initial intimation is expected while the investigation is still live, so it is necessarily provisional.
Stage two: within 72 hours of becoming aware of the breach, or a longer period if the Board allows on a written request, the fiduciary must provide the detailed report. The Rules specify its contents: updated and detailed breach information; the circumstances and events that led to the breach; the measures implemented or proposed to mitigate risk; findings about the person or persons who caused the breach, where identified; remedial measures taken to prevent recurrence; and a report on the intimations given to affected Data Principals.
Two elements of the detailed report deserve advance planning. The findings-about-who-caused-it element means your forensic process needs to run fast enough to say something meaningful within 72 hours — even if the answer is that attribution is ongoing, you should be able to describe the attack vector. And the report-on-intimations element creates an explicit dependency: the Board will see, in your own filing, whether and when you notified affected users. A fiduciary that files a polished Board report while its user notification is still stuck in legal review is documenting its own non-compliance.
As of mid-2026 the Board's digital filing mechanisms and enforcement posture are still maturing, and practice will firm up as decisions are published. The safe operating assumption is literal compliance with the Rules' timelines, with written extension requests — which the Rules expressly contemplate — used early rather than as an after-the-fact excuse.
CERT-In Reporting in Parallel: The 6-Hour Track
DPDP notification is not the only clock running during an Indian security incident. Under the CERT-In directions issued under the Information Technology Act, a wide range of cyber security incidents — including data breaches and data leaks — must be reported to CERT-In within six hours of noticing the incident or being brought to notice of it. This obligation predates the DPDP Act and continues to apply in parallel.
The two regimes ask different questions. CERT-In is a security incident regime: it wants technical details of the incident quickly, feeding national cyber situational awareness, and it applies to incidents whether or not personal data is involved. The DPDP Act is a privacy regime: it cares about personal data breaches specifically and about the impact on Data Principals. A given incident can trigger both, one, or neither — a DDoS attack with no data compromise is CERT-In-reportable but not a DPDP breach; a paper file lost by a courier is a DPDP breach but not obviously a CERT-In cyber incident.
Operationally, run the two tracks from a single incident record with a shared fact base. The six-hour CERT-In report will necessarily be thin — incident type, systems affected, initial observations — and the DPDP intimation without delay will follow, with the detailed 72-hour DPDP report drawing on the fuller investigation. Inconsistencies between filings to two arms of the same government are a self-inflicted wound, so route both through the same incident commander and keep a single source of truth for the timeline.
Regulated sectors carry additional clocks on top: RBI-supervised entities report cyber incidents to RBI within hours, SEBI and IRDAI have their own frameworks, and listed companies may face disclosure obligations. Your incident playbook should carry a jurisdiction-and-regulator matrix so the notification workstream can enumerate every applicable clock in the first hour of the incident rather than discovering them serially.
How the DPDP Regime Compares With GDPR Articles 33 and 34
Teams running multi-jurisdiction incident response need a precise view of where the DPDP Act and GDPR diverge, because the differences change decisions in the first hours of an incident.
The threshold difference is the big one. GDPR Article 33 exempts breaches unlikely to result in risk, and Article 34 requires individual notification only for high-risk breaches. The DPDP Act notifies everyone, always. An incident affecting both EU and Indian data subjects can therefore lawfully result in no individual notice in Europe and mandatory notice to every affected user in India — an asymmetry your communications team should anticipate, because Indian users publicising a notice may effectively force disclosure elsewhere.
The clock also starts and runs differently. GDPR's 72 hours applies to notifying the supervisory authority, with individual notification following without undue delay for high-risk cases. The DPDP structure is closer to inverted: the immediate obligations are the without-delay intimations to both the Board and the affected Data Principals, with 72 hours attached to the detailed follow-up report to the Board. In practice, DPDP compliance front-loads user communication compared with GDPR practice, where individual notice often lands days after the authority filing.
Content obligations are broadly parallel — nature of the breach, consequences, mitigation, contact point — but the DPDP detailed report reaches further into causation and attribution than a typical Article 33 filing, and explicitly audits your user-notification performance. The pragmatic approach for global programmes is to run a single incident process built to the strictest applicable standard: collect facts to the DPDP report's depth, prepare user notices on the DPDP timeline, and let the GDPR risk assessment govern only whether the EU notifications fire, not whether the work gets done.
Building the Incident Response Workflow
A DPDP-ready breach workflow has six stages, and the time to build it is before the incident. Detection and awareness come first: the regulatory clocks start when you become aware of the breach, so define internally what awareness means — typically when a responsible person confirms that a security event involves personal data — and log that determination with a timestamp. An ambiguous awareness moment becomes a dispute about whether your 72 hours have expired.
Classification comes second. Because every personal data breach is notifiable, the classification question is not whether to notify but scope: which systems, which data categories, which Data Principals, roughly how many. Your data map is the critical asset here — an organisation that knows which personal data lives in the compromised system can scope in hours, while one that does not will burn its notification window on discovery archaeology.
Third, roles. Appoint an incident commander, and pre-assign the regulatory notification owner (drafts and files the Board intimation and report, and the CERT-In report), the communications owner (user notices and support readiness), and the forensic lead (evidence preservation and causation findings for the detailed report). Fourth, evidence: preserve logs, images, and chain of custody from the outset — the detailed report's causation and remediation content is only as good as the forensics behind it.
Fifth, processors and vendors. Your DPAs should obligate processors to report suspected breaches to you within a defined short window — hours, not days — with enough detail to start your own clocks, and to cooperate with your investigation. A processor that sits on an incident for a week has consumed your entire compliance margin. Sixth, closure: after-action review, a remediation backlog with owners, and an updated breach register. The register matters beyond hygiene — it is exactly the evidence an SDF's independent auditor, or the Board in a subsequent proceeding, will ask to see.
Penalty Exposure and the Case for Preparation
The DPDP Act's penalty schedule puts breach-related failures at the top of the range. Failure to take reasonable security safeguards to prevent a personal data breach carries a penalty of up to ₹250 crore — the highest band in the Act. Failure to notify the Board or affected Data Principals of a breach carries its own penalty of up to ₹200 crore. The two are cumulative in effect: an organisation that suffers a breach through weak safeguards and then notifies late faces exposure under both heads.
The structure of these penalties rewards preparation in a specific way. The security-safeguards penalty turns on reasonableness, which the Board will assess against what the fiduciary knew and did before the incident: documented security measures, encryption, access controls, and the contractual safeguards imposed on processors. The notification penalty turns almost entirely on process execution during the incident. Both are heavily influenced by evidence you either created in advance or cannot create at all after the fact.
When the Board determines penalties, the Act directs it to consider factors including the nature, gravity and duration of the breach, the type of data affected, whether the breach was repetitive, and — critically — the action taken by the fiduciary to mitigate the effects, and the timeliness and effectiveness of that action. A fast, complete, well-documented response is not just compliance; it is direct mitigation of the penalty calculation.
The closing argument for investment is simple: under a notify-everything regime, breach response is not a tail risk process you hope never to run. Misdirected emails and misconfigured buckets happen at every organisation of scale, and each one now carries a regulatory filing and a user notice. Building the workflow, templates, data map, and processor obligations once — and rehearsing them — converts each such incident from a crisis into a procedure.
Related articles
When You Can't Delete: DPDP Erasure Requests vs RBI and SEBI's 5-Year Retention Mandates
Significant Data Fiduciary Under India's DPDP Act: Are You One, and What It Means
Children's Data Under the DPDP Act: Verifiable Parental Consent Explained
Automate your privacy compliance
See how TruePrivacy can handle DSRs, consent, and breach response — all in one platform.
Free 14-day trial · No credit card required · Setup in minutes