A ransomware recovery plan is a document, written before an incident, that says what happens when ransomware (malware that encrypts data and demands payment) has made systems unusable: who does what, which systems come back first and by when. Its key numbers are two values, the RTO (the target for how many hours restoration may take) and the RPO (how much data you accept losing, measured back in time). This article explains both with a worked calculation, then covers what the plan should contain and how to rehearse it. For the basic preventive measures, see How to Prevent Ransomware: 5 First Steps for Organizations.

RTO and RPO in plain language

Picture an accounting system that is encrypted on a Tuesday afternoon. Two questions need answers. First, how late can the system come back and still be acceptable? Second, how many hours of data, between the last backup and the attack, can you afford to lose? Those two questions are the RTO and the RPO.

The definitions from NIST, the US standards institute, put in plain words, are:

  • RTO (Recovery Time Objective): the longest time a system can stay unavailable before the impact on its business function becomes unacceptable. It answers "how many hours until recovery must be done"
  • RPO (Recovery Point Objective): NIST SP 800-209 describes it as the amount of data that can be lost after a failure, expressed in time. For example, an RPO of 4 hours means accepting the loss of the last 4 hours of data. NIST SP 800-34 describes it as the point in time before the disruption to which data can be recovered
  • MTD (Maximum Tolerable Downtime): the total time the system owner is willing to accept for a business process outage. The RTO must be shorter than the MTD because, once the system is restored, time is still needed to reprocess the data that piled up. NIST SP 800-34 gives this reason

The RPO sets how often you must back up, and the RTO helps choose the technology and method that can restore in time. NIST SP 800-34 has the plan author set the acceptable downtime together with the business process owners and leadership, rather than leaving it to IT alone. NIST SP 800-209 adds that the speed you need should be weighed against the cost of making every dependent part that fast.

INFOGRAPHIC
Backup interval sets the most data you can lose (if the latest copy is clean)
Weekly
up to 168 hours (7 × 24)
Nightly
up to 24 hours
Every 4 hours
up to 4 hours (6 runs a day)
Hourly
up to 1 hour, at the cost of more jobs and storage
Much data may be lostLittle data lost

Worked example: the accounting system of a made-up organization

This example uses made-up numbers to show the reasoning, not values to copy. The imaginary organization has an accounting system holding 6 TB of data (in this example 1 TB is taken as 1,000,000 MB). The business sets an RPO of 4 hours and an RTO of 24 hours, and the business can accept at most 48 hours of downtime (the MTD), so the 24-hour RTO is shorter than the MTD as the rule requires. Today the system is backed up every night at 01:00.

Start with the RPO. Suppose ransomware encrypts the system at 15:00 on Tuesday and the latest backup is from 01:00 the same day. The data lost is 14 hours (15:00 minus 01:00), which is 10 hours over the 4-hour target. If the attack comes shortly before the next backup, nearly the full 24 hours is lost, because backups are 24 hours apart. To reach an RPO of 4 hours, backups must run at least every 4 hours: 24 divided by 4 is 6 runs a day, which is 6 times as many as today (1 run a day).

But 14 hours is the best case, because it assumes the latest backup is clean. CISA, the US cybersecurity agency, says a ransomware event may be evidence of an earlier, unresolved network compromise, so the latest backup may carry it. Suppose it turns out the attacker got in after 01:00 on Sunday morning, so the 01:00 Sunday backup is still clean and is the latest clean restore point. The data lost is then 62 hours (Sunday 01:00 to Tuesday 15:00 is 24 + 24 + 14), which is 58 hours over the 4-hour target. The data actually lost depends on which copy is clean, not only on the backup schedule.

Next, the RTO. Recovery is not just copying data back. This example splits it into 5 tasks done one after another (the times are made up):

  • Confirm the scope and isolate infected systems from the network: 3 hours
  • Rebuild the user account system (Active Directory) and core servers from clean templates: 8 hours
  • Scan the backups and choose a clean restore point: 4 hours
  • Restore the 6 TB of data at a real average of 200 MB per second: 6,000,000 MB divided by 200 is 30,000 seconds, or 8 hours 20 minutes (30,000 divided by 3,600 is 8.33 hours)
  • Test the system and have users check it: 4 hours

