DPDP Data Breach in India: Your 72-Hour Incident Response Playbook

When the Alarm Goes Off, You Have 72 Hours

A data breach under the DPDP Act 2023 is not just a technical incident — it is a regulatory event with hard deadlines, mandatory notifications, and penalty exposure that begins from the moment of detection. The organisations that survive breaches with minimal regulatory consequence are the ones that had a playbook before the breach happened.

This is that playbook.

Before the Breach: Prerequisites

This playbook only works if three things are in place before an incident:

1. A designated Incident Commander — one named individual with the authority to declare an incident, pull in resources, and make the DPB notification call. Not a committee.
2. A CERT-In Point of Contact (PoC) — registered with CERT-In before you need it. Registration takes 20 minutes. Without it, your first 6 hours include creating an account under pressure.
3. Log retention — 180-day log retention per CERT-In 2022 direction. If your logs aren't there, forensics cannot establish the breach timeline and scope, which means you cannot write the notification accurately.

Hour 0–6: Containment

The first phase is about stopping the bleeding, not about understanding the full picture. Forensic completeness is a second-phase goal.

graph TD
    A[Alert Detected] --> B{Is this a declared incident?}
    B -->|No — monitor| C[Log and watch for 30 min]
    B -->|Yes| D[Notify Incident Commander]
    D --> E[Isolate affected systems]
    E --> F[Preserve logs — do NOT wipe]
    F --> G[Notify CERT-In PoC within 6 hrs]
    G --> H[Assemble response team]
    style D fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style G fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0

Hour-by-Hour Actions (0–6)

Hour 0: Detection and declaration

1. Whoever detects the alert (SIEM, user report, vendor notification) immediately escalates to the Incident Commander
2. Incident Commander makes the binary decision: declared incident or not
3. If declared: start the clock. Document the declaration time — this is the T=0 for all regulatory deadlines

1. Isolate affected systems from the network — but do not shut them down; memory forensics may be needed
2. Disable compromised credentials immediately — do not wait to understand the full scope
3. Snapshot affected servers (cloud snapshot or forensic image) before any remediation steps
4. Turn off log rotation on affected systems — preserve every log byte

1. What data is involved? Identify the database tables or files that were accessed
2. Is personal data included? Any Indian resident's name, phone, email, address, financial data, health data, government ID — it's in scope
3. How many individuals? Initial estimate is fine; precision comes later
4. What was the attack vector? (Approximate — exact RCA comes in phase 2)

1. Incident Commander, CTO/Head of Engineering, Legal counsel, DPO (if appointed), Communications lead
2. Brief the team on what is known and what is not — do not overclaim certainty
3. Begin drafting the CERT-In notification form (see template below)

1. File via cert-in.org.in/s2cMainServlet?pageid=PUBVLNRPT or email to incident@cert-in.org.in
2. Use initial estimates — CERT-In expects an initial report, not a final investigation conclusion
3. Retain the submission confirmation (email or form acknowledgement) — this is evidence of compliance

CERT-In Initial Notification Template

To: incident@cert-in.org.in
Subject: Cyber Incident Report — [Your Organisation Name] — [Date]

Organisation: [Name]
CERT-In PoC: [Name, Email, Mobile]
Incident Detected At: [Date, Time IST]
This Report Filed At: [Date, Time IST]

1. Nature of Incident: [Select from 28 CERT-In categories]
   e.g., "Unauthorised access to IT systems / Data breach"

2. Systems Affected: [Web application / Database server / API layer]
   Infrastructure details: [Cloud provider, region, OS]

3. Data Involved (initial estimate):
   - Categories: [Customer PII / Employee data / Financial records]
   - Volume: Approximately [X] individuals affected

4. Attack Vector (initial assessment):
   [e.g., SQL injection on login endpoint / Credential stuffing / Ransomware]

