How to Handle Data Breaches Under the DPDP Act
Must Read
Introduction
Data breaches have a way of arriving at the worst possible time. It could be on a friday evening, during a product launch week or right before a fundraise closes. When they do, most startups discover something uncomfortable, there is no plan. There is a vague memory of someone saying "we should document this process" six months ago, and a Slack message that never got a reply. That is the reality for a large chunk of Indian startups handling personal data today.
The Digital Personal Data Protection (DPDP) Act, 2023 has changed what that unpreparedness costs. Breach response is now a legal obligation, not just good practice.
If you want to know more about the DPDP Act itself, check out our earlier article — "What is the DPDP Act — And Why Startups Can't Afford to Ignore It."
What Counts as a Data Breach Under DPDP?
Most organisations mentally picture a breach as a dramatic external hack, ransomware, a sophisticated attack, or headlines. The DPDP Act is less cinematic about it.
Any unauthorised access, loss, leakage, or exposure of personal data qualifies. External attacks are the minority. The everyday operational failures — access control gaps, human error, and third-party vulnerabilities — are where most incidents actually come from. Breach protocols need to account for both.
🪣
Misconfigured S3 bucket
Publicly accessible for three weeks before anyone noticed
🔑
Ex-employee credentials
Never revoked after the person left the organisation
🔗
Vendor system compromise
A third party got hit, and it took your client data with it
📤
Accidental data export
An intern exported the wrong database to the wrong place
What the DPDP Act Requires
The obligations are straightforward, even if executing them under pressure is not.
01
Report to the Data Protection Board
Breaches must be reported to the Data Protection Board of India within prescribed timelines.
02
Notify affected individuals
Affected individuals must be notified if there is a reasonable likelihood of harm.
03
Maintain detailed incident records
Not a paragraph in a Google Doc — a proper, auditable account of what happened and what was done about it.
04
Accountability sits with the Data Fiduciary
The organisation that decided why and how the data was being processed carries responsibility — not just the processor.
The First 24 Hours — What Needs to Happen
Speed matters here, but not at the cost of documentation. Every action taken in the first 24 hours needs to be logged, with timestamps, with names, with decisions recorded.
The immediate priority is containment. Isolate affected systems. Revoke exposed credentials. Lock down the data that hasn't been compromised yet. Stop the bleeding before assessing the wound.
Once containment is underway, the scope assessment begins, how many individuals are affected, what categories of data are involved, whether the incident is ongoing or has been resolved. This assessment directly feeds the reporting obligation, so getting it right matters.
Notification and Reporting
Reporting runs on two tracks simultaneously.
The Data Protection Board needs to be notified with specifics, what happened, what data was involved, the likely scale of impact, and what corrective steps have been taken. Incomplete or delayed filings are treated as separate violations. Getting the substance right matters as much as getting the timing right.
Users need to hear from the organisation too, and the communication has to actually say something. Vague, heavily lawyered notifications that bury the facts in passive voice do more reputational damage than a clear, direct message.
Incomplete or delayed filings are treated as separate violations under the DPDP Act — the reporting obligation is independent from the breach itself.
The Investigation That Follows
Once the immediate crisis is contained, the harder work starts, understanding what actually went wrong and building a record of it.
The DPDP Act expects audit-ready incident documentation. A timeline of events. Systems affected. Data categories involved. Actions taken at each stage. Root cause identified. Remediation steps recorded. This is what the Data Protection Board will ask for if the incident comes under review, and it needs to hold up.
Root cause analysis deserves more rigour than it usually gets. A breach that happened because of weak access controls or an unpatched system is a preventable one. Identifying the cause without actually fixing the underlying condition is just documentation theatre.
Building Towards Prevention
Remediation after a breach should prompt a broader security review, not just the specific vulnerability that was exploited.
🔐 Access Control Audits
Regular reviews, not set-and-forget configurations.
🔒 Encryption at Rest & Transit
Significantly limits the damage of any exposure.
🎯 Scheduled Pen Tests
On a schedule — not only after something goes wrong.
📋 Practiced IR Plans
A plan that's never been rehearsed fails under real pressure.
🔗 Vendor Security Perimeter
Third-party integrations as part of the perimeter, not an afterthought.
🎓 Ongoing Team Training
Continuous familiarity, not a one-time onboarding session.
Conclusion
A breach, handled well, does not have to be fatal to trust. Some of the most credible companies in the world have had significant incidents and recovered, because they were transparent, they moved quickly, and they demonstrably fixed what was broken.Under the DPDP Act, the minimum bar is regulatory compliance. The smarter goal is to build breach response into the organisation's operating fabric, clear ownership, practiced processes, proper tooling, so that when something happens, the response is measured rather than chaotic.Preparation is the only strategy that actually works. The DPDP Act just made it mandatory.