Browse the site
Services
Who We Serve
Problems We Solve
Across India
Guides & Resources
Questions
Blog
Profiles
Company
Call Get a quote

What Is a Ransomware Incident Playbook?

A ransomware incident playbook is the written, tested procedure that runs from the first ransom note to a verified clean restoration. It fixes four things in advance: where the kill switch is, which systems are isolated in which order, which backups are trusted and how they are restored, and who has the authority to pay, declare or refuse. It matters because during an encryption event the expensive mistakes are decisions, not technical steps: powering down a machine that holds the key, restoring into a network the attacker still controls, or paying a ransom that buys a promise rather than a fix.

Key takeaways

  • The kill switch decision, whether to isolate the affected segment or pull the plug on everything, is written down in advance because it cannot be debated mid-encryption.
  • Segmentation matters more than any single control: an infected workstation must not be able to reach the backup console or the identity provider.
  • Offline or immutable backups are the only backups that survive a competent ransomware operation, and a restore test is what proves it.
  • Encryption keys and key management systems are targets, and an organisation that has never tested a bare-metal restore discovers that on the worst possible day.
  • Restoration order should be written down, starting with identity and DNS, then core systems, then the rest, so the business comes back in a coherent state.

As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.

What should a ransomware incident playbook contain?

Six parts. The trigger, which is what defines an incident, for example a ransom note, mass file renaming, or a spike in file change and delete activity on a file server. The isolation procedure, with the exact steps for a workstation, a server, a network segment and a cloud tenancy, and the order to do them in. The kill switch decision, a written choice between isolating the affected segment and shutting everything down. The restoration plan, naming the trusted backup, the restore order and the clean-build steps. The external notification map, covering the bank, the 1930 helpline, CERT-In, cyber insurance, customers and the police. And the decision rights, including who may authorise paying a ransom.

Should we isolate the network or shut everything down?

Neither, by default, because both are bad in the general case. Shutting everything down loses volatile evidence, often the only way to find the initial access vector, and it turns a contained incident into a total outage. Isolating only the affected segment assumes the attacker has not already moved laterally, which is optimistic in a ransomware operation that started weeks earlier. The defensible middle is: isolate the affected segment, pull the affected file server off the network but leave it running, block the east-west paths at the firewall, and revoke sessions and rotate keys across identity and cloud platforms. If encryption is still spreading after an hour, escalate to a full shutdown.

Why are offline or immutable backups the only ones that matter?

Because the modern ransomware operation looks for backups first. It uses the same stolen credentials to reach the backup console, deletes volume snapshots and retention policies, and encrypts the backup store itself. A backup on the same network, under the same identity, with the same credentials is a copy of the data, not a safety net. Offline, immutable or air-gapped copies survive because the attacker cannot reach them with the tools it already has. Two rules follow. A backup is not a backup until a restore has been tested end to end. And backup administration credentials should be a separate identity, so a compromised domain admin does not open the vault.

Should we pay the ransom if the business is stopped?

It is a business decision, not a technical one, and it must be made by named people in advance rather than by whoever is in the room. Paying does not guarantee a working decryptor, does not remove the risk of a repeat visit, and in India it may expose the payer to money laundering concerns. Payment is a rational last resort when the alternative is permanent loss of the business and no verified clean backup exists, and even then only after law enforcement advice. The better use of that meeting is to confirm what the extortionist holds, whether exfiltration has happened, and what the regulator and insurer need.

The ransomware playbook stages, what happens in each, and the decision that must be pre-authorised
StageActionDecision to pre-authorise
DetectionConfirm the ransom note, stop mass file changes, start the clockWhat counts as a confirmed ransomware event
IsolationSegment off, block east-west paths, revoke sessions, rotate keysIsolate the segment or shut everything down
InvestigationPreserve logs, identify the access vector and the exfiltrationWhen to involve external forensics
RecoveryClean rebuild, restore from immutable or offline backup, verifyWhich backup is trusted and who signs off
NotificationCERT-In, insurer, police, 1930, affected customersWho speaks to each audience
HardeningClose the access vector, verify segmentation, retest restoreBudget owner and timeline

What are the frequently asked questions?

What is a ransomware incident playbook?
A ransomware incident playbook is the written, tested procedure that runs from the first ransom note to a verified clean restoration. It fixes four things in advance: where the kill switch is, which systems are isolated in which order, which backups are trusted and how they are restored, and who has the authority to pay, declare or refuse. It matters because during an encryption event the expensive mistakes are decisions, not technical steps: powering down a machine that holds the key, restoring into a network the attacker still controls, or paying a ransom that buys a promise rather than a fix.
Is a ransomware playbook different from an incident response plan?
It is the ransomware-specific runbook inside the plan. The plan says who decides and what the obligations are; the playbook says the exact steps for an encryption event, in order, with the specific systems and commands.
How often should a ransomware playbook be tested?
At least annually, and always after a change to the backup architecture, the identity platform or the network segmentation. The test that matters most is a restore, not a tabletop, because restore is where most playbooks quietly fail.
Should we involve law enforcement before paying a ransom?
Yes. The 1930 helpline and the local cyber cell can advise on the payment and can help trace the funds, and a case number strengthens the insurer's claim. A private negotiation done without a case is far harder to defend later.
Do we have to notify the police if the attacker stole data as well as encrypted it?
Yes. Exfiltration in addition to encryption is a data breach, and it triggers the CERT-In reporting duty and, where personal data is involved, the notification requirements of the DPDP Act 2023. Report it on cybercrime.gov.in and to CERT-In within six hours of noticing.

Get a straight answer on this

Send us your segmentation diagram and your last restore test date, and we will mark the gaps in your ransomware playbook for free.

Send us the details See pricing

Related

Last reviewed: 24 October 2026. Information on this page is general guidance, not legal advice. Prices are indicative bands for a typical scope and are confirmed in a written quote before any work begins.