5. Actions Taken:
   - [Time]: Isolated affected systems
   - [Time]: Disabled compromised credentials
   - [Time]: Preserved logs
   - Ongoing: Forensic investigation in progress

6. Containment Status: [Partially contained / Fully contained]

7. Further information will be provided within 30 days per CERT-In follow-up requirement.

Hour 6–24: Assessment and Legal Review

The containment is in place. Now you need to understand what actually happened well enough to assess DPB notification requirements.

Actions in this window:

Technical investigation (hours 6–18)

1. Identify the initial access point — what vulnerability was exploited?
2. Reconstruct the attacker timeline from logs — when did they first enter, what did they access, when did they leave?
3. Determine if data was exfiltrated (versus only accessed) — check outbound network logs for large data transfers
4. Identify all affected user accounts and data records

1. Is this a "personal data breach" under the DPDP Act? (Answer: almost certainly yes if customer data was involved)
2. Does the breach trigger DPB notification? The Act requires notification for breaches that are "likely to cause harm" — the threshold is low; when in doubt, notify
3. Are there sector-specific parallel obligations? (RBI: 2-hour notification for financial incidents; SEBI: immediate notification for market-sensitive incidents; IRDAI: separate notification for insurers)
4. Brief legal counsel and document the legal assessment

1. Generate the list of affected user IDs from the technical investigation
2. Map to PII fields: what data did each affected user have in the compromised system?
3. This list is needed for the DPB notification and for individual notifications

Hour 24–48: Draft DPB Notification

The DPDP Act requires notification to the Data Protection Board "in such form and manner as may be prescribed." The Board has indicated it expects notification "without undue delay" — with the expectation that this is within 72 hours of the Data Fiduciary becoming aware of a breach.

DPB Notification Draft

The notification must contain:

Hour 48–72: Submit and Notify Individuals

Hour 48–60: Internal sign-off on DPB notification

1. Legal counsel reviews draft
2. CEO / Founder signs off — this is a Board-level decision, not an IT decision
3. If you have cyber insurance, notify your insurer before submitting — most policies require pre-notification

Individual notification must:

1. Be in plain language — not legal boilerplate
2. State what data was involved
3. Explain the likely impact on the individual
4. Tell them what steps to take (change passwords, monitor accounts, freeze credit)
5. Provide a contact for questions

Individual Notification Template

Subject: Important security notice regarding your [Company Name] account

Dear [First Name],

We are writing to inform you of a security incident that may have affected your account with [Company Name].

What happened: On [date], we discovered that unauthorised access occurred to our [systems]. Our investigation determined that your account was among those affected.

What information was involved: [Specific data fields — e.g., name, email address, phone number. State clearly what was NOT involved if relevant.]

What we have done: We have [taken steps — isolated the affected systems, reset all passwords, engaged forensic investigators, reported to CERT-In and the Data Protection Board].

What you should do:
- Change your password on any site where you used the same password
- Monitor your bank and financial accounts for unusual activity
- If you received a phishing email claiming to be from us, do not click any links

For questions, contact our Data Protection Officer at: [email] or [phone], available [hours].

We sincerely apologise for this incident.

[Authorised signatory]

Post-72 Hours: Recovery and Regulatory Follow-Up

The immediate crisis is managed. The next 30 days focus on:

1. Full Root Cause Analysis (RCA) — documented, with a timeline from initial access to detection
2. CERT-In follow-up report — due within 30 days of the initial notification, with complete technical details
3. Remediation verification — VAPT re-scan of the affected systems after fixes are deployed
4. Board briefing — full incident briefing to Board of Directors with lessons learned
5. Policy and control updates — what control failed, what would have caught it earlier, what is being changed

Need a custom incident response plan and breach notification templates? Bachao.AI's Full Report package includes a complete IR playbook built to your specific technology stack. Start with a free scan at bachao.ai/incident-response.

Written by Shouvik Mukherjee, Founder, Bachao.AI. DPIIT Recognised Startup. CERT-In empanelled security auditing organisation.