Ransomware Recovery Checklist: 11 Steps to Contain, Restore, and Recover Safely After an Attack With Lower Reinfection Risk

Key takeaways

• Declare the incident and establish single-point command before any system changes, so containment decisions and evidence preservation stay coordinated.
• Isolate affected assets in a sequence that stops lateral movement while keeping volatile forensic evidence intact.
• Establish whether cyberattackers exfiltrated data, because encryption evidence alone does not prove theft.
• Validate backups with documented test restores, then rebuild in a clean recovery environment before reconnecting production.
• Close the incident with written re-entry gates, rotated credentials, and continuous security awareness training that shortens reporting time.

Want more from Adaptive in your Google results?

A ransomware recovery checklist gives security and business leaders a controlled path through the crisis. It helps them contain the cyberattack, preserve evidence, restore trusted systems, and limit operational and data loss. This guide helps security, IT, and business leaders coordinate incident command, isolate affected assets without destroying forensic evidence, determine whether cyberattackers stole data, and validate backups before restoration.

The guide also covers how to build a clean recovery environment and prioritize services by safety and business impact. Later sections address legal and regulatory notifications, credential rotation, and reconnecting third-party dependencies under tighter controls. CISA's ransomware response guidance reinforces the need to preserve evidence, coordinate decisions, and rebuild from trusted foundations before infected systems return to production.

A successful backup job does not prove that an organization can recover, so documented test restores and measurable production-entry gates remain essential. Employees also strengthen recovery when continuous, scenario-based security awareness training helps them report phishing, spear phishing, vishing, smishing, and other signs of renewed compromise.

The checklist below replaces guesswork with accountable decisions, verified recovery steps, and specific fixes that lower reinfection risk.

Adaptive Security helps organizations measure and reduce the human risk that gives ransomware operators their first foothold. Explore how human risk management turns everyday employee behavior into a measurable recovery control.

1. Ransomware Recovery Checklist: Declare the Incident and Establish Command

A ransomware recovery checklist starts with disciplined command before any hurried system changes begin. In the first 15 minutes, activate the incident-response plan, protect people and evidence, appoint an incident commander, and move communications away from compromised systems. Within the first hour, confirm scope, preserve records, notify required parties, and assign decision authority.

Treat every action as reversible when possible, because premature cleanup can destroy evidence needed for containment, recovery, insurance, regulatory reporting, or law enforcement.

1. Trigger the Plan and Protect Immediate Safety

Activate the plan when the event meets the organization's threshold. A ransom note, widespread file encryption, disabled security tooling, suspicious administrator activity, inaccessible business systems, or confirmed data theft should trigger the response without waiting for perfect certainty. The person who discovers the incident should contact the designated security or IT escalation channel, but should not decide alone whether to formally declare the event.

Use the first 15 minutes to complete this operational checklist:

• Confirm the alert and record the exact discovery time, affected user or system, visible symptoms, and reporting person.
• Activate the incident-response plan through the preapproved security, IT, executive, or managed-response contact.
• Appoint an incident commander and a deputy who can assume control if the commander becomes unavailable.
• Move coordination to a known-safe out-of-band channel and verify participants through a second trusted method.
• Preserve ransom notes, suspicious messages, screenshots, volatile observations, access logs, and system names before changing them.
• Instruct staff not to reboot, wipe, reimage, negotiate, forward suspicious files, or contact the suspected cyberattacker unless the incident commander authorizes the action.
• Identify immediate safety and continuity risks, including clinical systems, industrial equipment, physical access controls, emergency services, payroll, and customer-facing operations.
• Start a decision log with synchronized timestamps, owners, approvals, actions, outcomes, and open questions.

The CISA #StopRansomware Guide and Ransomware Response Checklist provides an official initial sequence for organizations responding to ransomware and data extortion. Use it as a reference point alongside a documented ransomware incident response plan that covers legal, regulatory, insurance, continuity, and law-enforcement procedures. If the event affects safety-critical operations, escalate to the relevant operational leader immediately and prioritize human safety over system availability.

A ransomware declaration does not mean the entire environment is compromised. It is a governance decision that gives responders authority to coordinate, restrict access, preserve evidence, and make time-sensitive choices under one command structure. The declaration should identify what is known, what remains unconfirmed, who owns the response, and when the next status review will occur.

2. Establish Incident Command and Decision Authority

An effective response separates command from execution. The incident commander owns the operational picture and sets priorities, while technical specialists gather facts and perform approved actions. This prevents teams from isolating systems, restoring backups, contacting vendors, or communicating externally in conflicting ways.

The incident commander must be a named person with authority to direct security, IT, business continuity, legal, communications, and executive stakeholders. That person does not need to perform every technical task. Responsibilities include declaring the incident, setting response objectives, approving high-impact actions, resolving conflicts between business recovery and evidence preservation, and announcing when containment or recovery is complete.

Assign these roles at the start:

• Incident commander: Directs the response, approves priorities, and owns the final declaration that containment and recovery are complete.
• Technical lead: Coordinates forensics, identity review, endpoint analysis, network isolation, backup validation, and restoration work.
• Evidence custodian: Controls collection, labeling, storage, access, hashing, and transfer of forensic material.
• Legal and privacy lead: Determines notification duties, privilege considerations, law-enforcement coordination, contractual obligations, and breach assessment.
• Business continuity lead: Ranks critical services, defines acceptable downtime, and coordinates manual workarounds.
• Communications lead: Prepares internal, customer, regulator, media, and employee messages using approved facts.
• Executive sponsor: Removes organizational barriers, approves material business decisions, and communicates risk tolerance.
• Vendor and insurer liaison: Coordinates with the cyber insurer, outside counsel, forensic firm, cloud providers, identity providers, and other authorized partners.

Document who can activate the plan, replace the incident commander, and approve extraordinary actions. Those actions include shutting down a production environment, suspending privileged accounts, disconnecting a site, engaging a negotiator, or restoring from backup. If the named commander cannot be reached, specify an alternate authority and an escalation time limit. Silence cannot become an approval mechanism.

The incident commander should define two separate completion standards. Containment complete means the team has evidence-based confidence that active cyberattacker access, propagation, and destructive activity are blocked or controlled. Recovery complete means approved systems and business processes are restored, monitored, validated by their owners, and operating under heightened review. Neither status should be declared because systems are merely online.

Organizations can strengthen this discipline by keeping incident-response reporting and dashboards ready before an event occurs. A dashboard does not replace command authority. It can give executives a consistent view of affected services, outstanding decisions, recovery milestones, and human-risk signals without forcing responders to assemble updates manually.

3. Move Communications to a Safe Out-of-Band Channel

Ransomware creates an identity problem before it creates a communications problem. Email, single sign-on, directory services, collaboration platforms, VPN access, and corporate phones may be unavailable, monitored, or controlled by a cyberattacker. Assume normal channels are unsafe until the technical lead and identity owner verify them.

Use a preplanned out-of-band method that does not depend on the affected identity environment. Options include a separately administered emergency messaging platform, a clean conference bridge, or personal phone numbers held in a sealed contact directory. An alternate email tenant, printed call trees, or a designated physical command location can also work. Do not create an emergency group inside a potentially compromised collaboration system and assume it is private.

Authenticate every participant before sharing incident details. Use a callback to a previously verified number, an in-person confirmation, or a prearranged code phrase. Keep sensitive technical indicators and personal data out of broad channels. Record who joined, how identity was confirmed, what information was shared, and which participants received authority to act.

If phones are unavailable, use a clean device and a known-safe network while avoiding any workstation showing ransomware activity. If all digital communications are suspect, use the printed call tree and physical coordination points. The goal is to preserve command integrity while preventing cyberattackers from exploiting confusion, impersonating executives, or issuing fraudulent recovery instructions.

4. Build the First-Hour Decision Log and Chain of Custody

The first hour produces the record that explains why the organization acted as it did. Start a decision log that captures the incident ID, date, time zone, incident commander, and participants. Record the source of each fact, confidence level, decision owner, approval authority, action taken, result, and review time. Distinguish confirmed facts from assumptions. “The finance file server is encrypted” is different from “the cyberattacker accessed all finance data.”

Consistent time synchronization keeps the record usable across sources. Record timestamps in Coordinated Universal Time or include the local time zone consistently, and note clock differences discovered on affected systems. Preserve the original timestamp shown by the source, and avoid substituting the time someone entered the note. Every material event should have both an event time and a recording time when those differ.

Create an approval trail for consequential actions. The record should show who authorized account suspension, host isolation, shutdown, restoration, external notification, ransom negotiation, or evidence transfer. If an emergency requires verbal approval, document the approver, exact instruction, time, and person who repeated it back. Obtain written confirmation when systems are stable.

Chain of custody begins at collection. Assign each item a unique identifier and record who collected it, from which system, using what method, and at what time. Also record where it was stored and who accessed or transferred it afterward. Keep original evidence read-only when possible and perform analysis on verified copies.

Preserve ransom notes, logs, memory captures, disk images, suspicious files, access records, identity events, cloud audit trails, and relevant communications according to counsel and forensic guidance.

Avoid destructive actions that erase evidence. Reimaging a host, deleting cyberattacker accounts, or clearing logs can remove the facts needed to determine entry, persistence, data access, and scope. Rotating every credential without recording the original state has the same effect. Restoring systems over compromised storage carries the same risk.

If an action is necessary to protect people or stop active damage, record the reason when time permits, identify what evidence will be lost, and preserve an alternative copy.

The incident commander should hold a first-hour review before declaring progress. Confirm the current scope, unresolved safety risks, evidence status, communication channel, assigned owners, legal notifications, business priorities, and decision time. Containment and recovery are controlled declarations that require supporting evidence.

