# SAMA BCM Recovery Plan Testing: Four Exercise Scenarios That Prove Your Cyber-Resilience Controls Actually Work
Many SAMA-regulated financial institutions conduct recovery-plan testing through tabletop discussions that never validate whether systems can be restored or whether teams can make decisions under stress. Participants walk through procedures on paper, nod in agreement, and the exercise report concludes that the plan is adequate. When a real incident occurs—ransomware that encrypts core banking, a distributed denial-of-service attack against payment gateways, or a cloud provider outage—the institution discovers that the plan was never tested against the technical and operational realities of recovery. SAMA BCM recovery plan testing scenarios must go beyond discussion to demonstrate that critical services can actually be restored within the recovery-time objectives the institution has committed to.
The Saudi Central Bank expects regulated institutions to conduct exercises that validate both technical restoration and decision-making under realistic conditions. Section 5.2 of the SAMA Business Continuity Management framework requires institutions to test recovery plans through exercises that simulate disruption scenarios, measure recovery performance against objectives, and produce documented lessons that lead to plan improvements. This article defines four exercise scenarios that SAMA BCM examiners expect to see documented: ransomware encryption of core banking systems, payment-gateway distributed denial-of-service attack, data-centre power loss, and third-party cloud-service outage. For each scenario, we describe the participant roles, the decisions that must be logged, and the recovery-time measurements that prove the plan works.
Why Tabletop Discussions Alone Do Not Satisfy SAMA BCM Requirements
A tabletop exercise gathers stakeholders in a conference room, presents a hypothetical incident, and asks participants to describe what they would do. The facilitator reads from a scenario script, participants refer to the continuity plan, and the group discusses roles and escalation paths. The exercise concludes after ninety minutes, and the report states that all participants demonstrated familiarity with the plan.
This approach fails to validate three critical elements that SAMA BCM examiners assess during on-site reviews. First, it does not confirm that technical restoration procedures actually work—that backup systems can be brought online, that data can be restored from replicas, or that failover to a secondary site succeeds. Second, it does not test decision-making under time pressure—whether the crisis-management team can prioritize recovery actions when multiple systems are down, whether they can authorize expenditure for emergency services, or whether they can decide when to notify SAMA and customers. Third, it produces no measurable evidence of recovery performance—no timestamps showing how long each step took, no logs of decisions made, and no comparison between actual recovery time and the stated recovery-time objective.
SAMA BCM examiners review exercise reports to verify that the institution has tested its plans against realistic scenarios, that participants performed actual recovery tasks rather than discussing them, and that the institution measured performance and implemented improvements. An exercise program that relies solely on tabletop discussions will not satisfy these expectations.
The Four Exercise Scenarios SAMA BCM Examiners Expect to See
SAMA-regulated institutions should design an exercise program that covers four core disruption scenarios, each testing a different dimension of cyber resilience and business continuity. The scenarios should be documented with participant roles, decision logs, and recovery-time measurements, and each should be conducted at least annually so that the institution can demonstrate continuous testing and improvement.
Scenario One: Ransomware Encryption of Core Banking Systems
This scenario simulates a ransomware attack that encrypts the institution's core banking platform, rendering customer accounts inaccessible and halting transaction processing. The exercise tests the institution's ability to isolate infected systems, restore data from clean backups, and resume critical banking services within the recovery-time objective.
Participant roles include the IT recovery team responsible for system restoration, the information-security team responsible for containment and forensic preservation, the crisis-management team responsible for business decisions, and the communications team responsible for customer and regulatory notification. Each role should be assigned to named individuals who perform the tasks they would perform in a real incident.
Decision logs must capture the time at which the crisis-management team decided to activate the recovery plan, the time at which they decided to isolate the core banking platform from the network, the time at which they authorized restoration from backup, and the time at which they decided to notify SAMA and customers. Each decision should include the name of the person who made it and the information on which it was based.
Recovery-time measurements must record the time from initial detection to isolation of infected systems, the time from isolation to initiation of backup restoration, the time from initiation to completion of data restoration, and the time from completion to resumption of customer transactions. These timestamps should be compared to the recovery-time objective stated in the business-continuity plan, and any gap should be explained in the exercise report.
The exercise should use a test environment that mirrors the production core banking platform, so that the IT recovery team performs actual restoration procedures rather than describing them. If the institution does not have a test environment, the exercise should at least validate the first steps of the procedure—locating backup media, verifying backup integrity, and initiating the restoration process—and document the reasons why full restoration could not be tested.
Scenario Two: Payment-Gateway Distributed Denial-of-Service Attack
This scenario simulates a distributed denial-of-service attack that overwhelms the institution's payment gateway, preventing customers from completing card transactions and disrupting revenue. The exercise tests the institution's ability to activate traffic-filtering controls, fail over to a secondary gateway, and restore normal service levels.
Participant roles include the network-operations team responsible for traffic filtering and failover, the payment-services team responsible for transaction monitoring and reconciliation, the crisis-management team responsible for business decisions, and the third-party manager responsible for coordinating with the payment-gateway provider. Each role should be assigned to individuals who have the authority and access to perform the required tasks.
Decision logs must capture the time at which the network-operations team decided that the traffic pattern constituted an attack, the time at which the crisis-management team decided to activate the secondary gateway, the time at which they decided to notify the payment-gateway provider and request assistance, and the time at which they decided to notify customers of service disruption. Each decision should include the criteria used to make it.
Recovery-time measurements must record the time from initial detection to activation of traffic-filtering controls, the time from activation to failover to the secondary gateway, the time from failover to resumption of transaction processing, and the time from resumption to restoration of normal service levels. These timestamps should be compared to the recovery-time objective for payment services, and any delay should be analyzed to identify bottlenecks.
The exercise should involve actual failover to the secondary gateway in a test environment, or at least a controlled failover during a low-traffic period, so that the institution can verify that the procedure works and that transaction data is not lost during the transition.
Scenario Three: Data-Centre Power Loss and Generator Failure
This scenario simulates a power outage at the institution's primary data centre, followed by failure of the backup generator, forcing an unplanned failover to the disaster-recovery site. The exercise tests the institution's ability to execute site failover, restore critical systems at the secondary site, and maintain service continuity.
Participant roles include the data-centre operations team responsible for power management and site failover, the IT recovery team responsible for system restoration at the secondary site, the crisis-management team responsible for business decisions, and the facilities team responsible for coordinating with power and generator vendors. Each role should be assigned to individuals who have physical and logical access to both sites.
Decision logs must capture the time at which the data-centre operations team decided that the generator had failed and that site failover was necessary, the time at which the crisis-management team authorized the failover, the time at which they decided to notify SAMA of the disruption, and the time at which they decided to declare the incident resolved and fail back to the primary site. Each decision should include the technical information and risk assessment on which it was based.
Recovery-time measurements must record the time from power loss to generator failure, the time from generator failure to initiation of site failover, the time from initiation to completion of failover, and the time from completion to resumption of critical services at the secondary site. These timestamps should be compared to the recovery-time objective for each critical service, and any service that exceeded its objective should be flagged for plan revision.
The exercise should involve actual failover of at least one critical system to the disaster-recovery site, so that the institution can verify that data replication is current, that systems start successfully at the secondary site, and that users can access services from the new location.
Scenario Four: Third-Party Cloud-Service Outage
This scenario simulates an outage of a third-party cloud service on which the institution depends—such as a cloud-hosted customer portal, a software-as-a-service risk platform, or a cloud-based data warehouse. The exercise tests the institution's ability to activate alternative access methods, communicate with the cloud provider, and maintain business operations during the outage.
Participant roles include the third-party risk manager responsible for coordinating with the cloud provider, the IT team responsible for activating alternative access methods, the business owner responsible for the affected service, the crisis-management team responsible for business decisions, and the communications team responsible for customer notification. Each role should be assigned to individuals who have contractual authority and technical access to implement workarounds.
Decision logs must capture the time at which the third-party risk manager confirmed the outage with the cloud provider, the time at which the crisis-management team decided to activate the alternative access method, the time at which they decided to notify customers of reduced functionality, and the time at which they decided to escalate the issue to the cloud provider's senior management. Each decision should include the service-level agreement terms and contractual obligations that informed it.
Recovery-time measurements must record the time from initial detection to confirmation of the outage, the time from confirmation to activation of the alternative access method, the time from activation to resumption of business operations, and the time from the cloud provider's restoration to return to normal service. These timestamps should be compared to the recovery-time objective for the affected business process, and any gap should be used to inform contract renegotiation or service redesign.
The exercise should involve actual activation of the alternative access method—such as switching to a manual process, activating a standby service, or redirecting users to a different system—so that the institution can verify that the workaround is feasible and that data can be synchronized once the cloud service is restored.
Documenting Exercise Results for SAMA BCM Compliance
Each exercise must produce a documented report that includes the scenario description, the participant list with roles, the timeline of events with decision logs, the recovery-time measurements compared to objectives, the lessons learned, and the improvement actions with assigned owners and deadlines. SAMA BCM examiners review these reports to verify that the institution is testing its plans, measuring performance, and implementing improvements.
The report should include a table that lists each critical service affected by the scenario, the recovery-time objective for that service, the actual recovery time measured during the exercise, and the gap if any. For each gap, the report should explain the root cause—whether it was a technical failure, a procedural error, a resource constraint, or a decision delay—and describe the corrective action that will close the gap before the next exercise.
The improvement actions should be tracked in the institution's risk register or project-management system, with assigned owners and deadlines, and the status of each action should be reported to the board or the risk committee. When the next exercise is conducted, the report should reference the previous exercise and confirm that the improvement actions were completed and that the gaps were closed.
How We Build and Test Business Continuity and Cyber Resilience
We build and test your business continuity and cyber resilience capability in line with SAMA BCM and SAMA cyber resilience requirements: impact analysis, recovery strategies, plans and exercises.
Our 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.
We deliver 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.
If your institution needs to design and conduct SAMA BCM recovery plan testing scenarios that validate technical restoration and decision-making, we can help you build an exercise program that satisfies regulatory expectations and proves your controls actually work.
