SAMA BCM Framework Explained: A Practitioner's Guide

If the SAMA Cyber Security Framework is the most-discussed item in any Saudi bank's GRC programme, the SAMA Business Continuity Management (BCM) Framework is the most-underestimated. It is the framework that gets boxed off as "the BCM team's problem", scheduled for one tabletop exercise a year, and then quietly fails its first serious inspection because the documentation does not match what actually happens during a disruption.

This guide unpacks what the SAMA BCM Framework actually requires, where Saudi expectations go beyond ISO 22301, and how to build a programme that holds up under regulator scrutiny.

What the BCM Framework is — and what it isn't

The SAMA BCM Framework was issued by the Saudi Central Bank to set minimum business continuity expectations for every member organisation: banks, finance companies, insurers, payment service providers, exchanges and credit bureaus. It is mandatory, not advisory, and SAMA inspectors routinely test it during on-site supervision.

The framework is closely aligned to ISO 22301, the international standard for business continuity management, and to ISO 31000 for risk management. If you have ever implemented ISO 22301, the structure of the SAMA framework will feel familiar — programme governance, business impact analysis, risk assessment, strategy, plans, exercises, training and continuous improvement. But SAMA layered Saudi-specific expectations on top, and those expectations are exactly the areas inspectors focus on.

What the BCM Framework is not: a one-off document, an annual tabletop, an IT disaster recovery plan dressed up in BCM language, or a job for a single resilience analyst sitting in a back office. It is a continuously-tested capability owned at board level and exercised across the whole organisation.

The structure of the framework

SAMA's BCM Framework is built around a familiar lifecycle, but each stage carries specific expectations.

Governance and policy. The framework requires a board-approved BCM policy, a named BCM programme owner with sufficient seniority, defined scope (what is in and out of the programme), and clear roles and responsibilities. The board is expected to receive BCM reporting at a defined cadence — not just an annual update buried in the audit committee pack. The BCM function should report independently of the IT function so that the resilience view is not filtered through a single technology lens.

Business Impact Analysis (BIA). Every critical business process must be documented with a Recovery Time Objective (RTO), a Recovery Point Objective (RPO), the maximum tolerable downtime, the resources required to recover, the people responsible, and the dependencies (technology, people, third parties, data, premises) it relies on. The BIA is not a one-off exercise — it must be refreshed at least annually and after any material change to the business. Inspectors will ask for the most recent BIA, the change history, and evidence that it is the basis for everything else in the programme.

Risk assessment. A BCM-specific risk assessment looks at the threats most likely to disrupt the critical processes identified in the BIA: cyber incidents, third-party failure, physical events, regional disruptions, pandemic scenarios, infrastructure failures (power, telecoms, payment rails), insider events and so on. Saudi banks are increasingly expected to consider region-specific scenarios and the dependency on national shared services such as the local payment switch.

Strategy and planning. Once the BIA and risk assessment are in place, recovery strategies are defined for each critical process — alternate sites, backup providers, manual workarounds, technology recovery plans, communication trees, customer notification scripts. These come together as the Business Continuity Plan, the IT Disaster Recovery Plan, the Crisis Management Plan, and the dependent plans that sit underneath them. Plans must be approved, version-controlled and accessible to the people who need them — including in scenarios where the primary network is down.

Cyber resilience. SAMA's BCM Framework explicitly includes cyber resilience as a continuity domain. That means treating destructive cyber events (ransomware, wiper malware, supply-chain compromise) as in-scope continuity scenarios, not just as cybersecurity incidents. Recovery plans need to consider data integrity, clean-room recovery, immutable backups and the time needed to validate restored systems. This is the area that has changed most in the last three years and where most BCM programmes have catching-up to do.

Crisis management. A documented crisis management structure, escalation criteria, decision-making authorities and communication protocols. SAMA expects the crisis team to include senior business leaders, not just operations staff, and to be tested in realistic scenarios.

Awareness and training. Every staff member should know what to do in a continuity event relevant to their role. The framework expects role-based training, not just a generic e-learning module, and measurable participation rates.

Testing and exercising. Programmes must be tested through a combination of tabletop exercises, walkthroughs, technical recovery tests and full simulations. The frequency varies by criticality, but the most critical processes are typically tested at least annually. Inspectors will ask for the most recent test report, the lessons learned, and evidence that those lessons were closed out.

Lessons learned and continuous improvement. Every test, exercise and real incident must feed back into the BIA, the risk assessment and the plans. The framework is explicit that BCM is a continuous improvement discipline — the board is expected to see how the programme has improved year-on-year, not just confirm that an exercise happened.

Where SAMA expects more than ISO 22301

If you have an ISO 22301-certified BCM programme, you have most of what SAMA expects. But there are five areas where the Saudi requirements go further:

Regulator notification and reporting. SAMA expects to be notified of significant continuity events within defined timeframes and through defined channels. ISO 22301 says nothing about regulator notification — that is a Saudi-specific layer.

