Recovery Time Objective and Recovery Point Objective: What RTO and RPO Actually Mean for Your Recovery Planning
You send out the BIA questionnaire. You ask people to estimate their Recovery Time Objective. A few days later, the responses come back: two hours. Two hours. Two hours. Every team, every system, every process, all marked as needing recovery within two hours.
It's not that people are being careless. It's that most stakeholders don't have the context to answer the question any other way. "How long can you be down?" sounds straightforward. But without a shared understanding of what impact looks like over time, the answer defaults to whatever feels safe.
This is one of the central challenges in setting Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) well. The terms are standard. The process for determining them is where it gets complicated.
Below, we cover what RTOs and RPOs are, how they should be determined, and where the process tends to break down, so you can build objectives that actually hold up when it matters.
What are RTO and RPO?
A Recovery Time Objective (RTO) is the maximum time a process, system, or activity can be unavailable before the impact becomes unacceptable to the organization. Defined by ISO 22301:2019, it sits within a broader timeframe called the Maximum Tolerable Period of Disruption (MTPD), the point beyond which recovery becomes inadequate regardless of effort.
A Recovery Point Objective (RPO) is the maximum amount of data loss a business can tolerate, measured in time. It defines the point to which information must be restored to allow an activity to resume at predefined levels (ISO 22300:2021). It's not about how fast you recover, it's about how far back you can afford to go.
To make the difference concrete: imagine your customer portal goes down during a peak trading window. The RTO tells you how long you have before the financial and reputational damage becomes unacceptable. The RPO tells you how much transaction data you can afford to lose, whether that's the last 15 minutes or the last four hours.
A service can have a short RTO but a longer RPO. A payroll system may need to restart within two hours (tight RTO), but you might be able to restore from yesterday's backup if processing hasn't run yet (looser RPO). The two objectives can, and often do, behave independently. Understanding that distinction is the first step to setting them properly.
Why RTO and RPO matter
Without defined recovery objectives, recovery decisions get made ad hoc under pressure. The result is vague language, "get it back as soon as possible," "minimize data loss", etc. that sounds reasonable until a real incident requires you to act on it.
Vague targets create several problems. They prevent you from designing recovery strategies with any precision. They make it impossible to brief leadership on impact during an incident. They leave IT teams guessing at acceptable trade-offs when designing backup and failover architectures. And they give regulators nothing credible to audit.
RTO and RPO translate business criticality into measurable targets. Once you have them, you can design recovery solutions that are sized to actual need, test whether those solutions work, and demonstrate compliance with a level of specificity that holds up under scrutiny. They are the connective tissue between business expectations and technical capability.
Regulatory frameworks are increasingly demanding this level of specificity. The UK’s Operational Resilience requirements ask firms to identify important business services and define impact tolerances—including maximum tolerable disruption, a concept closely aligned with RTO. DORA, NIS2, and sector‑specific standards in financial services and critical infrastructure are all moving in the same direction: away from “do you have a plan?” and toward “can you prove it works within defined, measurable parameters?”
Challenges in defining RTOs and RPOs
This is where most organizations run into difficulty and where the gap between documented objectives and operational reality tends to open up.
Everyone calls things critical
One of the most common problems: without structured guidance, business units default to labeling everything as high priority. "Our team can't function without this system. It needs to be recovered in two hours." When every team says the same thing, the result is a set of RTOs that would require an impossibly large simultaneous recovery effort, and a planning process that nobody trusts.
The Business Continuity Institute’s (BCI) Good Practice Guidelines flag this directly. The terms "critical," "key," and "priority" are often used interchangeably and can lead to "misunderstandings and exaggerations when collecting information for the BIA." The guidance recommends replacing these terms with "prioritized activities"; activities that urgency must be given to in order to avoid unacceptable impact.
In practice, this means asking better questions. Not "is this important?" but "what's the financial, regulatory, reputational, or customer impact if this is unavailable for two hours? For twelve? For 48?" Impact over time is the measure, not perceived importance.
Stakeholders don't understand what they're being asked
Getting accurate RTO and RPO data requires input from people who don't think in BCM terms. Send a questionnaire asking someone to estimate their team's RTO, and you'll often get a number that reflects anxiety rather than analysis. "Two hours for everything" is a common response, not because two hours is the right answer, but because the person completing the form doesn't have the context to estimate differently.
This is why the BCI stresses that BC professionals must actively challenge and ensure that data collection is "credible, complete, reasonable, sufficiently accurate, and justifiable." That challenge function is central to getting useful outputs from a BIA. It can't be delegated to a form.
Terminology creates inconsistency
Even when stakeholders engage genuinely, inconsistent language produces inconsistent data. What one team calls a "critical process," another calls a "supporting activity." What one region interprets as a four-hour tolerance, another interprets as a hard cutoff. Across large or distributed organizations, this inconsistency compounds quickly, and reconciling it downstream falls to the BCM team.
How RTO and RPO are determined
RTOs and RPOs are outputs of the Business Impact Analysis (BIA), not inputs to it. That distinction matters. You don't start with a target and work backward. You start with a structured analysis of impact over time and the objectives emerge from that analysis.
The BIA process, as described in the BCI’s Good Practice Guidelines, involves determining how the impact of a disruption grows over time for each prioritized activity. The MTPD is the outer boundary: the point at which impact becomes unacceptable regardless of how it is managed. The RTO sits inside that boundary: the timeframe within which the activity must resume at a specified minimum capacity. The RPO is set separately, focused specifically on data and information: how far back can you restore and still operate at acceptable levels?
Several factors influence where these objectives land:
Business factors: What is the financial exposure of an outage? What contractual or regulatory deadlines does the activity support? What are the customer-facing consequences of unavailability?
Operational factors: Does the activity have a manual workaround? How long could that workaround sustain the business? Are there seasonal peaks when tolerance narrows such as a payment run, a regulatory cut-off, a trading window?
Technology factors: What is the backup frequency for dependent data? What are the replication and failover capabilities of supporting systems? How long does actual recovery take in practice, not in theory?
Dependency factors: What third parties, suppliers, or internal teams does the activity depend on, and what are their recovery capabilities? A tight RTO is only achievable if the whole dependency chain can deliver.
Different processes and systems will have different objectives. A customer-facing transaction system may have a one-hour RTO and a 15-minute RPO. A back-office reporting process may have a 48-hour RTO and a 24-hour RPO. Setting the same objectives across the board is a sign that the analysis hasn't happened yet.
Ownership of this process typically spans several functions. Business owners should define the impact and priority. BCM or resilience teams should guide methodology and ensure consistency. IT, application owners, and infrastructure teams should confirm what is technically feasible. Where there is a gap between what the business needs and what the technology can deliver, leadership should make an informed, risk-based decision about whether to close it through investment or accept the residual risk.
How to make objectives realistic
An RTO is not a wish. It is a commitment backed by capability.
This is where many organizations have objectives on paper that would not survive contact with an actual incident. The plan says two-hour recovery. The backup runs nightly. The failover has never been tested. The team that would execute the recovery is not on call.
That's exactly why recovery objectives must be validated through exercises and tests that confirm whether the organization can actually meet them under realistic conditions. Tabletop exercises work through the logic of recovery, but they can't confirm whether the technical steps actually execute within the required timeframe. Recovery drills, backup restoration tests, and failover tests do that.
Validation should measure actual recovery time against target recovery time, and actual data loss against the RPO. Where there is a gap, it is a gap that needs to be closed through investment, workaround development, or a conscious decision to accept a different level of risk.
Unrealistic objectives don't just fail during incidents. They create false confidence before them, which is arguably more dangerous.
Keeping objectives current
RTOs and RPOs set today reflect the organization you have today. They will not automatically reflect the organization you have in twelve months.
Business changes, system upgrades, new vendor relationships, regulatory updates, organizational restructuring, any of these can shift the criticality of a process, change its dependencies, or alter the technical capability available to recover it.
In practice, this means building BIA refresh into your change management processes, not just your annual BCM calendar. When a new system goes live, when a key supplier changes, when a business unit restructures, those are the moments when existing RTOs and RPOs need to be revisited, not twelve months later during the next scheduled review.
Stale objectives create hidden risk: the organization believes it has a plan, but the plan no longer reflects operational reality.
Stronger objectives, stronger continuity
RTO and RPO are not bureaucratic checkboxes. When set properly, they give your recovery planning a foundation that is credible, testable, and defensible. They tell leadership what the organization can actually withstand. They guide investment decisions about where resilience gaps need to be closed. They give responders clarity during an incident, when there is no time for interpretation.
Getting them right requires a structured BIA process, genuine stakeholder engagement, honest challenge of the data, and regular review as the business changes. None of that is simple, but it is the work that makes continuity planning meaningful rather than just documented.
Running this process manually across a large organization is one of the hardest parts of BCM at scale. Discover how automation can help you scale your business continuity program.
