SAMA Business Continuity Management — Bank Recovery Time Objectives

Overview

SAMA's Business Continuity Management Framework defines how banks must protect critical services from disruption. It mandates explicit Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) per banking service tier, regular continuity testing, and an integrated incident-management capability. Annual BIA refresh and biennial full-scale recovery drills are non-negotiable.

Who this applies to

• Every bank, finance company, insurance company and PSP licensed by SAMA.

Banking service tiers and recovery targets

SAMA defines four service tiers with maximum recovery targets:

| Tier | Examples | Max RTO | Max RPO | |---|---|---|---| | 1 — Critical | Payment switch, ATM authorisation, mobile banking auth, KYC/AML real-time screening | 1 hour | 0 (zero data loss) | | 2 — Important | Core banking ledger, treasury settlement, FX dealing | 4 hours | 15 minutes | | 3 — Routine | Reporting, batch postings, branch teller systems | 24 hours | 4 hours | | 4 — Non-critical | Marketing CRM, training systems | 72 hours | 24 hours |

Step 1: Business Impact Analysis (BIA)

Run an annual BIA covering every banking process:

process: card_authorisation
owner: Head of Cards
dependencies:
  - core_banking_switch (T1)
  - hsm_cluster (T1)
  - fraud_engine (T1)
  - external_scheme_link (T1)
financial_impact_per_hour: SAR 4.2m
regulatory_impact: SAMA reporting breach > 2h
recovery_target:
  rto: 30 min
  rpo: 0
recovery_strategy:
  - active-active across Riyadh + Dammam
  - automated failover via Anycast + GSLB
  - quarterly failover test

Step 2: Recovery architecture

| Tier 1 service | Pattern | |---|---| | Core ledger | Active-active 2 sites in KSA | | Payment switch | Active-active 2 sites in KSA | | HSM | 2-site cluster with key replication | | Fraud engine | Active-passive with hot standby | | API gateway | Active-active behind GSLB |

Step 3: Testing cadence

| Test type | Frequency | Witnessed by | |---|---|---| | Tabletop | Quarterly | Crisis Management Team | | Component failover (single service) | Quarterly | IT + Business | | Site failover (one DC) | Annually | Internal Audit | | Full-scale recovery (both DCs to alternate site) | Every 2 years | SAMA observer optional | | Cybersecurity-driven scenario (ransomware) | Annually | CISO + IR team |

Tests must be scripted and witnessed; a recorded test where one server is rebooted does not satisfy SAMA.

Step 4: Incident management integration

Incident classification triggers BCP activation:

incident severity table:
  P1 — outage of any T1 service > 15 min  → BCP partial activation
  P1+ — outage of any T1 service > 60 min → BCP full activation
  P2 — outage of any T2 service > 60 min  → BCP standby

Communication tree: Crisis Manager → CEO → Board (notification within 4h for P1+) → SAMA (notification within 4h per SAMA Incident Reporting Procedure).

Step 5: Cyber-resilience scenarios

SAMA expects BCM to address cyber scenarios explicitly:

• Ransomware encrypting primary + replica.
• DDoS sustained > 4 hours.
• Insider data destruction.
• Supplier compromise.
• Cloud-region outage.

For ransomware specifically: maintain immutable backups (object-lock S3 / WORM tape) outside the production domain, restore-tested quarterly.

Step 6: Reporting to SAMA

Annual BCM submission to SAMA must include:

• BIA results and changes since last submission.
• Test plan and results from the last 12 months.
• Open findings from the last independent BCM audit.
• Any incident that triggered BCP activation, with timeline and lessons learned.

Common gotchas

• "DR site is configured" but never tested in production-like load — fails on first drill.
• BIA based on system list, not business process list — auditors require business-process view.
• Backup retention 90 days — too short for ransomware that lurks 6 months.
• DR site staffed only "when needed" — for T1 services SAMA expects continuous coverage.

Verification

• BIA dated within last 12 months.
• BCP / DR playbooks per service.
• Test calendar with witnessed evidence per test.
• Quarterly exercise reports submitted to the CRO.
• Annual SAMA BCM submission acknowledged.
• Immutable backup architecture documented.

Conclusion

BCM is muscle memory for the bank — it is built by repetition and tested under realistic load. Skip a quarterly drill and SAMA assumes the muscle has atrophied; skip a year and they will tell you so in writing.

Related guides

• SAMA Cyber Security Framework — Full Roadmap
• SAMA IT Governance Framework
• SAMA Cloud Computing Rulebook