Most disaster recovery plans we inherit are twenty pages long and answer almost nothing. They list vendors. They name a hotel with a conference room. What they skip is the only part the business actually needs: how long we can be down, and how much work we are willing to redo. Those two answers drive every other decision, including spend.
The industry calls them RTO and RPO. The names are unfortunate. The ideas are simple, and once a leadership team says the numbers out loud, arguments about backup products tend to end quickly. Here is what each one means, a concrete example of both going wrong on an ordinary Tuesday, and how to set yours in about an hour.
RTO: How Long You Can Be Down
Recovery Time Objective is the clock. NIST, in Special Publication 800-34 Revision 1, defines it as “the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported mission/business processes.” In plain terms: from the moment something stops working, how long until the pain becomes unacceptable?
NIST pairs RTO with a related number, Maximum Tolerable Downtime, “the total amount of time the system owner/authorizing official is willing to accept for a mission/business process outage or disruption.” The relationship matters: NIST notes “the RTO must normally be shorter than the MTD.” If four hours is genuinely all the business can absorb, your recovery target has to be less than four hours, because recovery itself takes time, goes sideways, and gets retried. Targets that equal your breaking point are not targets. They are wishes.
RPO: How Much Data You Can Afford to Lose
Recovery Point Objective is not about time to restore. It is about how far back you land. NIST’s glossary puts it in nine words: “The point in time to which data must be recovered after an outage.” Special Publication 800-34 says the same thing at more length, describing the point “to which mission/business process data can be recovered (given the most recent backup copy of the data) after an outage.”
Here is the part people miss. Your RPO is set by your backup interval, not by your intentions. If backups run once nightly at eleven, your RPO is twenty four hours, full stop. It does not matter how fast your restore is. Everything entered between the last successful backup and the failure is gone, and somebody has to re-create it from paper, email, memory, or not at all. That work is real, it is unbudgeted, and it happens during the week you can least afford it.
A Tuesday Morning, Made Concrete
Picture a forty person insurance agency. Nightly backup at 11 p.m. At 9:40 on a Tuesday morning, the server holding the agency management system stops responding. The restore is started at 10:15 and finishes at 3:30 that afternoon.
Actual RTO: roughly six hours, most of a business day for everyone who depends on that system. Actual RPO: about eleven hours, because the restored copy reflects the world as of 11 p.m. Monday. Every policy change, note, payment, and endorsement keyed between 8 a.m. and 9:40 a.m. Tuesday is gone, and nobody has a list of it. Reconstructing means calling clients to ask what they told you this morning, the single most expensive phone call in customer service. The outage cost six hours. The data loss cost trust. Both numbers were set months earlier by a backup schedule nobody had revisited.
Different Departments Deserve Different Numbers
The most common mistake is setting one target for the whole company. That is either too expensive or too weak, and usually both at once. Sort your systems into tiers instead.
- Revenue stops without it. Order entry, dispatch, point of sale, the scheduling system, the phone system. Short RTO, short RPO. These justify real money.
- Customers notice within a day. Email, shared files, the CRM, the ticketing system. Moderate targets, usually measured in hours.
- Internal only, painful but survivable. Reporting, dashboards, the marketing asset library. A day or two is often genuinely fine, and admitting that frees budget for tier one.
- Archive and reference. Old project files, closed matters, historical records. Recovery in a week may be acceptable, but retention and integrity matter more than speed.
One caution. Tiering by department only works if you also map the dependencies. Accounting may be tier three, but if their system authenticates against the same directory as tier one, the directory inherits tier one’s targets. Rank the plumbing by the most demanding thing sitting on top of it.
How the Numbers Drive Frequency and Spend
This is the part that makes budget conversations easy, because the tradeoff is not subtle. NIST states it directly: “the shorter the RTO, the more expensive the recovery solutions cost to implement.” It gives the illustration too. If a system “must be recovered immediately, zero downtime solutions and alternate processing site costs will be much higher, whereas a low-impact system with a longer RTO would be able to implement a less costly simple tape backup system.” NIST also notes the other side of the curve: “the longer a disruption is allowed to continue, the more costly it can become to the organization.”
So the numbers translate into design. A four hour RTO usually means standby systems ready to take over, not a restore from scratch. A one hour RPO means near continuous replication rather than a nightly job. Each step down the clock adds cost, and each is a decision the business should make on purpose. Moving workloads to a hosted service does not remove this exercise. Cloud platforms have outages too, which we covered in the cloud can go down and what that means for your business. Your provider’s recovery targets become part of yours, so read them.
Setting Yours in a One Hour Conversation
You do not need a consulting engagement to get a first draft. You need the owner, the person who runs operations, and whoever knows the systems, in a room with a whiteboard.
- List the systems people actually use. Ten to twenty lines, named the way staff name them, not by server hostname.
- Ask the downtime question per system. “If this is unavailable starting at 9 a.m. Monday, when do we start losing money, breaking a promise, or violating an obligation?” Write the answer in hours.
- Ask the data loss question per system. “If we lose the last few hours of entries here, who re-creates them and how?” If the answer is “we cannot,” your RPO needs to be small.
- Subtract for reality. Set the RTO target below the breaking point, per NIST’s own guidance, to leave room for detection, decision making, and a second attempt.
- Compare targets to what you have today. Have your IT provider state the current achievable numbers per system. The gaps between the two columns are your project list, in priority order.
- Price the top three gaps and decide. Some gaps get funded. Some get formally accepted. Both are fine. Unexamined is not.
Then test it. A target you have never rehearsed is an estimate. Restore something real, time it, and write down what the clock said.
The Bottom Line
RTO is how long you can be down. RPO is how much work you are willing to redo. Write both next to every important system, tier them honestly instead of pretending everything is critical, and let the numbers pick the technology rather than the other way around. The most useful hour in disaster planning is the one where a few people say those numbers out loud and discover they disagree. That disagreement is the plan taking shape. For more on why this belongs on the leadership agenda, see our post on why cybersecurity is no longer optional for mid-sized businesses.
If nobody at your company can state your RTO and RPO today, we will run that hour with you, document the targets, measure what your current setup can actually deliver, and show you the gap in plain numbers. Contact us today.
Sources:
Comments are closed