
Introduction
One phished account. One unpatched VPN. That's often all it takes for ransomware to turn into an availability, data-protection, and business-continuity crisis across an entire organization.
The FBI's 2025 IC3 report logged more than 3,600 ransomware complaints with losses above $32M. Those are reports, not a census, and they leave out downtime, lost files, and remediation costs.
Many teams have a generic incident response policy that nobody has rehearsed against encryption and extortion. This guide covers what a ransomware-specific plan needs: preparation, detection, containment, eradication, recovery, communication, legal coordination, testing, and improvement.
Key Takeaways
- A plan only works with named owners, alternates, decision authority, and current contacts.
- Contain fast, but preserve evidence and protect backups and identity systems.
- Tested, isolated backups beat an untested recovery policy.
- Bring counsel, insurer, law enforcement, and executives in before an incident.
What Is a Ransomware Incident Response Plan?
What the plan is
A ransomware incident response plan is a documented set of roles, decisions, procedures, and communications used to prepare for, identify, contain, eradicate, recover from, and learn from a ransomware incident.
Current guidance has shifted. NIST SP 800-61 Rev. 3 (April 2025) replaced Rev. 2 and aligns incident response with CSF 2.0: Detect, Respond, and Recover, supported by Govern, Identify, and Protect.
The older four-phase model (preparation; detection and analysis; containment, eradication, and recovery; post-incident activity) still shapes many playbooks, including the CISA/MS-ISAC #StopRansomware Guide.
Why a general plan is not enough
Generic plans tend to skip the things ransomware makes urgent:
- Immediate isolation procedures
- Backup protection, since attackers target backups and shadow copies
- Evidence preservation
- Credential and identity recovery
- Data-exfiltration assessment
- Ransom decision authority
- Restoration sequencing
What outcomes the plan should support
Good plans support outcomes such as:
- Limiting encryption and data theft
- Shortening downtime
- Protecting sensitive data
- Meeting notification duties
- Restoring critical operations safely
- Leaving the organization more resilient afterward
Prepare Before a Ransomware Incident
Define the response team, roles, and authority
Name primary owners for each response role:
- Incident commander
- Security and IT leads
- Forensic contact
- Business continuity owner
- Legal counsel and communications lead
- Executive sponsor, cyber-insurance contact, and law-enforcement liaison
For each, record:
- A named alternate
- After-hours contact details
- Escalation thresholds and decision authority
- An out-of-band channel (phone bridge, for example) for when email and collaboration tools are compromised
CISA's guide recommends coordinated isolation and phone calls to avoid tipping off intruders. Outdated contact lists are among the most common plan gaps DeepSeas sees in readiness work.
Inventory and prioritize the environment
Keep a current inventory of:
- Endpoints, servers, and identities
- Cloud and SaaS services, plus third parties
- Network segments, OT, mobile, and BYOD assets
- Critical applications and sensitive data stores
Then map each to a business function. The team should know which systems to isolate first, which processes can run manually, and what gets restored first.
Protect and test backups
Attackers go after backups. A Sophos study found 94% of ransomware-hit organizations reported attempted backup compromise, and 57% of attempts succeeded.
Build backups accordingly:
- Follow 3-2-1: three copies, two media types, one off-site
- Keep offline or immutable copies
- Use separate administrative credentials
- Isolate the backup network
- Protect backup catalogs and recovery infrastructure
- Define retention requirements
Then test restoration on a schedule. Validate data integrity, dependencies, restoration time, and access to clean admin accounts. A completed backup job isn't proof you can recover.

Establish prevention and detection controls
Core controls include:
- Patching and phishing-resistant MFA
- Least privilege and secure remote access
- Segmentation
- EDR and centralized logging
- Threat intelligence
- Monitoring for mass file changes, credential abuse, lateral movement, and backup tampering
Cover on-premises, cloud, OT, mobile, and BYOD, and feed it all into your existing SIEM and EDR where practical.
Exercise the plan and maintain external support
Run ransomware-focused tabletops that test executive, legal, communications, insurance, recovery, and customer-impact decisions, not just malware detection. CISA offers free tabletop packages with ransomware scenarios and after-action templates.
Update the playbook after:
- Tabletop exercises
- Major technology changes or acquisitions
- New regulations
- Changes in insurer or response-provider contacts
Execute the Ransomware Incident Response Lifecycle
Detect and analyze
Treat these as triggers for investigation:
- Ransom notes and unusual file extensions
- Mass file renames and suspicious encryption processes
- Volume shadow copy deletion
- Abnormal privileged activity
- Unauthorized remote-management tools
- Beaconing and unusual outbound transfers
MITRE documents shadow-copy deletion and backup-catalog removal under T1490. The FBI/CISA RansomHub advisory also describes Rclone and WinSCP used for exfiltration. Those are advisory-specific behaviors, so don't treat them as universal signatures.
Responders should then establish scope and root cause from EDR, identity, firewall, cloud, and SIEM telemetry:
- Affected systems and likely patient zero
- Initial access, persistence, and lateral movement
- The variant and evidence of data theft
- Earliest known compromise
Contain the incident
Follow a prioritized sequence:
- Activate the plan.
- Isolate affected endpoints and network segments.
- Disable compromised accounts and sessions.
- Protect backup systems.
- Restrict lateral movement.
- Block communication with known malicious infrastructure.