Keep the command record intact until legal counsel, forensic investigators, insurers, and business owners confirm that the response file is complete. Isolation and evidence-preserving remediation can then begin.

2. Isolate Systems During Ransomware Attacks Without Destroying Evidence

This ransomware recovery checklist step limits encryption, credential abuse and lateral movement while preserving the evidence needed to understand the cyberattack. Isolate affected endpoints, servers, virtual machines, network shares, identity infrastructure, cloud resources and operational technology in a coordinated sequence. Keep systems powered on when forensic teams need volatile data, but power them down when no safe network disconnection exists and continued operation threatens wider spread.

1. Establish Incident Command Before Disconnecting Systems

Isolation is an incident response decision that requires formal authority. The incident commander should establish containment authority, while the forensic lead determines which systems require memory capture, disk imaging, log preservation or other evidence handling. Record the time, person, command and affected asset for every action.

Use out-of-band communications such as phone calls or a dedicated incident bridge that does not depend on potentially compromised email, collaboration or identity services. Cyberattackers who still have access can monitor internal messages and react by accelerating encryption, deleting logs or creating new persistence. The CISA #StopRansomware Guide directs organizations to isolate impacted systems, coordinate actions and avoid alerting adversaries to containment activity.

Start with a current asset inventory and divide systems into four groups: confirmed infected, suspected exposed, business-critical and apparently clean. Include laptops, desktops, domain controllers, file servers, backup infrastructure, hypervisors, virtual machines, databases, SaaS administration accounts, cloud workloads, network appliances and OT controllers. Treat an asset as exposed when it shares credentials, administrative paths, network segments or storage access with an infected system.

Do not begin with a broad shutdown unless the incident commander approves it. A rushed organization-wide power cut can destroy volatile evidence, interrupt life-safety functions, disable recovery services or remove the logs needed to identify the initial access path. Containment must be fast, but it must also be deliberate enough to preserve the facts that determine whether recovery is safe.

2. Cut Network Paths That Enable Lateral Movement

Network isolation should stop compromised systems from reaching additional hosts, shares, identity services and command-and-control infrastructure. Disconnect infected laptops and desktops from wired and wireless networks, then quarantine affected switch ports and disable network access control assignments. Block known malicious IP addresses, domains, hashes and file paths at the appropriate control points.

Preserve firewall, VPN, proxy, DNS, wireless controller and switch configurations before changing them. Export relevant logs and configuration histories to protected storage.

Prioritize the paths ransomware operators use to scale an intrusion. Restrict or disable SMB between workstations, suspend unnecessary RDP and remote administration, block unauthorized PowerShell remoting, pause remote monitoring and management tools, and limit access to file shares. Isolate domain controllers, privileged access workstations, identity providers, certificate authorities, backup consoles and virtualization management interfaces from ordinary user networks.

Disable compromised VPN accounts and remote access servers only after documenting active sessions and capturing the information the forensic lead requires.

Use narrow blocks before broad actions. Stopping a known malicious process, disabling a confirmed account or cutting a verified infected subnet is safer than shutting down every firewall rule. Revoking every identity or disabling all endpoint agents carries the same risk. Broad actions can trigger additional encryption, sever forensic collection or lock responders out of the environment.

When containment requires a network-level action, record the original rule, apply the smallest effective change and keep a rollback copy outside the affected environment.

For identity infrastructure, disable accounts confirmed or strongly suspected to be compromised, revoke active sessions and rotate credentials in an order approved by the incident commander. Protect break-glass accounts, service accounts and recovery credentials from simultaneous lockout. For cloud resources, isolate affected workloads with security groups or equivalent controls, restrict public exposure, suspend suspicious access keys and preserve point-in-time snapshots before making destructive changes.

Add cloud audit logs to the evidence set, including IAM, storage, network, API and administrative activity.

Organizations that operate manufacturing, utilities, medical devices or other operational technology must not treat OT like an ordinary endpoint network. Coordinate with plant operations, safety personnel and the OT owner before disconnecting controllers, programmable logic controllers, engineering workstations or supervisory systems. If isolation threatens physical safety or process stability, block IT-to-OT pathways, remove unnecessary remote access and move monitoring to a controlled channel before considering an abrupt power-down.

3. Decide Whether Each Device Stays Powered On

Power state determines what evidence survives. A powered-on system can contain volatile memory showing active processes, network connections, logged-in users, encryption keys, command history and malware that never reached disk. The forensic lead should approve memory capture and collection procedures before responders reboot, log off, run cleanup tools or make configuration changes. The incident commander should approve the operational risk of keeping the system active.

Keep a device powered on when the forensic team can isolate it safely at the switch, wireless controller, host firewall, virtual network or other control point. Volatile data on that device can explain the cyberattack. This approach is especially valuable for domain controllers, servers actively encrypting shares, suspected command-and-control hosts and systems holding evidence of privileged access.

Power down a device when it cannot be disconnected from the network. The same applies when it is actively spreading encryption with no containment control available, or when continued operation threatens critical systems. CISA warns that powering down can prevent further spread but destroy ransomware artifacts and evidence held in volatile memory. That decision requires approval from both the incident commander and forensic lead, with the reason documented in the incident record.

Do not reboot merely because a screen displays a ransom note. Do not run antivirus cleanup, delete suspicious files or restore from backup on an evidence-bearing system before forensic capture. Those actions can alter timestamps, remove persistence clues or make the attack chain impossible to reconstruct.

If a device must be stopped immediately, photograph or record its state when safe and note connected cables and screens. Preserve associated logs from switches, firewalls, identity systems and cloud services.

4. Build Separate Quarantine and Recovery Networks

A quarantine network gives responders a controlled place to inspect systems without allowing compromised assets to reach production. Place suspected endpoints, servers and virtual machines in a restricted VLAN or equivalent segment with deny-by-default egress. That segment should have no access to production shares and no administrative trust relationship with the recovery environment. Allow only the traffic required for forensic collection, malware analysis, time synchronization and approved management.

The recovery network must be cleaner and more tightly controlled than the quarantine network. Build it from known-good infrastructure, verified images and protected configuration backups. Keep it separate from infected production segments, compromised identity services and potentially exposed backup consoles. Use dedicated administrator accounts, fresh credentials and monitored jump hosts. Never add a restored system to the recovery network until its image, patches, persistence mechanisms and credentials have been reviewed.

Virtualization requires the same discipline. Isolate affected hypervisors and management planes, preserve snapshots where appropriate and do not assume that an untouched virtual machine is clean because its disk is not encrypted. A compromised hypervisor, shared datastore or administrative account can reintroduce the cyberattacker during restoration. Cloud recovery environments require separate accounts, subscriptions or projects where practical, along with restricted IAM policies and immutable logging.

Maintain a written map of every quarantine, production and recovery connection. Include VLANs, firewall rules, routes, trust relationships, shared storage, identity dependencies and OT gateways. For broader operational planning, pair containment procedures with ransomware prevention practices and phishing simulations that address the human behaviors behind initial access.

5. Verify Containment Before Restoring Anything

Containment is complete only when responders can explain why the cyberattacker can no longer move. Hunt for new privileged accounts, unusual VPN sessions, unexpected RDP or SMB connections, abnormal PowerShell activity and modified firewall rules. Look for disabled security controls, suspicious scheduled tasks, unauthorized remote-management tools and cloud IAM changes.

Review endpoint, firewall, switch, DNS, identity, cloud and OT logs together, because no single data source shows the full attack path.

Confirm that backup systems, golden images, hypervisors, domain controllers, SaaS administration accounts and recovery credentials are clean before reconnecting them. Block known indicators at every relevant control point, but keep copies of the original indicators and rule changes for investigation. Reconnect systems in priority order on the clean recovery network, monitor each connection and stop immediately if encryption, credential abuse or suspicious traffic returns.

The objective reaches beyond making screens usable again. Isolation should prevent the cyberattacker from surviving inside the environment, preserve evidence for legal and regulatory decisions, and give recovery teams a trustworthy foundation for rebuilding. Isolation succeeds when every restored system enters a controlled network with verified credentials, documented dependencies and a clear owner.

3. Identify Affected Systems, Accounts, Data, and Evidence for the Ransomware Recovery Checklist

A ransomware recovery checklist must begin with a complete scope assessment before anyone restores systems or deletes malicious files. Inventory affected and potentially affected assets, accounts, data stores, and network paths, then preserve volatile evidence before containment changes the scene. Treat every apparently clean system as unverified until logs, authentication records, and endpoint telemetry show that it was not involved.

1. Build the Asset and Account Inventory

Create one incident inventory with an owner, status, last-known activity time, and evidence location for every asset under review. Record whether each item is confirmed encrypted, suspected compromised, potentially exposed, or presumed clean. This prevents recovery teams from rebuilding one server while an overlooked workstation, service account, or cloud tenant still gives the cyberattacker access.

Include the following asset classes:

• Workstations, laptops, mobile devices, virtual desktops, contractor devices, and BYOD endpoints that accessed corporate resources
• File servers, domain controllers, application servers, database servers, hypervisors, storage arrays, virtual machines, and management consoles
• SaaS services, identity providers, email tenants, collaboration platforms, backup consoles, code repositories, and cloud tenants
• Privileged, administrator, domain, root, break-glass, service, API, automation, vendor, and managed service provider accounts
• Network segments, VLANs, VPN concentrators, remote access systems, wireless controllers, firewalls, routers, switches, and connections between production, backup, development, and recovery environments
• Business data, including file shares, databases, customer records, finance systems, source code, intellectual property, regulated information, and data stored in cloud object repositories
• Backups, snapshots, replication targets, immutable storage, offline media, golden images, infrastructure-as-code repositories, and recovery credentials

