What Happens After a Data Breach in India? A Step-by-Step Guide

First: Do Not Panic. Do Not Hide.

A data breach is serious. But the businesses that suffer the worst outcomes are not always the ones with the largest incident. They are the ones that handled the response wrong.

The DPDP Act and Rules 2025 contain a mandatory notification requirement with a hard 72-hour deadline. There is no legal route around it. There is no "manage it quietly" option that does not carry a ₹200 crore penalty.

Here is exactly what to do, in order.

Step 1 — Contain the Breach

Stop the bleeding before anything else.

Identify the source. Isolate the affected system, account, or process. If the source is not yet clear, restrict access broadly while you investigate.

Do not delete logs or overwrite systems in the process. You will need the evidence trail — for the regulator, for your insurers, and for your own investigation.

Step 2 — Understand the Scope

Once the breach is contained, assess what actually happened.

What data was affected? Whose data — customers, employees, both? How many individuals? Was data accessed, copied, deleted, or encrypted? Is there any evidence it has been shared or used?

Be rigorous. Underestimating the scope and then discovering it was worse is a compounding problem — with the Board, with affected individuals, and with your own credibility.

Step 3 — Notify Affected Individuals Immediately

Under the Rules, affected Data Principals must be notified without delay — before the 72-hour reporting deadline to the Board.

Tell them clearly: what happened, what data of theirs was involved, what you are doing about it, and what steps they can take to protect themselves.

Plain language. Direct tone. No corporate hedging that requires three readings to understand what actually occurred. A clear, honest communication is both legally required and, practically, the better approach.

Step 4 — Notify the Data Protection Board

This is a two-stage legal obligation, not a single notification.

Stage one: Submit an initial description of the breach to the Board without delay — as soon as you are aware a breach has occurred.

Stage two: Submit a complete, detailed breach report to the Board within 72 hours of becoming aware of the breach.

That report must cover: the nature of the breach, the categories and number of individuals affected, the categories of data involved, the likely consequences, and the measures taken or proposed to address it.

The 72-hour clock runs from the moment you become aware — not from when your investigation is complete. Partial information submitted on time is better than a complete report submitted late.

Step 5 — Investigate Properly

Bring in the right people — internal IT, external forensics if the situation warrants it, and legal counsel.

You need to understand: how the breach happened, whether the vulnerability is fully closed, whether data has already been misused, and what the full scope of affected individuals is.

Document the investigation thoroughly. The Board may request this record. Your insurers will expect it. The Rules require that system and processing logs be retained for a minimum of one year specifically to support investigations like this.

Step 6 — Fix the Root Cause

A breach that happens twice from the same vulnerability is a significantly worse regulatory outcome than one that happened once and was properly remediated.

Whatever created the exposure — a misconfigured database, an unpatched system, inadequate access controls — fix it. Then verify the fix. Then document that verification.

Step 7 — Review Your Broader Security Posture

A breach is a signal, not just an event. Most organisations discover, in the aftermath, that the immediate vulnerability was the visible part of a larger problem. Treat the investigation as an opportunity to conduct a broader security review — not just to patch the specific gap that was exploited.

The Penalties for Getting This Wrong

Failing to notify the Data Protection Board of a breach: up to ₹200 crore.

That penalty is not for suffering a breach. It is specifically for failing to notify — which is entirely within your control. Missing the 72-hour deadline is treated as a failure to notify. There is no provision for an extension except on written application with good cause.

What Works in Your Favour With the Regulator

The Board must consider mitigating factors when determining penalties. These help:

• Immediate notification before being asked
• Transparent cooperation throughout the investigation
• Evidence of prior reasonable security measures
• Swift and verified remediation
• Clear, honest communication with affected individuals
• Retention of evidence and logs as required under the Rules

None of these eliminate liability. But they all reduce it — sometimes substantially. The Board is looking for evidence of good faith, not perfection.

Build the Plan Before You Need It

The worst time to design a breach response is during one.

The 72-hour rule makes this non-negotiable. By the time a breach is confirmed, your team needs to know exactly who does what, who contacts the Board, who drafts the individual notifications, and who manages external communications.

Every business should have a documented incident response plan — tested at least once a year. If yours does not exist, building it is this week's priority.

The Bottom Line

A data breach under the DPDP Act is manageable if you respond correctly. Prompt notification, transparent cooperation, genuine remediation, and clear communication with affected individuals are the framework for a proportionate regulatory outcome.

The regulator can penalise you for the breach. Only you can give them reason to penalise you for everything that came after it.