A DPDP Act data breach isn’t something you can handle casually — a founder called me at 11 pm a few months ago, voice steady, but I could tell he’d been sitting with the news for hours before picking up the phone. “Sir, our database got exposed. Customer phone numbers, emails, maybe more. I don’t even know where to start.”
That’s usually how it happens. Not a dramatic hack in the movies, but a quiet discovery — a misconfigured server, a vendor’s slip-up, an employee who clicked the wrong link. And then a founder or a CXO sitting alone at night, wondering what they’re legally required to do next.
Under India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and the DPDP Rules, 2025 that were finally notified in November 2025, the answer isn’t optional and it isn’t slow. There’s a clock running the moment you find out, whether you’re ready or not.
The Clock Starts the Second You “Become Aware”
Most founders assume the clock starts once the investigation is “complete” — once they know exactly how many records were affected, how it happened, who’s responsible. That’s not how the law reads it.
Section 8(6) of the DPDP Act requires every Data Fiduciary — which, in plain terms, means any business that collects or processes personal data — to notify the Data Protection Board of India and every affected individual the moment a breach occurs. Rule 7 of the DPDP Rules breaks this into two stages: an initial alert to the Board “without delay,” followed by a detailed report within 72 hours of becoming aware of the breach. Affected individuals must also be notified without delay, separately from the Board process.
The 72-hour window can be extended, but only if you formally request it from the Board — you can’t simply assume you’ll get more time.
Here’s the part that surprises most business owners I speak to: this obligation applies whether ten records were exposed or ten million. There’s no minimum threshold, no “it was a small leak, so we’re fine” exception. If personal data was compromised, the obligation exists.
What Actually Counts as a “Breach”
The Act’s definition is broader than most people expect. It’s not limited to a hacker breaking in. Under the Act, a breach includes any unauthorised processing, accidental disclosure, unauthorised acquisition or sharing, alteration, destruction, or loss of access to personal data that compromises its confidentiality, integrity, or availability.
That covers a lot of ground I see in practice:
- An employee accidentally emailing a customer list to the wrong distribution group
- A third-party vendor with weak security getting compromised, exposing data you’d shared with them
- A misconfigured cloud storage bucket left open to the public
- A former employee retaining access to systems after their exit and misusing it
If any of these sound familiar from a “minor mistake” your team brushed off last year, it’s worth having someone review whether it should have been reported.
What the Notification Actually Has to Say
This isn’t a one-line email saying “we had an incident, sorry.” The notification to the Board and to affected individuals needs to include a plain-language description of what happened, what personal data was exposed, what protective steps the affected individuals can take, and contact details for follow-up queries. Vague or incomplete notifications don’t satisfy the requirement — they just delay the point at which you’re actually compliant.
The Penalties Are Not Symbolic
I’ve had clients ask me, half-joking, “worst case, what’s the fine — a warning letter?” No. The Schedule to the DPDP Act sets out some of the steepest data protection penalties in the world:
- Up to ₹200 crore for failing to notify the Board or affected individuals of a breach
- Up to ₹250 crore for failing to implement “reasonable security safeguards” in the first place
- Up to ₹200 crore for non-compliance with the special protections around children’s data
The Board does account for factors like the severity of the breach, how many people were affected, your company’s compliance history, and what remediation steps you took — so acting quickly and transparently genuinely matters when penalties are being assessed. But “we didn’t know we had to report it” has never been a defence that works, under this law or any other.
Don’t Forget the Other Clock: CERT-In
Here’s something that catches a lot of businesses off guard. If the incident is a cyber security event — a hack, ransomware, unauthorised access to your systems — you may also be separately obligated under CERT-In’s directions to report to CERT-In within 6 hours of noticing the incident. That’s a different law, a different regulator, and a much shorter window than the DPDP Act’s 72 hours.
A single breach can trigger both obligations at once, on two separate timelines. If your incident response plan only accounts for one of them, you’re already behind before you’ve started.
What I Tell Clients to Have Ready Before Anything Happens
By the time a founder calls me after a breach, it’s genuinely too late to build a response process from scratch — you’re already inside the clock. The businesses that come through this cleanly are the ones that had a plan sitting ready before they ever needed it:
- A designated point of contact who is responsible for coordinating breach response — not “whoever’s free that day”
- A documented, tested breach response plan that covers detection, internal escalation, and who drafts the Board and CERT-In notifications
- Vendor contracts that require your data processors to notify you immediately if something happens on their end — you can’t report what you don’t know about
- A record of your security safeguards, because “reasonable security safeguards” is judged against what you actually had in place, not what you say you intended to have
If your company processes any personal data — customer records, employee data, even a basic CRM — this isn’t a “when we’re bigger” problem. Full enforcement under the DPDP Act is expected by mid-2027, but the underlying obligations are worth getting ahead of now, not after the phone rings at 11 pm.
If you’re unsure whether your current data practices would hold up, or you’re building a breach response plan from scratch, that’s a conversation worth having before there’s an incident to manage — not during one.