The Ransomware Readiness Gap Most Plans Don't Test For

Ransomware is malicious software that encrypts an organization's files, servers, and systems, then demands payment, usually in cryptocurrency, in exchange for restoring access. It has been one of the most disruptive categories of cyberattack for the past decade, and it doesn't stay contained to a screen: it has shut down hospitals, pipelines, city governments, and manufacturing lines, sometimes for days or weeks at a time.

Ask most security teams what "ransomware readiness" means, and the answer is technical: how fast can we restore from backup, how isolated are our recovery systems, how current is our incident response runbook. Those are real questions, and they matter. But they all assume the same starting point, that the attacker is already inside. They say little about how the attacker got there in the first place.

What ransomware readiness usually tests, and what it skips

A typical ransomware readiness program centers on the technical middle and end of an attack: backup frequency, recovery point objectives, network segmentation, and tabletop exercises that simulate restoring operations after systems go down. These exercises are useful. They are also incomplete, because they start the clock after access has already been gained.

The entry point into most ransomware incidents isn't a vulnerability scan finding an unpatched server. Increasingly, it's a conversation. Attackers targeting large organizations have shifted toward identity-based intrusion: convincing a real person, usually IT support staff, that they are someone they're not, and getting that person to hand over access voluntarily.

Modern ransomware attacks also rarely stop at encryption. Most now involve double extortion: attackers copy sensitive data out of the network before locking it, so paying for a decryption key doesn't guarantee the stolen data won't surface anyway. That second layer raises the stakes of the initial access decision even further, because by the time encryption is visible, the data may already be gone.

The ten-minute call that cost $100 million

In September 2023, MGM Resorts disclosed a cyberattack that, according to the company's own SEC filing, cost an estimated $100 million. The attack shut down slot machines, hotel key card systems, reservation platforms, and payment systems across MGM's properties for days.

The attack didn't start with malware. According to security researchers who reconstructed the incident, a member of the threat group tracked as Scattered Spider found a real MGM employee's profile on LinkedIn, used that information to convincingly impersonate them, and called MGM's IT helpdesk asking for help logging in. The call lasted about ten minutes. It ended with the attacker holding administrator-level access to MGM's identity system, which is what allowed the group to move through the network and ultimately deploy ransomware.

Nothing about that call would have shown up in a vulnerability scan. It wasn't a technical failure. It was a verification failure: a helpdesk process built to be helpful, not built to confirm identity under pressure. Helpdesk social engineering has become one of the most common ransomware attack vectors precisely because it targets a process designed to grant access quickly, not to question it.

The gap between access and impact is getting shorter, not longer

The MGM case is now a few years old, but the tactic it exposed hasn't slowed down, it has accelerated. Mandiant's M-Trends 2026 report, based on the firm's own incident response investigations, documents a threat actor tracked as UNC6692 impersonating IT helpdesk staff over Microsoft Teams to gain initial access, then handing that access off to a second group for ransomware deployment. The median time between that initial access and the hand-off to deploy ransomware has dropped from more than eight hours to as little as 22 seconds.

That number matters more than it looks. A readiness plan that assumes hours between intrusion and impact, time to detect unusual activity, time to isolate a compromised account, is being tested against a timeline that increasingly no longer exists. When the gap closes to seconds, the moment that determines the outcome isn't the response after access is gained. It's whether access is granted in the first place.

Key insight: the readiness gap is before the breach, not after it

Ransomware readiness has been defined almost entirely around recovery: how fast can the organization get back to zero once it's already been hit. That is necessary, but it treats the human moment before the breach, the phone call, the Teams message, the request that sounds credible enough, as outside the scope of preparedness.

The MGM case and the pattern Mandiant documents in 2026 both argue otherwise. They start at the same point: a person deciding, in real time, whether the person on the other end of a conversation is who they claim to be. A backup strategy tested to the hour is still exposed if that decision is never tested at all.

What this means in practice

A ransomware readiness program built only around backup testing and recovery drills is testing half the problem. The other half is whether IT support staff, and employees more broadly, can recognize a convincing impersonation attempt under normal working pressure, not in a scenario they know is a test.

That requires the same kind of realistic, multi-channel testing that made the MGM case possible for attackers in the first place: a scenario that combines a plausible pretext with a specific channel, phone, chat, video, rather than a single generic phishing email. Simulating that combination, the way an actual social engineering attempt unfolds across channels, is precisely the kind of testing most annual security awareness calendars don't include.

None of this replaces backup testing, network segmentation, or incident response planning. It changes what "ready" means: not only how fast an organization can recover, but whether the specific conversation that led to MGM's ten-minute breach would succeed against its own helpdesk today.

The technical playbook for ransomware, encrypt, demand payment, negotiate or restore, has stayed fairly stable for years. What has changed is how fast attackers can reach the point where that playbook starts, and how little of that path still runs through code.

The organizations that test the phone call, not only the recovery plan, are the ones that will find out where they stand before an attacker does.