Ransomware response and recovery: prepare a usable plan

Prepare authority and communications

Identify who can isolate systems, disable accounts, change network access, authorize recovery, and coordinate external support. Keep the plan available through a communication path that does not depend entirely on the affected environment. Record critical provider contacts and recovery responsibilities in advance.

CISA’s StopRansomware Guide provides preparation and response guidance. Use it to evaluate your organization’s plan and dependencies rather than assuming one checklist fits every incident. A product team should know which infrastructure, identity, and specialist response owners it needs to involve.

References: [1] CISA, [2] NIST

Contain disruption and investigate reach

Coordinate isolation and other containment actions according to the active incident and operational priorities. Preserve relevant evidence where possible and record the changes made. Avoid untracked recovery attempts that reconnect affected systems to sensitive environments before their state is understood.

Review the identities, credentials, remote access, and data stores reachable from affected systems. Ransomware incidents can involve more than unavailable files, so do not assume the absence or presence of data theft from encryption alone. Scope those conclusions using evidence and the authorized response process.

References: [1] CISA, [2] NIST

Restore from a trusted recovery point

Identify suitable backups and validate that the recovery environment is separated and appropriately controlled. Review dependencies such as identity services, encryption keys, external integrations, and application configuration. Recovering a database snapshot does not automatically restore the complete product.

Replace or revoke compromised credentials through a trusted administrative path and address the intrusion path before normal service resumes. Select recovery actions based on the investigation and platform guidance. A successful boot or a readable filesystem is not enough to establish application integrity.

References: [1] CISA, [3] AWS

Test service behavior and improve the plan

Validate representative user journeys, permissions, data integrity, monitoring, and provider connections before staged restoration. Record the evidence and remaining limitations. Continue investigation where the response team has unresolved questions about persistence, scope, or additional affected systems.

After stabilization, test the plan against what actually happened. Improve backup isolation, recovery access, incident communications, and application logging where gaps were found. Schedule a controlled restore exercise so the next recovery decision is based on evidence rather than assumptions.

References: [3] AWS, [4] OWASP, [2] NIST

Your next steps

1. Assign incident, identity, infrastructure, application, and recovery owners.
2. Check the plan against current CISA guidance and your architecture.
3. Test a controlled restore with the dependencies the product actually needs.
4. Scope application hardening and remediation verification after immediate response.