Dependency on national shared services. Saudi banks operate inside a highly interconnected national payments and clearing infrastructure. SAMA expects member organisations to map their dependencies on shared services and to consider scenarios where those services are degraded or unavailable. ISO 22301 leaves this to the organisation to decide.

Cyber resilience integration. SAMA explicitly ties BCM to cyber recovery, including destructive attacks. Many ISO 22301 programmes treat cyber as one risk among many; SAMA wants to see specific cyber recovery scenarios, immutable backup strategies, and cross-team rehearsal between the BCM and CSIRT functions.

Board engagement. ISO 22301 requires top management commitment but does not prescribe board reporting cadence or board-level exercising. SAMA does — the board is expected to see BCM reporting at a defined frequency and to participate in crisis exercises at least periodically.

Outsourcing and third parties. SAMA's BCM Framework intersects with the SAMA Outsourcing Regulations. Material outsourcing arrangements need their own continuity assessment, contractual recovery commitments and ongoing monitoring. A bank that has outsourced critical services to a cloud provider or a managed service partner must demonstrate that those providers themselves have credible continuity capabilities.

What an inspection actually looks like

When SAMA inspects the BCM programme, the questions typically cluster around four areas.

First, policy and governance: show me the board-approved BCM policy, when was it last reviewed, who is the named programme owner, when did the board last receive BCM reporting, and what was discussed.

Second, the BIA: show me the most recent BIA, prove it covers every critical process, walk me through the RTO and RPO for the top three processes, and tell me how those numbers were derived.

Third, the most recent test: show me the test plan, the test report, the participants, the issues identified, and the closure of those issues. Auditors look particularly hard at whether issues from the previous test were genuinely fixed before the next one ran.

Fourth, a real incident: if there has been a real continuity event in the last 12–18 months, show me the incident timeline, the decisions made, the customer impact, the lessons learned and the improvements implemented. Real incidents are where the gap between documentation and reality becomes most visible.

The pattern in failed inspections is almost always the same: the documentation looks fine on paper, but the connection between the BIA, the plans, the test results and the risk register is broken. The BCM team has one set of numbers, the IT DR team has another, the risk team has a third, and the board sees a fourth. SAMA inspectors are very good at finding those mismatches.

Building a defensible BCM programme

Three habits separate the programmes that pass SAMA inspections from those that don't.

Habit one: one source of truth. The BIA, the risk register, the plans and the test results live in one connected system, not four spreadsheets. When the BIA is updated, the plans inherit the change. When a test surfaces an issue, it lands on the same risk register the board sees.

Habit two: realistic exercises. Tabletop exercises that always conclude with "the team performed well" are not exercises — they are theatre. Real exercises introduce surprise, break assumptions, run long enough to expose decision fatigue, and produce uncomfortable lessons. Inspectors can tell the difference within five minutes of reading the test report.

Habit three: cyber and BCM as one team. The destructive cyber scenario is now the most likely cause of a major continuity event for a Saudi bank. The BCM team and the CSIRT team should rehearse together, share runbooks, and treat ransomware recovery as a continuity discipline rather than a niche IT problem.

GRC Vantage's BCM module is built to support all three habits — a single connected workspace for BIAs, recovery plans, exercises, lessons learned and board reporting, with cross-links to the risk register and the cyber incident response workflow. It is used by Saudi banks and finance companies to run SAMA-aligned BCM programmes from one source of truth.

A 12-month BCM cadence

For teams trying to operationalise the framework, a workable annual cadence looks like this:

The first quarter is dedicated to refreshing the BIA and risk assessment, ideally tied to the start of the financial year so the latest business priorities are captured. This is also when the BCM policy comes back to the board for annual review.

The second quarter is plan refresh and training — updating the BCPs, IT DR plans, crisis management plan, contact lists and escalation runbooks, and running role-based training across the affected teams.

The third quarter is exercise season — at least one technical recovery test, at least one tabletop, and ideally one cross-functional simulation that includes the cyber and BCM teams together. Lessons learned are documented and tracked to closure.

The fourth quarter is reporting and improvement — consolidating the year's evidence, presenting the board with a connected resilience report covering BCM and cyber, and setting the improvement objectives for the year ahead.

This cadence is not a rigid template — it bends around the business — but it gives boards and inspectors a predictable rhythm, which is exactly what SAMA wants to see.

Where to go next

This post is part of our deeper series on the SAMA framework family. For the complete picture — CSF, BCM, IT Governance, CTI, Counter-Fraud and Outsourcing — read our pillar guide on the SAMA framework family.

For a side-by-side view of how SAMA CSF lines up with ISO 27001, see our post on SAMA CSF and ISO 27001 mapping.

And if you would like to see a SAMA-aligned BCM programme running on real data, book a demo and we will walk you through how Saudi banks use GRC Vantage to manage BIAs, exercises and board reporting from a single connected workspace.