DPDP-aware incident response (internal playbook)

Audience: security, IT, ops, privacy leads, founders · Last reviewed: March 2026

This page is for internal operations: how to run a calm first response when something breaks and personal data might be involved. It is not legal advice and does not describe specific notification duties, timelines, or Board processes—those depend on facts, sector context, and the authoritative legal text and notified rules. Use it alongside your security incident process and escalation matrix.

What this playbook covers

Typical triggers include mis-sent exports, misconfigured buckets or ad pixels, a vendor outage that exposes dashboards, a support agent downloading lists to a personal device, or a phishing hit on an account that can reach CRM data. The goal is not to merge every incident into “privacy” or “security” as a single vague label—it is to ensure someone checks whether personal data is implicated before you close the ticket.

• Pair with: time-boxed operational workflows (one-hour / one-day incident drills) and the compliance checklist security section.
• Distinguish: grievances and rights requests follow different paths—see grievance redressal and complaint preparedness.

Phases

1. Intake (minutes). One ticket, one owner; capture source (who reported), systems named, and whether customer-facing comms already went out.
2. Triage (same session). Classify: pure security with no personal-data angle vs uncertain vs confirmed personal-data categories. If uncertain, assume review is needed before external statements.
3. Contain. Follow security best practice first (revoke tokens, rotate keys, block exfil paths). Avoid “silent deletes” that remove audit evidence.
4. Escalate. Pull in legal/comms per your matrix; use when to involve counsel as a sanity check.
5. Record. Decision log: what was known at each step, which systems were checked, and which duties were confirmed against primary text (not memory).
6. Review. Post-incident learning with action owners; update SOPs and training where the failure was procedural.

Roles and handoffs

Clarity beats title inflation. At minimum, name a technical DRI (facts on systems), a privacy/compliance DRI (data categories, flows, notices), and a comms DRI (internal and external messaging). Agencies and outsourced teams should know which client’s data is in scope before anyone drafts customer language—see DPDP for agencies on client territories.

Evidence and recordkeeping

Regulators and enterprise customers eventually ask for demonstrable control, not intentions. Point to recordkeeping habits and ensure incident artifacts live in approved repositories—not personal chats. For fiduciary duties at a high level (including security safeguards), orient from duties of data fiduciaries and verify details in official resources.

After stabilizing

Run a short retrospective: what detection gap existed, what vendor or config failed, and what measurable control changed. Refresh data maps if the incident exposed shadow processing. If the event may affect how you explain processing to users, plan a coordinated review of notices with product—not a rushed one-off banner.

For a printable field worksheet, use the incident triage checklist sheet alongside this playbook.