What RTO Means for an MSP
Recovery time objective is the answer to a business question: how long can this client work without this system? The client decides it, you design to it. That order matters, because an RTO the MSP picked alone becomes a promise the client never agreed to pay for. RTO pairs with RPO, which covers how much data can be lost rather than how long the outage lasts.
Set RTO per system, not per client. Email, the line of business app and an archive share rarely need the same recovery speed, and treating them the same either overspends on the archive or underprotects the app.
The conversation works best in business terms. Ask what the client cannot do while a system is down, who is idle, which orders stop and which deadlines slip, then ask how long they could live with that. The answer is the RTO. Asking how fast they want restores to be only ever gets the answer immediately.
How RTO Drives What You Sell
| If the RTO is | The design usually needs |
|---|---|
| Minutes | Failover to a standby system or a cloud replica |
| Hours | Image-based backup with local restore or boot from backup |
| A day or more | Standard backup with restore from cloud storage |
Each step down that table costs less, which is why RTO is a pricing conversation as much as a technical one. Write the agreed RTO for each system into the agreement or its schedule, and make clear what happens when the client declines the design that would meet it. The answer on what a managed services agreement should include covers where that language belongs.
Proving You Can Meet It
A successful backup does not prove the RTO. Only a timed restore does, because the restore includes finding the right backup, pulling the data, rebuilding the server and checking the application works. If that takes longer than the objective, the objective is not met, whatever the backup report says.
- Run test restores on a schedule and record the elapsed time, not just a pass or fail.
- Track results as Restore Test Pass Rate beside Backup Success Rate.
- Include the time to reach the technician who can do the restore, especially out of hours.
- Review RTOs at the QBR when the client adds a system or changes how they work.
When a timed restore misses, raise it with the client with the options and their cost, rather than quietly absorbing the gap.
RTO During a Real Incident
An RTO is set for a failure, but the hardest test is ransomware. The restore cannot start until the environment is clean, the attacker is out and you know which backup predates the compromise. Build that investigation time into how you talk about RTO, and keep a written runbook per client listing systems in restore order, who approves each step and where the credentials for the backup platform live if the main directory is down.
Common Questions
Is RTO the same as an SLA response time?
No. An SLA response time covers how fast you start work; RTO covers how long the system can stay down in total.
Can a client have a zero RTO?
Not in practice. Very short RTOs need redundant systems and are priced as such, so ask what the business actually loses per hour of downtime.
Who owns RTO when a SaaS app fails?
The SaaS vendor controls the recovery, so the client's RTO depends on the vendor's own commitments. Document that dependency.