For each asset, capture the hostname, IP address, MAC address, operating system, business owner, physical or cloud location, criticality, connected services, and last successful backup. Record dependencies such as an application server relying on a database, a payroll system relying on an identity provider, or a backup platform relying on a privileged domain account.

CISA's #StopRansomware Guide and response checklist directs organizations to identify impacted systems, prioritize critical services, examine logs, and investigate accounts and systems involved in the initial breach.

Inventory accounts separately from devices. Review recently created users, privilege changes, unusual group memberships, disabled security controls, and new API keys. Examine OAuth grants, mailbox forwarding rules, remote access sessions, and service accounts that authenticated outside their normal pattern. Preserve each account's unique identifier, role, authentication method, source IP, device, session time, and actions taken.

Do not assume a shared service account points to one person. Trace its token, host, process, and execution context before assigning responsibility.

Identify systems that appear unaffected as well. A documented clean or unreviewed status is more useful than an empty row because it shows which systems require additional validation and which can remain outside the restoration sequence. Keep a read-only copy of the inventory outside the potentially compromised environment.

2. Preserve Evidence Before Changing Systems

Evidence preservation must precede broad cleanup, reimaging, password resets, or mass decryption. Coordinate with legal counsel, incident response specialists, cyber insurance contacts, and law enforcement as appropriate, because evidence-handling requirements differ by jurisdiction and litigation posture. Assign one evidence custodian and use a case identifier, collection time, collector name, source system, hash value, and chain-of-custody record for every item.

Preserve full system images from a representative sample of affected workstations, servers, virtual servers, and cloud workloads. Capture memory from live systems where feasible, especially before powering them down. Credentials, running processes, network connections, encryption keys, and command histories can disappear when volatile memory is lost. If a system cannot be imaged immediately, document the decision, isolate it, and record who approved any action that changes its state.

Collect relevant logs before retention windows or storage limits erase them. Prioritize identity and authentication logs, Active Directory events, VPN and remote access records, endpoint telemetry, EDR alerts, PowerShell and command-line activity, file access events, and SMB logs. Also collect application and database logs, firewall and DNS records, proxy data, cloud audit trails, object storage access, backup console activity, and network flow or packet captures.

Export copies of cloud audit records from every affected tenant, including identity, mailbox, storage, key-management, IAM, API, and administrative activity. Store exports in a separate access-controlled location while preserving the original timestamps and time zone.

Retain the ransomware note, ransom demand, contact details, wallet addresses, file extensions, encrypted files, filenames, directory paths, file metadata, and warning or readme files. Preserve malware samples only in a controlled, access-restricted repository. Record cryptographic hashes for samples, images, logs, and representative encrypted files. Do not open suspicious files on a normal workstation, upload confidential artifacts to unapproved analysis services, or rename evidence in a way that changes its metadata.

CISA advises collecting system images, memory captures, relevant logs, precursor malware samples, and volatile evidence such as system memory, Windows Security logs, and firewall buffers. That guidance matters because an apparently simple encryption event can conceal credential theft, data exfiltration, persistence, or an earlier intrusion. Documented ransomware attack examples show how often the encryption stage arrives last.

3. Perform Forensic Triage and Trace the Encryption Path

Forensic triage should answer three questions in order. Where did the cyberattacker enter, which identity or process performed the destructive action, and what additional systems or data could that identity reach? Begin with the earliest reliable alert, then work backward through authentication, endpoint, process, file, and network telemetry. Establish a normalized timeline in UTC while retaining each source system's original timestamp.

Server-side encryption does not prove that the server itself was infected. A workstation, compromised administrator account, service account, scheduled task, or remote management tool can write encrypted files across a legitimate network connection. Correlate the first encrypted filename and timestamp with the server's open-file and session records, file ownership and access metadata, and SMB events. Compare those results with authentication logs, RDP connections, endpoint process creation, and source IP addresses.

In Windows environments, review server session and open-file data to identify the user or system accessing affected files. Compare those results with Windows Security and SMB event logs, Terminal Services connection records, endpoint telemetry, and process execution data from the suspected workstation.

If the evidence shows an active remote write, capture network traffic on the affected server or relevant segment and filter for the file operations, source address, protocol, and timestamp. Map the source IP to a device, user session, process, and account at that exact time.

Cloud encryption requires the same correlation across different records. Match object or database modification timestamps with IAM activity, API calls, access keys, workload identity, source IP, user agent, virtual machine process data, and changes to key-management policies. A cloud audit record that names an account is only the starting point. Determine whether the account was used interactively, through automation, from a compromised workload, or through a stolen token.

Classify every finding as confirmed, probable, possible, or disproven, and document the evidence supporting that classification. Preserve the original artifacts after reaching a conclusion. This disciplined scope prevents premature restoration and exposes hidden persistence. It also gives the recovery stage a defensible list of systems that can be rebuilt, systems that require eradication, and systems that must remain isolated.

4. Determine How the Ransomware Entered and Whether Data Was Stolen

A ransomware recovery checklist must establish how cyberattackers entered, what they did before encryption, and whether they removed data. Encryption evidence alone does not prove that files were stolen, while a ransom note or leak-site threat does not prove the full scope of exfiltration. CISA's ransomware guidance treats encryption and data extortion as related but distinct investigative questions, so responders must preserve evidence for both.

How Should Investigators Analyze Initial Access?

Initial-access analysis identifies the first credible foothold and anchors the investigation. Start with the earliest confirmed alert and work backward across email, identity, endpoint, network, remote-access and cloud logs. The objective is to determine whether the intrusion began with phishing, exposed remote access, a vulnerable edge system, stolen credentials or a compromised third party.

Review the following evidence:

• Phishing and social engineering: Search secure email, identity and endpoint telemetry for malicious attachments, credential-harvesting pages and unusual OAuth consent. Review suspicious inbox rules and messages that preceded the first unauthorized login. Include vishing and smishing when a phone call or text could have supplied a password, one-time code or approval.
• Exposed remote access: Examine VPN, RDP, virtual desktop and remote monitoring and management (RMM) logs for unfamiliar devices, impossible-travel patterns and repeated failed logins followed by success. Review new administrator sessions and access outside normal working hours.
• Vulnerable edge systems: Compare firewall, VPN, virtual appliance and internet-facing application activity against patch timelines. Look for exploitation attempts, newly created accounts, web shells, configuration changes and connections from infrastructure with no prior relationship to the organization.
• Stolen credentials: Identify the first account used, its privileges, authentication method and recent password or multifactor authentication changes. Review sign-in tokens, session cookies, service accounts, API keys and privileged-group membership, and do not limit the investigation to user passwords.
• Persistence and tooling: Record newly created scheduled tasks, services, startup entries, local users, domain accounts and RMM installations. A portable RMM executable or new remote-access account can indicate persistence even when no conventional malware file remains.

Build a timeline with timestamps normalized to UTC and label each event as confirmed, probable or unresolved. The timeline should run from initial access through persistence, credential theft, privilege escalation, lateral movement, data discovery, data staging, exfiltration, encryption and extortion. Preserve the original log source, event identifier, system name, account, source address and investigator interpretation for every entry.

CISA's #StopRansomware Guide recommends examining detection systems and logs for precursor malware, because ransomware can be the final stage of an older, unresolved compromise.

Do not rebuild or wipe a system before collecting volatile evidence unless active spread leaves no safer option. Capture memory from representative affected hosts, preserve disk images, export firewall and cloud logs, and retain ransom notes, suspicious binaries, scripts and registry artifacts. These materials can reveal whether cyberattackers used PowerShell, PsExec, Cobalt Strike or credential-dumping utilities before encryption.

Those materials also give legal counsel a defensible record of what investigators knew and when they knew it.

What Should Threat Hunters Look For?

Threat hunting connects isolated alerts into an attack path. Begin with the first confirmed compromised account or host and pivot across authentication, endpoint, directory, network, storage and cloud telemetry. Search for PowerShell with encoded commands, unusual child processes, script-block activity, remote service creation and PsExec execution. Look for Cobalt Strike beacons, LSASS access, Mimikatz or other credential-dumping behavior, and administrative tools launched from user workstations.

Lateral movement often appears before encryption. Compare endpoint-to-endpoint connections with normal administrator workflows, especially SMB, RDP, WinRM and remote service activity. Look for one account authenticating to many systems, a workstation accessing servers it never previously contacted, and privileged credentials used from an unmanaged or recently compromised device. Investigate whether cyberattackers disabled security tools, altered firewall rules, deleted shadow copies, changed boot settings or modified backup agents.

Cloud activity requires a separate investigation, because a cyberattacker can operate without touching a traditional endpoint. Review IAM changes for newly created users, access keys, roles, policies, federation trusts and privilege escalations. Identify who changed firewall rules, security groups, storage permissions, logging settings, encryption keys or backup policies.

Treat a new rule allowing broad inbound traffic, a disabled audit trail or a role granted access to every storage bucket as a high-priority event.

Examine storage access and egress at the same time. Identify bulk reads, archive creation, unusual compression, database exports, access to file shares outside the user's role and downloads to unfamiliar cloud accounts. Compare outbound volume with the organization's baseline and inspect destinations, protocols and timing. Rclone, Rsync, FTP, SFTP, cloud-storage synchronization, HTTPS tunnels and newly installed transfer utilities can support data exfiltration.

The investigation should also cover cloud-backup deletion. Search for deleted snapshots, shortened retention periods, disabled immutability, removed recovery points, altered backup credentials and API calls that accessed or destroyed backup storage. A backup deletion event proves an attempt to impair recovery. It does not prove that confidential data was stolen. Keep those conclusions separate.

