DPDP Data Breach Response: Your 72-Hour Notification Playbook

Hour 0–4: Detect and Contain

The clock starts when you become aware of a personal data breach. DPDP Section 25(1) requires notification to the Data Protection Board 'in the prescribed form and manner' — pending rules, assume the 72-hour GDPR standard applies as a safe interpretation.

Immediate actions: (1) Isolate the affected system (disable the compromised API key, suspend the breached service), (2) Preserve evidence (take snapshots before logs rotate, enable enhanced logging), (3) Assemble the incident response team (DPO, engineering lead, legal), (4) Begin the breach log (all actions taken and timestamps).

Hour 4–24: Assess the Scope

Determine: what personal data was exposed, of whom, for how long, and whether it was accessed by an unauthorised party or merely exposed. For AI-related breaches, query your audit log (or CrewCheck's compliance dashboard) to identify all sessions where the breached data was processed.

Calculate blast radius: number of affected data principals, categories of personal data involved (Aadhaar, PAN, health, financial), and whether the data has been exfiltrated or merely accessible. This drives the breach notification content and the urgency of notifying affected data principals.

Hour 24–72: Notify and Document

Prepare the Data Protection Board notification. Required elements (anticipated from DPDP rules): description of the breach, categories and number of data principals affected, categories and volume of personal data involved, likely consequences of the breach, measures taken to mitigate consequences, contact details of the Data Protection Officer.

Simultaneously prepare notifications for affected data principals under DPDP Section 25(3): clear description of what happened, what data was exposed, what you're doing about it, and what affected individuals should do to protect themselves.

Post-Breach: Remediation and Evidence

After the immediate breach response, conduct a root cause analysis and document it. If the breach involved PII in LLM prompts or logs: (1) Implement the gateway + redaction architecture to prevent recurrence, (2) Rotate all API keys and secrets that could have been exposed, (3) Run a full PII sweep of your log storage to identify any remaining exposed data.

The post-breach document becomes evidence for the Data Protection Board that you've taken corrective action. It's also the foundation for your insurance claim (if you carry cyber liability insurance) and demonstrates the 'reasonable security safeguards' standard under DPDP Section 8(5).

Compliance operational checklist

DPDP Data Breach Response: Your 72-Hour Notification Playbook should be reviewed as an operating control, not only as a reference article. The minimum checklist is a data inventory, a stated processing purpose, owner approval, PII detection at the AI boundary, redaction or tokenisation where possible, retention limits, vendor transfer records, and a tested user-rights workflow. This checklist gives engineering and compliance teams a shared language for deciding what must be blocked, what can be allowed in shadow mode, and what needs human review before production release.

For AI systems, the review should include prompts, retrieved context, tool call arguments, model responses, logs, traces, analytics events, exports, and support attachments. Many incidents happen because teams scan only the visible form field while sensitive data moves through background context or observability tooling. CrewCheck's recommended pattern is to place the scanner at the request boundary, record the policy version, and keep audit evidence that shows which identifiers were detected and what action was taken.

A practical rollout starts with representative samples from production-like traffic. Run a DPDP scan, sort findings by identifier sensitivity and blast radius, fix Aadhaar, PAN, financial, health, children's, and precise-location exposure first, then move to consent wording, retention, deletion, and vendor review. Use shadow mode when false positives could disrupt users, and promote to enforcement only after the exceptions have owners and expiry dates.

This page is educational and should be paired with legal review for final policy interpretation. The operational proof should still come from repeatable evidence: scanner results, audit exports, pull-request checks, policy configuration, and a documented owner for the workflow. That combination is what makes the content useful during buyer diligence, board review, regulatory questions, or an incident investigation.