Back to blog
Security Practices

Ransomware readiness: the controls that decide the outcome

Ransomware outcomes are determined long before the ransom note. The controls that prevent it, the backup properties that survive it, and the decisions to make in advance rather than under pressure.
GRC Copilot Team
Ransomware readiness: the controls that decide the outcome

Whether ransomware is a bad week or an existential event is decided by controls you put in place months earlier. By the time a ransom note appears, the outcome is largely a function of two things: how far the attacker moved, and whether your backups survived.

How it usually happens

The pattern is remarkably consistent: initial access through phishing, exposed remote access or an unpatched internet-facing service; credential theft and privilege escalation; lateral movement over days or weeks; identification and destruction of backups; data exfiltration; then encryption. The encryption is the last step - which means every earlier stage was a chance to detect it.

Prevention: the controls that matter most

  1. Multi-factor authentication everywhere externally reachable - VPN, remote desktop, email, cloud consoles. The single highest-value control.
  2. Patch internet-facing systems fast. Edge devices, VPN appliances and public web applications are routinely exploited within days of disclosure.
  3. Eliminate standing privilege. Just-in-time elevation limits what a stolen credential can do.
  4. Segment the network so one compromised workstation does not reach every server.
  5. Endpoint detection with someone watching it - detection without response capability just produces a record of the incident.
  6. Restrict administrative tooling - the remote management and scripting tools attackers reuse.
  7. Email and web filtering, plus awareness training focused on reporting rather than blame.

Backups: the properties that actually matter

Attackers target backups deliberately, because a recoverable victim does not pay. Your backups need to be:

  • Immutable or offline - write-once storage, or genuinely disconnected copies. A backup server joined to the same domain is not a backup strategy.
  • Credential-isolated - backup administration must not be reachable with production credentials.
  • Versioned far enough back to predate the intrusion, not just the encryption. Attackers often dwell for weeks.
  • Tested by restoration, at the scale you would actually need, with the time recorded.
  • Monitored - deletion or policy changes should alert immediately.
The question that separates readiness from hope: how long would a full restore of your most critical system take, and when did you last measure it? Organisations that cannot answer are the ones that end up negotiating.

Evidence your recovery capability

GRC Copilot tracks your backup, recovery and resilience controls with restoration test evidence - mapped to ISO 22301, ISO 27001 and the resilience domains in regional frameworks.

Double extortion changes the calculation

Modern campaigns exfiltrate data before encrypting it. Perfect backups solve availability but not disclosure - you still face a data breach with notification obligations under the GDPR, the PDPL, NIS2 or your sector regulator. Two consequences follow:

  • Egress monitoring matters as much as backup integrity - large outbound transfers are a detectable signal.
  • Your incident response must include the privacy path from the outset, not as an afterthought once recovery is underway.

Decisions to make before the incident

These are the ones that stall a live response:

  • Who can authorise taking systems offline to contain spread - and is that person reachable at 3am?
  • What is your position on payment? Decide the principle in advance, with legal input, including sanctions considerations.
  • Who engages the insurer, and what does the policy require you to do first? Many policies mandate using their panel responders.
  • Which regulators must be notified, on what clock, and who decides?
  • How do you communicate if email and chat are unavailable? An out-of-band channel and printed contact list is not old-fashioned.
  • What is the recovery order across systems, agreed with the business rather than chosen by IT under pressure?

Test it

Two exercises, both worth doing: a tabletop covering the decisions above, and a technical restoration test proving you can rebuild a critical system from an isolated backup. The technical test is the one most often skipped and the one that most often surprises.

Frequently asked questions

Should we ever pay?

It is a legal, financial and ethical decision, not a technical one - and it may carry sanctions exposure depending on the actor. Decide your principles in advance with counsel; do not improvise it during an incident.

Does cyber insurance cover ransomware?

Often, with conditions. Policies increasingly require specific controls - MFA, EDR, tested backups - and non-compliance can affect cover. Read the conditions before you need them.

Are cloud workloads safe from ransomware?

No. Cloud storage can be encrypted or deleted by an attacker with valid credentials. Versioning, immutability and separate backup credentials matter as much as on-premises.

How far back should backups go?

Far enough to predate a typical dwell time - weeks, not days. Restoring from a backup taken after the intrusion began simply restores the attacker's access.

Key takeaways

  • Encryption is the last step - every earlier stage was detectable.
  • MFA on external access and fast edge patching prevent most cases.
  • Backups must be immutable or offline, credential-isolated and restore-tested.
  • Double extortion means a breach even with perfect backups - plan the privacy path.
#ransomware #backups #recovery #extortion #resilience