Free whitepaper on ransomware-resilient backup: the 3-2-1-1-0 rule, immutable storage, isolated admin access and recovery testing explained.
Modern ransomware attacks go after backups before they encrypt anything — deleting snapshots, changing retention and stealing backup administrator credentials. If clean restores are impossible, the attacker has leverage. This free Cyber Tech Insights whitepaper shows how to design backup that survives a deliberate attack.
Free whitepaper (PDF)Download the full guide instantly — no form required.
Download PDFWhat’s inside
- The 3-2-1-1-0 rule explained — three copies, two media types, one offsite, one immutable or offline, and zero errors after verification.
- Practical immutability options — object lock (WORM), hardened repositories, offline media and separate cloud tenancy.
- Isolating backup administration — separate identities, phishing-resistant MFA, a dedicated management network and multi-person approval.
- Recovery testing — automated verification, restore drills, clean-room recovery and runbooks.
- Buyer questions to ask storage and backup vendors, plus a one-page checklist.
Who it’s for
IT infrastructure, storage and security leaders responsible for backup, disaster recovery and ransomware readiness.
Get the whitepaper4 pages · PDF · Cyber Tech Insights
Download PDF5 proven best practices for ransomware-resilient backup
The whitepaper goes into detail, but most organisations can make rapid progress by focusing on five practices that consistently separate fast recoveries from painful ones.
- Keep at least one immutable copy. Object lock or write-once storage prevents backups from being encrypted or deleted, even by an attacker holding administrator credentials. Set retention long enough to cover the dwell time attackers often spend inside a network before they strike.
- Separate backup administration from the domain. Backup consoles should use their own identities, phishing-resistant multi-factor authentication and a dedicated management network. If an attacker compromises Active Directory, they should not automatically inherit control of your recovery systems.
- Keep an offline or logically air-gapped copy. A copy that is unreachable from production networks, whether tape, a vaulted cloud tenancy or a disconnected appliance, is your last line of defence.
- Test restores, not just backups. A green job report does not prove that data can be recovered. Schedule regular restore tests, including full application recovery, and record how long they take against your recovery time objectives.
- Monitor backups for signs of attack. Sudden changes in data change rates, deleted backup jobs or altered retention policies are early warnings. Feed these alerts into your security operations process.
Common mistakes to avoid
- Storing backup credentials in the same password vault or directory that ransomware operators target first.
- Backing up only servers and forgetting SaaS data such as email, files and collaboration platforms.
- Assuming snapshots on the primary array are backups. If the array is compromised, so are the snapshots.
- Never rehearsing a large-scale recovery, so priorities and sequencing are decided during the crisis.
Frequently asked questions
What does the final 0 in 3-2-1-1-0 mean?
It means zero errors after recovery verification. Backups should be automatically checked so you know they can be restored before you need them.
Is cloud backup enough on its own?
Cloud backup is valuable, but it must still be immutable, protected by separate credentials and regularly tested. Location alone does not make a copy resilient.
How often should we test recovery?
Test critical systems at least quarterly and after major changes, and run a broader recovery exercise at least once a year with both IT and business stakeholders.
A 90-day action plan
Days 1 to 30: list every system that holds business-critical information, confirm where each copy is kept and identify which copies an attacker with domain administrator rights could reach. Review who can change retention settings or delete jobs.
Days 31 to 60: enable object lock or another immutable target for your most important workloads, move console access to separate accounts with strong authentication, and set alerts for deleted jobs or shortened retention.
Days 61 to 90: run a full restore of one critical application into an isolated environment, time each step and document what slowed you down. Share the results with leadership and agree the next round of improvements.
Questions to ask your provider
- Can retention locks be shortened or removed by an administrator, or by the provider’s support team?
- How are encryption keys protected, and can they be destroyed by a compromised account?
- What tooling exists to scan restore points for malware before recovery?
- How quickly can large volumes be restored, and what network or egress limits apply?
- Which audit logs are retained, and can they be sent to our security monitoring platform?
Key terms explained
- Immutability: a setting that prevents data from being changed or deleted until a retention period ends.
- Air gap: separation that stops a network-based attacker from reaching a copy.
- Clean room recovery: restoring into an isolated environment to check systems before reconnecting them.
- Dwell time: how long attackers remain undetected inside a network before acting.
The bottom line
Attackers increasingly target recovery systems first, so protection must assume that production and even administrator accounts may be compromised. Immutable and isolated copies, separate administrative access, monitoring and regular restore testing provide the confidence that operations can be recovered without paying a ransom. Download the whitepaper for the full framework, then use the action plan above to close the most important gaps within the next quarter.
Further reading on ransomware-resilient backup
For authoritative, vendor-neutral guidance on ransomware-resilient backup, see CISA #StopRansomware guidance. You can also browse our free whitepapers.
