Ransomware is the incident type where the generic plan runs out fastest. The encryption is only the visible part: the attackers have usually been inside for days, have taken copies of data to threaten publication, and have often gone after the backups first. Restoring too early brings them back. Paying without checking sanctions lists can create a second legal problem. This free ransomware response checklist is the playbook for that one scenario. It runs as a sub-playbook of the Cybersecurity Incident Response Checklist, from the first encrypted file to a signed-off recovery: isolation that keeps evidence, a backup check before anyone restores, the extortion decision with legal and sanctions screening, rebuilding identity, restoring in business order, and the reports that follow.
A general incident response plan sets out roles, severity levels and the broad flow from detection to recovery and lessons learned, which is how NIST SP 800-61 Rev. 3 frames it through the CSF 2.0 Detect, Respond and Recover functions. Ransomware adds decisions a general plan does not spell out. Can we trust our backups? Is the identity system itself compromised? Has data left the building? Will we engage with the attacker at all, and who decides? If those questions are first asked on the day, they are answered by whoever is loudest on the call.
Modern ransomware is usually double extortion. The attacker encrypts systems to stop the business and steals data to threaten a leak if the ransom is not paid. That means a successful restore from backup does not end the incident. You may still have a personal data breach to assess and report, and a leak site to watch. CISA’s #StopRansomware Guide and the UK NCSC’s ransomware guidance both treat ransomware as a data breach risk as well as an availability problem, and this checklist does the same.
Owner: the security lead or incident manager.
Scope: triage, containment, investigation, recovery and lessons learned for any security incident.
Decisions it leaves open: backup trust, identity rebuild, ransom engagement and leak monitoring.
Owner: the same incident lead, with named roles for legal, finance and the executive sponsor.
Scope: encryption and extortion, from isolation to restoring in tiers and reporting the payment decision.
Decisions it makes in advance: who may authorise contact with the attacker, which backups are trusted and which systems come back first.
Keep both. Open the general incident record first, so the timeline, severity and notification triggers live in one place, then start this playbook from it when ransomware is confirmed. If data theft is confirmed, the Data Breach Response Checklist takes over the notification workstream.
Seven phases take a ransomware attack from the first alert to a signed-off recovery. The extortion phase appears only when a ransom demand has been received.
Owned by the incident lead. The answers in this phase decide which later phases appear.
Isolation tasks are assigned to the IT recovery lead; evidence tasks to the forensic lead.
The restore decision in task 6 needs approval from the IT recovery lead and the system owner.
Appears only when Phase 1 records a ransom demand. Every task is assigned to legal counsel or the executive sponsor, not to IT.
Each restore tier needs sign-off from the system owner before the next tier starts.
Notification tasks switch on when Phase 1 records data theft as claimed, suspected or not yet known.
Every ransomware incident is different, but the order of the first decisions rarely is. The timeline below shows where each phase usually sits. Treat the timings as a guide for planning a tabletop exercise, not a target you will always meet.
Ransomware is confirmed, affected hosts are isolated rather than switched off, the named team is called on an out-of-band channel and the insurer is told.
Compromised accounts are disabled, remote access is cut, backups are protected, and logs and a sample of encrypted files are preserved.
The variant, entry point and affected systems are known. Backups are checked. If there is a ransom demand, legal and sanctions screening run before any decision on contact.
Identity is rebuilt, the way in is closed, and systems come back tier by tier with sign-off at each step.
If personal data may have been taken, the GDPR and UK GDPR clock for notifying the regulator is running. Other sector deadlines can be shorter.
Reporting duties depend on your sector and location, so confirm them with counsel. In the US, the Treasury’s Office of Foreign Assets Control warned in its September 2021 advisory that ransom payments to sanctioned persons can breach sanctions law, and that prompt reporting to law enforcement and cooperation count as mitigating factors. The Cyber Incident Reporting for Critical Infrastructure Act of 2022 will require covered entities to report ransom payments to CISA within 24 hours of paying and covered incidents within 72 hours, but those duties start only once CISA’s final rule takes effect, which had not happened as of October 2026. SEC registrants must disclose a material incident on Form 8-K within four business days of determining that it is material. HHS treats ransomware on systems holding electronic protected health information as a presumed HIPAA breach unless a low probability of compromise can be shown.
In the UK, the government confirmed in July 2025 that it will ban ransom payments by public sector bodies and regulated critical national infrastructure, require other organisations to notify the government before paying, and introduce mandatory reporting of ransomware attacks. The legislation had not been passed as of October 2026, so check the current position before relying on it. The ICO and NCSC have both said that paying a ransom does not protect the data or reduce regulatory penalties. In the EU, entities covered by NIS2 must send an early warning of a significant incident within 24 hours. Phase 7’s reporting tasks can be edited as these rules change.
The extortion phase only appears when a demand exists, and every task in it is assigned to counsel or the executive sponsor by name. Nobody in IT can be pushed into opening a chat with the attacker, and the decision is recorded with its reasons whichever way it goes.
Approvals between restore tiers mean identity and security tools come back before the finance system, and each system owner signs off their service. The checklist shows exactly which tier is in progress when the board asks.
Every action carries a name and a time. Ransom notes, log exports, backup checks and legal advice are attached to the task they support, which is the evidence an insurer, regulator or lawyer will ask for.
CheckFlow is not a backup, EDR or decryption tool. It runs the human side of the response around those tools: who decides, who restores what, and what was reported. Recovery depends on backups you have already proven, which is what the Backup Verification & Restore Test Checklist is for, and the disaster recovery checklist guide explains how to plan the restore order before you need it.
Rehearse this playbook before it is real. Run it as the scenario in the Incident Response Tabletop Exercise Checklist at least once a year, and use the Cyber Insurance Readiness Checklist to confirm the controls your insurer expects, such as MFA, EDR and offline backups, are actually in place.
It should cover confirming the attack and mobilising a named team, isolating systems without destroying evidence, checking that backups are intact before restoring, a separate decision process for any ransom demand, rebuilding identity, restoring systems in business priority order, and the reports that follow. The two parts most plans leave out are the backup check and the extortion decision, and both cause the most expensive mistakes when they are improvised.
Law enforcement agencies, including the FBI and the UK NCSC, advise against paying. Payment does not guarantee a working decryptor, does not stop the attacker publishing stolen data, and can mark you as a willing payer. It can also be unlawful if the attacker is on a sanctions list. If an organisation does consider paying, the decision belongs to its executives with legal advice, after sanctions screening and a report to law enforcement, and should be recorded with its reasons. This checklist does not make the decision for you; it makes sure the right people make it, in the right order.
Usually not. Disconnect them from the network instead, through your endpoint tool or by unplugging the network cable, and leave them powered on. CISA’s #StopRansomware Guide recommends powering down only devices that cannot be disconnected, because shutting a machine down loses the memory evidence that can show how the attacker got in and, occasionally, recover encryption keys.
Often, yes. Most ransomware groups now steal data before encrypting it, so you should assume data may have been taken until the investigation shows otherwise. Under GDPR and UK GDPR, losing access to personal data can itself count as a personal data breach, even without theft. In US healthcare, HHS presumes that ransomware on systems holding electronic protected health information is a reportable breach unless a risk assessment shows a low probability that the data was compromised.
Check three things before restoring: the restore point predates the attacker’s first activity, not just the encryption; the backup system itself was not accessed or altered; and the restored data is free of the attacker’s tools. Immutable or offline copies are far more likely to survive. The best answer is a restore test you ran before the attack, which is why this playbook pairs with a monthly backup verification routine.
It depends on your sector and location. Typical parties are your cyber insurer, law enforcement, the data protection regulator if personal data is involved, affected individuals if the risk to them is high, sector regulators, customers under contract, and, for SEC registrants, investors through a Form 8-K if the incident is material. Some countries are adding specific ransomware reporting duties, including payment reporting. Confirm the list with counsel during the incident and record every decision, including decisions not to notify.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
