SAMA’s Operational Resilience and Business Continuity Expectations for Saudi Banks

SAMA does not yet hand Saudi banks a codified impact tolerance the way the PRA does. That gap is precisely why so many banks discover their resilience weaknesses during a supervisory inspection rather than before one.

Most writing on operational resilience in the Kingdom is either a restatement of the Basel principles or a vendor pitch for a business-continuity platform. This is a reading for the people who actually have to own the resilience programme in a Saudi bank: what the Saudi Central Bank (SAMA) already requires, where its expectations are heading, and what that means for the technology estate rather than the policy binder. The distinction matters, because SAMA’s frameworks are moving banks from a plan-centric view of continuity to a service-centric view of resilience, and the two demand different evidence.

What SAMA actually requires today

The codified instrument is SAMA’s Business Continuity Management Framework, which applies to member organisations across the sector — banks, insurers, finance companies, credit bureaux and financial market infrastructure. It is a maturity-based framework, aligned to ISO 22301 and sitting alongside the SAMA Cyber Security Framework issued in May 2017. It requires the familiar building blocks: a business-continuity governance structure with senior-management ownership, a periodic business impact analysis and risk assessment, documented recovery strategies, business-continuity and disaster-recovery plans, and a testing regime spanning tabletop exercises, simulations, failover tests and full disaster-recovery invocation.

Read literally, that is a continuity-management standard. The business impact analysis identifies critical activities and sets recovery time and recovery point objectives; the plans describe how the bank restores those activities after a disruption. What it does not yet do — and what the international direction of travel does — is oblige the bank to define the end-to-end services it delivers to customers, set a tolerance for how long each can be disrupted before the harm becomes intolerable, and prove it can stay inside that tolerance under severe-but-plausible scenarios. That is the service-centric model, and it is where SAMA’s supervisory attention is clearly moving.

The shift from plans to services

The reference point is the Basel Committee’s Principles for Operational Resilience, published in March 2021. They reframe the question. Instead of asking “do we have a tested plan for each critical system”, they ask “can the bank continue to deliver its critical operations through disruption, whatever fails”. The four moves that follow are mapping (tracing each important service through the people, processes, technology, data and third parties it depends on), setting a tolerance for disruption, testing against scenarios rather than against a plan, and governing the whole thing at board level. SAMA is a Basel-aligned regulator, and its recent supervisory messaging has pushed banks beyond the traditional continuity framework toward exactly this posture.

The practical consequence is that a recovery time objective and an impact tolerance are not the same thing, and treating them as interchangeable is the most common error I see. An RTO is an internal engineering target for restoring a system. An impact tolerance is an outward-facing statement of the maximum disruption to a customer service the bank is prepared to tolerate before intolerable harm results — measured in the service the customer experiences, not the system the bank operates. A payment service can breach its tolerance while every individual component sits inside its RTO, because the tolerance is set on the whole chain and the RTOs are set on the parts. If you have never reconciled the two, you do not know your real exposure. This is the same reconciliation the UK’s regime forced, and it is worth reading how the PRA’s SS1/21 expectations translate into what a technology function must be able to show.

Where it bites for architecture and data

Service-centric resilience is an architecture problem before it is a policy problem, and this is where Saudi banks find the real work. Mapping an important business service — say, domestic instant payments, or card authorisation, or retail onboarding — forces you to document every dependency in the chain: the core banking system, the payment gateway, the fraud engine, the identity provider, the network links, and the cloud or on-premise infrastructure underneath. Most banks discover that no single artefact holds this map. It is spread across a configuration management database that is out of date, architecture diagrams that describe intent rather than reality, and the knowledge of two or three senior engineers.

Data is the second pressure point. The recovery point objective — how much data you can afford to lose — is only meaningful if you know where the authoritative copy of each critical data set lives, how it is replicated, and whether the replica is genuinely independent of the primary failure. A synchronous replica in the same availability zone protects you from a server failure and nothing larger. Kingdom-specific factors sharpen this: data-residency expectations under Saudi law and the Personal Data Protection Law constrain where recovery sites and backups can sit, so the resilience design and the data-governance design have to be solved together rather than in sequence. I have written separately on how the PDPL, SAMA and the NCA stack up as a single technology-readiness problem, and resilience is where those three most obviously collide.

Third-party dependency is the third. A bank that outsources card processing, cloud hosting or its digital-onboarding stack cannot map a service to the edge of its own perimeter and stop. The disruption scenarios that matter most now — a cloud region outage, a processor failure, a ransomware event at a key supplier — originate outside the bank. SAMA’s frameworks treat third-party and cyber risk as in-scope for continuity, and a resilience map that excludes them is not a map.

The evidence a supervisor will ask for

Alignment is demonstrated in artefacts, not assertions. A supervisor working to a service-centric standard will want to see a defined inventory of important business services with a named owner for each; a dependency map for each one that is current rather than aspirational; a documented tolerance for disruption per service, approved by the board; and — the item that separates stated compliance from operating compliance — evidence that the bank has tested against a severe-but-plausible scenario and can show whether it stayed inside tolerance, with a remediation plan where it did not. A disaster-recovery test that confirms a server fails over is necessary but not sufficient; it proves the part works, not that the service survives. The discipline of designing those scenario tests and reading their results is a subject in itself, and it is worth understanding how resilience testing and impact tolerances fit together before you commission the first exercise.

Banks operating across the GCC will recognise this pattern from neighbouring regimes; the DIFC’s technology standards frame operational resilience in closely related terms, which helps if your group wants one coherent resilience model rather than two.

Who this is for

• The CTO or CIO of a Saudi bank who owns the technology side of the continuity programme and has been asked to show it is fit for where supervision is heading.
• Heads of operational resilience and business continuity translating a plan-centric BCM programme into a service-centric one.
• Board and risk-committee members who have approved a business-continuity policy and want to know what a supervisor will actually test it against.

The banks that come through inspection well are not the ones with the thickest continuity binder. They are the ones that can put an accurate service map, a board-approved tolerance and a real scenario-test result on the table in the same afternoon. That is the gap worth closing now, while it is a project rather than a finding.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.