Ransomware Incident Response Playbook: The First 72 Hours
Ransomware response is not primarily a technical problem — it is a decision problem under extreme time pressure with incomplete information. The organizations that recover fastest are those that made the critical decisions before the incident: which systems are tier-0, what the backup integrity verification process is, who has authority to authorize network isolation, and what the regulatory notification obligations are.
This playbook is written for incident responders, security leads, and IT leaders who need a structured response sequence for ransomware. It covers the first 72-hour decision tree, containment tactics, Active Directory emergency response, backup integrity validation, eradication, and recovery sequencing. The ransom payment decision is addressed as a business and legal decision, not a moral one.
Hour 0 to 4: Identification and Blast Radius Assessment
The first priority after ransomware detonation is confirmed is understanding what you are dealing with — not immediate containment. Premature containment that isolates systems before you understand the attack vector risks alerting the threat actor to evict their access before you can identify it, and it destroys forensic evidence that determines your recovery timeline.
Identification tasks in the first four hours: confirm the ransomware family if possible (check the ransom note, file extension, and encrypted file header against known families via ID Ransomware at nomoreransom.org or MalwareHunterTeam). Identify patient zero — the first system where encryption was observed — by checking encryption timestamps relative to other systems. Map the blast radius: which systems show encryption, which show ransomware binary execution without encryption (still being processed), and which show no indicators (potentially unaffected or not yet reached).
Simultaneously: preserve forensic evidence before anything is touched. Image at least one encrypted endpoint and one system that appears to have been the staging point for the attack. Capture memory from any running systems that may contain encryption keys or attacker artifacts. Do not reboot or clean systems before imaging — rebooting encrypted systems can make recovery impossible and destroys volatile forensic data.
Activate your incident response retainer if you have one. The retainer provider should be notified within the first hour — most have 4-hour SLA for senior responder deployment, and forensic investigation timeline is directly proportional to how early their investigators are engaged.
Hour 4 to 24: Containment Without Destroying Evidence
After blast radius assessment, containment begins in a deliberate sequence designed to isolate affected systems while preserving the ability to investigate the attacker's access path.
Network isolation strategy: do not immediately take the entire corporate network offline. Use targeted isolation — segregate encrypted systems from the rest of the network while maintaining connectivity for unaffected systems and for your response team's investigation infrastructure. If the ransomware is still actively encrypting, disconnecting affected VLANs from core switching is the priority. Do not simply pull physical cables indiscriminately — document every isolation action.
Active Directory emergency response is the most critical containment step and the most frequently delayed. If the attacker has compromised domain admin credentials (assume they have — attackers rarely deploy ransomware before achieving domain admin access), your entire AD infrastructure is compromised. Emergency AD actions: reset the krbtgt account password twice (to invalidate all Kerberos tickets issued with the old key), reset all privileged account passwords (Domain Admin, Enterprise Admin, Schema Admin, any account in protected groups), force re-authentication for all active sessions, and review group membership for unauthorized additions in the past 30 days.
Disable VSS-aware backup jobs immediately. Modern ransomware specifically targets Volume Shadow Copy and backup infrastructure. Ensure your backup agent services are stopped on affected systems before isolating to prevent encrypted data from being written to your backup repository.
If the attacker is still active in the environment — you can see live connections in your EDR or network monitoring — delay full network isolation by 30 to 60 minutes while your IR team captures attacker activity, tooling, and C2 infrastructure details. Active attacker observation has significant attribution and recovery value.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The Ransom Payment Decision
The ransom payment decision is a business and legal decision that the CISO cannot make unilaterally. It requires involvement of the CEO, General Counsel, CFO, and cyber insurance carrier before any payment discussion with the threat actor.
The factors that inform the payment decision: can you recover from backups without paying? (This is the first question — if backup recovery is viable within your business continuity timeframe, payment is rarely justified.) Has the threat actor exfiltrated data and are they threatening publication? (Double extortion changes the calculus — even if you recover systems from backup, payment may be considered to prevent data release, though paying does not guarantee non-publication.) What is your legal exposure for payment? OFAC sanctions prohibit ransom payments to designated individuals and entities — your legal counsel must verify the threat actor's attribution against current OFAC SDN designations before any payment. Paying a sanctioned group exposes the organization to civil penalties.
If payment is being considered: engage a professional ransomware negotiation firm (Coveware, Resilience, Kivu Consulting) rather than negotiating directly. They have current intelligence on attacker payment history, decryptor reliability by group, and negotiation leverage points. Decryptor reliability varies significantly by group — some groups have near-100% functional decryptor rates; others have chronic decryptor failures. Never pay without receiving and testing a proof file (a sample decrypted file from the attacker demonstrating the decryptor works on your encrypted files) before paying the full ransom.
If you pay and receive a non-functional decryptor, report it to the FBI IC3 immediately — this record is valuable for future law enforcement action and may support an insurance claim.
Hour 24 to 72: Eradication and Backup Integrity Validation
Eradication begins only after you are confident the attacker's access paths are understood and closed. Premature eradication that leaves a persistence mechanism in place means a second ransomware deployment within days of recovery — a scenario that occurs in approximately 10% of ransomware incidents.
Persistence mechanism identification is the most critical eradication step. Modern ransomware groups establish persistence before deployment: scheduled tasks, registry Run keys, WMI subscriptions, and most importantly, Active Directory persistence via unauthorized accounts, modified group membership, or domain-level backdoors (DCSync-capable accounts, AdminSDHolder ACL modifications, domain trust additions). Run BloodHound against your AD to identify unauthorized permissions added in the 30 days prior to detonation.
Backup integrity validation must occur before recovery begins. Ransomware groups routinely spend their dwell time poisoning backup repositories — either by deleting backup files, encrypting backups, or waiting until poisoned data replicates through all backup tiers before detonating. For every backup set you intend to use for recovery, verify: that the backup was created before the earliest identified attacker activity (check logs, not just backup timestamps — timestamps can be modified); that the backup files are not encrypted (spot-check file headers); and that the backup is restorable by performing a test restore to an isolated environment before committing to production recovery.
If backups are confirmed clean, recovery sequencing should prioritize in this order: identity infrastructure (Active Directory, LDAP, SSO) must be recovered first — nothing else can authenticate without it; then tier-0 infrastructure (DNS, DHCP, certificate authorities); then business-critical application servers in priority order defined by your BIA (Business Impact Analysis); then end-user workstations last.
Regulatory Notification and Post-Incident Requirements
Regulatory notification obligations are triggered by the incident, not by recovery completion — and deadlines count from confirmed discovery, not from the start of your investigation.
SEC Material Cybersecurity Incident disclosure: US publicly traded companies must file Form 8-K within four business days of determining the incident is material. Materiality determination (not incident discovery) starts the clock. Engage securities counsel immediately to assess materiality — the SEC's 2023 rules define a low materiality threshold.
HIPAA Breach Notification: covered entities and business associates must notify affected individuals within 60 days of discovering a breach of unsecured PHI. If more than 500 individuals in a state are affected, HHS and prominent media outlets in that state must also be notified within 60 days. If the total exceeds 500 individuals nationally, HHS must be notified within 60 days.
GDPR Breach Notification: if EU resident personal data is involved, the supervisory authority in the lead EU member state must be notified within 72 hours of becoming aware of the breach. If the breach is likely to result in high risk to individuals, those individuals must also be notified without undue delay.
State breach notification laws: 50 US states have breach notification laws with varying definitions of personal information and notification timeframes ranging from 30 to 90 days. Your General Counsel should maintain a current matrix of applicable state laws.
FBI notification is voluntary but strongly encouraged. The FBI IC3 can provide decryptor keys obtained from other investigations for some ransomware families, access to classified threat intelligence, and law enforcement investigative resources at no cost to the victim. Reporting does not obligate prosecution or public disclosure.
The bottom line
Ransomware recovery speed is almost entirely determined by decisions made before the incident: tested backup procedures, pre-authorized isolation authorities, IR retainer relationships, and regulatory notification processes documented in advance. If you do not have a tested backup recovery procedure (tested means you have successfully restored from backup in an isolated environment in the past 90 days), that is the highest-priority preparedness gap to close. The playbook above is the correct sequence; the ability to execute it quickly depends on pre-incident preparation that cannot be improvised under pressure.
Frequently asked questions
Should we pay the ransom?
Payment should only be considered when backup recovery is not viable within the business continuity timeframe, and even then, only after OFAC compliance verification by legal counsel. If backups are available and restorable, recover from backup — payment funds future attacks, decryptors are unreliable in roughly one-third of cases per Coveware data, and payment does not guarantee that exfiltrated data will not be published. If payment is the only path to recovery: engage a professional negotiation firm, obtain and test a proof file before paying, and report the incident to the FBI IC3 regardless of payment decision.
How do we know if our backups have been compromised by the attacker?
Validate backups by comparing backup creation timestamps against the earliest confirmed attacker activity timestamp in your logs (EDR process creation events, authentication logs, network connection logs). Any backup created after the earliest attacker activity date should be treated as potentially compromised. For backups created before that date, verify integrity by attempting a test restore to an isolated environment — not a logical check against the backup catalog. Ransomware groups deliberately wait for their poisoned data to replicate through all backup tiers before detonating, so the backup timestamp alone is insufficient. Physical or air-gapped backup copies that have no network connectivity are the strongest protection against backup compromise.
When should we bring in external incident response help?
Activate your IR retainer or engage an external firm immediately upon confirmed ransomware detonation if your internal team does not have: forensic investigation capability (memory forensics, disk forensics, log analysis at scale), Active Directory incident response expertise, ransomware negotiation experience if payment is being considered, or the capacity to run a 24/7 response operation for the duration of recovery. Most organizations benefit from external IR support even with mature internal teams, because ransomware response requires simultaneous forensic investigation, containment operations, executive communication, and regulatory compliance work that exceeds any internal team's bandwidth. Pre-establish an IR retainer before you need it — response SLAs are significantly better and pricing is lower.
What is double extortion ransomware and how does it change the response?
Double extortion ransomware groups exfiltrate data before encrypting it, then threaten to publish the stolen data on their dark web leak site as a second extortion lever beyond the decryption ransom. This means recovering from backup does not eliminate the threat — you can restore systems but still face data publication. The response additions for double extortion: conduct data exfiltration analysis to identify what was taken (EDR network connection logs, DNS queries to cloud storage providers, large outbound transfers in your firewall logs) and notify affected parties proactively based on exfiltration scope rather than waiting for data to be published. Payment to suppress publication has a poor track record — threat actors frequently publish regardless of payment.
How long does ransomware recovery typically take?
Recovery duration depends almost entirely on backup availability and infrastructure complexity. Organizations with tested, clean backups and a pre-planned recovery sequence typically restore critical systems in 4 to 7 days and achieve full recovery in 3 to 6 weeks. Organizations without viable backups face recovery timelines of 3 to 6 months, primarily due to application reinstallation, data reconstruction from partial sources, and the extended forensic investigation required to ensure complete attacker eviction. The single most impactful preparedness investment for reducing recovery time is a documented, tested backup recovery procedure with regular testing against a realistic failure scenario.
What should we communicate to employees and customers during a ransomware incident?
Employee communication should happen within the first few hours: inform employees that a cybersecurity incident is occurring, instruct them to stop using affected systems immediately, and provide a specific point of contact for questions. Do not provide technical details of the attack in broad employee communications — limit sensitive details to the response team. Customer communication timing depends on regulatory obligations and whether customer data is confirmed to be affected. Work with legal counsel on customer notification timing and content. Avoid public statements that quantify the scope of impact or make commitments about recovery timelines before those assessments are complete — inaccurate early statements create legal and reputational problems when the actual scope becomes clear.
What is the krbtgt account and why does resetting it matter in ransomware response?
The krbtgt account is a special service account in Active Directory used to encrypt and sign all Kerberos Ticket Granting Tickets (TGTs). If an attacker has obtained the krbtgt account's NTLM hash (via DCSync or other means), they can forge Kerberos TGTs for any account without authentication — this is called a Golden Ticket attack. Resetting the krbtgt password invalidates all outstanding TGTs and forces all Kerberos clients to re-authenticate, evicting any sessions based on forged tickets. The password must be reset twice (separated by the Kerberos ticket maximum lifetime, typically 10 hours) to fully invalidate tickets that were issued before the first reset. This is a disruptive operation that forces all users and services to re-authenticate, so it should be coordinated with your operations team.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.