← All Blogs

RTO and RPO: the two numbers that decide what you pay

By Best IT MSP Editorial Team - Updated October 20, 2026 - 13 min read

The Best IT MSP editorial team maintains this directory's provider data across the US and Canada. We rank providers on verified rating and firmographic data, label paid placement, and do not sell IT services.

RTO vs RPO: what is the difference?

Recovery time objective is how long you can be down. Recovery point objective is how much data you can lose. RTO is measured forward from the moment the system stops. RPO is measured backward from it, to the newest copy you could restore.

Most guides stop there. That is the problem, because neither number is a fact about your business. Both are prices. You are choosing how much to pay for speed and how much to pay to avoid data loss, and almost every SMB we see accepted whatever their provider set by default.

The standards bodies tie both targets to harm rather than to preference. NIST defines a recovery time objective as the overall length of time an information system's components can be in the recovery phase before negatively impacting the organization's mission. The word before matters. Above the RTO sits a harder limit, maximum tolerable downtime, which NIST defines as the amount of time a mission or business process can be disrupted without causing significant harm to the organization's mission. Maximum tolerable downtime is a fact about your business. Your RTO is a target you buy, and it has to sit inside that fact.

Here is the RPO in one line. You back up at 11pm, the server dies at 4pm, and seventeen hours of work is gone. Your RPO was 24 hours, so that data loss was inside the plan all along. Whether it is acceptable is a business question, not an IT one, and nobody asked you.

Our Backup and Disaster Recovery: A Complete Guide covers the definitions and the 3-2-1 rule. This post does the next part. It treats both numbers as price dials, shows you where the price starts climbing, and gives you a way to decide where to stop.

Why a tighter RTO and RPO costs more than you expect

A tighter RTO and RPO costs more because past a certain point you stop changing a schedule and start buying a second set of hardware. The cost curve is non-linear. It is almost flat on the right and steep on the left, and the last hour is the expensive one.

The three largest cloud providers publish the same warning in their own engineering guidance. Google Cloud's disaster recovery planning guide says the smaller your RTO and RPO values are, the more your application will cost to run, and that smaller RTO and RPO values often mean greater complexity. AWS describes its four recovery strategies as ranging from the low cost and low complexity of making backups to more complex strategies using multiple active Regions. Microsoft's Azure guidance says higher service levels can add complexity and increase cost and tells architects to weigh the trade-offs between cost, reliability, and complexity.

Five rungs explain where the money goes. The jump that matters is between the second and the third.

• Daily backup. One job runs overnight inside a quiet backup window. RPO of 24 hours, RTO in hours or days. The cheapest rung, and where most small firms actually sit.
• Hourly snapshots. You raise the snapshot frequency and pay for storage and bandwidth. RPO drops to an hour. Nothing structural changes, so the invoice moves a little.
• Continuous replication. Every write is replicated to a second copy as it happens. RPO falls to seconds. You now pay for a live link and a second live data store that runs all year.
• Warm standby. AWS describes this as a scaled down, but fully functional, copy of your production environment in another Region. You pay to keep a smaller second environment running whether you need it or not.
• Hot standby. AWS says you provision sufficient capacity such that the recovery Region can handle the full production load as deployed. That is a duplicate of everything, priced like a duplicate of everything.

Read the ladder again and the shape of the bill is obvious. Going from a 24-hour RPO to a one-hour RPO is a scheduling change. Going from one hour to near zero is an architecture change. AWS is blunt about the top rung, calling multi-site active/active the most complex and costly approach to disaster recovery, but it can reduce your recovery time to near zero.

The bottom of the ladder has a name too. A cold standby holds the data and runs nothing, so you rebuild the environment before you recover anything. Google Cloud groups the same options as cold, warm, or hot patterns and compares them with tires. Cold means no spare at all. Hot means run-flat tires you never stop driving on.

Nobody sells you the curve. They sell you a rung, and the rung they default to is the one that is easiest for them to run.

The RPO trap: near-zero replication copies the attack too

Continuous replication buys a near-zero RPO and can hand an attacker your second copy in the same second. Replication copies every change faithfully, including an encryption routine working its way through your files.

AWS says this in its own disaster recovery whitepaper, while selling the service. Continuous replication has the advantage of being the shortest time (near zero) to back up your data, but may not protect against disaster events such as data corruption or malicious attack (such as unauthorized data deletion) as well as point-in-time backups. That sentence should change how you read your next proposal. A number closer to zero is not automatically a number closer to safe.

So a good plan does two different things at once. You replicate for the hardware failure, where the newest copy is the best copy. You hold point-in-time snapshots for the attack, where the newest copy is the worst copy and you want the last clean one. Those are separate line items, and a provider who sold you only the first has left a gap. Sophos surveyed 2,158 organizations of 100 to 5,000 employees across 17 countries and found only one in three smaller organizations stopped the attack before encryption.

