Ransomware Recovery Plan: 6 Steps [Solved] 2026

Step 1: Isolate Infected Systems Immediately

The first minutes determine whether ransomware spreads across your entire network or stays contained. Disconnect network cables from infected servers and disable wireless adapters. Do not rely on software firewalls or shutdown commands—physical disconnection stops lateral movement instantly.

Keep infected machines powered on unless forensic analysis requires a memory dump. Some ransomware variants trigger additional encryption routines on shutdown or restart. In production incidents I responded to, premature reboots destroyed the last chance to capture running processes or memory-resident decryption keys.

Take photographs of ransom notes and any visible file extensions. Note the exact time you discovered the infection and which systems displayed symptoms first. This timeline becomes critical for identifying the entry point and determining which backups predate the compromise.

Step 2: Identify the Ransomware Variant

Upload a ransom note or encrypted sample file to ID Ransomware or check the No More Ransom Project database. Accurate identification determines whether free decryption tools exist and whether your backups are likely compromised. Different ransomware families exhibit different behaviors—some encrypt immediately, others exfiltrate data for weeks before locking files.

Check file extensions on encrypted files. Extensions like .locked, .crypted, or custom strings often correlate with specific ransomware families. Record the extension exactly as it appears. Search online for the extension combined with 'ransomware decryptor' to find known recovery tools.

If identification fails, assume the worst. Treat all systems on the same network segment as potentially compromised. Change credentials for any account that authenticated from infected hosts, including service accounts, database users, and admin panels.

Comparison: Backup Restoration vs Decryption vs Clean Rebuild

Backup restoration is the fastest path when backups are recent, tested, and stored offline or in immutable storage. You validate backup integrity, wipe infected systems, and restore files. This approach works best when backups are less than 24 hours old and you regularly test restore procedures. The risk is low if backups predate the infection and no backdoor persistence exists in restored data.

Decryption using free tools is viable only when trusted utilities exist for your ransomware variant. Check No More Ransom first. If a decryptor exists, test it on non-critical encrypted files before running it across production systems. Decryption leaves existing system configurations intact but cannot remove attacker backdoors or webshells. Use this method only when backup restoration is impossible and the ransomware family has a proven free decryptor.

• Backup restoration: Fast, low-risk, requires tested backups predating the infection
• Decryption: Medium speed, moderate risk of leftover backdoors, depends on tool availability
• Clean rebuild: Slow, zero persistence risk, requires fresh OS installs and data re-import

Step 3: Validate Backup Integrity on Isolated Hardware

Never restore backups directly to production without testing. Mount backup storage read-only and restore critical files to an isolated VM or spare hardware disconnected from the network. Start applications and check file contents. If files open correctly and services start, the backup is clean.

If backups contain encrypted files or configurations modified by the attacker, they are compromised. Roll back to an earlier backup set. In hosting incidents I worked, attackers often dwelled in systems for days or weeks before encrypting files, poisoning multiple backup generations. Test the oldest available backup if recent ones fail validation.

Check backup logs for authentication anomalies during the suspected infection window. If backup jobs show logins from unfamiliar IP addresses or at unusual times, attackers may have accessed backup infrastructure. In that case, treat backup credentials as compromised and rotate them immediately.

Step 4: Choose Recovery Method Based on Data Value and Tool Availability

If validated backups exist and are less than 48 hours old, wipe infected systems and restore. This is the safest and fastest option. Use fresh base OS images or reinstall from vendor ISOs to eliminate any attacker modifications to system files or boot sectors.

If no backups exist but a trusted decryptor is available for your ransomware variant, attempt decryption. Run the tool on a copy of encrypted files first. Never decrypt files in place without a backup copy. After decryption, assume the system is still compromised—immediately migrate data to clean infrastructure and decommission infected hosts.

When backups are unavailable and no decryptor exists, rebuild from scratch. Reinstall operating systems, reconfigure services from documentation, and manually recreate data that cannot be recovered. This takes the longest but guarantees attacker persistence is eliminated. For hosting environments, rebuild is often faster than negotiating with criminals or waiting for decryption tools that may never arrive.

Step 5: Restore Operations with Network Segmentation and Monitoring

Before reconnecting restored or rebuilt systems to production, change all passwords and API keys accessed from infected hosts. Enable MFA on admin accounts, hosting panels, and remote access tools. Rotate database credentials, SSH keys, and application secrets.

Scan restored systems with updated antimalware tools before allowing inbound connections. Deploy endpoint detection and response (EDR) agents if budget allows. Configure logging to capture authentication attempts, file modifications, and outbound network connections. In post-recovery monitoring, watch for unusual process execution or registry changes that indicate reinfection.

Segment your network so that compromised hosts cannot reach backup storage, management interfaces, or customer environments. Place web servers in a DMZ. Restrict database access to application servers only. Use firewall rules to block unnecessary lateral movement. If attackers return, segmentation buys time to detect and respond before encryption spreads.

Step 6: Document the Incident and Update Response Procedures

Record every action taken during recovery with timestamps and command output. Save ransom notes, forensic logs, and screenshots. This documentation supports insurance claims, law enforcement investigations, and internal post-mortems. Many cyber insurance policies require detailed incident timelines to approve coverage.

After operations stabilize, conduct a post-incident review. Identify how the ransomware entered your environment—common vectors include phishing emails, unpatched vulnerabilities, exposed RDP ports, and compromised credentials. Close the entry point first. If the vector was an unpatched CMS, update it immediately. If it was weak SSH passwords, enforce key-based authentication.

Update your recovery plan based on what worked and what failed. If backup validation took too long, automate restore testing. If credential rotation caused application outages, document service account dependencies. Schedule quarterly drills where you simulate ransomware infections and practice executing your plan under time pressure. The next attack will happen—preparation determines whether you recover in hours or lose days of uptime.