Ransomware defence: the controls that actually change outcomes
Ransomware response is decided long before the ransom note appears. What separates a bad week from an existential event is preparation.

Ransomware outcomes vary enormously between organisations of similar size in the same sector hit by the same group. One is trading normally within days. Another spends months in recovery, or does not recover. The difference is almost never the sophistication of the attack. It is what was in place beforehand.
How intrusions actually begin
The entry points are consistently mundane:
- Phishing delivering a loader, still the most common initial vector.
- Exposed remote access — RDP or VPN reachable from the internet, protected by a password alone.
- Unpatched internet-facing services, often exploited within days of a public advisory.
- Compromised suppliers with legitimate access into your environment.
Note what is absent: novel exploits and zero-days. Those exist but they are not what is affecting most organisations.
The dwell time you can use
Between initial access and encryption there is typically a period of days to weeks. The attacker is mapping the network, escalating privilege, locating backups, and — critically — exfiltrating data for the extortion leverage that now accompanies nearly every campaign.
That window is your opportunity. Detection during this phase is entirely achievable, because the activity is noisy: credential dumping, unusual administrative authentication, mass file access, large outbound transfers, and the disabling of security tooling.
Organisations that catch ransomware before encryption almost always catch it here.
Prevention worth the effort
Phishing-resistant MFA on all remote access. Hardware keys or passkeys. This alone removes the two most common entry vectors, because a phished credential is useless without the key.
No internet-facing RDP. Ever. If remote access is needed, put it behind a VPN with strong authentication, or an identity-aware proxy.
Patch internet-facing services urgently. Internal patching can follow a normal cycle. Anything internet-facing with a published exploit should be measured in days.
Remove standing administrative privilege. Ransomware needs privilege to spread. Just-in-time elevation limits what a compromised account can reach at any given moment.
Application control on endpoints. Restricting what can execute stops a large share of loaders before anything else happens.
Backups that survive the attack
This is the control that most often determines the outcome, and it is where assumptions go wrong.
Modern ransomware groups specifically target backups. They look for backup servers, they find the credentials, and they destroy or encrypt the backups before triggering the main event. A backup reachable from the production domain with domain credentials should be assumed lost.
What actually works:
- Immutable or air-gapped copies. Write-once storage, or offline media. Something the attacker cannot delete even with full domain administrative access.
- Separate authentication. Backup infrastructure must not be reachable with production credentials.
- Tested restores. Not "the backup job reported success" — an actual restore of an actual system, on a schedule. Untested backups fail at exactly the wrong moment with dispiriting regularity.
- Restore time you have measured. If full recovery takes three weeks and the business can tolerate three days, you do not have a working recovery plan. Knowing this before the incident lets you fix it.
Assume the data left
Exfiltration is now standard. Even a flawless restore does not resolve the extortion, because the attacker still holds your data and will publish it.
This means:
- Reducing what you retain limits what can be taken. Old data you no longer need is pure liability.
- Encrypting sensitive data at rest with properly managed keys reduces the value of what is stolen.
- Egress monitoring is one of the few controls that detects this phase directly.
- Your incident plan needs a communications and regulatory track, not just a technical one.
The plan, and rehearsing it
Write down, in advance: who declares an incident, who can authorise disconnecting systems, who contacts your insurer, your regulator, your customers, and your legal counsel. Keep it printed and stored offline — plans stored only on the network being encrypted have proven unhelpful.
Then rehearse it. A tabletop exercise where the team walks through a realistic scenario reliably surfaces problems: nobody knows who authorises a shutdown, contact details are stale, the recovery runbook assumes a system that no longer exists. Finding these during an exercise costs an afternoon.
Paying
This is a business decision with legal dimensions, made under pressure with incomplete information. Points worth knowing beforehand: decryption tools supplied by attackers are frequently slow and imperfect; payment does not prevent publication; and in some jurisdictions payment to sanctioned entities carries legal consequence.
Organisations with tested, immutable backups and a rehearsed plan rarely need to have this conversation seriously. That is the real argument for the investment.
Where to start
If you do three things: phishing-resistant MFA on remote access, one immutable backup copy the production domain cannot touch, and a tested restore of your most critical system. Those three change outcomes more than any product you could buy this quarter.