A personal data breach response playbook for India has to work before anyone knows the full story. One team may be blocking an attacker while another traces affected records, checks reporting routes, prepares an executive update, and preserves material for later review. The useful playbook is not a long policy. It is a set of controlled decisions that people can follow under pressure.
Begin with current primary sources. The Digital Personal Data Protection Act, 2023, MeitY’s final Rules collection, and CERT-In’s section 70B Directions page address different questions. NIST’s incident-response recommendations offer a technical framework, not an interpretation of Indian law. Have qualified reviewers determine which sources apply to the actual event.
What should the response team do when the first alert arrives?
Open one restricted incident record and give it a durable identifier. Record the alert as received, its source, discovery time, affected environment, initial owner, and the next review point. Preserve original logs and messages before routine retention or account changes erase context. Containment can begin while classification remains provisional.
The first hour works better when every entry is labelled:
| Entry | What good evidence looks like |
|---|---|
| Observed fact | A timestamped system event linked to its source |
| Working theory | A testable explanation, clearly marked as unconfirmed |
| Action | Actor, time, purpose, result, and approval if required |
| Unknown | A precise gap, owner, and expected update |
| Decision | Options considered, decision-maker, basis, and revisit trigger |
Do not paste credentials, raw personal data, or entire log sets into a broad chat. Store sensitive material in the approved evidence location and link to it from the incident record. A clean start prevents responders from reconstructing the reconstruction later.
How should a team separate a security incident from a personal data breach assessment?
Run the two assessments together, but do not merge their conclusions. Security responders ask how an event happened, whether access persists, and what containment is safe. Privacy reviewers ask whether personal data was involved, what happened to it, whose data it was, what consequences may follow, and which communications or decisions may be required.
Use a shared chronology with specialist workstreams:
Alert → preserve → contain → scope systems → map data → assess consequences → decide reporting → communicate → recover → verify
The privacy workstream should test inventory records against reality. Sample affected tables, storage locations, exports, backups, and provider flows. Record whether data may have been accessed, copied, altered, disclosed, encrypted, deleted, or made unavailable. If the answer changes, retain both versions and explain why. Silent overwriting is especially damaging when later reviewers ask what the team knew at a particular time.
Which evidence should be captured without slowing containment?
Capture enough to reproduce material events and decisions, not everything a system can emit. The following register keeps evidence usable:
| Evidence group | Minimum context | Control question |
|---|---|---|
| Alerts and logs | Source, time zone, collection method, hash or immutable reference | Can an investigator locate the original? |
| Identity events | Account, privilege, session, device, authentication trail | Was legitimate use distinguished from misuse? |
| Data scope | System, fields, population method, uncertainty | Can another reviewer repeat the estimate? |
| Containment | Change, operator, approval, before-and-after result | Did the action destroy relevant evidence? |
| Communications | Approved version, recipients, dispatch proof | Which facts were communicated when? |
| Decisions | Source, facts, adviser, outcome, revisit point | Is reasoning visible without privileged detail spreading? |
Keep a chain-of-custody record where forensic use may matter. Restrict access by role and define retention with counsel. Evidence preservation does not justify creating uncontrolled copies of sensitive material.
How can parallel reporting paths be managed without mixing them up?
Create a reporting matrix at incident launch. The DPDP framework, CERT-In Directions, contracts, customer arrangements, sector rules, and law-enforcement considerations may have different triggers, recipients, content, and timing. One report should never be assumed to discharge another route.
For every candidate route, record:
- exact official source and version checked;
- applicability owner and legal interpretation;
- triggering event and the timestamp used;
- facts required, facts available, and important unknowns;
- approved channel, recipient, and fallback contact;
- deadline calculation and review checkpoints;
- submission copy, acknowledgement, and follow-up commitments; and
- reasoned decision when no submission is made.
The CERT-In Directions and FAQ collection should be read directly because incident categories and operational expectations require careful mapping. Do not paraphrase a generic deadline into the playbook as if every privacy event follows it. Configure reminders only after the event and entity have been assessed.
What makes a breach communication accurate and useful?
Maintain an approved facts sheet with version history. It should state confirmed facts, current estimates, material unknowns, containment status, practical protective steps, and the next update. Legal, technical, privacy, customer-support, and communications reviewers can work from the same base without publishing the investigation record.
Before dispatch, check:
- recipient logic was tested and duplicates handled;
- numbers and dates reconcile to the current scope method;
- uncertainty is stated plainly rather than hidden;
- protective actions are realistic for the affected audience;
- contact and grievance routes are staffed;
- language and accessibility needs were reviewed;
- delivery, bounces, corrections, and acknowledgements are captured; and
- the exact approved version is retained.
Avoid speculative attribution and tidy narratives that exceed the evidence. A short, candid explanation with useful next steps usually serves affected people better than dense technical detail.
How should providers fit into the incident workflow?
The provider register should identify emergency contacts, services, data contexts, access paths, log availability, subprocessors, hosting context, contractual notification route, and evidence-preservation expectations. During an event, record every request and response rather than relying on an email thread that only one person can see.
Test provider scenarios before an incident. Can someone preserve expiring logs outside business hours? Who approves a disruptive containment step? Can the provider distinguish the organisation’s records in shared infrastructure? Who communicates with downstream providers? The answers belong in the playbook and the associated third-party privacy risk assessment, not in institutional memory.
For a prospective workflow platform, review Gotham’s security information, privacy information, and relevant agreements. These are diligence inputs. They do not establish a customer’s compliance or determine statutory roles.
How should recovery be proved rather than declared?
Recovery needs exit criteria. Confirm that persistence was removed, relevant credentials or keys were addressed, vulnerable paths were closed, monitoring covers the repaired environment, affected services operate as intended, and sensitive evidence remains protected. Reconcile restored systems to the assessed data scope rather than treating uptime as the only success condition.
Convert findings into evidence-linked work:
| Finding | Control change | Owner | Validation | Closure evidence |
|---|---|---|---|---|
| Unknown export path | Update inventory and restrict transfer | System owner | Repeat data-flow test | Approved map and access test |
| Short log retention | Extend or export relevant logs | Security owner | Simulated investigation | Retrieval record |
| Stale provider contact | Refresh escalation register | Procurement owner | Out-of-hours drill | Drill result |
A ticket is not closure. Someone independent of the implementer should check the agreed validation where risk warrants it. Record residual risk and the person authorised to accept it.
How often should the playbook be exercised and revised?
Use scenarios that force uncomfortable handoffs: compromised administrator credentials, an accidental public link, a provider compromise, ransomware with uncertain exfiltration, lost logs, and contradictory population estimates. Exercise decision-making and communications, not only technical containment.
Measure time to assemble the right roles, preserve volatile evidence, establish a dependable chronology, identify personal-data contexts, reach providers, resolve reporting routes, approve communications, and validate recovery. Track missing evidence and repeated friction. These are operational readiness signals, not a legal compliance score.
The playbook should trigger review after an incident, exercise, material architecture change, new critical provider, changed official source, or major organisational change. Keep a secure offline contact path for identity or network outages.
For the wider evidence system, see the related DPDP compliance software guide. Teams can also explore Gotham workflows, review security and compliance information, or contact Gotham about controlled incident coordination. Real incidents require current source verification and qualified legal and security judgment.
