DPDPA gives you 72 hours from the moment you discover a breach — not the moment it happened — to notify the Data Protection Board and every affected user. Waiting until that clock is running is the wrong time to build the process.
July 2026 · 4 min read
A data breach under the DPDPA isn't only a security incident — the moment it's discovered, it becomes a compliance deadline. The Act's headline requirement is stark: notify the Data Protection Board, and notify affected individuals where harm is likely, within 72 hours.
Notification obligations aren't limited to a classic hack. They cover unauthorized access to personal data, accidental deletion or modification, exposure through misconfiguration, ransomware or other system compromise, and — more broadly — any event that could reasonably cause harm to a data principal. If it's plausible that someone's data was exposed or altered without authorization, treat it as notifiable until you've established otherwise.
The 72 hours run from when your organization discovers the breach, not from when it technically occurred — a distinction that matters because breaches are frequently found days or weeks after the fact. If an incident happened on the 1st of the month but wasn't identified until the 4th, your notification deadline is the 7th, not the 4th. That makes detection speed, not just response speed, part of your compliance posture: a breach sitting undetected in your logs for a month doesn't buy you a longer runway once you finally notice it.
Your notification to the Board needs to cover the nature and cause of the breach, which categories of personal data were affected, how many individuals are impacted, what mitigation measures you've already taken, and the contact details of your DPO or grievance officer. Vague or partial disclosures invite follow-up scrutiny — the more complete the first notification, the less exposure you carry through a drawn-out back-and-forth.
Where harm is likely, affected individuals need a description of what happened, clear guidance on what steps they should take on their end, and a working helpline or support channel to reach you. This isn't boilerplate — a notification that reads as generic legal cover, rather than genuinely useful guidance, does little for the relationship with the people whose data was exposed.
Three days moves fast once an incident is live, which is why the infrastructure has to exist before you need it, not get assembled during the incident itself.
Start with a written breach-response SOP covering detection, escalation, containment, and notification as one continuous sequence rather than four disconnected steps. Stand up a breach committee spanning IT, Legal, your DPO, and Communications, so no single function is left improvising a decision outside its expertise. Run tabletop simulations on a quarterly cadence — a response plan that's only ever been read, never rehearsed, tends to fall apart under real pressure. And connect your breach process to your consent management platform directly, so the timeline, audit trail, and remediation tracking are captured automatically rather than reconstructed after the fact.
The instinct to delay disclosure while you investigate further is understandable, and it's also the wrong call — under DPDPA, quiet is non-compliant, not cautious. The defensible posture is transparency on the timeline the Act sets, genuine mitigation, and documentation of every step taken along the way. The requirement is strict, but with a response system built in advance rather than improvised under pressure, it's entirely manageable.
Building the response system before you need it is precisely what our breach readiness assessment and incident response retainer cover.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation