Building a basic incident response workflow
Most organisations don't lack the instinct to respond to a suspected data incident — they lack a written-down plan for who does what, so the first hour gets spent figuring out the process itself instead of acting on it. Here's a basic structure worth having before you need it.

Decide the roles before you need them
At minimum, someone needs to own the decision of whether an incident is a confirmed personal data breach, someone needs to be able to assess the technical scope, and someone needs to own communication — to affected individuals and to the Data Protection Board, both of which are required for any personal data breach. In a small team these can be the same person wearing different hats; the point is that it's decided in advance, not worked out mid-incident.
Write down who these people are by name or role, and how to reach them outside normal work hours. An incident rarely waits for a convenient time.
The first steps, in order
Contain what you can without destroying evidence: that might mean revoking access, isolating a system, or pausing a process, but not wiping logs or systems you'll need to understand what happened. Then assess: what data, how many people, how it happened, as far as you can tell in the first few hours.
Notification timing is a real constraint, not a formality: the DPDP Rules expect the Data Protection Board and affected individuals to be told without delay, with a more detailed report due within 72 hours. That clock starts running from when you become aware of the breach, which is a reason to escalate early rather than wait for full certainty.
What to say, and to whom
Affected individuals need enough detail to protect themselves — what happened, what data was involved, what you're doing about it, and what they can do. Vague, defensive language tends to erode trust faster than a clear, direct account of what's known and what isn't yet.
Keep a written record of what was decided and when, even in the middle of responding. It's the difference between explaining your response with evidence afterwards and reconstructing it from memory.
After it's resolved
A short internal review — what happened, what worked, what didn't — is worth doing while it's fresh, not months later. Feed anything that needs to change (an access control, a vendor clause, a monitoring gap) back into your actual processes, not just into a document that gets filed away.
From the source
The provisions this guide draws on — official text, in English.
- Section 2(u) · DPDP Act, 2023Definitions
- Section 8(5) and (6) · DPDP Act, 2023General obligations of Data Fiduciary
- Section 27(1) · DPDP Act, 2023Powers and functions of Board
- Rule 6(1)(c) and (e) · DPDP Rules, 2025Reasonable security safeguards
- Rule 7 · DPDP Rules, 2025Intimation of personal data breach
Want the first-24-hours version?
Keep the incident response checklist on hand for the hours when there isn't time to read a full guide.