For a repeatable process, ransomware-focused phishing simulations give employees practice recognizing the initial social-engineering signals that investigators later depend on. Those signals include spear phishing, business email compromise (BEC), vishing and smishing.

How Should Double Extortion Be Assessed?

Double-extortion assessment separates evidence of encryption from evidence of data theft. Encryption evidence includes renamed or inaccessible files, ransom notes, known ransomware binaries, mass file-write events, modified extensions, disabled recovery tools and encryption activity across shared drives. These findings establish disruption and help identify affected systems, but they do not establish that the cyberattacker viewed or copied data.

Data-theft evidence requires a different chain of proof. Look for file discovery commands, bulk reads, staging directories, archive files, database dumps, cloud-storage transfers, abnormal egress and cyberattacker communications that identify specific stolen documents. Correlate those findings with access-control logs and data classifications. A ransomware actor's claim that data was stolen is an investigative lead that still requires confirmation.

Report uncertainty precisely. Tell legal and executive stakeholders which systems are confirmed encrypted, which accounts or hosts are confirmed compromised, and which data repositories show evidence of access or transfer. Identify which logs are missing or unreliable. Use language such as “confirmed exfiltration,” “evidence consistent with exfiltration,” “no evidence identified in available logs” or “scope remains undetermined.”

Do not state that data was not stolen when retention gaps, disabled logging, encrypted traffic or compromised administrator accounts prevent that conclusion.

The final timeline should identify the earliest known access, the cyberattacker's persistence method, credential exposure, lateral movement, staging locations, suspected exfiltration path, encryption start time and extortion demand. That record allows counsel to assess notification duties and gives executives a fact-based impact statement. It also prevents recovery teams from restoring systems while a cyberattacker still controls an account, token, RMM tool or cloud role.

5. Identify the Ransomware Strain and Evaluate Decryption Options

A ransomware recovery checklist should identify the strain before anyone attempts decryption, restoration or rebuilding. A decryptor targets a specific ransomware family and version, while backups restore known data without relying on a cyberattacker's encryption weakness. These options can work together, but the correct sequence depends on evidence quality, backup integrity, business priorities and the risk of altering forensic data.

How Confident Is the Ransomware Attribution?

Ransomware identification starts with preserved evidence, because a filename guess cannot support recovery decisions. Save the ransom note, record its exact filename and contents, capture payment instructions without interacting with them, and document file extensions, affected directories and timestamps. A ransom note can identify a family, but operators reuse templates, imitate established groups and change branding, so the note alone is not proof.

Compare multiple signals before assigning a strain:

• Ransom note and extension: Match distinctive language, contact addresses, victim identifiers and appended extensions against trusted incident-response databases.
• Malware sample: Preserve a representative encrypted file and, when available, the suspected encryptor or related executable for professional analysis. Record cryptographic hashes before moving anything.
• Encryption behavior: Note whether filenames changed, files were partially encrypted, network shares or backups were targeted, and specific file types were skipped.
• Infrastructure: Review domains, IP addresses, command-and-control indicators, email addresses and cryptocurrency wallets against current government advisories and incident-response intelligence.
• Independent confirmation: Ask an experienced incident-response provider or qualified forensic examiner to compare the evidence, because a single automated scanner cannot settle attribution.

Treat attribution as a confidence level that can change with new evidence. High confidence requires multiple independent indicators that agree, such as a distinctive note, matching extension and consistent malware behavior. Low confidence means recovery decisions should pause while evidence is preserved. The CISA #StopRansomware Guide advises victims to report incidents to the FBI's Internet Crime Complaint Center or a Secret Service field office and request technical assistance from CISA.

Reporting gives investigators indicators that can connect related cyberattacks without forcing the response team into a premature attribution.

How Should a Ransomware Decryptor Be Verified?

A decryptor is a narrowly targeted recovery instrument with a limited scope. Confirm the ransomware family, supported version, operating system, encryption mode, file extensions and required key material before execution. Check that the tool comes from a recognized incident-response organization, national cybercrime center or established security research team. Read its complete usage guide before placing it near production data.

Test every candidate decryptor on forensic copies in an isolated environment. The test environment should have no unnecessary network access, use a separate administrator account and contain representative copies of encrypted files while the originals stay untouched. Compare file hashes, metadata, permissions, directory structure and file contents before and after testing. Confirm that the tool writes recovered files to a separate destination, preserves timestamps where required and creates logs another investigator can review.

Confirm that the tool leaves the encrypted originals in place. Overwriting them removes the only remaining copy of the evidence.

The No More Ransom decryption-tool directory associates individual decryptors with specific ransomware families and provides separate usage guidance. A successful test on one document does not prove the tool will recover databases, virtual machine images, large archives or files encrypted with a different campaign key. Test each important file class, calculate post-decryption hashes and stop if the output is corrupted or incomplete.

What Are the Risks of Unsafe Decryption Tools?

Unsafe decryptors create two risks at once. They can destroy evidence by changing file metadata, overwriting encrypted material or modifying system artifacts. They can also introduce malware when downloaded from an unverified forum, mirror or impersonation site. A tool that promises universal recovery, requests excessive privileges or lacks a verifiable publisher should be treated as untrusted code.

Do not execute a decryptor on the affected production host. Have incident responders validate its hash and signature, scan it in a controlled environment and review its network behavior before use. Preserve the original ransom note, encrypted files, memory captures, disk images and relevant logs separately. If a decryptor fails, retain the failure output and diagnostic logs for investigators, and avoid repeated experiments on the only available copy.

Should Responders Use a Decryptor, Restore Backups, or Rebuild?

Recovery decisions should compare evidence preservation, recovery speed and confidence in the environment. A decryptor is appropriate only when attribution is strong, the tool is independently verified and testing shows reliable results on forensic copies. Backup restoration is preferable when offline or otherwise protected copies are complete, recent and demonstrably free of compromise. Rebuilding from trusted images becomes necessary when system integrity cannot be established.

Rebuilding is also the right path when persistence remains possible or backups contain contaminated configurations.

No option is universally safe. A backup can contain the cyberattacker's foothold, a decryptor can fail across file types and a rebuild can omit critical data or dependencies. Validate restored systems before reconnecting them, rotate exposed credentials, preserve evidence and document every decision. Once the recovery path is selected, controlled restoration must proceed without sacrificing the artifacts needed to explain how the intrusion happened.

6. Verify Backups, Recovery Keys, and the 3-2-1-1-0 Strategy

A ransomware recovery checklist must prove that backups can restore clean, usable business systems. A completed backup job is only the starting point. Validate backup availability, coverage, restore points, isolation, encryption, key access, malware status and application dependencies before an incident turns recovery into guesswork. A documented ransomware preparedness checklist keeps those checks repeatable and assigns an accountable owner to each one.

1. Confirm Backup Integrity and Business Coverage

Map every critical service to its required backup set, recovery point objective and recovery time objective. Include production databases, file shares, identity services, cloud workloads, SaaS data, virtual machines, configuration files, source code, infrastructure-as-code templates, golden images, certificates, license files and application dependencies. A backup that contains payroll records but not the database schema, authentication service or encryption key cannot restore payroll operations.

Use this validation checklist during every review:

• Availability: Confirm that the backup exists, is reachable through an approved recovery account and remains within the retention policy.
• Scope: Match protected assets against the current inventory, including new cloud accounts, remote offices, containers, endpoints and third-party systems.
• Restore points: Verify that recovery points cover the required retention window and include versions from before the suspected compromise.
• Integrity: Compare hashes, perform catalog checks and inspect backup logs for incomplete jobs, skipped files, corrupted blocks and failed snapshots.
• Encryption: Confirm encryption at rest and in transit, identify the algorithm and record which key protects each backup set.
• Malware screening: Scan restored data in an isolated environment before reconnecting it to production. A successful backup does not prove that it captured clean data.
• Business consistency: Open representative files, query restored databases, start recovered applications and confirm that dependent services communicate correctly.
• Ownership: Record who can approve a restore, who can execute it and who validates that the recovered service supports business operations.

A successful backup job proves only that data moved from one location to another. It does not prove that the catalog is complete, the files are usable, or the database is transactionally consistent. It also does not prove that the organization still possesses the keys needed to decrypt the copy. CISA's #StopRansomware guidance calls for offline, encrypted backups and regular integrity testing so organizations can validate actual disaster recovery capability.

2. Test Documented Restores in a Clean Environment

A documented test restore provides the strongest operational proof that a backup supports recovery. Run a representative file-level restore, a full-system restore and an application-level restore on a schedule tied to business criticality. High-priority systems need more frequent exercises than archival data, and every exercise should use an isolated recovery network that cannot reintroduce dormant malware into production.

Record the source backup, restore point, start and finish times, operator, dependencies, errors, recovered data volume and validation results. Have the business owner confirm that the restored application produces accurate results, and treat a booting server as insufficient proof. A finance team should verify balances and transaction integrity, while a healthcare team should verify that clinical records, access controls and audit trails remain intact.

Test more than the preferred restore path. Rehearse recovery when the primary console is unavailable, the latest restore point is corrupt or the cloud provider has an outage. Keep an offline copy of the recovery runbook and the ransomware business continuity plan with vendor contacts, network diagrams, administrator procedures, licensing details and clean-build instructions.

A provider that cannot be reached during a crisis is not a recovery plan, so maintain a secondary provider or internal capability for critical systems.

