# SAMA BCM Recovery Time Objective Methodology: Derive RTOs from Impact Tolerance Instead of IT Estimates
When business-continuity managers at Saudi banks and insurers are asked to define recovery time objectives, the instinct is often to consult the IT department. How quickly can you restore this system? The answer becomes the RTO. Section 4.3 of the SAMA BCM guideline requires the opposite approach: the SAMA BCM recovery time objective methodology begins with the business-impact analysis, establishes the maximum tolerable period of disruption for each critical service, and only then designs recovery strategies capable of meeting that tolerance. The RTO is not what IT can do today; it is what the business requires, and recovery capability must be built to match.
This distinction matters because recovery time objectives derived from current IT capability often fail to protect the institution. A payment system that IT can restore in twelve hours may cause unacceptable customer harm, regulatory breach or liquidity stress after four hours. If the RTO is set at twelve hours because that is what the current backup schedule permits, the business-continuity plan has documented a gap, not closed it. SAMA expects RTOs to reflect impact tolerance, and recovery strategies to be designed—and tested—to meet those objectives.
This article presents the four-step method used to derive defensible recovery time objectives under the SAMA BCM guideline. It is the approach applied when building business continuity capability for regulated institutions in the Kingdom, and it produces RTOs that withstand both internal challenge and supervisory review.
Step One: Identify Critical Services and Map Dependencies
The foundation of any defensible RTO is a clear understanding of which services are critical and what they depend upon. SAMA BCM requires institutions to identify critical business services—those whose prolonged disruption would cause unacceptable harm to customers, counterparties, market integrity or the institution's safety and soundness.
Critical services are not the same as critical systems. A retail payment service may depend on a core banking platform, a card switch, telecommunications links, branch staff and cash logistics. The service is what matters to customers and regulators; the systems, processes and people are dependencies that must be analyzed to understand how the service can fail and how it can be recovered.
The first step is to catalog critical services and document their dependencies across technology, facilities, people and third parties. This is the business impact analysis phase. Each critical service is decomposed into the resources required to deliver it, and those resources are traced through the institution's operating model. A treasury dealing service depends on trading applications, market data feeds, settlement connectivity, dealer workstations, voice recording, and the dealing room itself. If any dependency is lost, the service may be impaired or unavailable.
Mapping dependencies is not a theoretical exercise. It requires interviews with service owners, process walkthroughs and architecture reviews. The output is a dependency map for each critical service, showing the technology, infrastructure, people and suppliers without which the service cannot function. This map becomes the basis for impact analysis and recovery design.
Step Two: Assess Impact Over Time for Each Critical Service
Once dependencies are mapped, the next step is to assess the impact of disruption over time. This is where the SAMA BCM recovery time objective methodology diverges sharply from the IT-driven approach. Instead of asking how quickly a system can be restored, the question is: how long can this critical service remain unavailable before the impact becomes intolerable?
Impact is assessed across multiple dimensions. For a payment service, one hour of disruption may cause customer complaints and reputational concern. Four hours may trigger regulatory reporting obligations under SAMA operational risk or incident notification rules. Eight hours may result in liquidity stress, customer attrition or breach of service-level agreements with correspondents. Twelve hours may threaten the institution's license to operate.
The impact analysis documents these thresholds for each critical service. The result is a time-based impact profile: minor impact within the first hour, moderate impact by four hours, severe impact by eight hours, catastrophic impact beyond twelve hours. The maximum tolerable period of disruption is the point at which impact becomes severe or catastrophic—the point beyond which the institution cannot accept further delay.
This assessment must be grounded in the institution's risk appetite, regulatory obligations and contractual commitments. SAMA expects institutions to define impact tolerance in measurable terms: financial loss, customer harm, regulatory breach, market disruption. Vague statements such as "significant impact" are not sufficient. The impact analysis should quantify, where possible, or describe in operational terms what happens at each time interval.
The output of this step is a set of impact tolerance thresholds for each critical service. These thresholds are not RTOs; they are the business requirement that RTOs must satisfy.
Step Three: Derive Recovery Time Objectives from Impact Tolerance
With impact tolerance defined, the recovery time objective can now be derived. The RTO is set at a point before the maximum tolerable period of disruption is reached, allowing a margin for variability in recovery execution. If a payment service reaches severe impact at eight hours, the RTO might be set at six hours, providing a two-hour buffer for unforeseen complications during recovery.
This is the core of the SAMA BCM recovery time objective methodology: the RTO is a function of impact tolerance, not current recovery capability. If the business can tolerate four hours of disruption but IT currently requires twelve hours to restore the core banking platform, the institution has a gap. The business-continuity plan must either identify an alternative recovery strategy that meets the four-hour objective, or escalate the gap to senior management and document it as a residual risk with a remediation plan.
RTOs are set for critical services, not individual systems. A single critical service may depend on multiple systems, and each dependency may have its own recovery priority. The payment service RTO of four hours drives recovery priorities for the core banking platform, the card switch, network connectivity and staff availability. If the core platform can be restored in three hours but network connectivity takes six, the service RTO is missed. Recovery strategies must address all dependencies in parallel.
It is also important to distinguish between recovery time objective and recovery point objective. RTO defines how quickly the service must be restored; RPO defines how much data loss is acceptable. A payment service with a four-hour RTO may have an RPO of zero—no transactions can be lost—or an RPO of fifteen minutes, depending on the criticality of transaction integrity. Both objectives are derived from the impact analysis, and both must be documented and tested.
Step Four: Design and Validate Recovery Strategies to Meet Objectives
Deriving the RTO is only half the task. The institution must then design recovery strategies capable of meeting the objective and validate through testing that those strategies work. This is where many business-continuity programs fail: RTOs are documented, but recovery capability is never built or tested.
Recovery strategies vary by service and dependency. For technology dependencies, strategies may include high-availability clustering, real-time replication to a secondary data center, or failover to cloud infrastructure. For people dependencies, strategies may include cross-training, remote work capability or standby teams. For facilities, strategies may include alternate sites, work-area recovery arrangements or mutual aid agreements. For third parties, strategies may include contractual RTOs, dual supply or exit clauses.
Each strategy must be costed, prioritized and approved. A zero-downtime strategy for a payment service may require active-active data centers and synchronous replication; a four-hour RTO may be achievable with asynchronous replication and manual failover. The choice depends on the impact tolerance, the cost of the strategy and the institution's risk appetite. SAMA does not prescribe specific recovery strategies, but it does require that strategies are proportionate to the criticality of the service and that they are tested.
Testing is the validation step. A business-continuity plan that documents a four-hour RTO but has never been tested is a statement of intent, not a capability. SAMA BCM requires regular exercises—tabletop and technical—to confirm that recovery strategies work, that roles are clear, and that objectives can be met under realistic conditions. When recovery strategies are tested, gaps emerge: a failover process that works in the test environment fails in production; a key person is unavailable; a third-party recovery site is already occupied by another client. These gaps must be documented, remediated and retested.
The cycle of analysis, strategy design, planning and testing is continuous. As services change, dependencies evolve and impact tolerance shifts, RTOs must be reviewed and recovery strategies updated. An RTO set two years ago may no longer reflect current regulatory expectations, customer demands or operational complexity.
How Business Continuity Capability Is Built for SAMA-Regulated Institutions
Building business continuity and cyber resilience capability in line with SAMA BCM requirements follows a structured process. The work begins with analysis of critical services, dependencies and impact over time. Recovery options are then matched to objectives and budget, balancing the cost of resilience against the cost of disruption. Continuity, IT recovery and cyber recovery plans are developed to document roles, procedures and escalation paths. Finally, tabletop and technical tests confirm that plans work, and lessons are captured in an improvement plan.
Deliverables include a BIA report that documents critical services, dependencies and impact tolerance; a BCM policy and framework that sets governance, roles and review cycles; business continuity and DR plans that specify recovery procedures for each critical service; cyber recovery playbooks for scenarios involving data encryption, system compromise or denial of service; and exercise reports with findings and remediation actions.
The engagement typically runs eight to twelve weeks, depending on the number of critical services, the complexity of dependencies and the maturity of existing continuity arrangements. The output is a business continuity capability that meets SAMA BCM requirements and can be demonstrated to supervisors, auditors and the board.
Closing: Build Recovery Capability That Meets Business Requirements
Recovery time objectives are not aspirational targets or IT estimates. Under SAMA BCM Section 4.3, they are business requirements derived from impact analysis, and recovery strategies must be designed, funded and tested to meet them. Institutions that set RTOs based on current IT capability document gaps, not resilience. Those that start with impact tolerance, derive objectives and build recovery capability to match produce business-continuity plans that protect customers, satisfy regulators and withstand real incidents.
If your institution is building or updating business continuity plans under the SAMA BCM guideline and needs support deriving defensible recovery time objectives, designing recovery strategies or running exercises to validate capability, the Business Continuity & Cyber Resilience service provides the analysis, planning and testing required to meet SAMA expectations and keep critical services running.
