What should be in our incident response plan for DPDP?
Key takeaways
- CERT-In requires listed incidents to be reported within six hours of notice, on incident@cert-in.org.in or 1800-11-4949, and that clock does not wait for certainty.
- DPDP Rule 7 notification obligations commence from May 2027, and 83% of Indian organisations have not begun comprehensive implementation.
- The plan must name individuals with deputies, because a plan that depends on one person's availability is not a plan.
- Evidence preservation is a legal requirement as well as a technical one, and a containment step that wipes logs can destroy the case.
- An untested plan is a document, not a capability: run at least two tabletop exercises a year against the six-hour clock.
As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.
How do the CERT-In and DPDP clocks fit together?
They are two separate obligations with two separate start points, and the tighter one governs your process. CERT-In requires listed incidents to be reported within six hours of your becoming aware or being brought to notice, on incident@cert-in.org.in or 1800-11-4949, and the report is made on what you know at that hour, not on what you wish you knew. DPDP Rule 7 notification obligations commence from May 2027, and from that point a data fiduciary also notifies affected individuals and the Data Protection Board. Build the plan so that the first four hours produce one incident record that feeds both reports, because running two parallel documentation processes is how the six-hour window is missed.
Who needs to be in the plan, and what do they do?
Name people, not job titles, and give each a deputy. For an Indian SME the minimum set is an incident lead who owns the clock, a technical investigator, a person who can authorise isolation of systems, a finance or business contact for BEC and payment fraud, a legal or compliance point of contact for notifications, and a communications owner for staff, customers and the media. Write down the trigger for each action, so that in hour two nobody is debating whether they are allowed to take the server offline. Also write down what happens when the incident lead is unreachable, which is the most common failure in a plan that has only ever been read once.
What should the containment, evidence and communication parts cover?
Containment should list the isolation options for each system type and the business cost of each, so a decision can be made in minutes rather than argued over. Evidence handling needs to cover what you preserve, where you preserve it, and the fact that CERT-In expects 180 days of logs to be retained, so a wipe of the affected host can destroy the record of the intrusion. The communication plan should have pre-approved holding statements for staff, customers, regulators and the press, because in a fraud or ransomware event the first hour of wording is usually improvised and later regretted. For an Indian company, include the National Cyber Crime Reporting Portal at cybercrime.gov.in and the 1930 helpline in the personal-incident path.
How do you prove the plan works?
Test it, twice a year, against the six-hour clock, and record the results. A tabletop exercise is enough: pick a plausible scenario for your business, for example a compromised finance mailbox or a ransomware note on a file server, and walk the plan minute by minute from detection to CERT-In report. Record the actual time to each decision, because that is the number that tells you whether the six hours are real. Then test the technical side at least once a year by exercising your backups, because untested backups are the most common reason an Indian ransomware recovery budget is fictional. A closing review after every real incident feeds the next version of the plan.
| Section | What it must specify | Evidence of readiness |
|---|---|---|
| Scope | All personal data, systems, and third parties holding it | Data flow and asset inventory |
| Roles | Named individuals with deputies and triggers | Contact list with tested numbers |
| Detection and triage | Sources of alerts, severity criteria, escalation | Alert routing evidence |
| CERT-In reporting | Six-hour clock, incident@cert-in.org.in, 1800-11-4949 | A filed test report and its timestamp |
| DPDP notification | Rule 7 path from May 2027, notice to individuals and Board | Template notice and approval record |
| Evidence | 180-day log retention, preservation, chain of custody | Preservation procedure and storage location |
| Containment and recovery | Isolation options per system, restore steps | Tested backup restore |
| Communication | Pre-approved statements for staff, customers, media | Signed-off template library |
| Testing | Two tabletop exercises a year against the clock | Dated exercise records and fixes |
What are the frequently asked questions?
Get a straight answer on this
Send us your system list and your current incident contacts, and we will run a one-hour tabletop against the six-hour clock and hand you a gap list.
Send us the details See pricing