The Incident Response Runbook We Use for Every Ransomware Case

The worst time to figure out your ransomware response process is during an actual ransomware incident. Decisions that should take minutes end up taking hours when nobody’s agreed in advance who calls what, who talks to whom, and in what order things happen.

This is the runbook we actually use — not a theoretical framework, but the step-by-step sequence we follow from the moment ransomware is suspected to the moment the organization is back to normal operations. Adapt it to your environment, but don’t skip the structure.

Phase 1: Detection and Initial Triage (First 15 Minutes)

Goal: confirm this is real, scope the blast radius fast, and stop the bleeding.

1. Confirm the alert is genuine ransomware activity, not a false positive from a legitimate bulk file operation (backup job, migration, antivirus scan). Check for the telltale signs: mass file renames/extension changes, ransom note files appearing in multiple directories, and a spike in failed file-write operations as encryption churns through permission-protected files.
2. Identify patient zero — the first host or account showing encryption activity — using your EDR’s timeline view.
3. Isolate affected hosts immediately, network-level if possible (not just killing the process), since many ransomware strains continue encrypting or spreading even after the initial detection.
4. Declare the incident formally and activate your incident response team, even if scope is still unclear. It’s far easier to stand down a declared incident than to escalate one that was quietly “being looked into” for an hour.

Phase 2: Containment (First Hour)

Goal: stop lateral spread before worrying about root cause.

5. Isolate, don’t power off, affected systems where possible — powering off can destroy volatile memory evidence needed later for root-cause analysis and potential law enforcement involvement.
6. Disable or suspend compromised accounts, particularly any with domain admin or broad file-share access, since ransomware operators frequently use a compromised privileged account to spread.
7. Segment or isolate backup infrastructure immediately. Ransomware operators increasingly target backups specifically before triggering encryption — confirm your backup systems haven’t already been tampered with before you need them.
8. Block identified command-and-control infrastructure at the firewall/DNS level based on whatever indicators your EDR or threat intel has already surfaced.
9. Preserve evidence — memory captures, relevant logs, and the ransom note itself — before any remediation actions that could overwrite it.

Phase 3: Investigation and Scoping (Hours 1-24)

Goal: understand how they got in, how far they spread, and what they touched.

10. Reconstruct the attack timeline from initial access through to encryption, using EDR process trees, authentication logs, and network traffic — this is where your MITRE ATT&CK mapping earns its keep, since you’re tracing a chain of techniques, not a single event.
11. Identify the initial access vector (phishing, exposed RDP, exploited vulnerability, compromised credentials) so it can be closed before restoration, not after.
12. Determine what data was accessed or exfiltrated, not just encrypted — modern ransomware groups frequently steal data before encrypting, specifically to add extortion leverage even if you can restore from backup.
13. Scope every system the attacker touched, not just the ones that show encryption, since dwell time before the encryption trigger is often days to weeks.
14. Identify the ransomware family/variant where possible — this affects decryption options, known behavior patterns, and whether the group has a track record of honoring or not honoring payment.

Phase 4: Eradication and Recovery (Day 1-7, Varies by Scope)

Goal: remove the attacker’s access completely and restore operations safely.

15. Rebuild compromised systems from known-clean images rather than attempting to “clean” an infected host — ransomware incidents are not the place to cut corners on this.
16. Reset credentials for every account in scope, and rotate any shared secrets, API keys, or service account credentials the attacker could have accessed.
17. Verify backup integrity before restoring — restoring from a backup that was already compromised or that captures the attacker’s dwell-time activity re-introduces the problem.
18. Restore systems in priority order based on business criticality, not necessarily the order they were affected, coordinated with business stakeholders who understand operational dependencies.
19. Patch or remediate the confirmed initial access vector before bringing restored systems back onto the production network.
20. Monitor restored systems closely for a defined period (we use a minimum of 30 days) for any signs of residual or renewed attacker activity before considering the incident fully closed.

Phase 5: Post-Incident (Week 2+)

Goal: turn the incident into permanent improvement, not just a closed ticket.

21. Run a blameless post-incident review within two weeks while details are still fresh, focused on process and system gaps, not individual blame.
22. Update detection rules based on indicators and techniques observed, so the same attack chain triggers faster next time.
23. Close the gaps that enabled initial access and lateral movement — this is often where organizations under-invest once the immediate crisis has passed.
24. Update this runbook itself with anything that didn’t go as planned. A runbook that never changes after real incidents isn’t being used properly.
25. Brief leadership and, where required, complete regulatory or legal notification obligations — these timelines are often stricter and shorter than the technical recovery timeline, so this step should start in parallel with Phase 4, not after it.

The Decisions to Make Before You Ever Need This

A few things are much better decided in a calm planning session than mid-incident:

• Who has the authority to isolate production systems, and do they need anyone’s sign-off to do it immediately?
• What’s your actual position on paying a ransom? Even a “we will never pay” default should be a documented decision made in advance, not improvised under pressure.
• Who is your outside counsel and incident response retainer, and do you have their contact information somewhere that doesn’t depend on systems that might be encrypted?
• What’s your communication plan for employees, customers, and (if applicable) regulators — drafted in advance, not written from scratch during the incident?

Why the Order Matters

Notice containment comes before full investigation, and investigation comes before eradication. Teams under pressure often want to skip straight to “clean it up and move on,” but rebuilding a system before you understand the full attack chain means you’re likely to reintroduce the same vulnerability that got you here, sometimes within the same week.

A ransomware incident is a bad day no matter how well-prepared you are. The difference a runbook makes isn’t avoiding that — it’s making sure the bad day doesn’t turn into a bad month because of decisions made in a panic that a calmer version of your team had already figured out in advance.