Knowing how to set RTO and RPO starts with a business question: how long can a service be unavailable, and how much recent work can the organization afford to lose? Those answers should come from the people responsible for business operations, with IT validating what can actually be recovered.
Recovery time objective (RTO) describes the target time to restore a service after a disruption. Recovery point objective (RPO) describes how far back in time recovered data may go, which determines how much recent work could be lost. They are related, but they measure different impacts.
A short RTO does not automatically require a short RPO, and vice versa. A system might need to return quickly while tolerating some recent data re-entry, or it might be acceptable for a service to remain unavailable while its data must be restored to a very recent point. The right targets depend on how the business uses the system.
Start with business impact, not backup settings
Before setting targets, identify what the business needs to keep doing during a disruption. A business impact analysis helps connect systems to essential processes and examine how disruption affects customers, employees, revenue, cash flow, obligations, and operations over time. NIST’s contingency planning guidance provides a framework for organizing this kind of planning.
Bring process owners and technology staff into the same discussion. Ask questions such as:
- Which customer, patient, or internal services stop if this system is unavailable?
- Could a disruption create safety concerns, missed commitments, or significant operational backlogs?
- What work can continue manually, and for how long before the workaround becomes unreliable or costly?
- What data would need to be recreated if the most recent changes were missing?
- Are there contractual or sector-specific obligations the organization should account for?
Assess the effect of a disruption as it continues, rather than treating downtime as a single condition. A brief outage may be manageable, while a longer one could disrupt customer service, interrupt cash flow, or prevent other essential work. Record the point at which the impact becomes unacceptable. That is the business’s maximum tolerable downtime, not necessarily the recovery target itself.
Set an RTO that leaves room to recover
To determine a system’s RTO, agree on when the service must be usable again to avoid unacceptable business impact. The target should be shorter than the maximum tolerable downtime. Allow room for the actual recovery work, including restoring components, checking that the service operates correctly, and confirming that the people who rely on it can access it.
Be precise about what “recovered” means. A server starting or a backup job completing does not necessarily mean a business service is ready. Define the outcome in operational terms: for example, whether users can sign in, complete the essential workflow, and access the information they need.
Then ask IT and relevant providers whether the proposed target is achievable with the current recovery methods, staffing, infrastructure, and budget. If it is not, leadership has a decision to make: change the recovery capability, accept a different level of business risk, or alter the process so the impact of an outage is lower. Do not record a target as a promise unless the organization has a credible way to meet and test it.
Set an RPO around the cost of lost work
To set an RPO, consider what would happen if the restored data did not include recent changes. Ask how much work could be recreated, who would need to do it, and whether a gap in records could affect customers, operations, reporting, or decisions.
Consider how the system’s data is created and used. A shared document repository may have different recovery needs from a system that records orders, appointments, payments, or work in progress. Look at how frequently information changes, whether other records can help rebuild it, and whether staff can reliably identify what is missing.
Turn those discussions into a clear business tolerance, then have technical teams assess whether the existing backup and recovery approach supports it. A backup’s schedule alone does not confirm the actual recovery point. The organization should verify the recovered data and identify any gaps that require manual reconstruction.
Map systems and dependencies before prioritizing
Set targets for business services and the systems that support them, not only for a list of servers or applications. A service may depend on identity and access, network connections, integrations, cloud providers, devices, facilities, staff, and external partners. If a dependency is unavailable, restoring the main application may not restore the business process.
Create a simple dependency map for each important service. Note which components must be available first, who owns them, and whether they are shared with other services. Use that map to sequence recovery. A component that supports several essential processes may deserve earlier attention than a standalone application, even if its direct business impact seems less visible.
Check whether recovery targets conflict. If a business service depends on several systems, its end-to-end recovery may take longer than the target assigned to any individual component. The service owner and IT team should agree on an achievable sequence, including the time needed to reconnect components and verify the full workflow.
For broader planning context, see Zevonix’s guidance on effective technology planning and technology strategy and planning.
Document targets in a practical worksheet
A recovery worksheet makes decisions visible and easier to review. For each business service, capture:
- The business process and its accountable owner.
- The systems, data, people, providers, and facilities it depends on.
- The impact of disruption as it continues, including workarounds and when they stop being sufficient.
- The maximum tolerable downtime and the agreed RTO.
- The acceptable data-loss window and the agreed RPO.
- How the team will know the service and its data are fully restored.
- Recovery method, responsible roles, known gaps, and the next validation activity.
Use the worksheet to surface assumptions. If the business expects near-immediate access but its process depends on a provider with a slower recovery commitment, that mismatch needs an owner and a decision. CISA’s service continuity resource guide can help inform continuity planning and the way dependencies are considered.
Test whether the plan meets the targets
Test full service restoration, not just whether backups exist or a restore job completes. A useful exercise checks whether the team can recover the necessary systems in the planned order, regain access, verify data integrity, and complete the essential business workflow. Record the actual outcome and compare it with the agreed RTO and RPO.
If a test misses a target, treat the gap as a planning decision rather than a reason to quietly revise the target. Identify whether the cause is a technical limitation, unclear ownership, missing access, a provider dependency, or an unrealistic assumption. Then decide what change is needed and who will take responsibility for it.
Review targets when business processes, data volumes, technology, providers, or the consequences of disruption change. Microsoft’s overview of business continuity and disaster recovery also distinguishes recovery planning from availability approaches, which can help teams clarify what their plans are meant to achieve.
Frequently asked questions
Should RTO be shorter than maximum tolerable downtime?
Yes. Maximum tolerable downtime describes the point at which disruption becomes unacceptable. Set the RTO earlier, leaving time to complete recovery and verify that the service is usable before that point.
How do system dependencies affect recovery priorities?
Dependencies can determine whether a service can function at all. Map the components, people, and providers it needs, then plan a recovery sequence that brings those dependencies online in a workable order.
How can a business check whether backups meet its targets?
Restore data and systems in a planned test, then measure the time to usable service and confirm the recovered data is intact and recent enough for the agreed RPO. A completed backup alone does not demonstrate that end-to-end recovery will meet the targets.
Make recovery targets an owned business decision
Effective RTO and RPO targets connect business impact to technical capability. Identify essential processes, assess the consequences of disruption and lost work, map dependencies, and test whether recovery delivers the outcome the business needs. Start by bringing process owners and IT together to document targets for the services that matter most, then assign owners to resolve any gaps.