A ransomware incident does not give you time to plan. The first hour sets the trajectory of the next ninety days. Organizations that respond badly in hour one end up negotiating with threat actors from a position of desperation; organizations that respond well contain the blast radius, preserve forensic evidence, and restore operations without paying. The difference is rarely technical sophistication. It is the presence of a runbook, executed by people who have rehearsed it.
This is the enterprise ransomware runbook we provide to clients. It is intentionally prescriptive. You will adapt it to your environment and regulatory obligations (DPDP Act, CERT-In directions, sector regulators), but the structure holds. If you are reading this during an active incident, skip to the containment section; come back to the preparation section after the fire is out.
Preparation: what must be true before an incident
Everything below assumes you have already done the preparation. If you have not, schedule it for next quarter.
- Named incident commander with authority to declare an incident, pause business operations, and authorize spend.
- 24×7 contact list including executive sponsor, legal counsel, external IR firm, cyber insurance broker, CERT-In point of contact.
- Out-of-band communication channel (Signal group, phone tree) for when the corporate network is compromised.
- Immutable, offline backups with tested restore procedures. A backup that can be encrypted by the ransomware is not a backup.
- EDR deployed on all endpoints and servers with centralized console and 30+ days of retention.
- Network segmentation between user workstations, production, backups, identity provider, and crown-jewel data stores.
- Tabletop exercise conducted in the past 12 months with executive participation.
Hour 0 to 1: Detection and declaration
Detection typically arrives from one of: EDR alert, user report of files they cannot open, ransom note on a monitor, SaaS outage, or backup job failures. The first responder:
- Preserve the evidence. Photograph the ransom note. Do not reboot the machine. Do not wipe. Do not pay yet.
- Escalate to the named incident commander within 15 minutes of detection.
- Incident commander declares an incident and opens the incident bridge on the out-of-band channel.
- Pull in: CISO or security lead, IT lead, legal counsel, communications lead, external IR firm.
- Start the incident log. Every decision and action, with timestamps.
The single most valuable artifact in a ransomware incident is the timestamped decision log. Courts, regulators, insurers, and the internal post-incident review will all depend on it.
Hour 1 to 4: Scoping and containment
The objective is to understand the blast radius and stop the spread. In parallel, not sequentially.
Scoping actions
- Identify patient zero and initial access vector. Common: phishing, exposed RDP, unpatched perimeter appliance, stolen credentials.
- Identify encryption status of file shares, databases, cloud storage, SaaS.
- Check domain controllers, backup systems, and hypervisors for indicators of compromise.
- Review EDR telemetry for lateral movement, credential theft, and persistence mechanisms.
Containment actions
- Isolate confirmed-compromised hosts at the network level. Preserve for forensics.
- Disable compromised accounts and service accounts.
- Rotate privileged credentials if credential theft is suspected.
- Block known command-and-control infrastructure at the egress firewall.
- Pause scheduled backup jobs to prevent overwriting clean backups with encrypted data.
- Consider disconnecting backup systems from the network until scope is confirmed.
Do not
- Reboot encrypted machines. You may lose forensic artifacts in memory.
- Run antivirus scans on encrypted machines. You may destroy evidence.
- Communicate with the threat actor yet. Wait for legal counsel and insurance.
- Post public statements. Wait for the communications workstream.
Hour 4 to 24: Investigation and stakeholder notification
Investigation
An external IR firm usually leads forensics. Internal focus is on:
- Confirming the ransomware family. This informs known decryption options, TTPs, and likelihood of data exfiltration.
- Determining whether data was exfiltrated before encryption. Most modern ransomware is double-extortion; assume exfiltration until proven otherwise.
- Identifying the initial access vector so you can close it before recovery.
- Mapping affected systems and data categories for notification obligations.
Regulatory notifications (India)
- CERT-In: Reportable incidents must be notified within 6 hours of noticing, per the 28 April 2022 directions. Ransomware falls squarely within the mandatory reporting categories.
- DPDP Act: If personal data of data principals is affected, notification to the Data Protection Board and affected principals is required. The DPDP Act references a 72-hour window; prepare the notification in parallel with investigation.
- Sector regulators: RBI-regulated entities have incident reporting obligations under the Master Direction on IT Governance. SEBI-regulated entities have obligations under the Cybersecurity and Cyber Resilience Framework. Identify your regulators and their timelines during preparation, not during the incident.
Stakeholder notifications
- Board and executive team briefed with incident status and decisions pending.
- Cyber insurance carrier notified if policy is in force. Many policies require notification within a set window.
- Legal counsel engaged for privilege and regulatory guidance.
- Customers notified when you have confirmed facts; avoid speculation.
Day 1 to 7: Eradication and recovery
Eradication
Before restoring, remove the threat actor’s access:
- Rotate all privileged credentials, including domain admin, service accounts, cloud root credentials, and long-lived tokens.
- Invalidate all Kerberos TGTs (KRBTGT reset, double-reset).
- Rebuild or reimage compromised hosts; do not trust in-place cleanup of a ransomware-infected host.
- Close the initial access vector (patch the appliance, fix the misconfiguration, reset the phished account).
- Deploy additional detection rules in EDR and SIEM tied to the observed TTPs.
Recovery
- Restore from clean, verified backups. Verify integrity before reconnecting.
- Bring systems online in tiers: identity first, then crown-jewel data, then production applications, then user workstations.
- Monitor restored systems intensively for signs of threat actor residuals.
- Track restoration status against a business prioritization list so you know what is back and what is not.
The pay-or-do-not-pay decision
This is a legal, financial, and ethical decision made by executive leadership in consultation with legal counsel and insurance. Key considerations:
- Are the backups viable and recent enough? If recovery is possible from backups, payment is rarely justified.
- Is data exfiltrated? Paying the ransom does not guarantee the data will not be leaked.
- Is the threat actor under sanctions? Payment may violate sanctions regimes.
- What is the business impact of extended downtime? Weigh against the ransom and the reputational cost of payment.
Paying the ransom should be the last option, not the fastest. It funds the next attack, does not guarantee recovery, and does not guarantee data will not leak.
Day 7 to 30: Post-incident review and hardening
- Formal post-incident review with all responders. Timeline, what worked, what did not, what to change.
- Root cause analysis published internally.
- Remediation backlog with owners and target dates. Track to closure.
- Revised runbook incorporating lessons learned.
- Updated tabletop exercise plan for the next cycle.
- Customer and regulator follow-up communications as needed.
Ransomware runbook at a glance
| Phase | Window | Primary objective |
|---|---|---|
| Detection and declaration | Hour 0 to 1 | Declare incident, preserve evidence, open bridge |
| Scoping and containment | Hour 1 to 4 | Understand blast radius, stop spread |
| Investigation and notification | Hour 4 to 24 | Identify TTPs, notify regulators and insurer |
| Eradication and recovery | Day 1 to 7 | Remove threat actor, restore operations |
| Review and hardening | Day 7 to 30 | Root cause, remediation, runbook update |
Related reading
- IR runbook β credential compromise & session hijack
- IR runbook β data exfiltration under DPDP
- DPDP breach notification β 72-hour playbook
- Hardening a new AWS account β two-hour runbook
- VAPT services in India β buyer’s guide
Work with RingSafe
RingSafe builds ransomware runbooks tailored to Indian enterprise environments, runs tabletop exercises that mirror real double-extortion scenarios, and provides retainer-based incident response so the phone rings at the right number at 2 AM. Founder Manish Garg (Associate CISSP, CEH, CCNP Enterprise) leads engagements with regulated Indian enterprises across BFSI, health-tech, and manufacturing.
If your runbook is a PDF nobody has opened in eighteen months, book a scoping call and we will stress-test your readiness before a threat actor does.