Blog

How Do You Set Recovery Times for Critical Processes in a Business Continuity Plan?

At a glance

Recovery times are set by business impact, not by technology preference: rank processes, then assign RTO and RPO per process.
RTO defines how long a critical process may stay down; RPO defines how much data loss is tolerable.
Boards and regulators expect documented, tested recovery targets, with dependencies and manual workarounds mapped alongside each process.
Life Titanium Risk Management - LT RISKMGMT advises banks, insurers, credit companies, investment houses and fintechs on operational risk and continuity.

LT RISKMGMT

Published: 2026-11-01

You set recovery times by ranking business processes according to the damage their interruption causes, then assigning each one a Recovery Time Objective (RTO) — the maximum period the process may remain unavailable — and a Recovery Point Objective (RPO) — the maximum volume of data, measured backwards from the moment of failure, the organization can afford to lose. The ranking comes from a business impact analysis, which examines financial loss, regulatory exposure, customer harm and reputational damage over successive intervals of downtime. Technology recovery capability is then matched to those targets, rather than the targets being written backwards from whatever the infrastructure happens to deliver today. A business continuity plan (BCP) is the document that records those decisions for emergency events — war, earthquake, pandemic, a cyber incident — together with the mapping of critical systems, processes and their recovery intervals.

In supervised financial institutions, this exercise carries weight beyond operational housekeeping. Directors hold personal responsibility for risk governance, and internal audit tests whether stated targets were ever validated. The practical difficulty is rarely the arithmetic. It is agreeing which processes genuinely qualify as critical, tracing the upstream dependencies — core systems, settlement interfaces, third-party providers, key personnel — that silently determine whether a stated target is achievable, and deciding what the business does manually while recovery runs. In 2026, many organisations are likely reviewing whether the recovery times in their plans have ever been tested. Life Titanium Risk Management - LT RISKMGMT is a boutique consulting and training firm in operational risk, fraud and embezzlement prevention, cyber, AI governance and business continuity, and the sections that follow set out how recovery targets are derived, documented, tested and kept current.

How do you set a recovery time objective for each critical process?

To set a recovery time objective for one critical process, work backwards from the moment an interruption starts causing material damage — regulatory breach, customer harm, unsettled positions — and then test that target against what the supporting systems can actually deliver.

A workable sequence for a single process looks like this:

Scope the process precisely. Name one end-to-end flow — for example, settlement of securities trades in the middle office, the control layer governing capital-market activity — rather than a whole department.
Run a business impact analysis (BIA). Document how the damage curve behaves as downtime extends, including regulatory reporting deadlines and contractual obligations.
Derive the maximum tolerable period of disruption (MTPD) from that curve, then set the RTO comfortably inside it so the plan has headroom.
Set the RPO from data criticality, driven by transaction volume and whether the process can reconstruct lost records from an upstream source.
Validate against the technical reality of backup frequency, failover design and supplier dependencies, then escalate any gap to the risk committee as an accepted exposure or a funded remediation.

Which attributes define a defensible recovery target?

Attribute — What it specifies — Why it drives the decision
RTO — Restoration deadline for the process — Sets the architecture and standby capacity the process needs
RPO — Tolerable data loss window — Determines backup and replication frequency
MTPD — Point of unacceptable damage — Provides the ceiling the RTO must sit beneath
Dependency set — Upstream systems, suppliers, people — A process recovers no faster than its slowest dependency
Manual workaround — Whether the process can run offline — Can extend an otherwise impossible RTO
Criticality tier — Ranking used to allocate recovery resources — Decides sequencing when several processes fail together

What must a business impact analysis produce before recovery times can be agreed?

A business impact analysis must deliver several concrete outputs before recovery times can be agreed, and skipping any of them turns the resulting figures into guesswork. The BIA is the structured assessment of how damage accumulates when a process stops; the RTO and RPO are values derived from it.

The prerequisite outputs are:

Process inventory — a register of business processes with their owners, the systems they consume, and the regulatory obligations attached to each. Criticality claimed without it cannot be demonstrated to an auditor.
Dependency map — the chain linking each critical process to applications, data stores, premises, key personnel, and third-party suppliers. A recovery time is achievable only if every dependency in that chain can be restored inside it.
Impact-over-time curve — how financial, regulatory, customer, and reputational damage escalates as an outage lengthens. This is what converts "important" into a defensible figure.
MTPD — the outer limit beyond which the organisation cannot absorb the consequences.

This means the sequence is fixed: the MTPD sets the ceiling, and the RTO sits below it with enough headroom for the dependency chain to be rebuilt. The same logic governs the RPO, which follows from the data-change rate and the reconciliation burden identified in the inventory, not from whatever the backup schedule happens to allow.

Where a board, internal audit function, or risk committee is weighing whether its continuity plan would withstand scrutiny, these artefacts are the evidence base it will be asked for.

Which factors decide whether a process gets a near-immediate or a multi-day recovery target?

Several factors decide whether a process earns a near-immediate recovery target or whether a longer, multi-day band is defensible. Because the RTO is an output of the BIA, the criteria are agreed before the bands are assigned, so tier placement is not settled by departmental self-assessment.

