DPDP Breach Notification Checklist — 72-Hour Playbook

Hour-by-hour breach response runbook

Standard incident response sequence aligned to DPDP + CERT-In clocks:

• Hour 0 — Awareness: someone (alert, customer complaint, security team) flags a potential breach. Open the incident, page on-call security, start the response timer.
• Hour 0-1 — Triage: confirm breach is real (not a false alarm). Establish initial scope estimate: what data, how many records, what time window.
• Hour 1-3 — Containment: stop the bleeding. Revoke compromised credentials, rotate keys, isolate affected systems, block attacker IPs at the WAF.
• Hour 3-6 — CERT-In notification (Form C): file the cybersecurity incident report. CERT-In's 6-hour clock expires here.
• Hour 6-24 — Forensic scoping: full forensic investigation. Confirm scope, attack chain, data exfiltration evidence. Engage forensic firm if no in-house capacity.
• Hour 24-72 — Board notification draft: prepare the 5-field DPDP notification. Legal review. Stakeholder sign-off.
• Hour 48-72 — Board notification filing: submit to Data Protection Board via prescribed channel. 72-hour clock expires here.
• Hour 72+ — Data principal notification: direct notification to affected data principals where significant harm is likely.
• Day 7-30 — Remediation + post-incident review: root cause analysis, control improvements, retest, executive lessons-learned.

The 5-field Board notification template

The Board notification must contain five fields. Pre-populate them in your incident response runbook to save 24-48 hours during the actual response:

• Field 1 — Nature of breach: brief description of what happened (ransomware, unauthorised access, data exposure, insider exfil, third-party compromise, etc.)
• Field 2 — Scope: categories of personal data affected (name, email, phone, payment, ID, biometric, sensitive) AND approximate number of data principals affected
• Field 3 — Likely consequences: harm assessment (financial, reputational, identity theft, secondary attack on principals, etc.)
• Field 4 — Measures taken: containment, eradication, recovery actions already completed
• Field 5 — Mitigation for principals: notifications, credit monitoring, password resets, fraud-watch advisories, etc.

Common breach-notification mistakes

From our incident response work — frequent failure modes:

• Waiting until forensic scope is 'fully confirmed' before notifying — the Board accepts preliminary scope and updates
• Notifying CERT-In but forgetting the parallel DPDP Board notification (different recipient, different timeline)
• Underreporting scope to minimise penalty — the Board treats underreporting as concealment, aggravating
• No documented breach severity matrix — every breach feels like a P1, no clear escalation criteria
• Counsel and security team operating in silos — notification draft delayed by legal review backlog
• No tested communication template for data principal direct notification (Section 8 likely-harm cases)

How to prepare in advance

The 72-hour clock starts at awareness, not at response readiness. Pre-built runbooks save the most time. Recommended prep: (1) Documented incident response plan with the hour-by-hour runbook above. (2) Pre-populated 5-field notification template with placeholders. (3) Forensic firm relationship established (not negotiated during the breach). (4) Communication templates for data principal notification across email, SMS, push, in-product. (5) Annual tabletop exercise to stress-test the runbook with a simulated breach.

Bachao.AI's breach response support

We provide pre-incident preparation (runbook authoring, tabletop exercise facilitation, notification template drafting) and in-incident forensic response (scoping, evidence preservation, CERT-In + DPDP notification drafting, remediation guidance). The deliverable is a forensic report admissible in Data Protection Board proceedings. See /incident-response for the full service description.