Track recovery telemetry as operational evidence. Capture backup success and failure events, deletion attempts, retention-policy changes, unusual download activity, restore requests, key-access events and administrator privilege changes. Send those signals to the organization's security information and event management (SIEM) or extended detection and response (XDR) workflow. The security team can then investigate suspicious backup activity alongside identity and endpoint events.

Include backup dashboards in security reporting and audit reporting, so executives can see tested recoverability alongside completion percentages.

3. Separate Offline and Immutable Copies

The 3-2-1-1-0 rule creates multiple barriers between ransomware and the data required for recovery. Keep three copies of important data on two different media types. One copy should be stored off-site, one copy offline or otherwise isolated, with zero unverified errors after backup and restore checks. The rule is a design target that still depends on testing. Three synchronized copies in one compromised cloud account still represent one failure domain.

Make the offline copy genuinely inaccessible during normal operations. Disconnect removable media, use a separate administrative boundary for vault access or place backups in a storage tier that production identities cannot mount. In cloud environments, use isolated accounts, separate credentials, object lock or equivalent retention controls and policies that prevent ordinary administrators from deleting backups or shortening retention periods.

Immutability prevents alteration or deletion during a defined retention period, but it does not guarantee clean data, correct configuration or usable restores. Confirm the immutability mode, retention duration, clock source, deletion permissions and escalation process for emergency access. Review who can change the policy and ensure that no single production administrator can both compromise systems and erase recovery copies.

4. Protect Recovery Keys and Administrator Access

Backup encryption is valuable only when authorized responders can retrieve the correct keys without exposing them to the same compromise. Store backup-encryption keys separately from backup data, restrict access through least privilege and require multifactor authentication for key administration. A separate offline vault, escrow arrangement or hardware security module can keep keys outside the reach of ransomware operators who compromise the backup console.

Document key ownership, rotation schedules, recovery procedures and break-glass access. Test key retrieval during every major restore exercise because a key that exists in a policy document but cannot be accessed during an incident is operationally unavailable. Keep recovery instructions in an offline format and divide approval responsibilities so one account cannot export keys, delete backups and authorize restoration.

Assume the backup administrator can be compromised. Maintain separate daily-use and privileged accounts, and prohibit routine email and web browsing from privileged administration workstations. Alert on new administrators, privilege escalation, disabled logging, mass deletion requests, retention changes and unusual restore activity. Review service-provider access against the same standard.

Contracts should define response times, emergency contacts, evidence preservation, key custody, restoration responsibilities and procedures for provider unavailability.

If the backup administrator is suspected of compromise, freeze destructive actions, revoke active sessions, disable affected credentials and move recovery operations to preapproved clean accounts. If the provider cannot respond, activate the secondary contact and internal runbook. Retrieve the offline copy and keys through the documented break-glass process, and record every action for incident response and legal review. Recovery depends on trusted access as much as stored data.

5. Close the Loop With Recurring Exercises

Finish each validation cycle by ranking failed controls according to business impact and assigning a remediation deadline. Repeat the restore after corrections, preserve the results and update recovery time estimates based on observed performance. Test after major infrastructure changes, provider migrations, key rotations, retention-policy changes and administrator turnover.

The strongest ransomware recovery checklist ends with evidence that a clean team can restore prioritized services without relying on one person, one console or one provider. That evidence gives incident responders a trusted recovery path while they isolate infected systems and preserve forensic evidence.

7. Build a Clean Recovery Environment for a Ransomware Recovery Checklist

A ransomware recovery checklist should treat the recovery environment as untrusted until the organization proves otherwise. Choose a clean room, quarantined VLAN, isolated recovery network, cloud recovery account, or alternate site based on the compromise scope, recovery priority, and confidence in existing infrastructure. Rebuild from verified images, validate every control before reconnecting systems, and keep restored assets separated until monitoring shows that persistence and unauthorized access are gone.

1. Choose the Recovery Environment That Matches the Compromise

The recovery environment is the controlled location where systems are rebuilt, tested, and restored before returning to production. The right choice depends on whether the cyberattack affected endpoints, servers, identity systems, virtualization platforms, cloud accounts, network controls, or facilities.

A clean room is a physically or logically separate environment built from trusted hardware, fresh operating systems, verified software, and independent administrative credentials. Use it when the production network, domain controllers, virtualization layer, or administrative accounts are compromised. A clean room provides the strongest separation, but it requires more time and equipment to assemble.

A quarantined VLAN works when the core network remains trustworthy and the organization can enforce strict segmentation. Place rebuilt systems in a dedicated VLAN with deny-by-default firewall rules, restricted routing, separate administrative access, and tightly controlled connections to backup repositories. A new subnet is not automatically clean. Validate the switches, firewalls, routing policies, identity controls, and administrator accounts that govern it.

An isolated recovery network is broader than a single VLAN. It can include separate switching, routing, DNS, directory services, storage, and management systems. Choose it when multiple production subnets are affected or when the existing network controls cannot be trusted. Allow communication only with approved backup sources, update repositories, forensic tools, and essential business dependencies.

A cloud recovery account is appropriate when on-premises infrastructure is damaged but the organization can establish a separate tenant, subscription, project, or account with independent credentials and billing controls. Do not recover into the same cloud account if its administrators, identity provider, network policies, keys, or audit logs could have been altered. Create new administrative identities, require phishing-resistant multifactor authentication, and restrict cross-account access until investigators clear the original environment.

An alternate site provides physical and operational separation when the primary facility, data center, or network cannot support safe recovery. It is useful for organizations that must maintain critical services while forensic work continues. Before using it, confirm that the site does not share compromised VPN credentials, privileged accounts, management tools, backup credentials, or network tunnels with the affected location.

2. Establish Trusted Foundations Before Restoring Workloads

A trusted foundation determines whether every later recovery decision is reliable. Start with hardware and firmware before application data, because a compromised boot chain or management interface can reinfect a system before endpoint protections load.

Verify the hardware inventory, asset identifiers, storage devices, hypervisors, and management controllers. Validate BIOS and UEFI versions against vendor-approved releases, restore secure boot settings, and review the boot order for unauthorized devices. Where supported, confirm trusted platform module status and attestation results. Replace or re-flash unverifiable firmware from a trusted source before the system enters the recovery network.

Build operating systems from cryptographically verified installation media or approved golden images. Confirm image hashes, build versions, patch levels, installed packages, startup services, scheduled tasks, local accounts, and administrative group membership. Do not import unknown drivers, scripts, plugins, certificates, or agent installers from compromised systems. Download required software through a trusted channel and record the version and source for each rebuild.

Recreate identity services carefully. Establish separate recovery administrators, rotate privileged credentials, and avoid accounts that existed during the intrusion until investigators clear them. Review directory synchronization, federation, service principals, API keys, access tokens, machine accounts, and secrets stored in automation systems. A clean server joined to a compromised domain is not a clean system.

Network policy requires the same discipline. Validate access-control lists, security groups, route tables, network security groups, firewall rules, proxy settings, DNS zones, remote-access policies, and load-balancer controls. Remove broad rules created during the incident, block unnecessary east-west traffic, and require a business reason for every connection. Enable logging before workloads communicate so the recovery team can see unexpected authentication, process, and network activity.

Install and validate endpoint protections before restoring data. Confirm that antimalware, endpoint detection and response, host firewalls, application control, vulnerability scanning, centralized logging, and time synchronization are active and reporting to trusted consoles. Test alerts using approved methods. A green dashboard is not proof of protection if the agent is misconfigured, the console is compromised, or logs are not reaching an independent destination.

3. Decide When to Rebuild and When to Clean

Cleaning an infected system preserves speed but also preserves uncertainty. Rebuild a compromised system when the cyberattacker obtained root or administrator access, stole credentials, established persistence, or altered security tools. The same applies when the intruder modified boot components, tampered with logs, or left the full scope of compromise unknown.

Rebuilding is also appropriate when forensic evidence cannot establish which files, services, accounts, scheduled tasks, registry entries, containers, or management agents changed. Persistence can hide in firmware, startup configuration, privileged identity systems, remote-management tools, cloud roles, and legitimate administrative utilities that routine malware scans do not inspect.

Do not rebuild blindly. Preserve representative disk images, memory captures, relevant logs, ransom notes, malware samples, and cloud snapshots before wiping systems, unless continued operation creates an immediate safety or spread risk. This evidence supports root-cause analysis, notification decisions, threat hunting, and validation that the rebuilt environment no longer contains the cyberattacker's access.

Use a rebuild-versus-clean decision record for each asset. Document the system’s business priority, compromise indicators, evidence status, recovery source, assigned owner, rebuild date, image version, credential-reset status, and validation results. Systems with confirmed limited exposure and intact integrity controls can sometimes be cleaned under incident-response direction. Systems with persistence, credential theft, privileged access, or evidence uncertainty should be rebuilt.

4. Restore From Verified Images and Controlled Data Sources

Restoration should begin with the smallest critical foundation that supports the next dependency. Rebuild identity, core networking, security monitoring, storage, and management services before application servers or user endpoints. Follow the predefined recovery priority, because the order shown in the backup console has no relationship to business criticality.

Use verified golden images created before the incident, scanned, versioned, and protected from unauthorized modification. Validate the operating system, applications, patches, configuration baseline, certificates, endpoint agent, logging settings, and administrative groups before deployment. If an image contains unknown credentials, embedded scripts, stale keys, or undocumented software, quarantine it for review before any team treats it as a trusted baseline.

Restore data from offline, encrypted, or otherwise protected backups only after confirming the backup date and integrity. Check whether the backup predates the cyberattacker's earliest known access, and treat the encryption event as a later marker. Scan restored data in the recovery environment, inspect executable content and macros, and validate database consistency before applications consume it.

