Breach Notification: Your First 72 Hours Under DPDP Act

It is 11pm on a Saturday. Your on-call engineer sees a spike in failed logins on an admin panel, discovers that a support agent's credentials were phished on Wednesday, and realises the attacker has been exporting from your CRM for 72 hours.

What happens in the next three days determines whether this is a manageable incident or a regulatory investigation.

Section 8(6) of the Digital Personal Data Protection Act, 2023 requires the Data Fiduciary to intimate the Data Protection Board of India and each affected data principal of any personal data breach. The DPDP Rules published in 2025 sharpen this into fast timelines. This is the hour-by-hour playbook we run with clients.

Hour 0–2: Contain and stand up the response

Do first:

1. Contain. Revoke the compromised credentials. Rotate any shared secrets. Isolate the affected system.
2. Preserve. Do not wipe. Snapshot the compromised system's logs, memory, and disk. Preserve access logs. This is your evidence base.
3. Convene the incident squad. Named on-call roles: incident commander (usually CTO or Head of Security), legal, comms, and the accountable privacy owner (the DPO or Section 10 equivalent).

Do not:

• Talk to customers.
• Post publicly.
• Delete or "clean up" anything.
• Speculate in Slack channels that will end up in a subpoena.

Hour 2–12: Establish the facts

The single most important question: is this a "personal data breach" as defined by the Act?

Section 2(u) defines it as "any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data". This is broad — an accidentally-shared internal Google Doc containing customer data qualifies.

Answer, with evidence:

• What personal data was affected? Categories, volumes, sensitivity.
• Which data principals? Are children involved? Employees? Third parties?
• What is the exposure window? First unauthorised access to containment.
• Was the data actually accessed, or was there only potential access?
• Is there any current continuing exposure?

Assign a scribe. Every fact goes into a single timestamped document. This document is your defence.

Hour 12–24: Legal and regulatory decision

With the facts in hand, legal (internal + external, if material) decides:

• Is Board notification required? Under DPDP, in practice: assume yes.
• Is data principal notification required? Almost always yes.
• Are sector regulators involved (RBI, IRDAI, SEBI, CERT-In)? CERT-In has its own 6-hour reporting obligation for certain cyber incidents — this often precedes the DPDP timeline.
• Are cross-border regulators involved? If EU or UK residents are affected, GDPR's 72-hour clock is running concurrently.

Draft the notifications now. Do not wait until the deadline. First drafts always take longer than expected. Legal and comms iterate. The DPO signs.

Hour 24–48: Board notification

Notify the Data Protection Board within 72 hours of becoming aware of the breach (the DPDP Rules practical standard). The notification should include, at minimum:

• Nature of the breach
• Categories and approximate volume of data principals affected
• Categories and approximate volume of personal data records affected
• Likely consequences
• Measures taken or proposed to address the breach and mitigate adverse effects
• Contact point (DPO or grievance officer)

If some facts are unknown at 72 hours, notify with what you have and commit to supplementary notification. This is standard practice; do not delay Board notification while you finalise details.

Hour 24–72: Data principal notification

Section 8(6)(b) requires intimating each affected data principal. Do this in parallel with (not sequentially after) Board notification.

The notification must be in plain language and include:

• What happened
• What personal data was affected
• What the likely consequences are (fraud risk, credential reuse risk, etc.)
• What the data principal should do (change passwords, watch for phishing, etc.)
• What you are doing about it
• How to contact the grievance officer

Common mistake: batching data principal notifications by risk tier and taking a week to send them. The Act does not accept "we prioritised high-risk users first" as a reason for delay.

Day 3–7: Deep forensics and downstream

• Forensic root cause analysis by an independent firm if the incident is material.
• Update the security controls that failed.
• Sub-processor breach cascade — if your data was affected via a vendor, they should have already told you; if you were the vendor, you should have already told your customers.
• Preserve everything for the Board's follow-up.

Day 7–30: Follow-up and post-mortem

• Supplementary notifications to the Board and data principals as facts become clearer.
• Blameless post-mortem: what failed, what the fix is, when it ships.
• Update the breach response plan with everything you just learned.
• Board-level briefing.

Mistakes that turn incidents into investigations

Across breach responses we've supported, five mistakes consistently make a bad situation worse:

1. Delay in the first 12 hours. Every hour of contained-but-unreported incident is an hour where regulator sympathy erodes.
2. Speculating in writing. "Attackers might have exfiltrated the entire user table" — written into a Slack channel at hour 3, then subpoenaed at month 6 as evidence that you knew the impact and downplayed it.
3. Understating scope in the first notification. It is better to notify broadly and narrow later than to notify narrowly and expand later. Expanding notifications look like coverups.
4. Silencing the on-call engineer. They saw what happened first. Their timeline is your best evidence.
5. Skipping the post-mortem. Regulators check whether the same control failure recurs. A documented root-cause fix is a defence; recurrence is aggravating.

Before the incident

Everything in this playbook is easier when it's been rehearsed. Once a year:

• Run a two-hour tabletop with a realistic scenario.
• Test that the on-call rota actually reaches the right people at 11pm on a Saturday.
• Test that legal, comms, and engineering can draft a notification in under 4 hours.
• Test that your DPA breach cascade with vendors works — call one Tier 1 vendor and ask them to walk you through their process.

If you want an incident response plan you can hand to a new incident commander at 11pm and trust, our breach response service rebuilds the plan and rehearses it with your team.