Key takeaways

  • The recovery time objective (RTO) is how long a system can stay down; the recovery point objective (RPO) is how far back its data can be rolled. They answer different questions and are set separately for each system.
  • NIST SP 800-34 Rev. 1 puts a third term above them: maximum tolerable downtime (MTD), the total outage the business will accept for a process. The RTO must normally be shorter than the MTD, because reprocessing work after recovery takes time too.
  • The guide describes the impact analysis in three steps: identify the business processes and how critical they are, identify the resources they need, and set recovery priorities for those resources.
  • Business owners, not IT, supply the impact numbers. IT supplies what each option costs and what it can deliver.
  • Four or five tiers are easier to run than one custom target per system. Fewer, clearer tiers also make budgeting and testing simpler.
  • The guide frames the decision as balancing the cost of the system being unavailable against the cost of the resources needed to recover it. Shorter targets cost more, and the curve is steep at the short end.
  • Targets that are never tested are only wishes. Each objective needs a test that shows it can be met.

Two numbers that are really business decisions

Every recovery conversation comes down to two questions. How long can this system be unavailable before it seriously hurts us? And how much recent data can we afford to lose? The first answer is the recovery time objective, or RTO. The second is the recovery point objective, or RPO.

An RTO of four hours means that after a failure the system should be usable again within four hours. An RPO of fifteen minutes means that, after recovery, no more than the last fifteen minutes of data may be missing. A nightly backup cannot meet that RPO; it can only meet one of about a day. The numbers drive the technology and the technology drives the cost, so they need to be chosen on purpose.

Where the targets come from: the impact analysis

The U.S. National Institute of Standards and Technology covers this in SP 800-34 Rev. 1, its contingency planning guide. The first step in setting recovery targets is a business impact analysis. The guide describes three steps. First, determine which business processes a system supports and how critical they are, including the impact of an outage and the estimated downtime the organization can tolerate while still maintaining its mission. Second, identify the resources needed to resume those processes, such as facilities, people, equipment, software, data files and the dependencies between them. Third, identify recovery priorities for system resources so that recovery happens in a sensible order.

Ready.gov, the U.S. government's business preparedness site, lists the kinds of impact to consider: lost or delayed sales and income, increased expenses such as overtime and outsourcing, regulatory fines, contractual penalties, customer dissatisfaction or defection, and delayed new business plans. Ask each process owner to put a number or a range on those for one hour, one day and one week of outage.

Run the conversation as an interview, not a survey

Sending a spreadsheet to department heads and asking for an RTO usually produces the answer 'immediately' for everything. Instead, sit with each process owner and ask concrete questions:

  • What do you do with this system, hour by hour? What stops if it is down?
  • Is there a manual workaround, and for how long can staff use it before it breaks down?
  • Which days or times are worst: month end, payroll, a filing deadline, a clinic's morning?
  • Does a regulator, a contract or an insurer set a deadline?
  • If we lost a day of data, could you re-enter it? How? How long would it take?
  • What else must be working before this system is useful: identity, network, a database, a partner's feed?

The last question matters because systems depend on each other. A fast-recovering application is no use if the directory service it signs in with takes a day. The RTO of a dependency must be at least as short as the RTO of everything relying on it.

Add the three terms up

The same guide separates maximum tolerable downtime, RTO and RPO. The MTD is the total outage the business will accept for a process, with every impact considered. The RTO is the longest a system resource can stay down before it causes an unacceptable impact on other resources and the MTD. The RPO is the point in time to which data can be recovered, a measure of tolerable data loss. NIST notes that RPO is not part of the MTD; it is about data, not time. It also notes that the RTO must normally be shorter than the MTD, since after systems return there is extra work to reprocess data, and that time has to fit inside the limit.

A worked example in words: the business says order entry can be down for eight hours at most, which is its MTD. Catching up on orders after recovery takes about two hours, so the RTO for the order system should be no more than six. The business can re-enter a half hour of orders from paper, so the RPO is thirty minutes.

Group systems into tiers

Once the numbers are in, resist giving each system its own target. Group them. A common model has four or five tiers, for example:

  • Tier 0: the foundations everything else needs, such as identity, DNS, the network core and the backup system itself. Recover these first.
  • Tier 1: systems where an outage stops revenue or safety within hours. Shortest RTO, smallest RPO, usually a replicated standby.
  • Tier 2: important systems where a day of downtime is painful but survivable. Restore from recent backups or a warm copy.
  • Tier 3: useful systems that can wait several days, restored from regular backups.
  • Tier 4: archives and rarely used systems, restored last or rebuilt.

Tiers keep the plan understandable. A new application is placed in a tier rather than argued from scratch, and each tier has a standard technology pattern and a standard test.

The cost trade-off, in plain terms

Shorter objectives need more machinery. A tight RPO needs continuous replication instead of nightly copies. A short RTO needs a ready standby environment, automation and rehearsed staff instead of a rebuild from scratch. Those standing resources are paid for every month, whether or not a disaster happens. The NIST guide describes the decision as finding the point that balances the cost of the system being unavailable against the cost of the resources needed to restore it, and shows it as a simple chart: downtime cost rises with time, recovery cost falls with time, and the best point is where they meet.

Show the business that chart for its own systems. Present two or three options per tier with what each delivers: for example restore from backup, warm standby, and active replication. Let the business owner choose with the cost and the residual risk in view. Often a process that asked for 'immediate' will accept four hours once it sees the difference, and sometimes a process that said 'a day is fine' turns out to need much more once its deadlines are on the table.

When a target cannot be met yet and the tolerable downtime is firm, NIST's guide says to document the gap and a plan of action to close it. Write the gap down and tell the owner; a hidden gap becomes a surprise during an outage.

Beware the usual traps

  • Setting RTO without checking restore speed. A backup that takes nine hours to copy back cannot meet a four-hour objective, whatever the document says.
  • Forgetting the people. The objective assumes someone with access and knowledge is available; plan for the person on vacation.
  • Treating cloud services as automatically resilient. A provider's service level is not your recovery time; check the provider's own limits and how you would recover your configuration and data.
  • Ignoring ransomware. Replication copies encrypted files as faithfully as good ones, so a tight RPO needs versioned or immutable copies as well.
  • Never revisiting. Objectives drift as the business grows. Review them yearly and after any large change.

Make it a living document

Capture the result in a simple table: process, owner, MTD, system, tier, RTO, RPO, dependencies, the recovery method, the date it was last tested and the achieved times. Have each owner sign it. Then test it; the next step is to run a drill that checks every number you have just written down.

Sources

This article is general guidance, not legal advice. Adapt it to your organization, and ask your counsel about employment, privacy and contract questions before you rely on it. Last reviewed .

Next article

Related reading

Need help with this?

Know how long you can be down, and prove you can come back before the day you must.

Disaster Recovery Planning