One question settles it. Ask your provider which copy you would restore from if ransomware encrypted the file server at 2pm, and how old that copy would be. A near-zero answer is the wrong answer here, and a provider who gives it has not thought about the attack at all.

How to work out what an hour of downtime costs you

To work out your downtime cost, add four things for a single hour. Lost gross profit on the sales you cannot take, payroll for the staff who cannot work, the labour to recover, and any penalty for a deadline you would miss.

Start by throwing out the published figures, because they describe somebody else. ITIC's eleventh annual downtime survey found 97 percent of large enterprises with more than 1,000 employees say an hour of downtime costs over $100,000, and 41 percent put it between $1 million and over $5 million. Then look at who reported cheap downtime. Only 4 percent of respondents said downtime costs them less than $100,000, and 93 percent of that group were micro firms with fewer than 10 employees. The sample was 27 percent firms of up to 200 users, 28 percent of 201 to 1,000 users, and 45 percent large enterprises, and the figures exclude the cost of litigation, fines or civil or criminal penalties. An owner reading $100,000 an hour is reading an enterprise average and has no way to act on it.

Now quantify your own hour. Four inputs, all of which you already hold.

• Revenue per trading hour. Divide last year's revenue by the hours you actually trade, then take the gross margin on it. Lost sales rarely arrive later in full.
• Payroll while idle. The Bureau of Labor Statistics puts total employer compensation costs for private industry workers at $46.89 per hour worked. Multiply that by the people who cannot work.
• Recovery labour. Your provider's hourly rate times the hours in its own restore estimate. Ask for that estimate in writing before you need it.
• Deadline penalties. Payroll runs, tax filings, customer service level agreement credits and tender submissions all sit on fixed dates that do not move for your outage.

Work an example. Take a ten-person firm turning over $3 million across 2,000 trading hours. That is $1,500 of revenue an hour, or $600 of gross profit at a 40 percent margin. Add ten idle staff at $46.89 each and the hour costs roughly $1,070 before anyone starts the recovery. Measure your own version of that figure once, because it is the number you negotiate with, and it is nowhere near $100,000.

Do the same sum for the RPO. The cost of data loss is the hours of work you would redo plus the records nobody can reconstruct. Twenty staff losing a morning is about 140 hours of re-keying, and the orders taken by phone that morning are simply gone.

Where the two curves cross

Buy a tighter target only while the downtime it prevents costs more than the upgrade. Multiply your hourly figure by the hours of downtime the next rung would actually save in a year, then compare that with its annual price.

That one sum turns a vague argument into a measurable decision. A continuous replication upgrade at $9,000 a year has to prevent about eight hours of downtime a year at $1,070 an hour to break even. If your systems were down for two hours last year, the answer is no, and now you can say no with a number instead of a feeling.

The tail risk sits on the other side of the sum, and it is why nobody should set these targets from the average week alone. IBM puts the global average cost of a data breach at $4.99 million and reports that it takes an average of 247 days to identify and contain an active breach across all industries. A plan tuned only to a failed disk ignores the quarter that ends the business.

Deadlines move the answer more than revenue does. A listed company files a Form 8-K generally within four business days after it determines a cybersecurity incident is material. Regulated SMBs carry their own fixed dates, from payroll filings to clinical reporting. Where a deadline is fixed and the penalty is large, your maximum tolerable downtime is set by the calendar rather than by your margin, and no amount of arguing about revenue changes it.

One company-wide RTO is almost always wrong

One company-wide RTO is wrong because your phone system and your 2019 project archive do not cost the same per hour to lose. Set a target per system and you stop paying premium prices to protect the folders nobody opened this year.

This is tiering, and in regulated sectors it is already the law. The HIPAA Security Rule contingency plan standard requires covered entities to assess the relative criticality of specific applications and data and to carry out periodic testing and revision of contingency plans. FEMA says priorities for IT recovery should be consistent with the priorities for recovery of business functions and that the recovery time for an IT resource should match the recovery time objective for the business function or process that depends on it. Microsoft's guidance assumes a business impact assessment for each solution, with defined recovery point objective, recovery time objective and mean time to repair metrics. Note the words for each solution.

The exercise behind all of that has a name. A business impact analysis is where you work out, system by system, what an hour without it actually does to the business. It is the only honest input to either target.

Google Cloud shows how far apart the answers land. It says compliance data justifies a large RTO value and cold DR pattern, an online service needs a hot pattern, and an email notification system is probably a candidate for a warm pattern because it typically isn't business critical. Same company, three different answers, three different prices.

Rank your own systems in an afternoon. Four tiers is enough for most firms.

