Ransomware Recovery: Why Tested Backups Decide Everything

Why backups fail exactly when needed

Human-operated ransomware is not an accident that encrypts random machines. Operators spend time inside the network, escalate privileges, and then detonate — and they frequently attempt to locate, disable, alter or delete accessible backup and recovery infrastructure first. The recurring failure patterns:

• Backups reachable with production credentials. Compromised privileged credentials may allow an attacker to alter or delete backups when the backup platform relies on the same identities, administrative paths or security boundary as production.
• Volume Shadow Copies wiped — deleting VSS snapshots is a frequently observed recovery-inhibition technique in ransomware incidents.
• A domain-joined backup server may share the production identity blast radius when it relies on the same privileged accounts and management path.
• Restores never tested. Jobs report green for months while backing up the wrong volumes, or restore at a speed that turns “we have backups” into weeks of downtime.
• Nobody knows the restore order. Identity first? The ERP? DNS? Discovering dependencies during the outage adds days.

The pattern that survives

Distilled from CISA, NIST and Microsoft guidance. These are resilience principles that materially improve your odds — not guarantees:

1. 3-2-1, with one copy out of the blast radius

Three copies, two media, one offline or immutable: a copy that cannot be encrypted, altered or deleted from the production network. Immutability or object-lock is only as strong as its configuration — it needs appropriate retention, a protected administrative override, deletion controls, alerting on changes, and periodic validation that the protections still hold.

2. Separate the identities and paths

Avoid relying exclusively on production-domain identities for backup administration. Use dedicated privileged accounts, least privilege, MFA where supported, protected management paths and tested emergency access. The objective: a production identity compromise must not automatically become a backup compromise.

3. Define recovery objectives per system — in writing

RTO (how fast back) and RPO (how much data you can afford to lose) per system, agreed with the business. Without them, “we have backups” and “we can be operational Monday” are unrelated statements.

4. Test restores — and know what each test actually proves

These are different claims, in increasing order of honesty:

1. Backup job succeeded — the software ran without error. Proves little by itself.
2. Backup data is readable — a file-level restore works.
3. A system is recoverable — a full server comes back to a working state, in a measured time.
4. Recovery is application-consistent — the database or application actually functions after restore, not just boots.
5. A full service is restorable — the critical path (identity, dependencies, application, access) comes back in order.
6. Business validation — the restored service meets the agreed RTO and RPO. This is the claim that matters.

Stop Ransomware recommended baseline

The intervals below are our recommended baseline, not universal official requirements — a practical starting point to adapt to system criticality, recovery objectives and regulatory requirements:

• File-level restore — e.g. monthly. The minimum pulse check.
• Full-system restore — e.g. quarterly, rotating systems, with the duration recorded.
• Scenario drill — e.g. annually: “identity is gone, laptops are encrypted” — restore the critical path in order, under a clock. This is the test that finds the dependency nobody documented.

Documented restore tests are also evidence — for your insurer, your auditor and, if you are in scope, for NIS2.

The honest caveat: backups do not end the extortion

Modern crews often exfiltrate data before encrypting, then threaten publication. A successful restore defeats the encryption leverage but not the leak. Two consequences: backups remove the attacker's strongest lever and buy you a decision made calmly instead of under existential pressure — but data-theft response, legal duties (including NIS2 and GDPR assessment) and communications still need a plan of their own.

Legal requirement vs good practice

• Legal requirement (if you are in NIS2 scope): NIS2 explicitly includes backup management, disaster recovery and crisis management among the cybersecurity risk-management measures. It also requires procedures for assessing the effectiveness of those measures. Untested or poorly evidenced recovery arrangements may therefore fail to demonstrate that the measure is effective.
• Good practice (everyone else): everything above. Ransomware does not check whether you are an “important entity”.

A 10-minute self-check

1. Could an attacker holding your production privileged credentials alter or delete every backup copy you have? If the honest answer is “probably” — that is the finding.
2. When did you last restore a full system, and how long did it take?
3. Does anyone outside the backup tool's UI know your real RTO for the top three systems?
4. Is there a written restore order for the critical path?
5. If the attack happened tonight, would the person who knows all this answer the phone?

If any answer is uncomfortable, start there — before an incident makes the schedule for you. And if the attack is happening now: our 24/7 response line.

This article is general resilience guidance, not advice for a specific environment. Recovery architecture and testing depth should be designed against your systems, dependencies and business objectives.