Free tools Windows power users keep installed
One-click scans. No signup required.
A useful ransomware playbook links preparation to a rehearsed response: know which services matter, who has authority, how to isolate affected systems, how to preserve evidence, and how to restore from clean backups. Before an incident, prepare and exercise the plan. During one, contain the spread, investigate for a wider compromise, communicate through approved channels, and recover in a prioritized order.
What should a ransomware response playbook cover?
Treat ransomware as a security incident that may include more than file encryption. The intrusion could involve compromised accounts, earlier malware, or access that remains after the encryption is stopped. A ransom note is evidence of an incident, not a complete account of it.
The joint CISA, FBI, NSA, and MS-ISAC #StopRansomware Guide, revised October 19, 2023, combines preparation and prevention advice with a response checklist. For broader risk-management framing, NIST lists NIST IR 8374 Revision 1: Ransomware Risk Management, a CSF 2.0 Community Profile as final and dated June 11, 2026. These sources offer guidance, not a one-size-fits-all recovery design: adapt the playbook to your services, technology, obligations, and available responders.
How should an organization prepare before an attack?
Map services, assets, and recovery dependencies
- Maintain an inventory of logical and physical IT assets, including the systems and dependencies that support health and safety, revenue, and other critical services. Protect the inventory and keep an offline copy that responders can access if normal systems are unavailable.
- Set restoration priorities in advance. Record which upstream systems, identities, network services, data stores, and suppliers each critical service depends on; a recovery order based only on the apparent importance of individual servers can miss these dependencies.
- Decide what recovery can realistically use: available staff, hardware or cloud platforms, rebuild materials, and the clean environment needed to restore systems without bringing the compromise back.
Approve and exercise the response and communications plans
- Define incident roles, technical escalation, decision authority, and how responders will coordinate if corporate email, chat, or phones are untrusted or unavailable.
- Set procedures for internal notifications, executive updates, service-provider and insurer contacts, public communications authority, and preparation of a holding statement. Keep a contact sheet accessible outside the systems an attacker might compromise.
- Run exercises that make participants practice decisions and communications, not just read the plan. Update the plan when exercises, incidents, or organizational changes reveal missing contacts, unclear authority, or impractical recovery steps.
Make backups and rebuild materials usable under attack
- Keep offline, encrypted backups of critical information, and regularly test their availability, integrity, and restoration steps in a disaster-recovery scenario. A backup that exists but cannot be accessed, verified, or restored does not establish recoverability.
- Maintain suitable golden images, system templates, required software, source code, and relevant license or escrow material so recovery does not depend on compromised production systems.
- Measure recovery against the service priorities and dependencies already defined. Backup separation should also limit the chance that production credentials or accounts can compromise the recovery copies.
Protect access and retain useful visibility
- Apply least privilege and access controls, secure exposed services and identities, and understand which security responsibilities belong to your organization and which to cloud providers.
- Retain system, network, endpoint, and cloud logs that can help establish what happened and which systems or accounts were involved. CISA advises keeping critical-system logs for at least one year if possible; this is a recommendation, not a universal legal retention rule.
- Include internal IT and security teams, executives, outside service providers, insurers, law enforcement, and relevant government response organizations in the contact plan. Sector information sharing and exercises can also support readiness.
What should responders do first after detecting ransomware?
Follow the incident plan and keep a decision log: record timestamps, observations, actions, owners, and the reason for consequential decisions. The first actions need coordination; improvised changes by separate teams can obscure the scope or undermine recovery.
Recommended Free Tools
- Identify affected systems and isolate them. Establish what is known without delaying containment. CISA’s checklist states: “Determine which systems were impacted, and immediately isolate them.” Disconnect affected devices from networks where practical. If multiple machines or subnets appear affected, network-level isolation may be more workable than device-by-device disconnection.
- Triage systems for restoration. Compare observed impact with the service priorities and dependencies prepared in advance. This is an initial prioritization for response and recovery planning, not permission to reconnect systems before the environment is ready.
- Examine detections and logs for the wider attack. Review endpoint and network security tools and available logs for precursor malware, additional affected systems, and signs of earlier compromise. Do not assume the encryption event was the intrusion’s first or only stage.
If attackers may be monitoring organizational activity, coordinate response work through out-of-band communications. Avoid exposing containment or recovery plans through channels that may be compromised.
How can teams contain ransomware without destroying evidence?
Contain access paths while preserving information that may disappear or be overwritten. In coordination with incident leads and, where appropriate, qualified responders, preserve system images, memory captures, relevant logs, malware samples, and indicators of compromise when feasible. Prioritize volatile evidence, such as memory and short-retention logs, before routine cleanup or shutdown removes it.
Identify compromised systems and accounts, including email accounts, and contain the routes that could permit continued access. The correct technical action depends on the affected environment; avoid treating a generic instruction to power off every device as universally safe, since it may sacrifice volatile evidence or disrupt critical services. Coordinate isolation, evidence capture, and operational safety decisions.
Use trusted advice for the specific malware or intrusion when available, and consult law enforcement or incident-response specialists as appropriate. CISA’s Play ransomware advisory is an example for a particular threat, not a universal response recipe. Its indicators and tactics may change, so check current advisories during a live incident.
Who should be notified, and when?
Use the approved communications plan to inform technical responders, organizational leadership, service providers, insurers, and other stakeholders. Decide who can authorize external statements and keep messages coordinated as facts develop; distinguish confirmed findings from what is still being investigated.
Assess whether data was exposed and whether applicable breach-notification requirements are triggered. Legal obligations depend on jurisdiction and circumstances, so do not treat a U.S. contact list or rule as global guidance. The CISA joint guide recommends reporting to or seeking assistance from CISA, a local FBI field office, the FBI Internet Crime Complaint Center (IC3), or a local U.S. Secret Service field office. Those are U.S.-specific routes; organizations elsewhere should follow their own jurisdiction’s reporting channels and requirements.
How should systems be restored safely?
- Prepare a clean recovery environment. Keep compromised systems out of the recovery path and ensure the environment used to rebuild and restore is not exposed to the same compromised access.
- Restore in service-priority order. Use the pre-established critical-service sequence and its dependency map. Restore from offline, encrypted backups and use trusted rebuild materials where needed.
- Validate before reconnecting. Check that restored systems are clean and functioning as intended before returning them to production or connecting them to other systems. The specific validation methods depend on the environment and incident findings.
- Document recovery decisions and remaining risk. Maintain a record of what was restored, what remains isolated, and the basis for reconnection decisions so operational owners and responders share the same picture.
What should change after recovery?
Document lessons from the incident, update the incident-response and communications plans, and correct gaps in asset knowledge, access control, logging, backup recovery, or decision authority. Share useful indicators and lessons with CISA or a sector information-sharing organization when appropriate. The aim is to make the next response faster and more evidence-led, not simply to return systems to their previous state.
For implementation, CISA’s #StopRansomware Guide publication page identifies the October 19, 2023 revision. NIST’s ransomware protection and response publications index lists the 2026 CSF 2.0 profile alongside earlier resources.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
