Data Breach Notification Under DPDPA: Timelines, Obligations and How to Be Prepared

If your company handles personal data in India and something goes wrong, a server gets accessed by someone who should not have, an employee's laptop with unencrypted customer records goes missing, a misconfigured S3 bucket leaves data sitting in the open, the DPDPA does not just expect you to fix it quietly and move on. It expects you to tell people. Two sets of people, actually: the Data Protection Board of India, and every single individual whose data was caught up in it.

This is one of those parts of the Act that sounds procedural until you actually sit down and try to build a process around it. Then it becomes very real, very fast.

Why This Is Not Just Another Compliance Checkbox

Section 8(6) of the DPDPA lays out the core obligation in fairly plain terms: in the event of a personal data breach, the Data Fiduciary must notify both the Board and the affected Data Principals. The DPDP Rules 2025, specifically Rule 7, then fill in the practical details, what the notification actually has to say, and how fast it needs to go out.

Here is the part that tends to get people's attention: not notifying is not treated as a footnote to the breach itself. It is its own separate violation, and it carries penalties that can run up to ₹200 crore. So even if your organisation contains the breach quickly and limits the actual damage, failing to notify, or notifying late, or notifying incompletely, can still land you in serious trouble on its own.

What Actually Counts as a Notifiable Breach

This is where a lot of organisations get tripped up, because under the DPDP Rules, there is no de minimis threshold and no risk-based filter – every personal data breach triggers notification. Any incident involving personal data qualifies, and that net catches more than you would think:

• Someone gaining unauthorised access to a database

• Data being exfiltrated or stolen outright

• A ransomware attack that encrypts personal data

• Personal data left exposed because of a misconfigured cloud bucket

• A lost or stolen device that had unencrypted personal data on it

• An insider, a current or former employee, walking off with data they should not have touched

Notice that this list includes accidents alongside deliberate attacks. A cloud storage misconfiguration that nobody meant to happen can still trigger the same notification obligations as a targeted ransomware attack. Intent does not matter here. Impact does not matter here either. Every breach triggers notification.

The Clock Starts the Moment You Know

The Rules use the phrase "without delay" to describe how quickly you need to notify both the Board and affected Data Principals once you are aware of a breach. While there is no fixed hourly timeline for the initial notification, Rule 7 requires a detailed follow-up report to the Board within 72 hours of becoming aware of the breach.

Here is a detail that is easy to overlook but genuinely matters: the moment your organisation becomes "aware" of the breach is when your notification timer starts running, not the moment the breach technically happened, and not the moment you finish investigating it. That means you need to be documenting, with a timestamp, the exact point at which someone in your organisation realised something was wrong. If that moment is not clearly recorded, you are going to have a hard time proving you moved fast enough.

What You Actually Have to Tell the Board

The notification to the Data Protection Board is not a one-line email saying "we had a breach." It needs substance. Rule 7 requires:

Initial intimation "without delay":

A description of the breach, including its nature, extent, timing and location of occurrence

The likely impact

Detailed report within 72 hours:

• Updated and detailed information on the breach description

• The broad facts related to the events, circumstances and reasons leading to the breach

• Measures implemented or proposed to mitigate risk

• Any findings regarding the person who caused the breach

• Remedial measures taken to prevent recurrence

• A report regarding the intimations given to affected Data Principals

What You Owe the People Whose Data Was Involved

The individuals affected deserve something different from what you send the Board. Not a compliance summary, but an explanation they can actually use. Under Rule 7, notification to Data Principals must include:

A description of the breach, including its nature, extent and the timing of its occurrence

The consequences relevant to them that are likely to arise from the breach

The measures implemented and being implemented by the Data Fiduciary to mitigate risk

The safety measures that they may take to protect their interests

Business contact information of a person who is able to respond on behalf of the Data Fiduciary

One requirement that is worth underlining: this has to be written in "concise, clear and plain" language. Not the kind of legal phrasing that shows up in your terms of service. If someone cannot understand what happened to their data after reading your notice, you have not actually met the spirit of the obligation, even if you have technically ticked the boxes.

Getting Your Organisation Actually Ready for This

Reading the requirements is one thing. Being able to execute them at 2am when you have just discovered a breach is another thing entirely. A breach response setup that can actually hold up under DPDPA needs a few pieces working together:

• A detection layer – monitoring that is actually capable of flagging unusual access patterns or signs of data leaving your systems, rather than relying on someone noticing something felt off.

• A classification process – a clear, fast way to determine whether what you are looking at crosses the line into a notifiable breach, so you are not debating definitions while the clock is running.

• A notification workflow – templates for both the Board and affected individuals that are already drafted and approved in advance, so you are customising details rather than writing from scratch under pressure.

• An escalation path – a defined sequence for who gets pulled in and when, whether that is your DPO, legal team, CEO, or board members, so nobody is left wondering who is supposed to make the call.

• And remediation tracking – a running record of every action taken after the breach, because that documentation is exactly what you will need if the Board ever asks you to walk through your response.

Organisations that handle this well almost never figure it out in the moment. They have built the plan, tested the templates, and rehearsed the escalation path long before anything actually happens. Which is really the only way to turn a data breach from a full-blown crisis into something you can manage with a clear head.

Effective DPDPA breach response depends on having clear records of consent, processing activities, and data-handling decisions before an incident ever occurs. A centralised consent management platform can help organisations maintain an auditable trail of user permissions and processing purposes, making compliance documentation easier to manage when scrutiny follows a breach. OneConsent provides a DPDPA-focused consent management approach to help organisations strengthen their privacy governance and maintain clearer compliance records.