NIST Special Publication 800-61 Revision 3, published in 2025, places clean-backup restoration and system rebuilding within recovery activities. Apply that guidance by testing restored workloads with representative transactions, monitoring authentication and network behavior, and requiring explicit approval before production reconnection.

Use a staged release model in the recovery checklist. Restore one service, validate it, observe it, and add the next dependency only after the evidence supports release. This exposes reinfection or configuration problems while the recovery footprint remains small.

5. Use Cloud Recovery and Infrastructure as Code to Control Drift

Cloud recovery fails when teams recreate infrastructure manually under pressure. Manual changes introduce inconsistent permissions, missing logs, exposed services, and undocumented exceptions that become future attack paths.

Store infrastructure-as-code templates in a version-controlled repository with protected branches, signed commits where available, independent review, and offline or separately protected copies. Templates should define networks, subnets, routing, security groups, firewall rules, identity roles, encryption settings, logging, backup policies, endpoint agents, and monitoring integrations. Scan templates before deployment and compare the deployed environment with the approved configuration.

Create a new cloud recovery account or subscription when the original account’s trust boundary is uncertain. Use separate break-glass credentials, restrict them to emergency use, and record every action. Establish deny-by-default service-control policies, block public exposure unless required, and prevent recovery administrators from deleting logs, weakening security groups, disabling backup protections, or changing key policies without independent approval.

After deployment, compare actual resources with the template and investigate every difference. Configuration drift is a security risk during ransomware recovery. An untracked firewall rule, permissive security group, altered access-control list, or newly created privileged role can reopen the path the cyberattacker used.

6. Validate the Environment Before Reconnecting Production

A recovery environment is ready only when technical controls and investigative findings agree. Confirm that every rebuilt system has an approved image, current patches, validated BIOS or UEFI, trusted firmware, and functioning endpoint protections. Verify centralized logs, correct time settings, restricted privileges, and documented network paths.

Test authentication with newly issued accounts, verify that old credentials and tokens fail, and review privileged access for unnecessary memberships. Validate backups through a controlled restore test. Confirm that firewall rules, access-control lists, security groups, DNS, proxy policies, and endpoint controls enforce the intended boundaries. Run vulnerability and configuration assessments against the rebuilt environment, then conduct threat hunting across authentication, process, DNS, cloud, and network telemetry.

Reconnect systems in priority order while maintaining quarantine controls around each release group. Keep heightened monitoring in place after restoration and define the evidence required to declare the incident over. A system is not recovered because it boots or users can log in. It is recovered when the organization can explain what was rebuilt, why it is trusted, how it is protected, and which signals would reveal renewed compromise.

8. Prioritize Restoration and Prove Systems Are Safe to Return to Production

A ransomware recovery checklist must restore services that protect life, sustain public operations, meet legal duties and preserve revenue. It must also prove that each system is safe and usable before reconnection. Build the sequence around business impact, dependencies, recovery-time objectives (RTOs) and recovery-point objectives (RPOs). The order in which systems were encrypted carries no weight in that decision.

Treat every restored service as untrusted until its data, identity controls, application behavior and monitoring pass documented exit criteria. Recovery is complete only when employees, customers and critical operations can rely on the service without reopening the cyberattacker's path.

1. Rank Restoration Tiers by Consequence and Dependency

Use a decision framework that the incident team can apply under pressure. Rank services by the harm caused by continued unavailability, their legal obligations and the systems they require. A hospital’s clinical systems, a utility’s operational technology (OT), emergency communications and public safety services generally outrank internal collaboration tools.

Revenue-generating platforms, payment processing, customer support and systems tied to contractual service-level agreements follow according to financial and customer impact. A service with a safety implication, contractual uptime requirement or major downstream dependency requires a documented decision from business and legal owners. An informal technical preference is insufficient.

Legal obligations can change the order. Systems supporting regulated records, breach notification, payroll, financial reporting or evidence preservation may require immediate access even when they do not generate revenue. Record the business owner, technical owner, approved recovery point, dependencies, validation method and rollback authority for every tier.

Use RTO to state how quickly a service must return and RPO to state how much data loss the business can accept. A critical payment system with a two-hour RTO and a 15-minute RPO requires a different restoration path from an archive with a 72-hour RTO and a 24-hour RPO.

The CISA #StopRansomware Guide recommends prioritizing critical systems through a predefined asset list that accounts for health, safety, revenue and essential services. Turn that guidance into a recovery board with authority to pause restoration when evidence, identity controls or dependency testing remain incomplete.

2. Restore in Dependency Order Before Application Order

A service is not recovered when its interface loads but its identity, database, messaging, storage or network dependencies remain unreliable. Map every application to authentication providers, domain services, key management, DNS, certificates, APIs, queues, file shares, databases, third-party connections and OT controllers.

Restore foundational services required by multiple higher-tier applications while keeping them isolated from unvalidated production networks. A dependency map prevents teams from declaring an application operational when a compromised identity provider, certificate authority or database can still interrupt it or reintroduce cyberattacker access.

Start with clean infrastructure, golden images or known-good templates. Recover individual files when specific records or user documents are needed. Rebuild compromised operating systems and application hosts, because infected installations cannot be trusted. Restore databases in a controlled environment and preserve original copies for investigation.

Do not allow recovered data to overwrite the only remaining evidence or destroy a later recovery point. The recovery environment must support business restoration and forensic investigation without forcing one objective to compromise the other.

Validate the selected backup before broad restoration. Confirm its creation time, retention status, chain of custody, encryption state and relationship to the intrusion timeline. A backup created after cyberattacker access, privilege escalation or destructive activity is not automatically trustworthy.

Compare multiple recovery points when the compromise window is uncertain, and document why the selected point is sufficiently clean. NIST Special Publication 800-61 Revision 3 directs organizations to restore from clean backups, rebuild systems when necessary and monitor restored systems during recovery.

3. Test Applications and Prove Recovered Data Is Business-Accurate

Malware-free does not mean production-ready. Recovered data must be complete, usable, internally consistent and accurate for the business process it supports. A database can pass an antivirus scan while missing transactions, duplicating records, breaking relationships or failing to reconcile with a general ledger.

A file share can open documents while silently losing permissions, version history or required metadata. Test the recovered service at four levels:

• File integrity: Check expected directories, record counts, hashes, timestamps, permissions, ownership and representative documents.
• Application behavior: Test login, search, create, update, export, billing, approval and reporting functions.
• Business reconciliation: Compare transaction totals, inventory counts, customer records, payroll outputs and operational readings against independent sources.
• User acceptance: Have the employees who perform the real work complete representative tasks and document defects.

Identity and access validation must run alongside application testing. Reset affected credentials, rotate secrets and tokens, revoke suspicious sessions, verify privileged groups and confirm that service accounts hold only required permissions.

Test multifactor authentication, conditional access, certificate chains and break-glass accounts. A restored application that authenticates through a compromised identity provider reopens the path into the environment.

Make failover testing explicit. Shift traffic to the restored instance or secondary site, confirm replication direction, validate queue behavior and test the return path. Confirm that backups, logging, alerting, endpoint controls and administrative access work in the recovery environment.

Keep the recovered service segmented until these tests pass and an accountable owner signs the result. Technical availability without trustworthy identity, data and monitoring creates the appearance of recovery while preserving the conditions for reinfection.

4. Establish Production Re-Entry Gates Before Reconnecting

Production re-entry requires written gates, because confidence based on elapsed time proves nothing. The incident commander, system owner, security lead and business owner should approve the release together. For safety-critical OT or public services, include engineering, safety and regulatory stakeholders before changing operating modes.

The approval record should identify test evidence, unresolved defects, compensating controls and the person authorized to roll back. Use this restoration gate checklist:

• The compromise scope and likely persistence mechanisms have been investigated.
• The restored host, image or cloud resource came from an approved clean source.
• Required patches, configuration changes and hardening controls are complete.
• Data is complete, readable, reconciled and accepted by the business owner.
• Identity, privileged access, secrets, certificates and service accounts have been reviewed.
• Dependencies, integrations, failover and recovery procedures have passed testing.
• Logging, alerting, backups and time synchronization are operating.
• Legal, regulatory, customer and contractual notifications are assigned or complete.
• Users have completed acceptance testing and know how to report abnormal behavior.
• A rollback point, rollback procedure and decision deadline are documented.

Rollback criteria must be measurable. Stop or reverse re-entry if new privileged accounts appear, authentication anomalies exceed the incident baseline, or unknown binaries execute. The same applies when unexpected outbound traffic emerges, integrity checks fail, transaction reconciliation breaks, customer errors exceed the agreed threshold or monitoring stops reporting.

Do not keep a failing service online to protect an arbitrary restoration milestone. A controlled rollback preserves evidence, limits blast radius and gives the recovery team a defined path back to a known-good state.

5. Monitor Intensely After Re-Entry and Define the Exit Point

Re-entry starts the highest-risk observation period. Apply heightened monitoring to authentication, privilege changes, endpoint execution, administrative tools, data access, outbound transfers, backup activity, application errors and business transactions.

Compare activity with the pre-incident baseline and behavior observed during clean-room testing. Keep recovery logs, evidence and approvals together so investigators can connect a new signal to the original incident.

Define heightened monitoring before production access resumes. A practical exit standard requires all critical services to meet their RTO and RPO commitments and complete business reconciliation with no unexplained material variance. Security telemetry must remain uninterrupted, scheduled backup verification must pass, and no confirmed persistence or unauthorized privileged activity can remain. Services should also operate without critical defects for a period approved by the incident commander and business owners.

