How to plan ransomware backup and disaster recovery

What does a ransomware recovery plan need?

A ransomware recovery plan needs clear roles, a priority list of critical services, set limits for downtime and data loss, current contacts, and written sign-off from the CEO or equivalent. The National Institute of Standards and Technology lays out these elements in its Ransomware Risk Management Profile (NIST, 2026), and CISA, the FBI, the NSA and the MS-ISAC describe much the same approach in the #StopRansomware Guide (2023).

Managed backup services can supply the technical side of recovery, but the written plan still needs clear roles and a prioritized list before any copy of data gets restored. A plan without these pieces leaves staff guessing during an attack, and guessing costs time and money. The guidance points to seven things a plan names:

1. Critical services in restore order
2. Roles and decision making
3. Acceptable downtime and data loss
4. Current contacts
5. Out-of-band communications
6. Written approval by the CEO or equivalent
7. Regular exercises

Each item answers a question a team faces mid-attack: which system comes back online first, and how staff will communicate if phone and email systems are down. A plan written before an attack settles these questions ahead of time, when no one has to debate them under pressure.

What makes a backup safe from ransomware?

A safe backup is offline or off-site, encrypted, and immutable, meaning it cannot be altered or deleted, and it covers the organization's whole data infrastructure (FBI IC3, 2025 Internet Crime Report, 2026).

Ransomware actors look for accessible backups first. They delete or encrypt copies they can reach, and they hunt for stored credentials that open backup tools (CISA, FBI, NSA and MS-ISAC, #StopRansomware Guide, 2023). Automatic cloud backups carry a quiet risk too: a backup that syncs on a schedule can overwrite a clean copy with an already-encrypted file before anyone notices the attack (CISA and partners, 2023).

How do we know our backups will work after a ransomware attack?

Backups prove themselves through testing. Organizations test both the availability and the integrity of backup data on a regular schedule, in a disaster recovery scenario, and confirm integrity again right before any restore (CISA, FBI, NSA and MS-ISAC, 2023; NIST, Ransomware Risk Management Profile, 2026).

Regular restore tests catch problems early, such as a corrupted file, a missed server, or an expired credential. The NIST Ransomware Risk Management Profile (2026) calls for checking backup integrity immediately before restoration begins, since a copy made before an attack was fully contained can still carry hidden damage.

FunctionOne includes backup and disaster recovery among its managed IT services, beginning work with a security assessment that reviews systems and accounts and agrees on scope and response rules with leadership.

Who decides what gets restored first?

Process owners, leadership and business managers decide what gets restored first, guided by a predefined list of critical assets: systems tied to health and safety, revenue generation, and other critical services, along with everything those systems depend on (CISA, FBI, NSA and MS-ISAC, #StopRansomware Guide, 2023).

Unaffected systems get tracked and deprioritized, so recovery teams spend their time where it counts. The full incident response plan, including this restore order, needs written approval from the CEO or an equivalent senior leader before an attack happens (CISA and partners, 2023). Settling this ahead of time keeps a crisis from turning into a debate over authority.

What are RTO and RPO?

Recovery time objective, or RTO, is the longest a system can stay unavailable before the impact becomes unacceptable. Recovery point objective, or RPO, is how much data loss a process can tolerate. Both get set with process owners, leadership and business managers (NIST, SP 800-34 Rev. 1, Contingency Planning Guide, 2010).

These two numbers turn a vague goal, recovering quickly, into something a team can plan and test against. A payroll system might carry a short RTO because missed paychecks damage trust fast, while an archive server might tolerate days of downtime. RPO works the same way: a sales database might need backups every hour, while a reference library might only need a backup once a week. Setting these targets before an attack gives the recovery team a clear finish line instead of an open-ended task.

How long does it take to recover from a breach?

42% of breached organizations fully recovered, up from 35% the year before, and fewer than 1 in 20 recovered within 50 days (IBM, Cost of a Data Breach Report 2026).

IBM defines recovery as more than restoring files. Full recovery means operations are back to normal, obligations are met, trust is restored with customers and partners, and controls are back in place (IBM, Cost of a Data Breach Report 2026). That broader definition explains why recovery often outlasts the technical restore: a company can bring systems back online in days while still working for months to rebuild client confidence or meet regulatory obligations.