Data Breach Notification Under the DPDP Act: What Section 8 Requires
A personal data breach is one of the sharpest tests of your compliance posture. It is the moment when process, evidence, and readiness matter far more than intentions. Under India's Digital Personal Data Protection Act 2023, breach handling is not left to discretion — Section 8 places clear obligations on every Data Fiduciary, from securing data in the first place to notifying both the regulator and the individuals affected when something goes wrong.
This guide explains what Section 8 requires, how notification works under the DPDP framework, and how to build a repeatable incident process that holds up under scrutiny.
What Counts as a Personal Data Breach
Under the DPDP Act, a personal data breach means 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.
That definition is deliberately broad. A breach is not only a malicious external attack. It includes:
- A misconfigured database or storage bucket exposed to the public internet
- An employee emailing a customer list to the wrong recipient
- A ransomware event that locks you out of your own records (a loss of availability)
- A lost or stolen laptop containing unencrypted personal data
- A vendor or processor mishandling data you entrusted to them
Because the definition covers confidentiality, integrity, and availability, incidents that many teams would not instinctively label a "breach" still fall within scope. Your internal process needs to recognise all three.
Section 8 — The Data Fiduciary's Core Obligations
Section 8 sets out the general duties of a Data Fiduciary — the entity that decides the purpose and means of processing personal data. Two of these duties sit at the heart of breach handling.
Reasonable Security Safeguards
The Act requires every Data Fiduciary to protect personal data in its possession or under its control by taking reasonable security safeguards to prevent a personal data breach. This obligation applies whether the data is processed by the fiduciary directly or by a Data Processor on its behalf.
The Act does not hand you a fixed checklist of controls. "Reasonable" is context-dependent — it scales with the sensitivity and volume of data, the nature of your processing, and the current state of good practice. In practice, this points to well-understood measures such as encryption, access controls, logging, tested backups, and vendor due diligence. The obligation is preventive: safeguards are meant to reduce the likelihood of a breach, not merely to respond after one.
Erasure When the Purpose Is Served
Section 8 also requires you to erase personal data once the purpose for which it was collected is no longer being served, and to require your processors to do the same — unless retention is required by another law. Good data hygiene is itself a form of breach reduction: data you have already and lawfully deleted cannot be exposed in an incident.
Section 8(6) — Notifying the Board and Affected Principals
The obligation that most defines DPDP breach handling is in Section 8(6). In the event of a personal data breach, the Data Fiduciary must give intimation of the breach to:
- The Data Protection Board of India — the regulator established under the Act to enforce its provisions, and
- Each affected Data Principal — the individuals whose personal data was involved.
This is a dual-notification model. You cannot satisfy the Act by informing only the regulator, nor by quietly notifying customers without telling the Board. Both channels are required.
A few practical points follow from this:
- Individual notice means you must know who was affected. If your systems cannot tell you which principals' data was involved in a given incident, you cannot meet the individual-notification duty. This is a strong argument for maintaining clear records of what data you hold and where.
- The form and detail of notification are set out in the Rules. The Act establishes the duty; the operational specifics — what a notice must contain and how it must be delivered — are elaborated in the DPDP Rules.
- Notification is not an admission of failure. It is a legal obligation. Treating it as routine incident procedure, rather than a reputational crisis to be managed, leads to faster and more compliant responses.
A Note on Timelines — What the Act Actually Says
This is where careful reading matters. The DPDP Act itself does not fix a numeric deadline for breach notification. It creates the obligation to notify the Board and affected principals, but the specific timelines and procedural detail are left to the DPDP Rules.
The draft DPDP Rules published in 2025 propose specific timeframes and content requirements for breach intimation. Because these are draft Rules, the exact figures may change before they are finalised, and you should treat any specific number as provisional rather than as a settled requirement of the Act.
The safe operating posture is to build a process that can notify quickly — measured in hours and days, not weeks — so that whatever timeline the final Rules set, you are already able to meet it. Speed of detection and assessment is the variable you control; design for it now rather than retrofitting later.
If you want the underlying statutory framing, our overview of what the DPDP Act requires sets the wider context for these obligations.
What a Breach Process Actually Needs
Meeting Section 8 in practice is less about a policy document and more about an operational muscle you can exercise under pressure. A workable process has five moving parts.
1. Detection
You cannot notify what you never notice. Detection depends on logging, monitoring, alerting, and clear channels for staff, users, and vendors to report suspected incidents. Define what triggers an investigation and who receives the alert.
2. A Breach Register
Maintain an internal, append-only record of every incident — suspected and confirmed. Each entry should capture when the incident was detected, what data and how many principals were potentially involved, the suspected cause, the containment steps taken, and the notification decisions made. This register is both a management tool and your evidence trail.
3. Assessment
Not every anomaly is a reportable breach, but every anomaly needs a documented decision. Assess scope (what data, whose data, how much), cause, containment status, and the risk to affected principals. Record the reasoning behind your notification decision either way — a defensible "we assessed and concluded X" is far stronger than silence.
4. Notification
Execute the dual notification required by Section 8(6): intimation to the Data Protection Board and to each affected Data Principal, in the form and within the timeframe the Rules require. Prepare templates in advance so you are drafting from a known structure, not from scratch, in the middle of an incident.
5. Evidence and Follow-Through
After containment, capture what happened, what you did, and what you changed to prevent recurrence. This closes the loop between incident response and the "reasonable security safeguards" duty — each breach should measurably improve your defences. Retain the evidence in case the Board asks you to demonstrate your handling.
How DPDP Comply Helps
Handling a breach well is a documentation and coordination problem as much as a technical one. DPDP Comply gives you the operational backbone to meet Section 8 in practice:
- A structured data breach notification workflow to log incidents, assess scope, and track the dual notification to the Board and affected principals through to completion.
- A durable, timestamped incident register so your assessment decisions and notification steps are recorded as evidence, not reconstructed after the fact.
- Consent and records management that helps you understand what data you hold and which principals are affected — the foundation of any individual-notification duty. Our consent management guide explains how that record-keeping fits the wider Act.
- A single compliance workspace where breach handling sits alongside consent, rights requests, and privacy documentation, so your incident response is consistent with the rest of your DPDP programme.
Preparation is the whole game with breaches. The organisations that respond well are the ones that built the process before they needed it.
Ready to put an incident process in place? Create your free account and set up your breach workflow before you need it.
This article is general information, not legal advice.