Ransomware recovery: the decisions you make in the first 48 hours

Ransomware readiness is a planning exercise. Ransomware recovery is a sequence of consequential decisions made with incomplete information, under time pressure, by people who have been awake too long. Which is exactly why the decisions should be made in advance.

The first hours

1. Contain, but preserve. Isolate affected systems from the network without wiping them - you need the encrypted files and artefacts for investigation, and sometimes for decryption.
2. Protect the backups first. Attackers target them deliberately, often before triggering encryption. Verify they exist, are intact and are unreachable from compromised credentials.
3. Assume identity compromise. Reset privileged credentials and revoke sessions, on the assumption the attacker holds valid access rather than only malware.
4. Establish out-of-band communication. Email and chat may be compromised or unavailable.
5. Start the log immediately. Nobody reconstructs the timeline afterwards, and regulators, insurers and lawyers all need it.
6. Notify the insurer - policies frequently require it promptly and may mandate approved responders.

Restore or rebuild

The instinct is to restore quickly. The risk is restoring into an environment the attacker still controls, or restoring a system that was already compromised before encryption.

The safer pattern is to rebuild the identity and management layer first, into a clean environment, then restore data into it. That is slower and it is the difference between recovery and re-infection. Dwell time is frequently weeks, so backups from before the intrusion - not merely before the encryption - may be what you need.

This is why retention length matters as much as backup frequency. If dwell time was six weeks and you retain four, every copy you hold may already contain the attacker.

The payment decision

Not primarily a technical question. The considerations:

• Legality. Payment may be unlawful depending on the party involved and sanctions exposure. This is a legal determination, not a commercial one, and it must be checked before any payment is contemplated.
• Decryption is unreliable. Tools supplied after payment are frequently slow, partial or buggy. Payment does not guarantee recovery.
• Data publication. Under double extortion, payment buys a promise not to publish - from a party whose business model is dishonesty.
• It marks you. Organisations that pay are disproportionately targeted again.

Decide your position in principle in advance, with legal and the board. Deciding under pressure, with operations down and revenue stopped, is how organisations pay against their own policy.

Double extortion changes the calculus

Where data was exfiltrated, this is a breach regardless of whether you restore successfully. Notification obligations, customer commitments and regulatory clocks all apply, and they are unaffected by paying. Treat exfiltration as a separate workstream from encryption from the outset - establishing what left is often harder than restoring what was encrypted.

Communications

Prepare holding statements in advance. Say what you know, avoid speculating on cause or attribution, give a next-update time and honour it. Silence is filled by customers, journalists and the attacker - and attackers increasingly contact customers directly to increase pressure, so your customers may hear from them before they hear from you.

Returning to operation

Define what "recovered" means before declaring it: systems restored and verified clean, credentials rotated, the entry vector closed, monitoring in place for re-entry, and data integrity checked. Reinfection after a premature all-clear is common and considerably worse the second time.

Key takeaways

• Protect backups first - attackers target them before encrypting.
• Rebuild identity into a clean environment before restoring data.
• Retention must predate the intrusion, not the encryption.
• Decide the payment position in advance, with legal and the board.