A recovery time objective (RTO) is the length of time, measured from the start of a disruption, within which an organisation aims to have a given system, process or business activity working again. It is a planning target set in advance. An RTO of four hours for a payment system means that the organisation has designed its backup arrangements so that payments can resume within four hours of an outage.
The concept comes from business continuity management and information technology disaster recovery, and it is used in every industry. In financial services it carries particular weight, because regulators set expectations for how quickly critical services must be restored and because interruptions to payments, trading and settlement spread quickly to other firms. It is a core measure in managing operational risk.
The RTO is one of a group of continuity targets that are often confused:
- Recovery point objective. The maximum amount of data, expressed as a period of time, that the organisation can accept losing. A recovery point objective of fifteen minutes means that data must be backed up or replicated often enough that no more than the last fifteen minutes of transactions would be lost.
- Maximum tolerable period of disruption. The longest a process can be unavailable before the damage to the organisation becomes unacceptable. The RTO must be shorter than this, to leave a margin.
- Recovery time actual. The time recovery really takes, as measured in a test or a live incident, for comparison with the objective.
How an objective is set
Objectives are derived from a business impact analysis. For each business process, the organisation estimates how the consequences of an outage grow over time: lost revenue, contractual penalties, regulatory breaches, harm to customers and damage to reputation. This establishes how long the process can be down. Because a process depends on applications, data, infrastructure, staff and suppliers, the objective for each of those components must be short enough, in sequence, for the process as a whole to recover in time.
Cost is the counterweight. Very short objectives require duplicate infrastructure running in parallel at a second location, with automatic failover and continuous data replication. Longer objectives can be met more cheaply, by restoring from backups onto standby equipment. Organisations therefore group systems into tiers, with the shortest targets reserved for the most critical.
Regulatory expectations in finance
The best-known numerical standard applies to financial market infrastructures. The Principles for Financial Market Infrastructures, issued in 2012 by international standard-setters for payment systems, central securities depositories, securities settlement systems and central counterparties, state that the business continuity plan should be designed so that critical systems can resume operations within two hours of a disruptive event, and that settlement can be completed by the end of the day even in extreme circumstances.
For banks and other firms, supervisors generally require documented and tested continuity plans with defined objectives for critical functions, without always prescribing a number. The European Union's Digital Operational Resilience Act, which has applied since January 2025, requires financial entities to set recovery time and recovery point objectives for each function, taking account of whether it is critical or important, and to test their plans. Contracts with technology suppliers are expected to reflect these objectives, which links the subject to third-party risk and vendor risk management.
Relationship with impact tolerance
The operational resilience rules introduced in the United Kingdom use a related but different concept. A firm must set an impact tolerance for each important business service: the maximum level of disruption, usually expressed as a duration, beyond which there would be intolerable harm to customers or risk to market integrity or financial stability.
The differences are of perspective. An RTO is an internal target for a system or process, set with cost and risk appetite in mind, and a firm expects to meet it. An impact tolerance is defined for an outward-facing service from the point of view of those who use it, and represents an outer limit that must not be exceeded even in severe scenarios. The objectives for the underlying components, identified through operational resilience mapping, need to be consistent with the tolerance for the service they support, and will normally be considerably shorter.
Testing
An objective has value only if it has been shown to be achievable. Firms test by failing systems over to backup sites, restoring from backups and running simulated incidents, and they record the actual time taken. Testing frequently reveals that recovery takes longer than planned, because of undocumented dependencies between systems, steps that rely on particular individuals, or data that must be reconciled before processing can restart.
Limitations
A single time target simplifies a complex reality. Recovery from a hardware failure, for which replication to a second site works well, is very different from recovery from ransomware or data corruption, where the replicated copy may be corrupted too. Widespread use of the same cloud and software providers means that many firms' recovery plans may depend on the same supplier, a concentration that regulators address through critical third-party oversight. Broader threats are considered under cybersecurity risk.