Business Impact Analysis for Saudi Banks: A Guide

The business impact analysis is the single most consequential artefact in a Saudi bank's business continuity programme. It is the document SAMA inspectors ask for first, the document that drives every recovery strategy decision the bank will make, and the document the audit committee uses to satisfy itself that the institution can withstand disruption to its critical services. A weak BIA produces a weak BCM programme — no amount of polished plans and rehearsed exercises can compensate for an analysis that misidentifies what is critical.

This post is a practical walkthrough of how to run a business impact analysis for a Saudi bank in 2026, aligned to the SAMA Business Continuity Management Framework and ISO/IEC 22301:2019. It is methodology-aware, regulator-aware, and built around the questions the Head of Business Continuity actually has to answer.

What a BIA is — and what it is not

The BIA is the structured analysis that identifies the bank's products and services, the activities required to deliver them, the resources those activities depend on, the impacts of disruption over time, and the recovery objectives that follow. It is forward-looking and outcome-driven. It is not a technical asset inventory, it is not a risk assessment, and it is not a recovery plan. The BIA tells the bank what matters and how quickly; the recovery plan tells the bank how to bring it back.

Saudi banks routinely conflate these documents, and the result is a BIA that reads like an IT inventory or a recovery plan that includes risk scoring. Both are signs that the BIA discipline is not yet established.

The regulatory expectation

The SAMA BCM Framework is explicit about the expectation. Member organisations must conduct a BIA for the products and services they deliver, document the resource dependencies, define recovery time objectives and recovery point objectives, and refresh the analysis at least annually and when material change occurs. SAMA inspectors examine the BIA in detail because it is the foundation everything else in the BCM programme is built on.

ISO/IEC 22301:2019 clauses 8.2.2 and 8.2.3 require the same: a documented BIA process with defined criteria, applied consistently across the organisation, with the outputs feeding the continuity strategy. Banks pursuing ISO 22301 certification are assessed against the BIA's existence, currency and quality.

In short: SAMA expects a BIA, ISO 22301 expects a BIA, and the audit committee expects a BIA. It is not optional and it is not a one-off exercise.

Step 1 — Define scope

The first decision is the scope of the analysis. For a Saudi bank, the practical scoping choices include:

• Whole bank vs. critical-products-only. A first BIA for a smaller bank may sensibly cover the full product set; a tier-one bank typically scopes to its identified critical economic functions.
• Customer-facing vs. internal services. Both matter; the BIA should treat them as a connected set rather than focus only on the customer-facing products.
• Sharia advisory and Islamic banking products. Treated as distinct services with their own continuity considerations.
• Cross-border and correspondent banking activities. Included if material to the bank's operations.

Document the scope statement, get it approved by the BCM steering committee, and circulate it to the business owners before the BIA begins.

Step 2 — Inventory products and services

The next step is to inventory the products and services in scope. For a Saudi bank, a typical inventory includes:

• Retail deposit products (current accounts, savings, time deposits).
• Retail lending products (personal loans, auto, mortgage, credit cards).
• Payment services (domestic transfers, SARIE, international wire, card acquiring).
• Corporate banking (corporate accounts, trade finance, cash management, treasury).
• Capital markets and treasury (own-account trading, FX, fixed income).
• Investment and wealth management.
• Islamic banking products (Murabaha, Ijara, Sukuk, Tawarruq).
• ATM and branch services.
• Digital channels (mobile app, internet banking, open banking APIs).
• Custodian and trustee services where applicable.

Each product or service should be a row on the BIA worksheet and should carry an owner — a named individual on the business side, not a function or a job title.

Step 3 — Identify activities and dependencies

For each product or service, identify the activities required to deliver it and the resources each activity depends on. The dependency dimensions worth capturing include:

• People. Named roles (not headcount) and their concentration risk.
• IT systems. Core banking, payment switches, identity providers, customer-facing channels, document management, reporting, end-user computing, supporting infrastructure.
• Data. The data sets required, where they are stored and the recovery point objectives that apply to them.
• Facilities. Buildings, branches, datacentres, cash centres, call centres.
• Third-party services. SARIE, SAMA reporting, SWIFT, card networks, cloud providers, key vendors.
• Specialist equipment. Cash sorters, ATMs, dealing room turrets, hardware security modules.

A dependency map for one product is rarely small; for an Islamic banking product spanning Sharia review, contract management, payment execution and customer servicing, the dependency list can run into dozens of items. The discipline matters because every dependency is a single point of failure that the BCM programme will need to plan against.

Step 4 — Quantify the impact of disruption

The core analytical exercise of the BIA is quantifying the impact of disruption to each product over time. The standard practice is to assess impact at a series of time horizons — 1 hour, 4 hours, 8 hours, 24 hours, 48 hours, 72 hours, 1 week — across multiple impact dimensions:

