Building a DPDP-compliant breach response plan (the 72-hour rule in practice)

At a glance

A personal data breach starts a clock under India’s DPDP Act. You must send the Data Protection Board an initial intimation without delay the moment you become aware, then a detailed report within 72 hours (extendable on request), and notify each affected person in plain language. A separate CERT-In rule can require reporting certain cyber incidents within 6 hours. A breach response plan is what lets you hit those clocks under pressure — decided in advance, not invented mid-incident. This is the actionable build; the rule itself is covered in the breach pillar.

Educational resource only. This explains how to prepare for the breach-notification duty under India’s Digital Personal Data Protection Act, 2023 (DPDP Act); it is not formal legal advice.

The situation

A breach is the worst time to work out who does what. Systems are down or compromised, information is thin, and a legal clock is already running. A response plan turns a panicked scramble into a sequence you’ve rehearsed — which is exactly what meeting the notification duties requires.

Why you build the plan before the breach

The duties are time-boxed, so the work has to be done ahead of time. The DPDP Act requires a Data Fiduciary to notify the Data Protection Board of India and affected individuals of a personal data breach (Section 8). Because the reporting is on a tight clock, you can’t assemble roles, contacts, and templates after the fact and still comply. The plan is the difference between “we notified within the window” and “we were still figuring out who to call.”

Failing to notify carries serious exposure — penalties for not reporting a breach run to the highest tiers.

Use the template

DPDP breach notification template — a ready-to-fill report covering both the initial intimation and the detailed 72-hour follow-up.

The clocks you’re planning against

Three timelines can run at once — plan for the tightest. In practice:

• Immediately — initial intimation to the Board. The moment you confirm a breach, an initial notice goes to the Data Protection Board describing what’s known.
• Within 72 hours — the detailed report. A fuller account to the Board: the nature and extent of the breach, the sequence of events, remedial and mitigation measures taken, and findings on who or what caused it. You can request an extension in writing.
• Affected individuals — without delay. Each affected person is told, in concise, clear, plain language, what happened and what they can do.
• Separately — CERT-In’s 6-hour rule. India’s cyber-incident directive can require reporting certain incidents to CERT-In within 6 hours. It’s a distinct obligation that can apply alongside the DPDP duty, so your plan should account for both.

The response plan, step by step

Build it as a runbook: who acts, in what order, with what already prepared.

1. Name the response team and a lead — who decides, who investigates, who communicates. One named owner of the clock.
2. Define “aware.” Decide what counts as becoming aware of a breach, so the clock’s start isn’t ambiguous.
3. Pre-write the notifications — template intimations for the Board and for affected individuals, with blanks to fill under pressure.
4. Keep contacts ready — how you reach the Board, CERT-In, your processors, and (if relevant) your DPO or grievance contact.
5. Set the investigation steps — contain, assess scope (what data, whose, how much), preserve evidence, and record a timeline as you go.
6. Plan the affected-person message — plain-language, what happened, what data, what they can do, and how to reach you.
7. Log everything. A written record of when you became aware and every step since is what demonstrates you met the duty.
8. Rehearse it. A tabletop run once a year finds the gaps before a real incident does.

What to decide in advance

A few decisions are much harder mid-crisis — make them now. Agree upfront: who has authority to notify the Board (don’t wait for someone on leave); how you’ll reach affected customers at scale; which processor contracts require the vendor to alert you fast (so their breach doesn’t blow your clock); and where your evidence and logs live. These are the calls that, left to the moment, cause missed windows.

FAQ