The observation period should reflect the service’s risk and transaction cycle, such as a full payroll run, billing cycle, clinical shift or operational production cycle. If the service cannot complete that cycle with trustworthy data and uninterrupted monitoring, it has not reached a stable operating state.

Close the recovery phase only after the exit criteria are met. Preserve the recovery environment and evidence, record lessons learned and update asset tiering, dependency maps, RTOs, RPOs and restoration tests. A ransomware recovery checklist succeeds when systems become trustworthy enough for people and critical operations to rely on again.

9. Ransomware Recovery Checklist: Manage Communications, Notifications, Insurance, and Ransom Decisions

A ransomware recovery checklist must compare controlled restoration with ransom payment before pressure turns an incident into an irreversible decision. Restoration keeps the organization focused on clean backups, rebuilt systems, and verified operations, while payment transfers control to a cyberattacker. Payment can create legal, sanctions, insurance, ethical, and operational exposure without guaranteeing decryption or deletion of stolen data.

Negotiation can buy time or provide intelligence, but it does not replace evidence preservation, containment, or recovery testing. The decision depends on verified recovery capability, public-service impact, data exposure, legal advice, insurer requirements, and the organization’s duty to affected people.

How Should Crisis Communications Compare With Silence or Speculation?

Crisis communications should provide verified facts, clear instructions, and regular updates. Silence, blame, and speculation all deepen the damage. Activate one communications lead and one approval chain for internal stakeholders, executives, the board, employees, customers, suppliers, regulators, law enforcement, cyber insurers, and incident-response counsel. Give each audience the information needed to act while keeping the underlying facts consistent.

Use an incident log to record what is known, what remains unconfirmed, who approved each statement, when it was issued, and which audiences received it. Tell employees how to report suspicious messages, where to obtain approved updates, and whether systems or facilities are unavailable. Explain how to work safely without creating new accounts or transferring data through unapproved channels.

Customer and supplier communications should explain service impacts, alternative contact methods, authentication changes, delayed transactions, and the time of the next update. If public services, clinical operations, emergency functions, education, transportation, or essential supplies are affected, prioritize continuity instructions over reputational language. Provide captions, screen-reader-compatible documents, translated notices, relay-accessible support, and phone alternatives for people who cannot use the affected digital channel.

Do not confirm data theft until forensic evidence supports that conclusion, and do not conceal a credible exposure while waiting for perfect certainty. State what happened, which systems are affected, what the investigation has confirmed, what remains under review, and what recipients should do now. If personal, financial, health, employee, credential, or payment data could be involved, route the assessment through counsel and privacy specialists before issuing individualized notices.

The CISA #StopRansomware Guide recommends maintaining and exercising an incident response plan with an associated communications and notification plan. That practice turns communications from an improvised public-relations task into an operational control, especially when technical uncertainty and public pressure rise together.

How Should Organizations Assess Legal, Regulatory, and Insurance Duties?

Legal and regulatory assessment should begin as soon as the organization identifies a credible compromise, because notification deadlines and contractual duties can run before the technical investigation is complete. Incident-response counsel should coordinate privacy, employment, sector, consumer-protection, securities, and cross-border analysis while forensic teams preserve evidence. The assessment should identify whose information was exposed, where those people live, and what data fields were affected.

The assessment should also determine whether encryption protected the data, and whether cyberattackers accessed or exfiltrated it.

Review obligations for personal, financial, and health information separately. Health records can trigger health privacy and breach-notification rules, while payment information can activate card-network, bank, and contractual requirements. The Federal Trade Commission's 2024 Health Breach Notification Rule expanded the federal framework for certain breaches involving personal health records. Early data classification is therefore essential for organizations outside traditional clinical settings.

Notify law enforcement through the appropriate channel and preserve ransom notes, wallet addresses, chat transcripts, malware samples, logs, forensic images, and negotiation records. Inform the cyber insurer before engaging vendors or making material recovery commitments when the policy requires prior consent. Confirm coverage for business interruption, forensic work, restoration, notification, public relations, legal services, ransom payments, and extortion negotiations. Record every approval, denial, deadline, and recommendation in the incident file.

How Do Ransom Payment and Recovery Alternatives Compare?

Ransom payment is an exceptional decision that no organization should treat as a recovery plan. Before anyone authorizes it, counsel should assess sanctions exposure and the recipient's identity or likely affiliation, and finance leaders should model the total cost. The insurer should confirm coverage and approval, technical teams should test whether the offered decryptor works, and executives or the board should document the business and ethical rationale.

Payment can fund further cyberattacks, create reporting duties, expose the organization to sanctions risk, and leave stolen data in a cyberattacker's possession.

Compare the available paths using verified evidence:

• Restore: Recover from clean, offline, or otherwise protected backups, rebuild compromised systems, rotate credentials, and validate business processes before reconnecting users.
• Negotiate: Use a qualified incident-response negotiator to slow decision pressure, obtain proof of decryption capability, clarify data claims, and gather intelligence without promising payment.
• Decrypt: Test a reputable, independently verified decryptor against forensic copies. Never run an untested tool against original evidence or assume a decryptor will restore databases, cloud systems, or damaged files.
• Rebuild: Reimage or replace compromised infrastructure when trust in the environment is lost, then restore only validated data and applications in a controlled sequence.
• Pay: Consider payment only after legal, sanctions, insurance, operational, financial, and ethical review, with written executive approval and a documented fallback if the cyberattacker fails to deliver.

CISA and federal partners state that ransom payment does not guarantee file recovery. Those agencies do not recommend paying ransom as a default response, as reflected in this advisory. Preserve the approval record even when the decision is to pay, including alternatives considered, recovery estimates, sanctions screening, insurer guidance, negotiation activity, payment authorization, and post-payment validation.

What Should Happen Before Communications Resume?

Communications should continue throughout restoration, including the period when systems begin returning online. Set update intervals, publish a single source of truth, and correct errors transparently with the date and reason for each correction. Customer support should use scripts that avoid speculation and escalate identity-theft or safety concerns. Those scripts should provide practical steps such as credential resets, fraud monitoring, or alternate service access.

Close the recovery process only after leaders confirm that notification duties are complete, affected audiences received accessible information, and insurers and regulators have the required records. The board must also understand residual risk. Feed lessons from the incident into board-ready security reporting so recovery performance, communication gaps, and human-risk signals become measurable improvements.

Recovery is complete when the organization can operate safely, explain its decisions, and support affected people without overstating what it knows.

10. Rotate Credentials, Secure Cloud Resources, and Reconnect Dependencies

A ransomware recovery checklist is incomplete until the organization assumes that credentials, tokens, keys, and trusted connections were exposed. Reset privileged access from a verified clean system, invalidate active sessions, review MFA enrollment, and rebuild external connections under least privilege. Reconnect services in controlled stages with logging, approval gates, and rollback plans so recovery does not reopen the cyberattacker's path.

Treat every restored identity as untrusted until its ownership, permissions, and activity history are verified.

1. Rebuild Privileged Credentials and Remote Access

Start with privileged identities that can change the environment. From a trusted administrative workstation or clean recovery enclave, rotate domain administrator and enterprise administrator credentials, local administrator passwords, and service-account secrets. Also rotate VPN credentials, remote-access accounts, and credentials used by backup, encryption, and recovery systems. Do not reset passwords from a potentially compromised endpoint, because malware can capture replacement credentials immediately.

Include dormant, emergency, shared, embedded, and machine-generated accounts in the reset. Disable unknown accounts, newly created administrators, unexpected delegated permissions, suspicious group memberships, and accounts without a current business owner. Review password-vault access, privileged-access-management policies, scheduled tasks, run-as configurations, scripts, and application settings for hard-coded secrets.

Cyberattackers often preserve access after encryption by changing legitimate passwords or creating new accounts. In its 2025 Ghost ransomware advisory, CISA reported that threat actors created local and domain accounts, altered existing passwords, and used credential dumping to support unauthorized access. Record each reset, approving administrator, source system, and change time so investigators can distinguish recovery activity from renewed intrusion.

Invalidate every active session, refresh token, API session, browser cookie, VPN connection, remote desktop session, and federated identity token supported by the identity provider. Revoke application passwords and personal access tokens, because a password change does not invalidate them. Re-register MFA only after confirming the user's identity through an independent channel, remove unfamiliar authenticators, and require phishing-resistant MFA for privileged and remote access where available.

2. Lock Down Cloud and SaaS Control Planes

Cloud consoles and SaaS administration panels can restore cyberattacker access even when on-premises credentials are clean. Review cloud IAM users, roles, groups, service principals, workload identities, OAuth grants, federation settings, conditional-access policies, access keys, and organization-level administrators. Remove excessive privileges, disable unused identities, rotate cloud access keys, and reissue certificates and encryption keys from trusted systems.

Inspect anomalous firewall rules, security groups, route tables, private endpoints, storage policies, exposed management ports, forwarding rules, and newly approved geographic locations. Check whether a cyberattacker weakened logging, disabled alerts, changed retention periods, modified backup policies, or redirected logs externally. Preserve configuration history before changing it, because the timeline can show how access was maintained.

Use a defined access sequence for cloud recovery. Restore identity-provider controls, logging and monitoring, core infrastructure, business applications, and data services under separate approval gates. Use temporary recovery roles that expire, and avoid permanent administrator access. Require two-person approval for changes to identity, backup, encryption, firewall, and recovery controls. A human risk management program can track identity-related exposure and route targeted training after employees report suspicious reset requests.

Give backup permissions separate scrutiny. Confirm that backup operators, repositories, snapshots, replication jobs, immutable storage, and recovery consoles use credentials distinct from production administration. Test restoration with a nonproduction copy before granting broad write access. If backup credentials were present on an infected system, treat them as compromised and reissue them from a clean recovery environment.

