Is your backup ransomware-ready? A practical guide to backup and disaster recovery

A backup is ransomware-ready when an attacker who controls your network still cannot reach it, when it is encrypted, and when you have restored from it recently enough to know it works. In most environments we review, the weak points are backups that sit on the same network as the systems they protect, or that were never tested until the day they were needed. Ransomware readiness is the combination of isolated copies, regular restore tests, and a written plan for rebuilding.

Why ransomware changed what a backup has to do

Backups were originally designed for hardware failure and accidental deletion. Ransomware operators know that a working backup is the main reason a victim does not pay, so finding and destroying backups is now a routine step in an attack. Backup consoles, storage shares, and the admin accounts that manage them are targets.

The scale is significant. The Verizon 2026 Data Breach Investigations Report found that 48% of all breaches now involve ransomware, though it also notes that payouts are shrinking. Fewer payouts is good news, but it does not reduce the disruption. Whether or not a ransom is paid, the business still has to restore systems, and the quality of the backup decides how long that takes.

What does CISA recommend for backups?

The #StopRansomware Guide, published in September 2023 by CISA, MS-ISAC, the FBI, and the NSA, gives specific backup guidance. The key points:

• “Maintain offline, encrypted backups of critical data.” Offline means a copy that cannot be reached from the production network or with production credentials. Encrypted means a stolen backup does not become a data breach.
• “Regularly test the availability and integrity of backups in a disaster recovery scenario.” A successful backup job only proves data was written. A restore test proves it can be read back and used.
• “Maintain and regularly update ‘golden images’ of critical systems.” A known-good, current image of servers and key workstations shortens rebuild time considerably.
• “Retain backup hardware to rebuild systems.” If recovery depends on hardware you would have to order, the order time becomes part of your outage.

The guide also cautions organizations to “use immutable storage with caution as it does not meet compliance criteria for certain regulations.” Immutable storage, which cannot be altered or deleted for a set retention period, is a strong defense against an attacker deleting backups. The caution is about retention and deletion obligations, so confirm how immutability interacts with any regulatory requirements that apply to your data before you design around it.

Separately, many teams follow the common industry practice known as 3-2-1: three copies of data, on two different types of media, with one copy offsite. It is a useful starting rule, and it fits well with CISA’s emphasis on an offline copy.

RPO and RTO in plain language

Two numbers define what “recovered” means for your business, and leadership should agree on them before an incident:

• Recovery Point Objective (RPO) is how much data you can afford to lose, measured in time. An RPO of four hours means backups must run at least every four hours, and an incident could cost up to four hours of work.
• Recovery Time Objective (RTO) is how long a system can be down before the business impact becomes unacceptable. An RTO of eight hours means the restore process, including any rebuild, must complete within eight hours.

These numbers are set per system, not per company. Email, the accounting platform, and the file server often have very different tolerances. Tighter objectives cost more, so the exercise is a business decision about where downtime hurts most. Setting them honestly also exposes gaps: if the stated RTO is four hours but a full restore of the file server has never been timed, the RTO is a hope rather than a measurement.

How often should you test restores?

Testing cadence should match how critical the system is and how often it changes. A reasonable baseline for most small and mid-size organizations:

• Monthly: restore a sample of files and at least one mailbox, and verify they open correctly.
• Quarterly: perform a full restore of one critical server or application into an isolated environment, and record how long it took against the RTO.
• Annually: run a tabletop or live disaster recovery exercise that walks through a ransomware scenario end to end, including who makes decisions and how staff are told what to do.
• After major changes: test again after a migration, a new application, or a change to the backup platform.

Record the results. A dated log of successful restore tests is also the evidence insurers and auditors increasingly ask for.

The SaaS backup gap

Many organizations assume Microsoft 365 or Google Workspace data is backed up because it lives in the cloud. These platforms are built for availability and include retention features, but retention settings are not the same as an independent backup you control. If an account is compromised and data is deleted or encrypted through a synced client, or if a retention policy is misconfigured, recovery options inside the platform can be limited.

A separate SaaS backup that copies mailboxes, OneDrive or Drive, SharePoint, and shared drives to storage outside the tenant closes this gap. Apply the same rules as on-premises: separate credentials, encryption, and regular restore tests.

What belongs in a recovery runbook?

When ransomware hits, nobody wants to improvise. A recovery runbook is a short, written document, stored somewhere that remains reachable if the network is down. It should include:

• The list of critical systems in recovery order, with RPO and RTO for each.
• Where each backup lives, how to access it, and who holds the credentials (kept separate from normal admin accounts).
• Steps to isolate affected systems before restoring, so you do not restore onto infected machines.
• The location and version of golden images, and the hardware available to rebuild.
• Contacts: internal decision-makers, your IT and security providers, cyber insurer, legal counsel, and law enforcement.
• How to validate a restored system before it returns to production.

The runbook should sit alongside your broader incident response plan, which covers detection, containment, and communication.

How Intelligent Group can help

Intelligent Group designs and runs backup and disaster recovery programs built around isolated, encrypted copies, scheduled restore testing, and written runbooks. Our managed SOC isolates a compromised endpoint in under 30 seconds, which limits how far ransomware can spread before recovery begins. For organizations focused on availability more broadly, our work to eliminate downtime ties RPO and RTO targets to monitoring and a 99.9% uptime SLA.

Frequently asked questions

Is cloud backup enough to protect against ransomware?

It can be, if the cloud copy is isolated from your production credentials and cannot be deleted or encrypted by someone who has taken over your network. A cloud folder synced from an infected computer offers little protection. Check how the backup is accessed and who can delete it.

What is the difference between a backup and disaster recovery?

A backup is a copy of data. Disaster recovery is the tested process of getting systems and people working again within agreed time limits, which includes backups, golden images, hardware, runbooks, and decision-making.

Should we use immutable backups?

Immutable storage is a strong control against attackers deleting backups. CISA advises using it with caution because it does not meet compliance criteria for certain regulations, so review your retention and deletion obligations before relying on it, and confirm regulatory questions with counsel.

How do we know our RTO is realistic?

Time an actual restore of the system in question and compare it with the target. If you have never performed a full restore, treat the current RTO as unverified until you do.