What to do after a ransomware attack or data breach in India

1. The first hour: contain without destroying

The instinct on discovering ransomware is to pull the plug on everything. Resist the extreme version of that instinct. Isolating affected machines from the network, disabling compromised accounts, revoking sessions and tokens, blocking known malicious infrastructure and taking backups offline are all correct and urgent. Powering systems down, reimaging quickly to restore service, or deleting artefacts destroys volatile memory and logs that forensics, regulators, insurers and any later litigation all depend on.

Activate the response team immediately and make the decision structure explicit: a single incident commander, a technical lead, a legal lead, a communications lead and a named executive with authority to approve spending and external statements. Incidents go badly when three people are each talking to a different vendor and no one is recording what was decided. Start a contemporaneous log from minute one, recording times, observations, decisions and who made them.

Engage external counsel and a forensic provider in the first hour, ideally from a pre-agreed retainer. Counsel's early role is not paperwork: it is to structure the investigation so that findings are protected as far as possible, to identify which reporting clocks have started, and to keep the technical team from making statements or changes that foreclose options later. Notify the insurer early too, because many cyber policies condition cover on prompt notification and on using approved vendors.

Contain, preserve, then remediate. Teams that reverse the middle two steps lose the evidence they need for every conversation that follows.

2. Evidence preservation, forensics and privilege

Preservation means forensic images of affected systems, capture of volatile memory before shutdown where feasible, collection and off-system copies of relevant logs including authentication, endpoint, firewall, VPN, email and cloud audit logs, and a hold on routine log rotation and mailbox deletion policies. CERT-In's directions already require retention of ICT system logs for a rolling one hundred and eighty days within India, and companies that have not implemented that requirement discover the gap precisely when the logs would have answered the scope question.

The forensic mandate should be scoped deliberately: how the attacker entered, when, what they accessed, whether data was exfiltrated as distinct from encrypted, whether persistence remains, and what the indicators of compromise are. Exfiltration is the question that drives most legal consequences, because it converts an availability incident into a personal data breach with notification duties. Absence of evidence of exfiltration is not evidence of absence, and the report should say which it is.

On privilege, structure beats labelling. Retain the forensic provider through counsel with a scope tied to the provision of legal advice and anticipated proceedings, restrict distribution of investigative outputs to a defined group, keep operational remediation communications separate from advice, and avoid speculation about cause or fault in wide internal channels, which are discoverable and frequently surface later in exactly the wrong context. Indian privilege doctrine is narrower than many executives assume, so plan for the possibility that documents will be seen.

3. CERT-In: the six-hour clock

CERT-In's directions require entities including body corporates, service providers, intermediaries and data centres to report specified cyber incidents within six hours of noticing them or being brought to notice of them. The listed incident types are broad and include ransomware attacks, unauthorised access to IT systems and data, data breaches and data leaks, attacks on critical infrastructure, and malicious code attacks. Reporting is by the prescribed channels and format, and the initial report is expected on the facts known at the time.

The practical difficulty is that six hours is short relative to how long scoping takes, and teams delay filing while they establish what happened. That is the wrong trade. File on what is known, state clearly what is not yet established, and supplement as the investigation develops. A prompt initial report with honest gaps is a materially better regulatory posture than a complete report filed two days late.

The directions also carry standing obligations that matter during an incident: synchronisation of system clocks to designated time sources, retention of ICT system logs for a rolling one hundred and eighty days within Indian jurisdiction, production of those logs and information when directed, and designation of a point of contact for CERT-In communications. Confirm the point of contact and the filing route now, in calm conditions, because looking it up during hour four of an incident is a preventable delay.

4. DPDP Act breach intimation

Where personal data is involved, the Digital Personal Data Protection Act, 2023 requires the data fiduciary to give intimation of the breach to the Data Protection Board and to each affected data principal, in the form and manner prescribed. This is a separate obligation from CERT-In reporting, with a different audience and different content, and it applies to the fiduciary even where the incident occurred at a processor. Contracts with processors should therefore require notification to the fiduciary fast enough for the fiduciary to meet its own duty.

The gating question is scope: which data sets were affected, which categories of personal data they contained, and which individuals those records relate to. This is answerable in hours only if a current data inventory exists. Without one, the organisation faces a choice between over-notifying, which has reputational and operational cost and can still be inaccurate, and delaying, which is worse. The inventory is not a compliance artefact; it is the operational prerequisite for breach response.

Notification content should be accurate, specific and plain: what happened and when, what categories of data were involved, what the organisation has done and is doing, what the individual can do to protect themselves, and how to get answers. Avoid minimising language that a later forensic finding will contradict, and avoid definitive statements about exfiltration in either direction until the evidence supports them. Every notification should be reviewed by counsel before it goes out, because it will be read by regulators, customers, claimants and journalists.

5. Sector regulators, customer contracts and insurers

