Incident Response
Data Breach Response in India: The Complete Checklist for DPDPA and CERT-In Compliance
When a data breach occurs, most organisations discover their response plan too slowly, coordinate too loosely, and document too little. The result is not just a worse technical outcome — it is compounded regulatory exposure. India's DPDPA 2023 and CERT-In Directions 2022 create hard notification deadlines that begin at the moment of awareness, not the moment of confirmation. This checklist exists so you act in the right order, at the right speed.
1. The Two Clocks: CERT-In and DPDPA Run Simultaneously
Before the checklist, understand the timeline architecture. Two separate regulatory frameworks impose notification obligations on different timelines from the moment a relevant incident is detected.
| Obligation | Regulator | Deadline | Trigger |
|---|---|---|---|
| Cybersecurity incident notification | CERT-In | 6 hours from detection | Any of 21 prescribed incident types, including data breaches |
| Personal data breach notification | Data Protection Board | 72 hours (rules to specify) | Any unauthorised processing, accidental disclosure, or loss of personal data |
| Data Principal notification | Board direction | As directed by Board | Board may direct notification to affected individuals |
⚠ “Awareness” Is the Starting Point, Not Confirmation
Both clocks start when an authorised person in your organisation becomes aware that an incident has occurred or may have occurred — not when the technical investigation is complete, not when the scope is confirmed, and not when the board has been briefed. Organisations that wait for certainty before notifying consistently miss the CERT-In window.
2. Hour 0–1: The Actions That Determine Everything Else
What your organisation does in the first hour of a breach creates the evidentiary and regulatory record against which every subsequent decision will be judged. These are not optional steps — they are the foundation of your legal defence and your regulatory response.
Engage Legal Counsel Immediately
Call your attorney before you call your IT vendor. This establishes attorney-client privilege over the investigation from the first moment — protecting forensic findings, internal communications, and gap assessments from regulatory compulsion. Any communication made before privilege is established is potentially discoverable.
- SIRI Law LLP emergency line: +91 7981912046 — 24/7
- Privilege attaches from the moment of engagement, not from the moment a formal retainer agreement is signed
Issue Legal Hold Notices
Immediately issue legal hold notices to all custodians of potentially relevant evidence — IT team, operations, HR, and any employees with access to affected systems. A legal hold requires the preservation of all documents, communications, and data relevant to the incident. Failure to preserve evidence is spoliation — which creates independent legal liability.
- Legal hold notices should come from legal counsel, not IT
- Scope: all emails, logs, configurations, access records, and communications related to affected systems from 30 days before the incident
- Include cloud storage, personal devices used for work, and messaging platforms
Do Not Restore or Wipe Affected Systems
Under no circumstances should affected systems be restored, wiped, reimaged, or taken offline before forensic imaging is complete. Every minute a system runs after detection overwrites volatile evidence — memory, active processes, open network connections — that cannot be recovered. Document who made what decisions about system status in the first hour.
Activate Forensic Imaging
Begin forensic imaging of affected systems while they are still in their compromised state. Images must be taken using forensically sound tools and methods that preserve chain of custody — because they may be used as evidence in criminal complaints, civil litigation, or regulatory proceedings.
- Memory (RAM) capture before shutdown — volatile data is lost on reboot
- Disk imaging of all affected servers and endpoints
- Network traffic capture if incident is ongoing
- Log collection: application, system, security, firewall, DNS
3. Hours 1–6: CERT-In Notification
The CERT-In notification must be filed within 6 hours of the incident becoming known. It does not need to be complete — it must be timely. CERT-In accepts preliminary notifications with partial information, provided a follow-up report is submitted as more information becomes available.
What the CERT-In notification must contain:
- Organisation details: Name, address, sector, contact name, email, and phone
- Incident details: Type of incident (from CERT-In’s 21 prescribed categories), date and time of detection, systems affected
- Initial scope assessment: Estimated number of users affected, nature of data involved (even if approximate)
- Immediate actions taken: What containment and preservation steps have been initiated
- Attack vector (if known): How the incident occurred — mark as under investigation if not yet determined
ⓘ Who Files the CERT-In Notification
CERT-In notifications must be filed by the organisation, not by a third party on its behalf unless explicitly authorised. SIRI Law LLP attorneys are authorised to file CERT-In notifications on behalf of clients as part of the incident response engagement. This ensures the notification is legally accurate, appropriately scoped, and filed before the 6-hour deadline even when the technical investigation is still underway.
4. Hours 6–72: DPDPA Board Notification Assessment
Once CERT-In notification has been filed, the second assessment begins: does this incident constitute a personal data breach requiring notification to the Data Protection Board?
- Was personal data affected? Health data, financial data, identity data, contact data, biometric data — any data relating to an identifiable individual
- Is the breach likely to cause harm? Financial harm, reputational harm, discrimination, identity theft — the Board assesses actual and potential harm
- How many Data Principals are affected? Scale is a factor in the Board’s assessment of notification requirements and penalty
- Is the data encrypted and the key secure? Encrypted data where the encryption key is uncompromised may not require Board notification in all circumstances
This assessment must be made by legal counsel — not by the IT team alone — because it has legal consequences. The Board notification, once filed, becomes part of the regulatory record.
5. Communications: What to Say and What Not to Say
Communications during a breach — internal memos, board briefings, customer notifications, media statements, and regulatory correspondence — create the evidentiary record that defines your organisation’s legal position. Every communication made before legal review is a risk. Every communication made after legal review is a managed disclosure.
⚠ What You Should Never Say Without Legal Review
Do not characterise the incident as a “minor issue” or “contained” before forensic scope is confirmed. Do not estimate numbers of affected users before legal review of the figure. Do not admit fault or liability in any external communication. Do not make forward-looking statements about security posture. Each of these creates unnecessary legal exposure in subsequent regulatory or civil proceedings.
6. The Post-Incident Obligations
Regulatory obligations do not end with the notification filing. The weeks and months following a breach create additional requirements that, if neglected, compound the original exposure.
- CERT-In follow-up report: A detailed incident report — including root cause, full scope, remediation taken, and lessons learned — is required within 30 days of the initial notification
- Board proceedings: If the Board initiates an inquiry, legal representation and document production requirements begin
- Insurance notification: Cyber insurance policies have notification requirements that are often shorter than regulatory deadlines — check your policy terms on day one
- Contractual obligations: Enterprise contracts, data processing agreements, and partner agreements typically impose breach notification obligations with independent timelines
- Remediation documentation: Document every security improvement made post-breach — this evidence reduces penalty exposure in any Board proceeding
7. The Breach Response Checklist at a Glance
| Timeframe | Action | Owner |
|---|---|---|
| Immediate | Engage legal counsel — establish privilege | CEO / General Counsel |
| Hour 0–1 | Issue legal hold notices to all custodians | Legal counsel |
| Hour 0–1 | Preserve affected systems — no restoration | IT / CISO |
| Hour 0–1 | Activate forensic imaging | Forensics team / SIRI Security |
| Hour 1–6 | File CERT-In notification | Legal counsel (SIRI) |
| Hour 1–6 | Brief board with attorney-reviewed communication | CEO + Legal |
| Hour 6–72 | DPDPA Board notification assessment and filing | Legal counsel |
| Hour 6–72 | Threat actor analysis — attack vector confirmation | Forensics / SIRI Security |
| Day 3–7 | Customer and partner notification (where required) | Legal + Communications |
| Day 7–30 | Insurance notification | Finance + Legal |
| Day 30 | CERT-In detailed follow-up report | Legal counsel |
| Post-incident | Remediation documentation for Board proceeding | Legal + IT |
Prepare Your Breach Response Architecture Before You Need It.
SIRI Law LLP activates legal hold, forensics, CERT-In notification, and DPDPA assessment in parallel — from a single 24/7 call. Get the infrastructure in place now.