Incident Response Plan
A written plan that says who does what when a security incident or breach happens.
An incident response plan is a written playbook that tells your team who does what, in which order and by when, from the moment a security problem is spotted until normal service and trust are restored.
Meaning of Incident Response Plan
A good plan names an owner, sets how the incident is classified, explains how and when affected people, the Board, CERT-In and sector regulators are told, and covers containment and recovery. The Rules require a detailed report to the Board within 72 hours, so the plan should be built around that clock.
An incident response plan (IRP) turns panic into procedure. It sets out how an event is detected and reported inside the organisation, who decides whether it is a security incident or a personal data breach, who leads, who is called, and how the company contains the damage, investigates, notifies and recovers. A useful plan is short enough to be read in the middle of the night, names real roles and phone numbers, and comes with checklists and message templates.
The Act and Rules make a plan close to unavoidable. Section 8(6) requires a Data Fiduciary to intimate the Data Protection Board and each affected Data Principal of a breach. Rule 7 shapes the timetable: affected individuals are told without delay, the Board is told without delay with the nature, extent, timing, location and likely impact, and a detailed report follows within 72 hours or any longer period the Board allows. Rule 6 adds backups and continuity measures, and Section 8(5) the duty to take reasonable security safeguards.
A plan should also account for duties outside the DPDP framework. CERT-In directions expect certain cyber incidents to be reported within six hours of being noticed. Banks, insurers, listed companies and telecom licensees may have to inform RBI, IRDAI, SEBI or the telecom authorities on their own schedules. The plan should list each regulator, the trigger, the deadline and the person who files.
Think of the plan in phases: prepare, detect and triage, contain, eradicate and recover, notify, and learn. It differs from a business continuity plan, which keeps operations running, and from a disaster recovery plan, which restores technology. It also differs from a breach register, which records what happened, whereas the plan instructs what to do.
Examples of Incident Response Plan
A plan assigns the CISO to lead, the legal team to prepare notices and the communications team to draft customer messages, with a checklist for the 72-hour report.
A hospital's plan names the medical records head, not just IT, as a decision-maker. When a [ransomware](term/ransomware) note appears on the billing server, the team switches to paper processes, isolates the network, informs CERT-In, and starts preparing patient notices the same day.
An HR manager sends a payroll file to the wrong vendor email. Because the plan has a one-page misdirected-data checklist, she reports it within minutes, the vendor confirms deletion in writing, and the privacy lead documents why notification thresholds were assessed and decided.
A fintech app's plan maps every regulator and contact, so a credential-stuffing wave triggers parallel reports: one to CERT-In, one to its sector regulator and, because accounts were accessed, an initial and a 72-hour report to the Board, drafted from templates.
Why Incident Response Plan matters
The cost of a breach is driven heavily by the first day. Delay in containing an intruder, uncertainty about who may speak to customers, and arguments about whether to notify all eat into the narrow window the Rules allow. A failure to notify can lead to a penalty of up to ₹200 crore, and a failure of security safeguards up to ₹250 crore. A rehearsed plan lowers both the chance and the severity.
There is also a human side. People whose data is exposed need clear, early, plain-language advice to protect themselves from fraud. Employees need to know they will not be punished for reporting a mistake quickly.
How it works in practice
- 1Appoint an incident lead and deputies, and form a small team spanning security, IT, legal, privacy or the Data Protection Officer, communications, HR and a senior business decision-maker. Keep an offline out-of-hours contact list.
- 2Define severity levels and the criteria that trigger a breach assessment: was personal data exposed, altered or made unavailable, whose data, how many people, and what harm could follow.
- 3Write containment steps for common scenarios: stolen laptop, compromised email account, ransomware, misdirected email and vendor breach. Include when to isolate systems and how to preserve logs.
- 4Pre-draft notices: a template for affected individuals, a Board report skeleton aligned with Rule 7, and a CERT-In report format.
- 5After every real incident, hold a blameless review, record root cause and fixes in the breach register, and feed lessons back into training and controls.
Where it appears in the DPDP Act and Rules
Common mistakes to avoid
Writing a long plan that sits on a shared drive and has never been tested. Run drills and trim the plan until people can follow it under stress.
Making IT the only owner. A breach is also a legal, communications and customer issue.
Forgetting the clock starts at awareness. Keep a timestamped log of when the first person knew.
Compliance tips
Keep a printed or offline copy of the plan and contact list, because the systems holding the digital copy may be down.
Agree in advance who can approve notices to customers and the Board, so approvals do not become the bottleneck.
Tell all staff one simple rule: report anything odd immediately, to one phone number or mailbox, with no blame for honest mistakes.
Common questions about Incident Response Plan
Is an incident response plan required by the DPDP Act?
No section names it, but Section 8(5), Section 8(6) and Rules 6 and 7 together demand security safeguards and fast, structured breach notification. In practice that is very hard to meet without a written, tested plan, so it is treated as a core compliance document.
What should an incident response plan include?
Roles and contacts, severity criteria, containment steps for common scenarios, evidence handling, notification procedures and templates for individuals, the Board, CERT-In and sector regulators, recovery steps, and a post-incident review process. Add an annual testing schedule.
How often should we test the plan?
At least once a year, and ideally twice, plus after major organisational or system changes. Tabletop exercises are cheap and effective. Record the exercise, the gaps found and the updates made, since that record is useful evidence of preparedness.