• Financial. Revenue lost, fines, breach of contractual SLAs, cost of compensation.
• Operational. Backlog accumulation, throughput degradation.
• Customer. Number of customers affected, severity of impact.
• Regulatory. Reportable incidents, breaches of SAMA expectations, missed regulatory submissions.
• Reputational. Public visibility, media exposure, market confidence.

The impact analysis should be based on real numbers wherever possible — actual transaction volumes, actual customer counts, actual revenue figures — and on documented assumptions where exact numbers are not available. SAMA inspectors react badly to BIAs built on round numbers and unstated assumptions.

The output of the impact analysis is the Maximum Tolerable Period of Disruption (MTPD) for each product — the duration after which the impact of disruption becomes unacceptable to the institution.

Step 5 — Set recovery objectives

From the MTPD, the bank derives the Recovery Time Objective (RTO) for each product — the target duration within which the product must be recovered. The RTO must be shorter than the MTPD; the gap between them is the safety margin.

Where data is involved, the bank also sets the Recovery Point Objective (RPO) — the maximum acceptable amount of data loss measured backwards from the disruption. For payment systems and core banking, the RPO is typically near zero; for analytics and reporting, it can be hours.

A practical Saudi bank BIA produces a table for each in-scope product with MTPD, RTO, RPO, and the rationale for each value. The rationale matters because the inspector will ask why a particular value was chosen.

Step 6 — Assess current capability against recovery objectives

The next step is the gap analysis between the recovery objectives and the bank's current recovery capability. For each product, ask: given today's continuity arrangements, can the bank actually recover within the RTO and RPO it has set?

This analysis surfaces the gaps the BCM programme must close. Common gaps in Saudi banks include:

• Single-region cloud deployments for products whose RTO does not tolerate the time required to fail over.
• Manual recovery procedures for products whose RTO assumes automation.
• Single-supplier dependencies that have no documented substitution path.
• Recovery plans that assume staff availability during scenarios (pandemic, mass evacuation) that prevent it.
• Backup and recovery procedures that have not been tested against the stated RPO.

The gap analysis is the bridge between the BIA and the continuity strategy.

Step 7 — Cyber resilience overlay

A BIA conducted without explicit cyber consideration is incomplete. SAMA CSF and NCA ECC both expect BCM and cyber to be treated as connected disciplines, and the BIA is where the connection is made concrete.

For each in-scope product, the BIA should include cyber-specific scenarios: ransomware, destructive malware, large-scale data exfiltration, supplier cyber failure. The recovery objectives for these scenarios may be tighter than the general RTO because cyber recovery often requires forensic preservation that consumes time.

The cyber resilience overlay also drives the linkage between the BCM exercise programme and the cyber incident response programme. They should not be operated as separate disciplines.

Step 8 — Approval and refresh cadence

The BIA should be approved by the BCM steering committee and presented to the audit committee. It should be refreshed at least annually and immediately when there is material change to the bank's products, services, structure, technology or supplier base. A BIA that has been unchanged for two years is a finding waiting to happen.

The refresh cycle should be triggered by both calendar (annual) and event (material change). Banks that rely on the calendar alone routinely miss material change between reviews.

Common pitfalls

A handful of pitfalls account for the majority of the BIA findings SAMA inspectors raise:

• BIA built around technology assets rather than business products. Loses sight of what the customer experiences.
• Round-number impact estimates with no documented rationale. Cannot be defended in inspection.
• MTPD and RTO set by the BCM team without business sign-off. The business does not own the numbers.
• No cyber scenarios in the BIA. Misses the half of the threat surface SAMA cares most about.
• No refresh cadence and no triggers for ad-hoc refresh. The BIA ages and stops representing reality.
• Recovery objectives that do not match actual recovery capability. Aspirational rather than operational.

How GRC Vantage supports BIA in Saudi banks

GRC Vantage's BCM module supports the full BIA lifecycle — scope, product inventory, dependency mapping, impact analysis at defined time horizons, MTPD/RTO/RPO derivation, gap analysis against current recovery capability, and approval workflow — on the same platform that runs the bank's recovery plans, exercises and post-exercise reviews. The SAMA BCM Framework and ISO 22301 ship pre-mapped, the cyber resilience overlay is built in (BIA records link directly to the cyber risk register and the SAMA CSF and NCA ECC control libraries), and the platform can be deployed inside Saudi Arabia for data residency, fully on-premise or air-gapped. Our delivery teams in Riyadh and Dammam routinely work with Saudi banks on first BIAs and on refreshing legacy ones.

For the wider international BCM context, read our ISO 22301 Saudi Arabia guide. For the SAMA-specific BCM Framework, read our SAMA frameworks guide. When you are ready to put a credible BIA on real numbers, book a demo.