Incident Response Runbook: Data Exfiltration Under DPDP (India)

Data exfiltration incidents were difficult enough before the DPDP Act 2023. Now they carry statutory teeth: notification obligations to the Data Protection Board and to affected data principals, penalties that can reach 250 crore rupees for failure to implement reasonable security safeguards, and an evolving interpretation that will be shaped by the Board’s early enforcement actions. An Indian enterprise that handles data exfiltration badly under DPDP is not just dealing with a breach; it is dealing with a breach the regulator will later examine in forensic detail.

This runbook is tailored to India. It assumes you are the data fiduciary under DPDP, that personal data has been accessed or removed from your environment without authorization, and that you must simultaneously run technical incident response and regulatory compliance. The two tracks run in parallel, not sequentially.

What DPDP actually requires during a breach

Section 8(6) of the DPDP Act requires the data fiduciary to notify the Data Protection Board and every affected data principal of a personal data breach, in the form and manner to be prescribed. The broader framing of “reasonable security safeguards” under section 8(5) means the Board will also ask, after the fact, whether your controls were reasonable. Breach notification and safeguard adequacy are the two enforcement threads you must anticipate.

The prescribed form currently calibrates around a 72-hour notification window, aligned with international norms. Even where the rules have not crystallized every detail, the direction is clear. Assume 72 hours as your planning horizon for Board notification and expect affected-principal notification to follow closely.

Separately, CERT-In directions of 28 April 2022 require notification of cyber incidents (including data breaches affecting IT systems) within 6 hours of noticing. The 6-hour CERT-In clock and the 72-hour DPDP clock run in parallel. A data exfiltration affecting personal data triggers both.

Preparation: what must already be in place

• A named data protection officer or DPO-equivalent contact, with escalation authority.
• A data inventory linking systems to data categories and data principal counts, maintained currently.
• A breach notification template pre-drafted and legally reviewed.
• A decision matrix for classifying incidents as “reportable” under DPDP.
• Contact lists for the Data Protection Board (as prescribed), CERT-In, sector regulators, cyber insurer, legal counsel.
• DLP or egress monitoring with 90+ day retention for exfiltration pattern detection.
• Data loss prevention alerts tuned to high-volume downloads, mass emails with attachments, external sharing of sensitive repositories.
• A communications plan for data principal notifications, including SMS, email, and public notice vehicles.

Hour 0 to 1: Detection and triage

Exfiltration detection is rarely immediate. Common first signals:

• DLP alert: mass download or external sharing from a file repository.
• Unusual outbound data volume on a network link or from a SaaS.
• Unfamiliar database query patterns or bulk exports.
• Cloud storage event showing download by an unauthorized principal.
• Third-party notification (threat intelligence vendor, customer, law enforcement).
• Data surfaces on a leak site or underground forum.

Response:

1. Analyst confirms the signal is real and not benign. Ghost alerts exist.
2. Escalate to the incident commander within 15 minutes.
3. Incident commander declares an incident. The DPO or equivalent is paged immediately because DPDP timelines start running at noticing.
4. Open the incident bridge on the out-of-band channel. Start the decision log.
5. Legal counsel engaged before external communications.

Under DPDP, the clock starts at the moment the data fiduciary becomes aware of the breach. Document the time of awareness precisely; it will be asked about later.

Hour 1 to 6: Scoping and initial containment

Scoping questions

• Which systems are affected? Which databases, file stores, SaaS tools, endpoints?
• What data categories are exposed? Names, contact details, financial data, health data, Aadhaar numbers, biometric data, authentication credentials?
• How many data principals are affected? Exact count if known, estimated range otherwise.
• What is the initial access vector? Credential compromise, insider threat, misconfigured cloud storage, third-party breach?
• Is the exfiltration ongoing, or has it stopped?

Containment

