When SAMA BCM assessors review a business continuity program, one finding appears more frequently than any other: the business impact analysis measures technology recovery rather than business-process interruption. The institution has documented how long it takes to restore the core banking platform or payment switch, assigned those durations as recovery time objectives, and built continuity plans around them. The assessor rejects the analysis because it answers the wrong question.
The SAMA BCM impact analysis RTO determination must start with the business process—the activity that generates revenue, meets a regulatory deadline or fulfills a customer obligation—not the system that supports it. An RTO that reflects how quickly the IT team can rebuild a server tells you nothing about how long the business can tolerate suspended loan disbursement, delayed card authorization or interrupted regulatory reporting. This distinction is not semantic. It changes which processes receive priority, which recovery strategies the institution selects, and whether the board can rely on the continuity plan when an incident occurs.
This article explains why technology-centric impact analyses fail SAMA BCM requirements, describes the process-mapping method that produces defensible recovery priorities, and outlines the steps to link business activities to the objectives and budgets that recovery strategies must meet.
Why Technology-Centric Impact Analyses Fail SAMA BCM Requirements
SAMA's business continuity management framework requires institutions to identify critical services and determine the maximum tolerable period of disruption for each. The framework defines a critical service by its importance to customers, counterparties, regulators and the institution's financial position—not by the technology that delivers it.
When an institution begins its impact analysis by listing systems, it inverts the logic. The IT department reports that the core banking platform has a four-hour RTO because that is how long the vendor estimates failover will take. The payment switch has a two-hour RTO because the infrastructure team believes it can restore the standby node within that window. These figures reflect technical capability, not business tolerance.
The problem becomes visible when the institution experiences an actual disruption. The core banking platform fails over successfully within four hours, but loan officers cannot disburse approved credit for six hours because the workflow also depends on the document management system, which was assigned an eight-hour RTO. The payment switch recovers in two hours, but card authorization remains unavailable because the fraud-detection service, hosted by a third party, was not included in the impact analysis at all. The institution met its technology RTOs and still failed to maintain critical services.
SAMA BCM assessors identify this gap immediately. They ask which business processes stop when a system fails, how long each process can remain interrupted before the institution suffers financial loss or regulatory breach, and whether the recovery strategy addresses every dependency. An impact analysis that begins with systems cannot answer these questions.
The Process-Mapping Method That Produces Defensible RTOs
A defensible business impact analysis starts with the activities the institution performs, not the systems it operates. The method has four steps: identify business processes, determine impact over time, map dependencies, and assign recovery objectives.
Identify Business Processes
List every activity the institution performs that generates revenue, satisfies a regulatory obligation or fulfills a customer commitment. Examples include:
- Loan disbursement
- Card authorization and settlement
- Funds transfer and remittance
- Customer onboarding and KYC verification
- Regulatory reporting to SAMA
- Payroll processing
- Collateral valuation and margin calls
Each process is defined by its output—a disbursed loan, an authorized transaction, a submitted report—not by the department that performs it or the system that supports it. A single process may span multiple departments and rely on several systems, third parties and manual steps.
Determine Impact Over Time
For each process, document what happens if it stops. The analysis must quantify impact in four dimensions: financial loss, regulatory breach, customer harm and reputational damage.
Financial loss includes direct revenue forgone, contractual penalties, and costs incurred during disruption. A suspended loan disbursement process costs the institution the margin on every loan that would have been drawn during the outage. A halted card authorization process costs interchange revenue and may trigger service-level penalties from payment networks.
Regulatory breach occurs when the institution misses a deadline or fails to meet a continuous obligation. SAMA requires certain regulatory returns by specific dates; if the reporting process is disrupted close to the deadline, the institution breaches its license conditions. Anti-money-laundering transaction monitoring must operate continuously; any gap creates exposure under the Anti-Money Laundering Law.
Customer harm includes broken commitments and service degradation. If the institution has promised same-day loan disbursement and cannot deliver, it harms the customer. If card authorization fails, the customer cannot complete a purchase. The analysis must consider both contractual obligations and reasonable customer expectations.
Reputational damage is harder to quantify but no less real. A multi-hour disruption to digital banking may not breach a contract, but it will generate complaints, social-media criticism and customer attrition.
For each process, document the impact at intervals: one hour, four hours, eight hours, 24 hours, and so on. The pattern reveals the maximum tolerable period of disruption. Loan disbursement may show negligible impact in the first hour, moderate financial loss at four hours, and regulatory breach at 24 hours if same-day commitments are missed. Card authorization shows immediate financial loss and customer harm from the first minute.
Map Dependencies
Once the impact timeline is clear, identify everything the process requires: systems, data, third parties, facilities, people and manual steps. This is where technology enters the analysis—as a dependency of the business process, not as the starting point.
For each dependency, document:
- What it does within the process
- Whether it is critical (the process cannot function without it) or supporting (the process can continue in degraded form)
- Where it is hosted, who operates it, and what contractual or technical recovery commitments exist
- What happens if it fails
A loan disbursement process typically depends on the core banking system, the document management system, the payment gateway, the credit bureau interface, and manual approval workflows. If any critical dependency fails, the process stops. If a supporting dependency fails, the process may continue at reduced capacity or with manual workarounds.
Third-party dependencies require particular attention. The institution does not control the vendor's recovery capability, and the contract may not specify an RTO that meets the institution's business tolerance. If card authorization depends on a fraud-detection service with a 12-hour vendor RTO, but the business impact analysis shows that the institution suffers material loss after two hours, the recovery strategy must address the gap—perhaps by implementing a rule-based fallback or negotiating a faster vendor commitment.
Assign Recovery Objectives
The recovery time objective for a business process is the maximum tolerable period of disruption identified in the impact analysis, not the time required to restore any particular system. The recovery point objective is the maximum tolerable data loss, determined by the same impact analysis.
If loan disbursement cannot tolerate more than four hours of interruption before financial loss becomes material, the RTO is four hours. Every dependency—core banking, document management, payment gateway, credit bureau—must be recoverable within that window, or the institution must implement an alternative strategy such as manual processing, a standby service or a different process design.
If card authorization cannot tolerate more than 15 minutes of interruption, the RTO is 15 minutes. The institution must either deploy highly available infrastructure with automatic failover, or accept that it cannot meet the business requirement and must limit its service commitments accordingly.
The recovery strategy must then match the objective to the institution's budget and risk appetite. High-availability infrastructure is expensive; manual workarounds are slow and error-prone; third-party standby services introduce new dependencies. The institution makes an informed choice because the impact analysis has quantified what is at stake.
Common Pitfalls in Process-Based Impact Analysis
Even when institutions adopt a process-based approach, several pitfalls remain.
Confusing process criticality with system criticality. The core banking system supports many processes, some critical and some not. The system itself does not have an RTO; each process that depends on it has an RTO, and the system must meet the most stringent.
Overlooking manual workarounds. Some processes can continue manually if systems fail, but only if the institution has documented the procedure, trained staff and tested it. An untested workaround is not a recovery strategy.
Ignoring cumulative impact. A single process interruption may be tolerable; simultaneous interruption of several processes may threaten the institution's viability. The impact analysis must consider scenarios in which multiple processes fail together.
Underestimating recovery complexity. Restoring a system is not the same as resuming the business process. Data may be inconsistent, queues may be backlogged, and manual reconciliation may be required. The RTO must include the time to return the process to normal operation, not just to bring the system online.
Building the Recovery Strategy Around Business Tolerance
Once the impact analysis is complete, the institution can design recovery strategies that address actual business risk. The strategies vary by process:
- High-availability infrastructure for processes with very short RTOs, such as card authorization or payment switching
- Standby sites and failover procedures for processes with RTOs measured in hours, such as loan disbursement or customer onboarding
- Manual workarounds and alternative channels for processes that can tolerate longer interruptions or degraded service
- Third-party standby services for processes that depend on external providers
- Process redesign to eliminate dependencies or reduce recovery complexity
The institution documents each strategy in business continuity and IT recovery plans, assigns roles and responsibilities, and tests the plans through exercises. The exercise program must validate not only that systems can be restored within the technical RTO, but that the business process can resume within the business RTO, including all dependencies and manual steps.
How We Build Business Impact Analyses That Withstand SAMA BCM Assessment
Our Business Continuity & Cyber Resilience service builds and tests business continuity and cyber resilience capability in line with SAMA BCM and SAMA cyber resilience requirements, covering impact analysis, recovery strategies, plans and exercises.
The process follows four stages. We analyze critical services, dependencies and impact over time. We strategize recovery options matched to objectives and budget. We plan continuity, IT recovery and cyber recovery plans. We exercise through tabletop and technical tests, lessons and fixes.
Deliverables include a BIA report, BCM policy and framework, business continuity and DR plans, cyber recovery playbooks, and exercise reports and improvement plan. The engagement typically runs eight to twelve weeks.
The business impact analysis we deliver maps every critical business process to its revenue contribution, regulatory deadline and customer obligation, documents impact at defined intervals, identifies all dependencies including third parties and manual steps, and assigns recovery time and point objectives that reflect business tolerance rather than technical capability. The result is a set of recovery priorities that SAMA BCM assessors can verify and that the board can rely on when an incident occurs.
If your institution is building or updating its business continuity program and needs an impact analysis that starts with business processes rather than systems, we can help you get it right from the beginning.
