Most Indian companies will face a data incident at some point — a misconfigured S3 bucket, a phished employee mailbox, a vendor compromise, an exposed API. The DPDP Act, the CERT-In Directions of April 2022, and the IT Act together create a reporting matrix that is genuinely demanding. The companies that handle it well are the ones who decided what to do before it happened.
This is the playbook we run with our clients. The first 72 hours decide the regulatory posture, the public posture and — often — the litigation posture.
Hour 0–6: contain, then report to CERT-In
Containment first — isolate the compromised system, rotate credentials, disable the abused API key, pull the affected workload off the network. Preserve volatile state before you reboot anything: memory captures, running process lists, current network connections, current user sessions. A reboot in panic destroys evidence that you will later need to prove what was and was not exposed.
Within six hours of becoming aware of a reportable cyber incident, CERT-In must be notified under the April 2022 Directions issued under Section 70B(6) of the IT Act. That window is hard. The format is on the CERT-In website; we keep a pre-filled template on file for every client we onboard.
Hour 6–24: scope the breach
You cannot notify Data Principals or the DPBI accurately until you know what was actually accessed. Forensics work — log review, IAM trail review (CloudTrail, Audit Log, equivalent), database query logs, egress traffic analysis — establishes scope. Engage external forensic counsel early if the scale is non-trivial. Internal-only investigations have a credibility problem with regulators.
- What categories of personal data were involved (contact, financial, health, children's, KYC documents)?
- How many Data Principals are affected, and can they be individually identified?
- Was the data exfiltrated, or merely accessed?
- Is the threat actor still in the environment? Have you actually evicted them?
- Which systems' logs are intact, and which were rotated or destroyed by the attacker?
Hour 24–72: notify the DPBI and Data Principals
Under Section 8(6) of the DPDP Act, the Data Fiduciary must, in the event of a personal data breach, notify both the Data Protection Board of India and each affected Data Principal — in the form and manner prescribed. The exact rules under the Act are still being finalised at the time of writing, but the practical standard regulators will look for is 'as soon as possible' once scope is established. We work to a 72-hour clock as a matter of discipline, modelled on the GDPR equivalent.
Notice to Data Principals must be specific. Vague 'we have noticed unusual activity' notices invite regulatory and reputational backlash. Tell them what was accessed, what risks it creates, what you have done, and what they should do — change passwords, watch for phishing referencing real account details, monitor bank statements.
Parallel: the criminal complaint
Where there is reason to believe an offence has been committed — unauthorised access (IT Act Section 43 read with 66), data theft (Section 66 read with Section 378 BNS, formerly 378 IPC), extortion (Section 308 BNS) where the attacker is demanding ransom — file an FIR with the local Cyber Crime cell. The FIR is also useful regulatorily; it demonstrates that the company treated the incident seriously.
Evidence preservation, legal-grade
Your forensic narrative will eventually be tested. SHA-256 hash every disk image and every log export at the time of capture. Maintain a chain-of-custody log. Keep a separate, write-protected copy. Where Section 65B of the original Evidence Act framework — now reflected in the Bharatiya Sakshya Adhiniyam (BSA), 2023 — applies to electronic records, the certificate accompanying the records must be issued by someone in lawful control of the relevant system. Get those certificates while memory is fresh, not two years later when the matter goes to trial.
Common traps
- Paying the ransom without legal sign-off. Sanctions exposure (OFAC and equivalent), tax issues and DPBI explanation problems are all real.
- Letting the engineering team do its own forensics with no preservation. Logs get rotated, systems get reimaged, evidence vanishes.
- Issuing a comms statement before scoping is complete. Walking back a claim later is much worse than not making it.
- Forgetting downstream processors. If your vendor was the entry point, they have their own DPDP obligations and your contracts allocate liability.
- Treating the legal team as an afterthought. Privilege is established at the moment counsel is engaged — communications and forensic work product organised under privilege from day one are protected; the same work, organised after the fact, often is not.
Board, insurance and disclosure obligations
If your company is listed, SEBI's LODR Regulation 30 read with the August 2023 amendment requires disclosure of material cybersecurity incidents to the stock exchanges. If you carry cyber insurance, almost every policy has a notification timeline (usually 72 hours) and a panel-counsel requirement — read it before you need it. Board-level update should go out within the first business day even if scope is incomplete; trickling information to directors is how trust between the board and the management team breaks down during an incident.
If you are in the early hours of an incident, message us on +91 63634 69138. We work alongside your CISO and your forensic provider to manage the regulatory clock and the legal exposure. The first 24 hours decide how this ends — and we move fast when speed is the point.
Discuss your matter with us.
Articles can only go so far. Every legal matter has its own facts. Reach out for a confidential consultation.