RTO and RPO Are Business Decisions

The Decision in Front of You

Two numbers govern disaster recovery. The recovery time objective (RTO) is the longest a system can stay unavailable before the harm becomes unacceptable. The recovery point objective (RPO) is how far back in time the restored data may be, which sets how much recent work the company is prepared to lose. Both sit inside a wider limit set by the business owner, the maximum tolerable downtime of the process, and the RTO must be shorter than it ¹.

These numbers size the disaster recovery budget. A one-hour RTO with near-zero data loss needs a second running environment and continuous replication. A three-day RTO with a one-day RPO needs good backups and a tested rebuild procedure. In the illustrative model in Exhibit 2, the first design costs fifteen times as much as the second each year, and the choice repeats for every system.

The decision for leadership is who sets the targets. NIST SP 800-34 Rev. 1, the federal contingency planning guide, describes a curve where the cost of disruption rises the longer an outage runs while the cost of recovery rises as the RTO shrinks. The right target sits where the two curves meet ¹. The business knows the first curve and IT knows the second, yet most companies let one side draw both.

What's Happening

Confident targets, loose alignment

Veeam's Data Trust and Resilience Report 2026, based on more than 900 senior IT, security, and risk leaders, found 90% were confident they could recover within their RTOs. Only 69% said those RTOs were fully aligned with business continuity goals ². The vendor sells recovery software, so treat the figures with caution.

Regulators now ask who set the number

In the United Kingdom, the Financial Conduct Authority's operational resilience rules (PS21/3) required firms, by March 31, 2025, to set an impact tolerance for each important business service and show they can stay within it in severe but plausible scenarios ³. An impact tolerance is the most disruption a service can suffer before harm becomes intolerable. The FCA reported in 2024 that it had seen a wide range of tolerances with limited rationale for where intolerable harm begins, and it expects the board to approve the firm's self-assessment ³.

In the European Union, the Digital Operational Resilience Act (DORA) has applied in full since January 17, 2025 ⁴. Article 12 requires financial entities to set recovery time and recovery point objectives for each function, taking into account its criticality and its potential impact on market efficiency ⁵. Coverage of the related standards indicates Article 11 expects those objectives to rest on a business impact analysis and requires the continuity plans to be tested at least once a year ⁴.

In the United States, the FFIEC's Business Continuity Management booklet, issued in November 2019, places continuity under board and senior management oversight and builds the program on a business impact analysis that estimates the cost of disruption over time ⁶⁷. The booklet defines RTO, RPO, and maximum tolerable downtime more fully than its predecessor ⁷. ISO 22301:2019, the international business continuity standard, also treats a business impact analysis that sets tolerable disruption periods and recovery objectives as a core requirement ⁸.

These rules bind financial firms, and the same reasoning fits any company whose revenue stops when its systems do.

Two recent cases

Delta Air Lines, July 2024. After the CrowdStrike software outage of July 2024, Delta recovered more slowly than other major U.S. airlines. It canceled about 7,000 flights and delayed more than 10,000 over five days, affecting about 1.3 million customers ⁹. Its chief executive put the cost at about $500 million ¹⁰. The outage disrupted Delta's crew-tracking system, which assigns pilots and flight attendants to flights, and the airline had to reset about 40,000 servers by hand ¹⁰. The U.S. Department of Transportation investigated the slow recovery and closed the probe in 2026 without seeking penalties ⁹. Public reporting does not say what recovery target Delta had set for crew tracking. The lesson is that the system that limits recovery is often a supporting one, and only the people who run the operation know which one it is.

Jaguar Land Rover, September 2025. JLR disclosed a cyberattack on September 2, 2025, stopped production at its major plants, and restarted in phases by October 8, roughly five weeks later ¹¹. It booked £196 million in incident costs in its July to September quarter, when it reported a loss before tax and exceptional items of £485 million against a £398 million profit a year earlier; tariffs and lower volumes also contributed ¹¹. The UK government approved a £1.5 billion loan guarantee to support the supply chain ¹¹. The Cyber Monitoring Centre, an independent body, estimated the total cost to the UK economy at £1.9 billion across more than 5,000 organizations ¹². For impact analysis, the lesson is that harm grows with time and spreads to suppliers, so a target set without that view understates what a week of downtime costs.