• Tier 1, minutes. The systems that stop money moving. Card payments, the order database, the phone system.
• Tier 2, hours. Systems that slow the business without stopping it. Email, the main line-of-business application, the quoting tool.
• Tier 3, one day. Departmental file shares where people can work on paper for a day and catch up afterwards.
• Tier 4, one week. Archives, closed project folders, historical reporting data nobody will miss before Friday.

Prioritize honestly and the saving is real. Most firms find two or three systems in tier 1 and everything else below it. A single near-zero RPO across the whole estate funds continuous replication for data that has not changed since 2023.

FEMA adds the step almost every plan skips. It says data restoration times should be confirmed and compared with the IT and business function recovery time objectives. A target nobody has ever timed is a guess with a decimal point.

What to put in the contract

Put a per-system RTO and RPO in the service level agreement, name the measurement method, and require a report that shows the achieved figure beside the target. A proposal is marketing. A contractual number is something you can point at.

Specify these seven lines.

• Name the RTO and RPO for each tier, in hours or minutes, system by system rather than company-wide.
• State which copy each target is served from, including whether any copy is point-in-time rather than replicated.
• Define when the clock starts, because a clock that starts when an engineer opens the ticket is not a clock that starts at the outage.
• Separate the failover target from the restore target, because switching to a standby and rebuilding from backup are different jobs with different times.
• Record the snapshot frequency and the backup window, so you can see when a quiet change loosens your RPO.
• Fix the reporting, so the achieved time appears beside the agreed time every quarter.
• Agree what happens when a target is missed, in credits rather than apologies.

Then test it, because an untimed target is a number in a document. We cover the evidence to ask for in When was your backup last restored, not just run?. For the split between keeping the business trading and recovering the systems, read Business Continuity vs Disaster Recovery.

Six questions to ask your provider this week

Six questions tell you whether your targets were chosen or inherited. Send them in one email and keep the reply, because the reply is your baseline.

• What RTO and RPO are we contracted to today, per system? Good answers arrive as a short table. Weak ones say we back up nightly.
• Who agreed those numbers, and on what date? Good names a person and a date. Weak cannot say, which means a vendor default quietly became your plan.
• What would a one-hour RPO cost, and what would 15 minutes cost? Good gives two prices and explains the technology change between them. Weak quotes one number for both.
• Which systems run on continuous replication, and which on point-in-time copies? You want both, on different systems, for the reason in the RPO trap above.
• If ransomware hit the file server at 2pm, which copy would we restore from? Good names the last clean point. Weak names the newest copy.
• When was the last timed restore, and how did the measured time compare with our RTO? Good gives both numbers without being chased.

Price every answer against your own hourly figure rather than against a brochure. Best IT MSP is an independent directory. We rank providers on verified rating and firmographic data across 24,491 roster rows in 730 city datasets, we label paid placement, and we do not sell IT services, so we have no replication licence to sell you.

None of this buys perfect uptime, and no honest provider promises it. What it buys is a pair of numbers you set on purpose, at a price you understood when you agreed it. That is a different position from the one most owners are in today, which is owning two numbers somebody else picked and nobody ever priced.

FAQ

What is the difference between RTO and RPO?

Recovery time objective is how long your systems can be down. Recovery point objective is how much data you can afford to lose, measured in time. RTO looks forward from the outage, RPO looks backward. NIST defines RTO as the overall length of time an information system's components can be in the recovery phase before negatively impacting the organization's mission.

What is RPO, in plain terms?

Recovery point objective is the age of the newest copy you could restore. Back up once at 11pm and your RPO is 24 hours, so a 4pm failure loses a day of work. Lowering it means raising snapshot frequency, and below about an hour it means replicating every write, which AWS calls the shortest time (near zero) to back up your data.

How do I decide what RTO and RPO my business needs?

To decide, price one hour of downtime first. Add lost gross profit, idle payroll, recovery labour and any deadline penalty. The Bureau of Labor Statistics puts total employer compensation costs for private industry workers at $46.89 per hour worked. Then buy the next tier only while an hour of loss exceeds what that tier costs to own.

Should every system have the same RTO?

No. Rank systems into tiers, because an order database and an archive do not cost the same per hour to lose. The HIPAA Security Rule requires covered entities to assess the relative criticality of specific applications and data, and FEMA says priorities for IT recovery should be consistent with the priorities for recovery of business functions.

Why does a shorter RTO cost so much more?

Because past about an hour you stop changing a schedule and start duplicating infrastructure. Google Cloud says the smaller your RTO and RPO values are, the more your application will cost to run. AWS calls near-zero recovery the most complex and costly approach to disaster recovery, and a warm standby already means a second environment running all year.

← All Blogs