Regulated entities carry additional incident reporting duties to their sector regulator, often with tight timelines and prescribed formats, and those obligations frequently attach to a broader set of events than the CERT-In list. Financial services, insurance, securities market intermediaries, payment system participants and telecom licensees should map their specific obligations into the response plan rather than researching them mid-incident.

Customer contracts are the obligation set most often missed. Enterprise agreements routinely require notification of a security incident within twenty-four or forty-eight hours, sometimes shorter, with defined content, cooperation rights, audit rights and occasionally step-in or termination rights. During an incident, someone must own the task of extracting these obligations from the contract stack and tracking them, because a breach of a notification clause becomes a commercial dispute layered on top of the technical event.

Insurers should be notified promptly and in accordance with the policy. Most cyber policies require prior consent for the appointment of forensic providers, counsel, negotiators and public relations advisers, and for any ransom-related expenditure. Using your own vendors first and seeking approval later is a common and expensive mistake. Keep costs categorised from day one, because claim documentation is far harder to reconstruct afterwards.

6. The ransom decision

No Indian statute expressly prohibits paying a ransom, but that is not the same as the payment being straightforward. Sanctions regimes can make a payment to a designated person or entity unlawful, which requires attribution work and screening before any transfer. Exchange-control and anti-money-laundering considerations affect how a payment could lawfully be structured. And payment does not extinguish any reporting obligation, does not reliably produce a working decryptor, and does not guarantee that exfiltrated data is deleted rather than resold.

Where payment is genuinely under consideration, usually because backups are unusable and the operational impact is severe, treat it as a board-level decision with documented inputs: the technical assessment of restoration alternatives and timelines, forensic attribution and sanctions screening, legal advice on the exposure, insurer position and cover, the negotiator's assessment, and the business impact analysis. The record of how the decision was made matters as much as the decision itself, for regulators, insurers and shareholders.

Whatever is decided, do not let the negotiation displace the response. Reporting clocks continue, notification duties continue, forensic investigation continues, and recovery planning continues. Organisations that pause everything for a negotiation lose days on obligations that were never suspended.

7. Communicating without creating liability

Establish one approved narrative and one channel for it. Early statements are quoted back for years, and the gap between an initial reassurance and a later forensic finding is where credibility and legal exposure are both lost. Say what is known, say what is being done, say when the next update will come, and avoid characterising cause, blame or scope before the evidence supports it.

Internal communication needs the same discipline for a different reason. Employee messages, chat channels and vendor emails are discoverable and are frequently written in the heat of the moment by people who do not have the full picture. Brief staff on what they may and may not say externally, route customer questions to a prepared response, and keep speculation out of writing.

Sequence matters. Regulators and affected individuals should not learn of a breach from the press. Prepare regulator filings, individual notifications, customer briefings, employee messaging and any public statement together, with counsel review, and release them in a planned order. Where a threat actor is publishing data or contacting customers directly, that timeline compresses, which is another reason for templates to exist in advance.

8. Recovery, root cause and remediation

Recovery should be deliberate rather than fast. Restore from backups verified clean into a hardened environment, with the entry vector closed and the identity estate reset, including privileged credentials, service accounts, API keys and any certificates the attacker could have accessed. Rebuilding into the same configuration that was compromised, using credentials the attacker may still hold, is how organisations experience a second incident within weeks.

Root cause is a legal deliverable as much as a technical one. Regulators, insurers, customers and sometimes courts will ask what allowed the incident and what changed afterwards. The root-cause report should identify the initial access vector, the controls that failed and why, the detection gap, and a dated remediation plan with owners. Where dwell time was long, be specific about what was accessible during that period, because that is the question that determines notification scope and litigation exposure.

Close out with the full workstream, not just the technical one: regulator follow-up correspondence, completion of individual notifications and handling of the questions they generate, contractual reporting to customers, the insurance claim, employee and vendor remediation, and an updated incident response plan reflecting what actually failed during the event. Then run the tabletop again in ninety days against the revised plan.

9. What to build before it happens

Four investments change the outcome more than any others. First, an incident response plan naming the decision-makers, with external counsel, forensics and a negotiator on retainer, and the CERT-In point of contact and filing route recorded. Second, segregated offline backups with documented restoration tests carried out at least annually against systems that matter. Third, log retention configured to the one-hundred-and-eighty-day requirement within India, with clocks synchronised as the directions require. Fourth, a current data inventory that answers the scope question in hours.

Add to those the controls that reduce likelihood and dwell time: phishing-resistant multi-factor authentication across the identity estate, least-privilege access with periodic review, network segmentation that limits lateral movement, endpoint detection with monitored response, patch discipline on internet-facing systems, and vendor security assessment for anyone with access to your environment.

Then rehearse. An annual tabletop that runs the six-hour CERT-In clock, the DPDP intimation obligation, a customer contractual notice and a ransom decision, with the actual executives who would make those calls, exposes the gaps that documentation hides. The value is not the plan on the shelf; it is the muscle memory of the people who will be awake at three in the morning.

Frequently asked questions