Why the Usual Approach Fails

When IT sets recovery targets alone, the first common failure is the uniform target. Someone writes "four-hour RTO, fifteen-minute RPO" for every system because it sounds responsible. Meeting it across the estate would need standby environments for payroll, the intranet, and the marketing site alongside the order system. When the quote arrives, the budget is cut, and the target stays in the plan anyway, now untrue.

The second is the reverse-engineered target. The team writes down what the current tooling happens to deliver, often "next business day" for everything. That number describes the technology. Nobody has checked whether the warehouse can ship without its system for a day, or whether a lost afternoon of orders can be re-keyed from email.

Both failures share a root cause. Downtime has never been priced per system by the people who own the revenue. NIST's guide assigns that task to process owners and business managers, working with the contingency planner to decide how much downtime and data loss each process can accept ¹. In the author's experience, the planner usually fills in the form alone.

Dependencies make it worse. Order taking depends on the order application, a database, an identity service, a network, and often a third-party platform. An RTO set for the application alone means little if the identity service recovers last, as Delta's crew-tracking delay showed ¹⁰.

The Framework: The Recovery Target Contract

Treat each recovery target as a contract. The business owner states what an outage would cost and signs for the risk, IT commits to build and prove the capability, and the CFO countersigns because the target sets the spend.

flowchart LR
    A[Impact<br/>owner prices<br/>downtime and data loss] --> B[Choose<br/>tier from a<br/>priced menu]
    B --> C[Sign<br/>owner and CFO<br/>approve RTO and RPO]
    C --> D[Engineer<br/>IT builds<br/>to the target]
    D --> E[Prove<br/>test and report<br/>gaps to leadership]
    E --> A

Impact. For each business service, the owner estimates the cost of an outage at one hour, one day, and one week, in revenue, penalties, customer loss, and regulatory exposure. The owner also estimates what an hour or a day of lost data would cost to re-create, and whether it can be re-created at all. Include suppliers and customers, as the JLR case shows ¹².

Choose. IT publishes a short menu of recovery tiers, each with an RTO, an RPO, and an annual cost. The owner picks a tier. Cost and impact sit on the same page, which is the comparison NIST's cost balance curve calls for ¹.

Sign. The business owner and the CFO sign the chosen RTO and RPO. The signature records who accepted the residual risk.

Engineer. IT builds every dependency of the service to the signed tier, sets backup frequency to the RPO, as NIST SP 800-53 expects ¹³, and records where the current design falls short.

Prove. Recovery is tested against the signed target, and any system that misses it goes to leadership with a date and a cost to fix. A target counts once a test has met it.

What a priced menu looks like

This illustrative model covers a hypothetical distributor's order system.

The model shows why IT cannot pick the tier alone. At $5,000 per hour of outage, Tier 3 becomes the cheapest choice for the same system. The per-hour figure comes from the business.

Costs, Risks, and Tradeoffs

How to Act

Questions to Ask Your Team

1. Who chose the recovery time and recovery point for our order system, and when?
2. What does one hour, one day, and one week of downtime cost on each of our top five services?
3. How much recent data could we lose on each of them, and could we re-create it?
4. Which of our written targets have we met in a test, and which have we never tried?
5. Which supporting systems, such as identity or scheduling, would recover last, and what waits on them?
6. Which vendors' recovery commitments are we relying on, and have we read them?

Closing

Recovery targets decide what an outage will cost and what the company spends to avoid it. Those are business choices with a price on each side. Have the people who own the revenue set the RTO and RPO for each system through an impact analysis, have the CFO sign them, and hold IT to building and proving exactly what was signed.