How To Build A Ransomware-Ready Backup Plan

Ransomware readiness is not simply a matter of running backup jobs. A useful plan must help people restore trustworthy systems, data, identities, and business processes under pressure. That requires knowing what matters most, protecting recovery copies, and practicing the steps needed to return to normal operations.

One important safeguard is to keep at least one recovery copy outside the normal attack path. Cohesity, a data security company with services spanning backup and recovery, cloud data protection, and cyber resilience, provides an air-gapped backup explained resource that outlines how physical, virtual, and logical isolation can help protect recovery data from unauthorized access or destructive changes.

Why A Backup Plan Must Include Recovery

A backup marked “successful” is not proof that the organization can recover. An attacker may affect production workloads, backup administration tools, cloud accounts, shared credentials, or the network paths used to access stored copies. Data protection involves creating and retaining copies. Operational recovery is the ability to restore clean, usable services in the right order and within an acceptable timeframe.

Build the plan around both outcomes. The team should be able to identify a safe recovery point, access it with separate credentials, restore it into a clean environment, and verify that the application works.

Identify What Matters Most

Start with an inventory of systems that directly support revenue, customer service, safety, legal obligations, and daily work. Include applications, databases, file shares, SaaS platforms, identity services, DNS, configuration files, encryption keys, and recovery documentation.

Map Dependencies Before An Incident

A business application rarely operates alone. An ordering platform, for example, may depend on identity services, a database, network services, payment tools, and cloud storage. Record these dependencies and classify workloads by priority. This keeps the recovery team from restoring a low-priority file share while a critical identity platform remains unavailable.

Set Recovery Point And Recovery Time Targets

A recovery point objective, or RPO, defines how much recent data loss the business can tolerate. A recovery time objective, or RTO, defines how long a system may remain unavailable. These targets should be approved by business owners, not assumed by IT.

• A payment or customer transaction system may require an RPO measured in minutes and a short RTO.
• An archived file share may allow a longer gap between backups and a slower restoration process.
• Identity systems and core network services often need early recovery because other applications depend on them.

Different workloads need different targets. A single standard for every system usually creates unnecessary cost for some services and inadequate protection for others.

Use Multiple Protection Layers

One backup copy is a single point of failure. Maintain multiple copies across distinct storage systems, locations, or media types. A local copy can support fast restores, while an off-site copy can help when a facility, storage platform, or production network is unavailable.

For every copy, document its location, owner, retention period, access method, and recovery purpose. A copy that cannot be found or accessed during an emergency has limited value.

Keep One Copy Outside The Attack Path

Isolation can be physical, network-based, or policy-based. Physical isolation separates backup media or systems from production connections. Network isolation uses separate networks or controlled connections. Policy-based isolation relies on separate accounts, limited privileges, approval workflows, and tightly controlled recovery actions.

Whichever model is used, avoid shared administrator credentials between production and backup environments. Require multifactor authentication for privileged access, restrict management interfaces from public internet exposure where practical, and regularly review service accounts, API keys, and emergency access procedures.

Use Immutability And Retention Controls Carefully

Immutability and retention controls can prevent recovery points from being altered or deleted for a defined period. Examples include write-once controls, object lock capabilities, protected retention policies, and version history. These features are valuable only when configuration, permissions, and logging are reviewed.

• Identify who can shorten retention periods or delete backup data.
• Require approval for high-impact policy changes.
• Log and review changes to retention, storage, and access settings.
• Test whether protected copies can actually be changed or removed by a standard administrator account.

Detect Trouble Before A Restore Is Needed

Monitor failed backup jobs, unexpected deletion requests, unusual permission changes, abrupt growth in backup data, and sudden increases in encrypted or renamed files. Review backup logs on a schedule rather than only after a security event. Earlier detection can help preserve clean recovery points before suspicious activity spreads further.

Test Recovery In A Clean Environment

Regular restore testing turns assumptions into evidence. Restore individual files, databases, virtual machines, and complete applications in a clean or isolated environment. Measure the actual recovery time, compare it with the RTO, and verify that restored data is complete and usable.

Record every delay, missing dependency, access issue, or unclear handoff. Then assign an owner and deadline for fixing it. The CISA ransomware guide emphasizes maintaining offline or isolated backups and testing recovery procedures as part of preparation and resilience.

Create A Simple Recovery Runbook

1. Confirm the suspected incident and identify affected systems.
2. Contain compromised devices or network segments when appropriate.
3. Protect backup systems and pause risky synchronization activity.
4. Notify incident response, leadership, legal advisers, and key providers.
5. Select a clean recovery point based on the attack timeline.
6. Restore essential services in dependency order.
7. Reset credentials and address the weakness that enabled the intrusion.
8. Document lessons learned and update the plan.

Align The Plan With Current Guidance

Use the NIST ransomware risk management guidance released in June 2026 to review governance, protection, detection, response, and recovery activities as a single, integrated program. The plan should reflect the organization’s risk tolerance, resources, and operational priorities.

Quick Review Checklist

• Critical systems, data, and dependencies are documented.
• Business leaders have approved RPO and RTO targets.
• Multiple recovery copies exist in separate locations or systems.
• At least one copy is isolated from ordinary production access.
• Backup accounts have strong, separate access controls.
• Retention and immutability settings are tested.
• Recovery exercises occur on a defined schedule.
• The runbook includes technical, legal, operational, and communications actions.

Make Recovery A Routine Practice

A ransomware-ready backup plan is a repeatable operating practice, not a storage purchase or policy document. Prioritize the right systems, protect recovery copies, limit access, test restores, and improve after every exercise. Organizations that practice recovery before an incident are better positioned to restore services with less confusion and delay.