How to Set RTO and RPO for a Business Application: A Practical Planning Guide

RTO and RPO answer different recovery questions

Recovery time objective (RTO) is how long a system or business process can be unavailable before the impact becomes unacceptable. Recovery point objective (RPO) is how much recent data the business can afford to lose, expressed as a period of time.

Imagine an application fails after its last recoverable backup was made the previous evening. RPO describes the amount of work entered since that recovery point that might be lost. RTO describes how long the business can tolerate the application being unavailable while it is restored and made usable again.

These objectives are related, but one does not determine the other. A business might need an application back quickly while being able to recreate some recent data, or it might tolerate a longer outage but have very little tolerance for losing transactions.

Begin with the business workflow, not the server

List the work the application supports before discussing recovery targets. A CRM may support sales and customer service; an online store may support product browsing, orders and payment processing. The important question is what people cannot do when the application is unavailable or its data is out of date.

For each workflow, identify who is affected, whether work stops completely, and what alternatives exist. Staff might be able to record requests temporarily in another approved system, for example, but that workaround may be slow, limited or unsuitable for some data.

A useful starting point is a short business impact assessment: identify the critical processes, the systems they rely on and the consequences of interruption. Include people who perform the work, not only the person responsible for the application.

• Name the workflow and the application features it depends on.
• Identify the staff, customers or partners affected by an interruption.
• Record any manual or alternate process, its limits and who can authorize its use.
• Note which business activities must resume first.

Estimate downtime impact across different periods

Do not choose an RTO because a particular number sounds reassuring. Estimate what an outage means over several periods, such as a short interruption, part of a working day and a longer disruption. The right intervals depend on how the business operates.

Consider lost sales, missed service commitments, staff unable to work, delayed decisions and customers who may go elsewhere. Ask when the combined impact exceeds what the business can absorb. That point helps define an RTO objective; it is not proof that recovery will finish by then.

Separate the time needed to restore technical access from the time needed to resume the business process. An application may be running while staff still need to verify records, confirm access or work through a backlog.

• Describe the consequences of an outage at each time interval you choose.
• Include operational disruption as well as direct financial effects.
• Identify the point at which a workaround stops being acceptable.
• Agree what “recovered” means for the workflow, not just for the server.

Choose an RPO by examining what data can be recreated

For each workflow, identify the records created or changed during normal work and ask how much of that information could be reconstructed after a disruption. A product catalog may be recoverable from another source, while recent orders, payments or customer updates may be difficult or impossible to recreate accurately.

The acceptable data-loss period can differ between parts of the same application. Consider what would happen if the business had to re-enter recent work, and whether that re-entry would be complete, timely and safe. Include the risk of duplicate or inconsistent records if people use a workaround during an outage.

Write the RPO as a business tolerance, not as an assumption about how often data is saved. The recovery arrangements must then be checked against that tolerance.

• List important data by workflow, including transactions, uploaded files and changes to existing records.
• Classify each item as easy, difficult or impossible to recreate.
• Ask how much recent work could be repeated without unacceptable cost, confusion or risk.
• Record the acceptable age of recoverable data for each workflow.

Map dependencies that recovery also needs

An application is only one part of its service. Recovery planning should include supporting technologies and services that affect the business process, even if they are not usually treated as critical on their own.

Trace the path a user follows to complete the work. Depending on the application, that path may involve a database, uploaded files, identity or authentication, DNS, routing, TLS certificates, email or other external services. Confirm which dependencies are essential, who manages them and what must happen before users can work again.

Also consider integrations and external partners. A restored application may not support the workflow if an essential connected service is unavailable or its connection needs attention.

• List the application, database and files needed for the workflow.
• Include access, domain-name and connection dependencies where relevant.
• Record external services and partners that the application relies on.
• Identify an owner or contact for each dependency and note the recovery order.

Set separate targets where business criticality differs

A single RTO and RPO for every application can hide important differences. Set objectives for the application or workflow based on its business impact, data-loss tolerance and available alternatives.

For example, the workflow that accepts customer orders may have different recovery needs from an internal reporting workflow using the same application. Document the reason for each difference so the targets reflect business priorities rather than an informal ranking of software.

When several workflows depend on one application, note which one drives the recovery priority. Make sure the people who own those workflows agree with the proposed objectives.

• Group applications or workflows by business impact, not by technical convenience alone.
• Assign an RTO and RPO to each relevant group or use case.
• Explain the business reason behind each target.
• Review conflicts where one application serves workflows with different priorities.

Check that the objectives are achievable

A target is useful only if the chosen deployment and recovery arrangements can reasonably support it. Compare each objective with the actual ways the application and its data can be recovered. Consider dependencies, decision time, access to the recovery process and the work needed to verify the restored service.

Do not assume that a backup schedule is the same as an RPO, or that a backup being available proves an RTO can be met. The organization needs to understand what is included in recovery, how the required data and services are brought back, and how operational readiness is confirmed.

Airbip manages deployments of catalog applications as Docker workloads on its cloud servers, automates routing and TLS certificates through Traefik and Let’s Encrypt, and provides DNS checks, service lifecycle management and configurable daily, weekly and monthly backups. These capabilities are not a promise that a particular RTO or RPO will be achieved. Review the live service details and the recovery needs of your specific application before deciding whether the arrangement fits.

If the proposed targets cannot be supported by the recovery arrangements, revisit the objectives, the business workaround or the deployment approach. Do not label an untested target as a guarantee.

• Confirm what data and dependencies are covered by the recovery arrangement.
• Check how recovery is initiated and who has the access and authority to do it.
• Compare backup timing and restoration procedures with the RPO and RTO objectives.
• Identify gaps, assumptions and decisions that need validation before relying on the targets.

Turn targets into an owned, tested recovery plan

Document more than the RTO and RPO. A practical plan names who decides that recovery should begin, who carries out each step, who verifies that the application is usable and who communicates with staff, customers or partners.

Set clear decision points: how an incident is recognized, who is authorized to declare a disruption, when a workaround should be used and what checks are needed before normal work resumes. Include the order for restoring dependencies and the process for handling work created during the interruption.

Test the plan and record what happened. A recovery objective is a target to validate, not evidence that recovery will meet it. Exercises can reveal unclear ownership, missing access, overlooked dependencies or a gap between the stated target and the recovery process.

After a test or real disruption, update the objectives and procedures where necessary. Changes to workflows, data importance, integrations or operating arrangements can make an older recovery plan inaccurate.

• Name a decision-maker, recovery owners and communications owners.
• Write the recovery steps and dependency order in language responders can follow.
• Define the checks that show the service and business workflow are usable.
• Test the plan, capture results and track unresolved gaps.
• Review targets when business processes or application dependencies change.