The total is 27 hours 20 minutes (3 + 8 + 4 + 8 hours 20 minutes + 4), which is 3 hours 20 minutes over the 24-hour RTO but still within the 48-hour MTD. To make it, some task must get shorter. For example, if the data restore must finish in 5 hours (24 − 3 − 8 − 4 − 4 = 5), it needs 6,000,000 MB divided by 18,000 seconds, about 333 MB per second, roughly 1.7 times faster than before (333 divided by 200 is about 1.67). In real life some tasks can run in parallel, so measure the time in an actual rehearsal. An RTO written on paper is still only a target.

INFOGRAPHIC
RTO in the example: time per task (made-up numbers)
1
Confirm scope and isolate
3 hours
2
Rebuild accounts, core servers
8 hours
3
Scan copies, pick restore point
4 hours
4
Restore 6 TB of data
8 h 20 min at 200 MB/s
5
Test and user checks
4 hours
6
Total
27 h 20 min, over the 24 h target

The example shows that the RTO depends on every task along the way, not only on how fast data can be copied, and that the RPO depends on the clean restore point, not only on how often backups run. The example also leaves out the time to find and remove the root cause, which in a real incident can take far longer (see the next section), and it is a conclusion from our own made-up calculation, not a value set by NIST or CISA documents.

What a recovery plan should contain

NIST SP 800-184, the guide to cybersecurity event recovery, calls a usable plan a playbook, meaning step-by-step actions written down in advance, and says to write it before an event. The list below is compiled from both NIST and CISA:

  • An inventory of systems, people and dependencies: which system must be restored before which. NIST SP 800-184 gives the example that an identity or authentication server often has to be restored before files and messaging, and NIST SP 800-209 says to protect Active Directory and DNS (the system that maps domain names to machines) so that a full recovery is possible
  • Priorities for systems: CISA says to rank by importance to health and safety, revenue generation and other critical services, including the systems those depend on
  • An RTO and RPO for each system: set using the method in the example above
  • The conditions for invoking the plan, and who has the authority: NIST says to define when the plan starts, who can start it and how recovery staff are notified
  • Where backups are kept and how to reach them: including off-site and offline copies. See The 3-2-1-1-0 Backup Strategy and Immutable Backups
  • A communication plan: internal and external, from executives, legal and public relations to service providers and the bodies that must be notified
  • Workarounds: NIST says to prepare approved procedures for when a system cannot be restored within its RTO
  • Criteria for declaring recovery finished: NIST SP 800-61 Rev. 3 says the end of recovery is declared based on defined criteria and the incident documentation is completed
INFOGRAPHIC
Example restore order (the real order comes from your dependency map)
01
Clean network
no attacker left inside
02
User accounts and DNS
before other systems
03
Business-critical systems
per the priority list
04
Remaining systems
in order of importance
05
Verify before go-live
check what was restored

