A founder called me at 7:40 on a Monday morning. His voice was flat, the kind of flat you get when panic has burned itself out. “Someone posted our customer database on a forum overnight,” he said. “Names, phone numbers, email IDs. A journalist has already messaged me. What do I do first?”
So I asked him one question: “Do you have a breach response plan?”
There was a long silence. Then he said, “We have a firewall.”
But a firewall is not a plan. Most Indian businesses are exposed in exactly this gap. They have security tools, but they don’t know what to do when those tools fail. The Digital Personal Data Protection (DPDP) Act, 2023 makes that gap expensive.
So here is your guide to DPDP Act data breach notification: what the law expects, who you must tell, and what your first 72 hours should look like.
What Counts as a “Personal Data Breach” Under the DPDP Act?
First, the Act defines a personal data breach broadly. In simple terms, it is any unauthorised or accidental event that exposes, changes, destroys or blocks access to personal data.
That means a breach is not only a hacker stealing your database. For example, all of these can qualify:
- An employee emailing a customer list to the wrong person
- Cloud storage with a misconfigured setting that anyone can open
- A lost laptop with unencrypted customer records
- Ransomware that locks you out of your own data
- A vendor getting hacked, with your customer data going along
The last one matters most. Under the Act, the responsibility stays with you, the Data Fiduciary, even if the breach happens at your vendor. So read our post on why every vendor contract needs a Data Processing Agreement.
DPDP Act Data Breach Notification: Who Must You Notify?
You must report a personal data breach to two parties:
- The Data Protection Board of India
- Each affected Data Principal (the individual whose data the breach exposed)
Start with the individuals. Notify them without delay, in plain language. Tell them what happened and what data the breach involved. Then explain the risks they face, what you did to contain the breach, and who they can contact.
The Board notification has two stages under the Rules. First, you send an immediate intimation. Then you file a detailed report within 72 hours, or a longer period if the Board allows. That is where the 72 hours in the title comes from.
Note: The government is phasing in the DPDP Rules, so the breach-related obligations start on different dates. Always confirm the current dates and exact wording before you rely on any summary, including this one.
The First 72 Hours: A Practical Checklist
Hours 0 to 6: Contain
- Stop the bleeding. Disable compromised accounts, revoke API keys, take exposed storage offline and isolate affected systems.
- Do not delete anything. Panic deletion destroys evidence, so preserve logs, emails, server snapshots and screenshots.
- Activate your response team. Call your IT or security lead, a decision-maker from management, your legal counsel and your DPO, if you have one.
- Start a breach log. Also, write down who discovered what, and when. Timestamps matter later, so record them.
Hours 6 to 24: Assess
- Which data did the breach touch? For instance, names and emails carry different risk than financial or health data.
- How many people does it involve? Also, you need a rough number, even if it is only an estimate for now.
- What caused it? An external attack, an internal error or a vendor failure?
- Is it still happening? Confirm that you have actually closed the breach.
- What harm could follow? Think of fraud, phishing, identity misuse and reputational damage.
Hours 24 to 48: Prepare
- First, draft the notification for affected individuals in simple, honest language.
- Then prepare the intimation and report for the Data Protection Board.
- Also decide on your communication channels, such as email, SMS or an in-app notice.
- Brief your customer support team, so they don’t improvise answers.
- If the incident is a crime such as hacking or extortion, consider filing a complaint on the National Cyber Crime Reporting Portal. Also check whether CERT-In reporting applies to you. Under its directions, some incidents need a report within six hours, separately from your DPDP duties.
Hours 48 to 72: Report and Document
- Submit the detailed report to the Board within the prescribed timeline.
- Then confirm that every affected individual has received your notification.
- Next, document every decision and the reasoning behind it.
- Finally, begin the root-cause fix, not just the patch.
The Five Mistakes I See Again and Again
1. Hoping nobody notices. Quiet breaches often become loud ones. Once data is on a forum or in a customer’s spam folder, silence looks like concealment.
2. Blaming the vendor and stopping there. Your vendor may share the blame, but your legal duty to notify does not transfer to them.
3. Waiting for “complete information.” In practice, you will rarely have the full picture in 72 hours. So report what you know, flag what you are still investigating, and update as you learn more.
4. Sending a vague notification. “We experienced a security incident” tells people nothing. Instead, affected individuals need to know what data the breach exposed, so they can protect themselves.
5. Having no plan until the crisis. After all, deciding who calls whom at 3 AM, during a breach, is the most expensive way to make decisions.
What Is the Penalty for a Data Breach Under the DPDP Act?
The penalties are steep. Failing to take reasonable security safeguards can cost you up to ₹250 crore. On the other hand, failing to notify the Board and affected Data Principals can cost up to ₹200 crore.
The actual penalty depends on several factors: the nature, gravity and duration of the breach, the type of data involved, and the steps you took to reduce harm. Therefore, a documented response matters. It shows good faith.
Build Your Breach Response Plan Before You Need It
The founder who called me that Monday morning got through it. But he got through it expensively, with sleepless nights, legal firefighting and customers who lost trust. A one-page plan from months earlier would have saved him most of that.
In practice, a workable breach response plan should include these steps:
- Name your incident response team, with phone numbers, not just email IDs
- Define what counts as a reportable breach
- Decide who can authorise notifications
- Prepare templates for Board and Data Principal notifications
- List your vendors and add breach-reporting clauses to each contract
- Run regular drills, even a simple tabletop exercise twice a year
Final Thought
In short, a breach is no longer only a technical problem under the DPDP Act. It is a legal event that comes with a clock. The businesses that handle it well do not have the biggest security budgets. Instead, they decided in advance exactly what they would do.
No breach response plan yet? Not sure whether your current one meets DPDP requirements? I can help you build one.
Book your free consultation: nitindigital.com/contact | Call: +91 98736 78373