A business should recover each service within the time its business impact analysis shows it can be down before the harm becomes unacceptable. That limit is the recovery time objective, and the data the service can afford to lose is the recovery point objective. No universal number exists.
Operational resilience is the ability to keep important services within those limits. This article sets out how to find those limits service by service, and how to prove they can be met. It draws on NIST’s definitions, the UK Financial Conduct Authority’s rules on important business services, and the EU’s Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, which has applied to financial entities since 17 January 2025.
Recovery time and recovery point objectives
NIST defines both terms in SP 800-34 Rev. 1. The recovery time objective (RTO) is how long a system’s components can be in the recovery phase before the organization’s mission or business processes are harmed. The recovery point objective (RPO) is the point in time to which data must be recovered after an outage.
Each answers a different question. The RTO says how fast the service must be back. The RPO says how much recent data the business can afford to lose or re-create, which in practice decides how often data is backed up or copied.
Set both from a business impact analysis
NIST defines a business impact analysis (BIA) as the process of analyzing operational functions and the effect a disruption might have on them. It is where recovery objectives come from. A figure copied from another company or a survey describes someone else’s business.
- List the services customers and the business would notice losing, such as taking orders, paying suppliers or answering support calls.
- For each service, describe how the harm grows as the outage lengthens, in lost revenue, customers unable to act, missed legal deadlines and safety.
- Find the point where that harm becomes unacceptable, and have the service’s business owner sign it off.
- Set the RTO inside that point, and set the RPO at the amount of data the service can afford to lose.
- Check that the technology can meet both, because the backup schedule sets the shortest RPO a service can achieve.
DORA asks the same of financial entities. Article 11 requires a BIA of their exposure to severe business disruptions. Article 12 has them set recovery time and recovery point objectives for each function, taking into account whether the function is critical or important. The regulation’s recitals say firms may set those objectives flexibly, so DORA gives no single recovery time either.
Important business services and impact tolerances
The UK Financial Conduct Authority builds its operational resilience rules around important business services. Its rules came into force on 31 March 2022, and by that date firms had to identify their important business services and set impact tolerances for the maximum tolerable disruption. By 31 March 2025 they had to finish the mapping and testing that shows they can stay within those tolerances.
The idea works outside UK finance too: start from the service a customer receives and set the limit from the customer’s side. A system that comes back on time does not restore the service if a supplier it needs is still down.
Map every dependency, including third parties
Recovery fails at the dependency nobody listed. For each important service, map the people, processes, systems, data, sites and suppliers it needs, and the suppliers those suppliers rely on where you can find out.
DORA makes this explicit for financial entities. Article 8 requires them to identify and document every process that depends on an ICT third-party service provider. Article 11 has the BIA consider third-party dependencies, and Article 28 requires a register of information on every contractual arrangement for ICT services from third-party providers.
Cloud providers belong on that map. In the DigitalXForce Security Posture Benchmark 2026, 33.6% of companies report at least one business continuity control not in place in their published CSA STAR answers. Ask each provider behind an important service for its recovery objectives and the date it last tested them, and use the 30 minute cloud vendor review for the rest of that check.
Test against the objectives, and record the result
A recovery plan that has not been tested is an estimate. Test in rising order of realism: a tabletop walk-through with the people who would run the recovery, a restore of real data from backup, then a failover of a whole service. Record the time each recovery took and the point its data was restored to, and compare both with the RTO and RPO.
Include a supplier failure among the scenarios. Ask what the service does if a cloud provider or a critical software supplier is unavailable, and whether the fallback works inside the RTO.
DORA sets a floor for financial entities. Article 11 requires them to test their ICT business continuity plans and their ICT response and recovery plans at least yearly, and after substantive changes to systems that support critical or important functions. Fix what each test shows, then test again, and report the gap between the objective and the achieved time.
What DigitalXForce does here, and what it does not
This is the model DigitalXForce runs in X-BCOR, its Business Continuity and Operational Resilience module, which ties the BIA, continuity plans and disaster recovery plans to live control coverage. The glossary entry for X-BCOR gives the short definition, including its scenario planning, control dependency mapping and DORA alignment.
DigitalXForce does not restore systems, run backups or fail workloads over. That work belongs to your backup, disaster recovery and infrastructure tools and the team that runs them. A business with a handful of systems at one site can run its BIA and its recovery tests from a spreadsheet and a calendar.
Backups decide the RPO a service can meet, and the article on preventing ransomware attacks covers them with the other basic controls. The article on risk and resilience integration explains how a control failure becomes a resilience decision.
Questions about outage recovery
What is a good recovery time objective?
A good RTO is one set from your own business impact analysis and proven by a test. The right value depends on the harm each service causes when it is down, so a figure from another business does not transfer to yours.
What is the difference between RTO and RPO?
The RTO is how long a service can be in recovery before the business is harmed. The RPO is the point in time to which data must be recovered, which sets how much recent data can be lost. NIST defines both in SP 800-34 Rev. 1.
What is operational resilience?
Operational resilience is the ability to keep important business services within tolerable limits through a disruption and to recover them within those limits. The UK Financial Conduct Authority builds its rules on important business services and impact tolerances, and DORA applies the idea to EU financial entities.
Does DORA set a maximum recovery time?
DORA sets no single recovery time. Article 12 has financial entities set recovery time and recovery point objectives for each function, taking into account whether it is critical or important. DORA has applied since 17 January 2025.
How often should recovery plans be tested?
DigitalXForce recommends testing at least once a year and after any major change to the systems an important service depends on. That matches DORA’s floor for financial entities, which is at least yearly and after substantive changes to systems supporting critical or important functions.
Should cloud providers be part of a business continuity plan?
A cloud provider belongs in the plan whenever an important service depends on it. Map it as a dependency, ask for its recovery objectives and last test date, and plan what the service does if it is unavailable. In the DigitalXForce Security Posture Benchmark 2026, 33.6% of companies report at least one business continuity control not in place.
Sources
- NIST defines the recovery time objective at https://csrc.nist.gov/glossary/term/recovery_time_objective, read on 24 September 2026.
- NIST defines the recovery point objective at https://csrc.nist.gov/glossary/term/recovery_point_objective, read on 24 September 2026.
- NIST defines the business impact analysis at https://csrc.nist.gov/glossary/term/business_impact_analysis, read on 24 September 2026.
- The Financial Conduct Authority sets out its operational resilience rules in PS21/3 at https://www.fca.org.uk/publications/policy-statements/ps21-3-building-operational-resilience, read on 24 September 2026.
- The text of DORA, Regulation (EU) 2022/2554, including recital 50 and Articles 1, 8, 11, 12, 28 and 64, is at https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R2554, read on 24 September 2026.
- The DigitalXForce Security Posture Benchmark 2026 is at https://digitalxforce.com/research/security-posture-benchmark-2026/, built from CSA STAR Registry data retrieved on 26 August 2026.
Do this once instead of every audit
Every step above can be done by hand. DigitalXForce keeps the impact analysis, the dependency map and the recovery plans tied to live control evidence, maps the result to 50+ frameworks once, and keeps the evidence current between audits. A 30 minute walkthrough on your own framework set shows what that removes from your calendar.