• Revoke the attacker’s access vector: disable accounts, rotate tokens, block IPs.
• Isolate affected systems where feasible.
• Pull access logs before the attacker has a chance to tamper.
• Preserve forensic artifacts: endpoint memory, network captures, cloud audit logs, database query logs.
• Engage the external IR firm if one is on retainer.

CERT-In notification (6-hour clock)

Prepare and submit the CERT-In incident notification within 6 hours of noticing. This is separate from DPDP notification. CERT-In’s format and email address are published. Include: incident time, systems affected, data affected, initial containment, contact.

Hour 6 to 72: Investigation and DPDP notification preparation

Investigation objectives

• Confirm the identity of data categories exfiltrated. Speculation at this stage will create problems later.
• Confirm the population of affected data principals. Build the list.
• Determine whether the exfiltrated data is already being misused (dark web presence, phishing using the data, account takeovers).
• Assess whether any minors’ data is affected (DPDP has elevated obligations for data of children).

DPDP notification to the Data Protection Board

Prepare the notification to the Board in the form prescribed. Key content typically includes: description of the breach, categories and approximate numbers of data principals affected, likely consequences, measures taken or proposed to mitigate, contact details of the DPO or equivalent, description of any cross-border data transfer implications.

Notification to affected data principals

Each affected data principal must be notified. The DPDP Act emphasizes direct notification where feasible. Content typically includes: plain-language description of what happened, what data was affected, what the data principal can do (reset passwords, monitor accounts), what the fiduciary is doing, contact for queries, mechanism to exercise rights under DPDP.

For large-scale breaches where direct notification is not feasible, a public notice in widely-read media complements individual outreach.

Day 3 to 14: Eradication, recovery, and ongoing communication

• Close the initial access vector permanently.
• Rebuild compromised systems. Do not trust in-place cleanup of data stores an attacker has accessed.
• Rotate all credentials, tokens, and keys within the compromised blast radius.
• Monitor for follow-on attacks using exfiltrated data.
• Maintain a support channel for affected data principals with trained staff.
• File supplementary notifications to the Board as investigation progresses and new facts emerge.

Day 14 to 90: Post-incident and regulatory engagement

• Formal post-incident review with all responders and executives.
• Root cause analysis with documented remediation backlog.
• Updated risk register and Statement of Applicability if ISO 27001 certified.
• Board oversight: briefing on the incident, response quality, and remediation plan.
• Continued cooperation with the Data Protection Board on inquiries or enforcement actions.
• Revised data minimization posture: why was that data accessible to that user or system in the first place?
• Third-party notifications: customers, partners, insurers, auditors.

The DPDP clock alongside other regulatory clocks

Common mistakes

• Starting the clock late. Document the exact moment of awareness; auditors reconstruct it from logs.
• Underestimating affected-principal count. Better to estimate conservatively (higher) with a clear methodology than to be accused of downplaying.
• Delaying CERT-In while focusing on DPDP. Both clocks run in parallel.
• Speculating about cause before investigation concludes. Initial notifications should state what is known; updates follow.
• No DPO or DPO-equivalent named. The Board will ask; if there is no named contact, every question lands on the CEO.

DPDP is not a one-event regulation. The Board will look at your pre-incident posture as evidence of whether your safeguards were reasonable. The best breach response is the one you rehearsed before the breach.

Related reading

• IR runbook — ransomware (enterprise)
• IR runbook — credential compromise & session hijack
• DPDP breach notification — 72-hour playbook
• DPDP compliance — complete guide
• DPDP compliance checklist — download

Work with RingSafe

RingSafe builds DPDP-aligned incident response programs, drafts breach notification templates reviewed by Indian counsel, and runs DPDP tabletops with executive teams. Founder Manish Garg (Associate CISSP, CEH, CCNP Enterprise) and the team have guided Indian enterprises through real data exfiltration incidents with parallel CERT-In, DPDP, and sector-regulator tracks.

If your breach response playbook is not DPDP-ready, start with a DPDP assessment, or book a scoping call and we will build a runbook that survives regulator scrutiny.