Avoid indiscriminate shutdowns and wiping. CISA's guidance is to isolate first and power down only when disconnection isn't possible, because shutdown loses volatile memory evidence. Emergency shutdown makes sense when stopping active encryption takes priority.
Eradicate the threat and persistence
Deleting the visible payload isn't eradication. Check for remaining footholds:
- Scheduled tasks, services, and registry changes
- WMI subscriptions and rogue accounts
- Stolen credentials and cloud tokens
- Unauthorized remote-access tools
Then rotate credentials, review privileged access, patch the exploited weakness, and decide per system whether to sanitize or rebuild. If Active Directory may be compromised, Microsoft's forest recovery guidance calls for a trusted backup, an isolated first domain controller, and resetting admin credentials including krbtgt.
Recover and validate operations
Recover verification-first:
- Confirm backup integrity.
- Build a clean recovery environment.
- Restore identity and core infrastructure.
- Bring back applications by business priority.
- Validate restored data.
- Reconnect under heightened monitoring.
Before closing the incident, verify:
- No reinfection, unauthorized access, or persistence
- Data integrity and security-control coverage
- Business-function availability
Coordinate Communication, Legal, and Ransom Decisions
Build an incident communications structure
Set separate workflows for each audience:
- Employees and executives
- The board
- Customers and partners
- Regulators, insurers, and law enforcement
- Media
Appoint one authorized communications lead and pre-approve holding statements.
Share known facts, unknowns, operational instructions, and the time of the next update. Don't speculate about scope, and don't expose response activity to the attacker.
Coordinate counsel, insurers, law enforcement, and specialists
Contact counsel and your cyber insurer early and confirm policy requirements. Bring in qualified forensic support, preserve chain of custody, and document major decisions.
Notification clocks differ, and they start at different moments:
| Obligation | Clock |
|---|---|
| HIPAA | Within 60 days of discovery |
| FTC Safeguards Rule | 30 days after discovery (500+ consumers) |
| SEC Item 1.05 | Four business days after materiality determination |
| DFARS 252.204-7012 | 72 hours after discovery |
| NYDFS 500.17 | 72 hours after determination; 24 hours after extortion payment |

All 50 states also have breach notification laws with differing scope and timing. CIRCIA's proposed rule would add 72-hour incident and 24-hour payment reporting, but only once a final rule takes effect. Obligations vary by industry and contract, so get legal advice on applicability.
Create a ransom-payment decision framework
Define who can authorize negotiation or payment. Require review of:
- Clean backups and decryption options
- Operational impact and data exposure
- Sanctions risk and insurance terms
- Law enforcement guidance and counsel's advice
Payment guarantees nothing. FBI and CISA don't encourage it and note recovery isn't assured. OFAC's 2021 advisory warns that payments to sanctioned parties can carry strict-liability civil penalties, even without knowledge.
Preserve evidence while restoring operations
Capture the following without delaying critical containment:
- Ransom notes and relevant logs
- Memory or disk images where appropriate
- Malware samples and account activity
- Network telemetry and a running timeline
That evidence supports root-cause analysis, regulatory response, insurance claims, litigation readiness, threat intelligence sharing, and confidence that eradication is complete. Failing to retain logs during a crisis is a recurring gap in the readiness work DeepSeas performs.
Test, Measure, and Improve the Plan
Run realistic exercises and recovery tests
Combine recurring tabletops, technical simulations, restoration drills, and targeted red-team or penetration testing. Build each exercise around your actual infrastructure, attack paths, and staffing.
Every exercise should end with an after-action report that covers:
- Unclear decisions
- Missing contacts
- Failed controls
- Restoration dependencies
- Communication delays
- Remediation owners with deadlines
Measure operational readiness
Track practical metrics:
- Time to detect, declare, isolate, and contain
- Time to restore critical services
- Percentage of critical assets under monitoring
- Backup restoration success rate
- Closure rate of corrective actions
These metrics give executives and the board a trend line. Avoid borrowed benchmarks; no single target fits every organization. Define terms like MTTR carefully, since repair and recovery aren't the same.
Use external expertise when internal coverage is limited
Staffing is a real constraint: ISC2's 2025 study found 33% of respondents lacked adequate staffing resources. Organizations without a 24/7 SOC can supplement with an MDR provider.
DeepSeas, for example, runs a 24/7 CyberFusion SOC, supports existing SIEM and EDR tools, and covers IT, cloud, OT, mobile, and BYOD environments. Its responders work inside the client's tools and governance.
The aim is to close monitoring, investigation, and response gaps. Ownership of the plan stays with your organization.
Frequently Asked Questions
What should I do if my organization is attacked by ransomware?
Activate the plan, isolate affected systems, protect backups, and preserve evidence. Escalate to the response team, then contact legal counsel, your cyber insurer, and the appropriate authorities.
What should a ransomware incident response plan include?
Defined roles, detection, containment, eradication, backup-based recovery, and communications. Add legal and regulatory coordination, ransom decision authority, testing, and post-incident improvement.
Can you give an example of a ransomware incident response playbook?
An alert fires and is verified. Responders isolate systems, contain accounts, preserve evidence, and scope the damage. They then validate clean backups, restore by priority, notify stakeholders, and hold a post-incident review.
What does incident response mean in cyber security?
It's the coordinated process of preparing for, detecting, analyzing, containing, eradicating, recovering from, and learning from a security incident.
What are the 3 most common types of malware?
Classifications vary, but trojans, worms, and spyware are commonly cited. Ransomware is its own category: it encrypts data and demands payment, so response must cover recovery and extortion, not just removal.