Criterion — What it measures — Pushes toward the fastest band when… — A longer band is defensible when…
Irreversibility of loss — Whether harm can be undone after restoration — Funds, trades or client instructions are in flight — Work queues up and can be processed later without loss
Supervisory obligation — External reporting or disclosure deadlines — A fixed regulatory clock is already running — The obligation is periodic and has slack
Workaround exposure — Control strength while running manually — The manual route weakens segregation of duties or approval limits — A documented, rehearsed fallback exists
Dependency depth — How many critical processes wait on this one — It is an upstream feed for other tiered processes — It sits at the end of the chain

Workaround exposure deserves particular attention: manual continuity procedures can loosen the automated controls that normally prevent fraud and human error, so the fallback route needs its own control review. Each process is scored against all four criteria, and the reasoning behind its placement is documented so an internal auditor or a board risk committee can retest it.

How do you test and validate recovery times after the continuity plan is approved?

Testing and validating documented recovery times is what turns a continuity plan from an approved document into a defensible control. The RTO and RPO remain assumptions until an exercise measures them against the clock, and many plans look complete on paper while process owners have never run the recovery under pressure.

A workable sequence:

Walk the plan through with each process owner, confirming that named roles, call trees and dependencies still exist.
Run a tabletop exercise against a realistic scenario — cyber incident, extended power or communications loss, pandemic conditions, security emergency.
Execute a technical restore or failover on a defined scope, timing actual elapsed recovery against the documented RTO and measuring recovered data against the RPO.
Capture evidence as you go: timestamps, decision logs, participant lists, screenshots of restored systems.
Record every gap in a tracked remediation register with an owner and a due date, and report residual exposure to the audit committee or board.

Test approach — What it proves — Limitation and how to contain it
Live failover test — Technical recovery within the RTO — Production disruption; scope it to a maintenance window and agree abort criteria in advance
Tabletop exercise — Decision-making and escalation — Does not prove technical recovery; pair it with a restore test per critical process
Repeated scenario — Familiarity with the plan — Teams rehearse the script rather than the capability; rotate scenario types and add unannounced variables
Supplier recovery assurance — Third-party commitments on paper — Request the supplier's exercise evidence and reflect it in the dependency map

Re-test after any material change to systems, outsourcing arrangements or organisational structure, and on a documented recurring cycle in between.

Why do AI, fintech and non-bank credit firms need different recovery assumptions?

When an AI-enabled fintech or a non-bank credit provider sets recovery times, the assumptions behind a traditional bank's continuity plan rarely transfer intact. A long-established institution largely restores infrastructure it owns; a cloud-based provider often restores a combination of managed services, payment providers and external interfaces it does not control, so its recovery clock depends on parties outside the organisation.

Practical adjustments for these firms:

Set recovery times per customer-facing process (disbursement, collections, onboarding) rather than per system, and check each target against the provider's own restoration behaviour.
Map every external interface a critical process crosses, including credit bureaus and payment providers, and agree fallback handling and manual workarounds in advance.
Treat model and data pipelines as critical processes in their own right, with an RPO alongside the RTO, since a model restored without its data may not behave as validated.
Rehearse degraded-mode operation, not only full restoration, using the staff actually available at night and on weekends.

AI risk is a separate discipline from continuity planning. LT RISKMGMT's Chief AI Officer service covers writing a dedicated AI risk map and accompanying the AI rollout across its lifecycle — data, validation, AI red teams, and legal and regulatory aspects; Lea Tzur is a certified Chief AI Officer through Copenhagen Compliance.

Frequently Asked Questions

What is the difference between an RTO and an RPO?

The RTO is a limit on time: how long the process may stay down. The RPO is a limit on data: how much activity may be lost and re-entered. Both sit underneath the MTPD, the outer limit the board is willing to absorb. Setting an RTO without also fixing an RPO leaves the recovery team restoring a system on time with stale data.

How do you decide which processes are critical enough to need a recovery time?

Through a business impact analysis: you map each business process to the revenue, obligations and customer commitments it carries, then trace its dependencies — core systems, suppliers, premises and the specific people who can actually execute it. Supervised financial institutions in Israel often consider ISO 31000 and the relevant Proper Conduct of Banking Business directives when structuring this work, and document why each process is or is not treated as critical.

How often should recovery times be reviewed?

Review them whenever a critical process, system, supplier or organisational structure changes materially, and on a documented recurring cycle otherwise. Each review should check the BIA assumptions, the dependency map and the latest exercise results, and record any target that was changed and why.

Who owns and approves recovery time objectives?

The process owner proposes them, the risk function challenges them, and the board or executive committee approves them, since accountability for risk management sits there. Internal audit then tests whether the stated times are evidenced by exercises. Organisations that do not want a full-time hire, mainly mid-sized and government bodies, can use LT RISKMGMT's outsourced Risk Manager as a Service. LT RISKMGMT's clients include Discount Bank, Bank Leumi, Bank of Israel, Menora Mivtachim, Visa Cal and the Ministry of Justice (Corporations Authority).

Where can risk managers learn to set recovery objectives properly?

Through structured training. According to LT RISKMGMT's course page, its certification course for operational, cyber and AI risk managers runs about 40 academic hours of experiential learning, including workshops, hands-on sessions, visits to a leading SOC and guest lecturers from major organizations in Israel and abroad. The course is recognized by IRM, the Institute of Risk Management, and the current cycle includes an AI module.

About this article

LT RISKMGMT publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by LT RISKMGMT before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-11-01

Ready to get started?

See how LT RISKMGMT can help.

צרו קשר