When Ransomware Lands: The Decisions That Matter in the First 48 Hours

The discovery usually happens in the middle of the night. A monitoring alert fires, or an operations team member notices the file servers are behaving strangely, or someone tries to open a document and gets an error, and then notices that every file in the directory has been renamed with an unfamiliar extension.

You are now in the first hour of a ransomware incident. The decisions you make in the next 48 hours will determine whether this is a recoverable event or a company-defining one. Most of those decisions are ones your organization has not thought through yet, because thinking through them in advance requires imagining a scenario that nobody wants to fully picture.

Here is what you are actually deciding, and in what order.

Isolate First, Investigate Second

The question in the first minutes is whether to disconnect affected systems. Unlike many other incident types, ransomware has a clearer containment answer: yes, quickly, but with a checklist.

Disconnecting an actively encrypting system stops the encryption process on that machine and prevents it from spreading further across network shares. What you lose is volatile memory, which may contain decryption keys if the ransomware is still active, along with forensic artifacts that live only in RAM. In most ransomware incidents, this tradeoff favors isolation. The encryption keys in RAM are rarely recoverable in a useful way, and spread is the more immediate threat.

What you should not do is power systems off completely before imaging them. There is a meaningful difference between isolating a system from the network (pull the cable, disable wireless, block at the switch) and powering it down. Powered-off systems lose volatile evidence. Depending on the variant, some ransomware operators have deployed wiper components that trigger on shutdown. Isolate first, image later, shut down only when you have captured what you need.

The Backup Question Changes Everything

Before any conversation about paying a ransom occurs, you need to know the actual state of your backups. Not the theoretical state. Not "we have backups" - the actual, tested, verified, offline status of your backup infrastructure.

Ransomware operators know that backups are the defense. Modern ransomware operations spend time in target environments before encrypting anything. During that dwell time, which averages weeks in enterprise environments, they find the backup infrastructure and encrypt or delete it first. The ransom demand appears only after the backups are neutralized.

If your backups are stored on network-attached storage that the compromised accounts could reach, assume they are gone. If your cloud backup solution was accessible from the compromised environment, verify it before assuming it is intact. "We have backups" and "our backups survived this specific attack" are different statements, and every decision that follows depends on which one is actually true.

Tested, verified, offline backups that survived the attack change the decision tree entirely. You are now in a recovery operation, not a ransom negotiation. Painful and slow, but recoverable without paying.

The Identity Question: Does It Actually Matter?

Ransomware variants are often attributed to specific criminal organizations, some of which operate under sanctions that make payment legally problematic. The FBI maintains guidance. Your outside counsel should be involved early specifically to assess whether payment is even permissible given the variant you are dealing with.

Beyond the legal question, the identity of your attacker affects the reliability of the decryption keys you would receive if you paid. Established ransomware operations have a business incentive to actually provide working keys. Their model depends on victims believing that payment produces results. Newer or less organized actors sometimes cannot or will not deliver working decryptors regardless of payment.

Neither scenario is good. One is just marginally less bad.

What the Pay/Don't-Pay Decision Actually Involves

The ransom decision is not a security decision. It is a business continuity, legal, and financial decision that happens to require security inputs.

Security provides: what data was encrypted, what was exfiltrated (and nearly all modern ransomware operations exfiltrate before encrypting), whether backups survived, and how long recovery would take with and without the decryption key.

Finance and legal provide: what payment compliance looks like given the attacker's identity, what cyber insurance covers and what conditions apply, what the cost of downtime is per day, and what the legal exposure of paying versus not paying actually is in your specific situation.

Leadership decides. Not security. The security team's job is to give them accurate inputs, including an honest assessment of recovery timelines with working backups versus without them.

One factor that consistently gets underweighted: paying does not end the incident. You have paid people who still have copies of your data, who still know your environment, and who may sell access to other actors. The decryption key, if you receive one, decrypts the files but does not remediate the access path the attackers used. You still need to complete the full incident response: find the initial access vector, evict the attacker, rotate credentials, rebuild from known-good state. Paying buys a faster path to that work, not a shortcut past it.

The Decision That Actually Matters Most

The most important decision in a ransomware incident is not whether to pay. It is whether your organization did the preparation that makes the payment decision a real choice.

Offline backups the attacker cannot reach. An incident response retainer with a firm that has handled ransomware before, so when this happens you are not trying to find outside help under time pressure at midnight. Cyber insurance that was reviewed for ransomware coverage before you needed it, not during the claim. A pre-established decision framework that identifies who has authority to approve payment, what threshold of business impact triggers that conversation, and what legal review is required before the wire goes out.

Most organizations do not have these things in place. The ones that do are the ones where a ransomware incident is a bad week instead of an existential one.

The ransomware operators spent weeks in your environment before you knew they were there. They did their preparation. The question is whether you did yours before they arrived.