3. Reconnect Third-Party Dependencies in Controlled Stages

Rebuild external access as deliberately as internal access. Create an inventory of managed service providers, cloud hosts, SaaS providers, payment platforms, software vendors, contractors, identity federations, remote-support tools, data exchanges, and supply-chain connections. For each dependency, identify the data it can reach, accounts it uses, network paths it requires, contract owner, and incident-notification deadline.

Notify providers and managed service providers through verified contacts. Addresses found in suspicious messages or compromised mailboxes cannot be trusted. Ask each provider to confirm whether it observed unauthorized access, reset shared credentials, invalidate sessions and tokens, review administrator activity, and preserve logs. Legal, privacy, procurement, and executive stakeholders should approve the notification sequence when obligations involve customers, regulators, insurers, payment partners, or affected data subjects.

Reconnect one dependency at a time. Begin with a low-risk service or test tenant, permit only documented ports and identities, and monitor authentication, API calls, data movement, firewall changes, and administrative actions. Keep the connection disabled between tests. Promote it to production only after the owner confirms expected behavior and the security team records a rollback method.

Every restored connection needs least-privilege permissions, a named owner, an expiration or review date, and centralized logging. Use separate integration accounts for separate vendors, restrict API scopes to required functions, and prohibit shared administrator credentials. If activity deviates from the approved baseline, revoke the connection immediately and return to the last known-good state.

Do not declare identity recovery complete when users can log in. Confirm that privileged access is limited, MFA enrollment is trustworthy, tokens are expired or reissued, and cloud controls are intact. Verify that backup permissions are isolated, third parties have acknowledged the incident, and staged reconnections remain observable. With those controls in place, the recovery team can isolate infected systems without destroying the evidence needed to explain how the intrusion persisted.

11. Close Recovery Gaps and Strengthen the Human Layer

A ransomware recovery checklist is complete only when it converts the incident into measurable improvements across people, processes and technology. Without a structured post-incident plan, an organization can restore systems while preserving the same initial access path, weak identity control or reporting delay that enabled the cyberattack. CISA recommends documenting lessons learned, testing backups and exercising response plans so recovery capability improves before another incident.

How Should the Post-Incident Review Identify Lessons Learned?

A blameless post-incident review should reconstruct the cyberattack as a system failure. Individual employees are rarely the root cause. Examine how initial access occurred, when detection began, how long containment took and which decisions increased the blast radius. Determine whether an employee reported a suspicious email, phone call or text before automated controls detected the intrusion.

Document these measures:

• Initial access vector and affected identity, device or third party
• Detection time, containment time and mean time to recover
• Restoration success by critical system, application and data set
• Data-loss window and last verified clean backup
• Coverage of critical assets, privileged accounts, remote access paths and recovery dependencies
• Corrective actions, accountable owners, due dates and completion status

Separate facts from assumptions. Preserve relevant logs, memory captures, system images and communications before changing systems. Protect recovery documentation from the same compromised identity and network controls that failed during the incident. CISA’s ransomware response guidance recommends documenting lessons learned, restoring from offline backups and securing incident-response plans in offline or hard-copy form.

Which Control Changes Should Follow the Review?

The improvement plan should turn every confirmed gap into a control change with a verification test. If phishing enabled initial access, update email reporting workflows, strengthen phishing-resistant MFA, review privileged access and add spear phishing scenarios for the targeted roles. If a phone call or text bypassed verification, add vishing and smishing simulations that rehearse callback procedures, payment approvals and identity verification under pressure.

Network and identity hardening should address the specific attack path before applying generic controls. Segment critical services, remove unnecessary remote access, enforce least privilege, separate administrator accounts from daily-use accounts and review dormant or excessive permissions. Protect backup consoles, recovery keys and documentation with separate credentials, strong authentication and offline access procedures.

Confirm that immutable or offline backups cannot be deleted by the same administrators who manage production systems.

Recovery documentation also requires protection. Keep an offline copy of the incident-response plan, asset priorities, vendor contacts, recovery dependencies and communication templates. Store a controlled hard copy where authorized responders can find it during an outage. Assign an owner to every corrective action and require evidence of completion, such as a successful restore, access review or updated network diagram.

How Should Recovery Metrics and Exercises Improve Resilience?

Metrics show whether the organization can recover under pressure. A descriptive summary of the incident offers far less value. Track detection time, containment time, mean time to recover, restoration success, data-loss window and the percentage of critical assets covered by tested backups. Report corrective-action completion separately from training completion, because a finished course does not prove that a control works.

Run recurring backup restores for priority systems, including applications with complex dependencies and data that must be reconciled after restoration. Test whether clean systems can be rebuilt on an isolated network without reintroducing compromised credentials or malware. Pair technical restore drills with tabletop exercises involving security, IT, legal, communications, finance, executives and key vendors.

CISA's Tabletop Exercise Packages provide customizable ransomware scenarios, discussion questions and after-action templates that organizations can adapt to their recovery priorities.

How Should Employee Behavior and Awareness Change After Ransomware?

Employees become a stronger detection and reporting layer when training is continuous, scenario-based and tied to observed behavior. Replace one-time ransomware awareness training with role-based microlearning triggered by real risk signals. Those signals include a missed phishing simulation, delayed reporting, an exposed open-source intelligence (OSINT) profile or repeated interaction with suspicious links. A cybersecurity awareness training program can connect those signals to targeted practice.

Connect the ransomware recovery lifecycle to cybersecurity awareness training and phishing awareness training. Finance teams should rehearse invoice fraud and business email compromise (BEC) verification. Executives should practice deepfake and voice-impersonation verification. Help desk staff should handle suspicious password-reset requests. All employees should experience spear phishing resistance drills, vishing simulations and smishing simulations.

Review results without shaming participants. Use observed behavior to refine scenarios, shorten reporting paths and deliver targeted refreshers within a human risk management program. Assign owners, set review dates and test every corrective action. Carry those findings into the organization's recovery exercises so each drill strengthens the decisions that determine whether containment holds.

Ransomware Recovery Checklist FAQs

What Is the First Step in a Ransomware Recovery Checklist After Detecting a Ransomware Attack?

The first step is to declare the incident, activate the response plan, and isolate affected systems without destroying evidence. Assign an incident commander, establish an out-of-band communication channel, record timestamps and decisions, and involve legal, forensic, and business leaders. Do not begin broad shutdowns, mass credential resets, or restoration before responders understand the scope and preserve critical evidence.

CISA's Ransomware Response Checklist directs organizations to determine impacted systems and isolate them immediately. Treat the first hour as a controlled evidence-preservation exercise. Clear ownership and a decision log prevent conflicting actions while responders determine whether the cyberattack is still spreading.

Should Affected Devices Be Powered Down if They Cannot Be Disconnected From the Network?

Power down an affected device only when it cannot be disconnected from the network and leaving it online creates a greater risk of continued encryption or spread. CISA's Ransomware Response Checklist specifically recommends powering down systems that cannot be disconnected. Before shutdown, obtain approval from the incident commander and forensic lead when feasible, because volatile memory, active processes, and network connections can contain evidence.

Capture that data first when the situation is stable and responders have the capability. For operational technology, medical equipment, or safety-critical systems, coordinate with the system owner to avoid creating physical danger while restricting connectivity through controlled isolation.

How Can Responders Tell Whether Ransomware Encrypted Data or Exfiltrated It First?

Responders can distinguish encryption from exfiltration by reconstructing a timestamped attack timeline across file, endpoint, identity, network, cloud, and backup logs. Encryption evidence includes rapid file-renaming or write activity, ransom-note creation, and processes opening large numbers of files. Exfiltration evidence includes archive creation, unusual outbound volume, access to sensitive repositories, new cloud-storage connections, and tools such as Rclone or Rsync.

CISA guidance for organizations hit by ransomware identifies common exfiltration indicators and recommends preserving evidence. Correlate process IDs, accounts, source addresses, and egress destinations. Report the sequence as confirmed, probable, or unknown, and avoid treating a ransom claim as proof.

What Is the 3-2-1-1-0 Backup Rule for Ransomware Recovery?

The 3-2-1-1-0 backup rule means keeping three copies of data on two different media types. One copy is stored offsite and one copy offline or otherwise isolated, with zero errors verified through recovery testing. The rule reduces the chance that ransomware, an administrator compromise, or a site outage will destroy every recovery option. CISA's ransomware guidance advises maintaining offline, encrypted backups and regularly testing their availability and integrity.

Apply the rule to critical systems, protect backup credentials separately, and validate restore points in an isolated environment. A successful backup job proves that data was copied. A documented test restore proves that the organization can recover.

Who Decides When a Ransomware Incident Is Contained and Recovery Is Complete?

The incident commander decides when containment is achieved, while the recovery lead recommends closure after technical and business exit criteria are met. The decision should require evidence that cyberattacker access is removed, persistence is addressed, and credentials and tokens are rotated. It should also show that affected assets are rebuilt or validated, restored data is accurate, and monitoring shows no renewed malicious activity.

Business owners must confirm that critical services operate safely, legal and communications leads must complete required notifications, and executives must accept residual risk. Record approvals, unresolved uncertainties, and heightened-monitoring results in the incident log.

Reduce Human Risk Before Ransomware Reaches the Recovery Plan

Ransomware recovery depends on detecting suspicious activity before cyberattackers gain the access and time needed to encrypt or steal data. Adaptive Security connects security awareness and human-risk signals to stronger reporting and response readiness. Take a self-guided tour of Adaptive Security's human-risk and security awareness capabilities.