If an incident affects personal data, check the breach notification duty under the PDPA (Thailand's Personal Data Protection Act). Secondary sources we found summarize it as notifying the Personal Data Protection Committee Office without delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to put individuals' rights at risk. We did not check the official text of the law, so have legal staff confirm the current requirements and put them in the communication plan.

How the recovery plan connects to incident response

NIST SP 800-61 Rev. 3 (April 2025) treats recovery as part of incident response. The Recover function, one of the main functions of CSF (NIST's cybersecurity risk framework) version 2.0, means that assets and operations affected by an incident are restored. The document says incident response and recovery used to be completed within a day or two, but today incidents occur more often and cause far more damage, and recovery often takes weeks or months. Our observation: one system's RTO does not mean the whole organization is back to normal by then, so have workarounds ready.

The main recovery steps in CISA and NIST SP 800-61 Rev. 3 are:

  • Isolate infected systems and prioritize what to restore: CISA says to isolate affected systems at once, use out-of-band communication such as phone calls so attackers are not tipped off, and prioritize restoration using the critical asset list prepared in advance
  • Remove the cause before restoring: CISA says to look for dropper malware and for access the attacker left behind before rebuilding from backups, so systems are not reinfected
  • Check copies before using them: NIST SP 800-61 Rev. 3 says to check restoration assets for indicators of compromise, file corruption and other integrity issues before use
  • Restore on a clean network in priority order: CISA says to rebuild from preconfigured images where possible, and if a new virtual network (VLAN) is created for recovery, to add only clean systems to it
  • Reset passwords and close the gaps: once the environment is cleaned and rebuilt, CISA says to reset passwords for affected systems and accounts, patch vulnerabilities and update customer-managed encryption keys as needed. Also check for accounts the attacker may have created; see ITDR: Detecting and Responding to Identity Attacks
  • Verify what was restored, declare the end and capture lessons: NIST says to verify the integrity of restored assets, confirm with system owners and declare the end based on criteria. CISA says to document lessons learned to improve the plan

Rehearsals: making the RTO and RPO real

NIST SP 800-184 says to use both exercises (practicing a scenario) and tests (real technical checks). The results confirm or refute the assumptions in the plan, in particular whether the recovery targets are realistic, expose gaps in the process, and train people who have new recovery duties. NIST sets no fixed frequency: the organization chooses one that suits it and records the results every time.

Rehearsal formats that work:

  • Tabletop (talking through a scenario around a table): NIST suggests each team include at least one person playing the adversary, adding realistic obstacles, and using a real incident from the news as the scenario. For simulation tools, see Network and Cyber Security Simulators: Types and Uses
  • A real restore test: pick a system, restore it from backup into an isolated area, and time it against the RTO. NIST SP 800-209 says to test restores periodically to make sure they finish in the required time
  • A rehearsal without the normal systems: have the team communicate through backup channels and work from the printed plan. CISA says to keep both a hard copy and an offline version of the plan
  • A review afterwards: NIST says to review the results thoroughly, what worked and what did not, and then update the plan

NIST SP 800-184 gives example metrics to track, such as the percentage of successful and timely restorations from backup, the number of recovery events that achieved recovery objectives, and the number of gaps found in exercises. These show whether the RTO and RPO you set are achievable. NIST also warns that collecting metrics must not get in the way of the actual recovery work.

Common mistakes

  • Letting IT set the RTO and RPO alone: NIST says to set them together with business process owners and leadership
  • Counting only the data copy time as recovery time: forgetting the time to confirm the scope, rebuild systems, scan copies and verify before going live, which together make up 19 of the 27 hours 20 minutes in the example above, more than two thirds of the total
  • Assuming the RPO always equals the backup interval: if the latest copy is not clean, you must go back to an older point, so more data is lost than the schedule suggests
  • Keeping the plan on a server that may be encrypted too: CISA says to keep both a hard copy and an offline version
  • Rehearsing only with the IT team: NIST says to exercise both technical and non-technical aspects, such as personnel and legal issues
  • Restoring in a hurry before removing the cause: restored systems can be attacked again if the dropper malware or the accounts the attacker left behind are still there
  • Not updating the plan when systems change: outdated dependency maps and RTO and RPO figures lead to restoring in the wrong order or too slowly

Start today

  • Pick three critical systems: ask the owners within how many hours each must be restored (RTO) and how many hours of data it can lose (RPO)
  • Compare today's backup schedule with the RPO: use the same method as the example above to find how many times more often you must back up
  • Try restoring one system and time each step: put real numbers in place of the made-up ones
  • Draw a one-page dependency map: note whether the user account system and DNS must come before the others
  • Print the contact list and recovery steps and keep them offline: so they can be read even when the network is unusable
  • Schedule one tabletop this quarter: include legal, corporate communications and executives

To assess your organization's overall readiness, try the self-assessment.

The recovery plan is one part of the overall incident response plan; see Incident Response Plan Under NIST SP 800-61 Rev. 3.

Once you have a recovery plan, rehearse it with your team using Ransomware Tabletop Exercise Template: Ready Scenario.

References and further reading