Backup & Disaster Recovery

RPO/RTO Standards for MSPs

How to define, measure, and report Recovery Point Objectives and Recovery Time Objectives that are realistic, testable, and actually useful in a disaster.

KPI guide Â· Updated Feb 2026

By MSP Workflows Team

Contents

1.What RPO and RTO Actually Mean in Practice
2.Typical RPO/RTO Tiers for MSP Clients
3.How to Define RPO/RTO Per Client
4.How to Measure and Report RPO/RTO
5.Untested RPO/RTO targets are guesses
6.RPO/RTO and cyber insurance
7.What RPO/RTO should MSPs offer as a standard service tier?
8.How should RPO/RTO be documented in the MSA?
9.What happens when RPO/RTO targets can't be met?

What RPO and RTO Actually Mean in Practice

Recovery Point Objective (RPO) defines the maximum amount of data loss a client can tolerate, measured in time. An RPO of 1 hour means the client accepts losing up to 1 hour of data. In practice, this means your backup must run at least every hour. Recovery Time Objective (RTO) defines the maximum time from disaster declaration to system usability. An RTO of 4 hours means the client expects their systems back online within 4 hours of the decision to recover. These are not aspirational targets. They're commitments that should be tested, documented, and achievable with your current tooling and staffing. An RTO of 1 hour written in a contract but never tested against reality is a liability, not a standard.

Typical RPO/RTO Tiers for MSP Clients

Tier	RPO	RTO	Typical Systems	Backup Method
Critical	15 min to 1 hour	1 to 4 hours	Domain controllers, SQL servers, primary LOB apps	Image-based with BDR appliance
Important	4 to 8 hours	8 to 24 hours	Secondary servers, shared file stores	Image-based, daily incremental
Standard	24 hours	48 to 72 hours	Workstations, non-critical VMs	File-level or image-based, daily
Archive	Weekly or longer	1 to 2 weeks	Legacy data, compliance archives	File-level, weekly with long retention

How to Define RPO/RTO Per Client

Start with a business impact analysis, not a technical assessment. Ask the client: if this system goes down, how long can your team work without it? What's the cost per hour of downtime (lost revenue, idle staff, missed deadlines)? How much data can you afford to recreate manually? The answers define the tier. Most clients overestimate their tolerance for downtime until you translate it into dollars. A law firm that says "we can survive a day without the document server" changes their answer when you calculate that 8 attorneys at $300/hour billing rate lose $19,200 in a single day. Map each system to a tier, get client sign-off, and use the tier to drive backup configuration. This alignment between business requirement and technical implementation is what separates a backup service from a backup commodity.

How to Measure and Report RPO/RTO

RPO is measured during restore tests. The age of the restored data compared to the current time is your actual RPO. If the most recent backup was 45 minutes old and your RPO target is 1 hour, you're within spec. RTO is measured from the moment you decide to restore (not when the disaster occurred) to the moment the system is usable by end users. "Usable" means the application is functional, not just that the OS has booted. Include the time to verify functionality in your RTO measurement. Report both metrics per system, per client, per quarter. Compare actual measurements to targets. If actual consistently exceeds target, either improve the recovery process or adjust the target.

Untested RPO/RTO targets are guesses

If you've defined RPO and RTO in a contract but never measured them through a restore test, you don't know whether you can meet them. The first real disaster is the worst time to discover that your 4-hour RTO actually takes 12 hours because nobody accounted for the time to provision a replacement server and download 2 TB from the cloud.

RPO/RTO and cyber insurance

Cyber insurance applications increasingly ask about RPO and RTO targets and whether they've been tested. Having documented restore test results showing that you meet your stated objectives strengthens the client's application and can reduce premiums. Include this as a value-add in your backup service pitch.

What RPO/RTO should MSPs offer as a standard service tier?

A common standard tier is 1-hour RPO and 4-hour RTO for servers, 24-hour RPO and 24-hour RTO for workstations. Offer a premium tier (15-minute RPO, 1-hour RTO) for clients who need it and are willing to pay for faster backup and recovery infrastructure.

How should RPO/RTO be documented in the MSA?

Include a service schedule that lists each protected system, its assigned tier, the RPO and RTO targets for that tier, and a note that targets are validated through quarterly restore tests. Include a clause stating that targets assume client cooperation (such as providing replacement hardware within a defined window for on-premises recovery).

What happens when RPO/RTO targets can't be met?

If a restore test shows you can't meet the target, you have two options: invest in faster recovery infrastructure (larger BDR appliance, pre-staged cloud recovery, better bandwidth) or adjust the target to reflect reality. Never leave a target in the contract that you know you can't meet. That turns a recovery challenge into a breach-of-contract issue.

← Back to all guides