Knowing how to set RTO and RPO starts with a business question, not a backup setting: what happens if a system is unavailable, and what recent work could you afford to lose? The answers can differ across your business. A customer-facing application, a shared file system, and a tool used occasionally may not need identical recovery targets.
RTO and RPO turn those business needs into recovery goals. They are useful only when they reflect real operational consequences and when your backup, recovery process, and staff can support them. Here is a system-by-system way to set targets that are both meaningful and achievable.
Know what RTO and RPO mean
Recovery time objective (RTO) is the target for how long a system can be unavailable after an interruption before the impact becomes unacceptable. It helps you decide the order and approach for restoring systems.
Recovery point objective (RPO) is the amount of recent data, expressed as time, that the business can tolerate losing. It helps shape how often data needs to be backed up or replicated, and how you will confirm that usable data is available after an incident.
These goals are related, but they answer different questions. RTO is about downtime. RPO is about the gap between the incident and the newest recoverable data. A system could be restored quickly but from a backup that is too old to meet the business’s data-loss tolerance. Or the latest data could be protected, while restoring access takes longer than the business can accept.
Start with the work the system supports
List the business processes your organization needs to keep operating, then identify the systems that support them. Include more than major applications: consider identity and access, internet connectivity, network equipment, cloud services, websites, and systems managed by outside providers.
For each process, ask what an outage would mean as time passes. Could staff continue using a manual workaround? Would customers be unable to make purchases or receive service? Could payroll, scheduling, client work, or record keeping be delayed? For businesses with care, legal, financial, educational, or nonprofit responsibilities, consider how an interruption affects the people and obligations the organization serves.
A business impact analysis can help organize these questions. Ready.gov’s Business Impact Analysis Worksheet offers a structured way to consider the effects of disrupted functions and the resources they depend on.
Use a worksheet for each system
Keep the record simple enough to revisit. For each system, capture:
- Business process: What work does the system enable?
- Outage impact: What becomes difficult or impossible, and how does that impact change as downtime continues?
- Maximum tolerable downtime: At what point does the interruption become unacceptable?
- Target RTO: How soon does the system need to be restored to support the business?
- Acceptable RPO: How much recent data can the business afford to lose?
- Owner: Who can confirm the business need and approve the target?
- Dependencies: What must be available before this system can work?
Set targets based on consequences, not on what a backup product or service happens to offer. A vendor’s recovery capability can inform planning, but it does not determine what your business can tolerate. If the required target is not currently achievable, record the gap and decide whether to change the recovery approach, accept the risk, or adjust the business process.
Prioritize dependencies, not just applications
A system may be high priority but still unusable until its dependencies are restored. A business application might require working internet access, user accounts, authentication, a database, or a third-party service. Restoring the application alone may not let employees do their work.
Map the order of those dependencies and confirm who is responsible for each one. Ask which shared systems support several business processes. A dependency that looks routine on its own may deserve early attention if multiple critical services rely on it.
This is also why recovery priorities should be reviewed across the whole environment, rather than decided separately by each software owner. If your business is assessing how systems connect, see Zevonix’s guidance on small-business software integration. For cloud workloads, the recovery plan should account for the relevant environment and access requirements; the cloud services overview may help frame those questions.
Check whether backups and restores match the goals
Backup frequency affects whether you can meet an RPO, but the schedule by itself does not prove that you can. Confirm when data is captured, whether the copy is complete and accessible, and how you will identify a clean recovery point. Consider changes made in the system that may not be included in a backup or replica.
RTO depends on more than the time needed to copy files. It can include finding the right backup, preparing replacement equipment or an alternate environment, restoring data, reconnecting dependencies, confirming access, and checking that the system works for staff. Include the people and decisions required to carry out each step.
Test restores and recovery procedures, then compare what happened with the targets. A tabletop exercise can help staff walk through decisions and responsibilities. A hands-on restore can expose issues that a written plan may miss, such as missing credentials, unclear ownership, or a dependency that was not included. Record the results and update the plan when the test reveals a gap.
Plan for local disruptions as well as technical failures
For businesses in Jacksonville and Northeast Florida, consider whether a recovery plan still works if staff cannot reach the worksite or if power, connectivity, or building access is disrupted. A cyber incident and a regional storm may create different recovery needs, even when the same systems are involved. Decide where staff would work, how they would communicate, and which manual workarounds are practical.
JaxReady information for business owners can help inform local preparedness planning. Zevonix also has a guide to IT preparedness for Jacksonville-area businesses. Use local planning alongside system-specific recovery targets, not as a replacement for them.
Review goals when the business changes
Recovery targets can become outdated when an application changes, a new service is introduced, work moves to the cloud, or business processes shift. Revisit the worksheet when a significant change occurs, after a test or incident, and as part of your regular continuity planning. Confirm that system owners, dependencies, backup arrangements, and recovery responsibilities still match how the business operates.
Frequently asked questions
Should every application have the same RTO and RPO?
No. Set targets according to each system’s business impact, data needs, and dependencies. Some systems may support essential work, while others can remain unavailable longer or rely on a workable manual process.
How do I decide how much data loss is acceptable?
Ask the process owner what work would need to be repeated or reconstructed if recent data were unavailable. Consider the accuracy and practical effort involved, then use that consequence to define the acceptable RPO.
How can a small business check whether it can meet its goals?
Test recovery, measure the steps and time involved, confirm the recovered data is usable, and check that staff can access the system and its dependencies. Compare the results with the targets and address any gap.
How often should recovery goals be reviewed?
Review them when systems or business processes change, after recovery exercises or incidents, and during regular continuity planning. The important point is to keep the targets aligned with current operations.
Make recovery targets practical
RTO and RPO are useful when each one reflects the business process behind a system and a recovery method you have tested. Start with the impact, map dependencies, then validate that backups, people, and procedures can meet the targets. Zevonix provides IT support and technology services for small businesses in Jacksonville and Northeast Florida, including disaster recovery and backup support. If you are unsure whether your current plan matches your needs, discuss the systems and recovery steps with your IT provider.