Business Continuity Plan Template for Saudi Arabia

A business continuity plan is the operational document a Saudi organisation uses to recover its critical activities when something has gone wrong. It is the artefact a SAMA inspector asks to see, the artefact the audit committee expects to be exercised at least annually, and the artefact the BCM coordinator picks up first when a disruption hits. Yet a surprising number of Saudi organisations operate with continuity plans that were written years ago, are no longer accurate, and would not actually guide recovery under stress.

This post is the business continuity plan template Saudi organisations can use as a working starting point. It is structured to align with the SAMA Business Continuity Management Framework, ISO/IEC 22301:2019 and the cyber resilience expectations of SAMA CSF and NCA ECC. A downloadable working copy is available at the end.

What a continuity plan is and is not

The continuity plan is not the BCM strategy, not the BIA, and not the risk assessment. It is the actionable runbook that says: when a defined disruption type occurs, here is who is in charge, here is who they call, here are the steps they take, and here is how the organisation knows recovery is complete. Plans that read like strategy documents are plans that will not work under stress.

A practical Saudi organisation usually has not one continuity plan but a plan set:

• A crisis management plan (high-level, board and executive-facing).
• An incident management plan (operational, for the BCM coordinator).
• Recovery plans for each prioritised product or service.
• IT disaster recovery plans for each in-scope system.
• Supplier failure plans for each material third party.
• Communication plans (internal, regulator, customer, media).

The template below covers the structure of a single recovery plan. The same structural pattern applies to the others with different focus.

Plan template structure

Section 1 — Plan identification

• Plan title (e.g. "Recovery Plan for Retail Payments — Saudi Bank X").
• Plan owner (named individual).
• Plan version.
• Date of last review.
• Date of next scheduled review.
• Approval signatures (BCM lead, business owner, executive sponsor).
• Distribution list.
• Document classification.

Section 2 — Scope

• Product or service this plan covers.
• Locations and business units in scope.
• Disruption scenarios this plan addresses.
• Scenarios explicitly out of scope.
• Related plans (cross-references).

Section 3 — Activation criteria

• The trigger conditions under which this plan is activated.
• The decision authority who activates it (named role).
• The escalation path for activation outside business hours.
• The deactivation criteria.

Section 4 — Recovery objectives

• Maximum Tolerable Period of Disruption (MTPD) for the in-scope service.
• Recovery Time Objective (RTO) — target duration to recover.
• Recovery Point Objective (RPO) — maximum acceptable data loss.
• Minimum Business Continuity Objective (MBCO) — the minimum acceptable level of service during recovery.

Section 5 — Roles and responsibilities

A clear roster of who does what during activation:

• Plan owner. Overall accountability for the plan and its execution.
• Activation authority. Authorised to activate the plan.
• Recovery team leader. On-the-ground lead during activation.
• Recovery team members. Named individuals with defined responsibilities.
• Communication lead. Owns internal and external communication.
• Liaison roles. Regulator (SAMA, NCA, SDAIA), customer, media, supplier, partner.
• Stand-down authority. Authorised to declare recovery complete.

For each role: name, alternate name, contact details, location.

Section 6 — Dependencies

The dependency map for the in-scope service, ideally pulled from the BIA:

• People dependencies (named roles, concentration risks).
• IT system dependencies (core systems, supporting infrastructure).
• Data dependencies (critical data sets, location, RPO).
• Facility dependencies (buildings, datacentres).
• Third-party dependencies (named vendors, contracts, contact details).
• Specialist equipment dependencies.

Section 7 — Recovery procedures

The actionable runbook for recovery. This is the operative part of the plan.

For each defined scenario:

• Step-by-step recovery procedure. Numbered steps the recovery team will execute.
• Decision points. The points at which the recovery team needs a decision and who makes it.
• Validation checks. How the team verifies each step has succeeded.
• Rollback procedures. What to do if a step fails.
• Estimated duration. How long each step is expected to take.

The recovery procedure should be written in instructional language a stressed person can follow — short, numbered, with explicit checkpoints. Plans written in narrative paragraphs are plans that will not work under stress.

Section 8 — Communication plan

• Internal communication. Templates for staff updates at defined intervals. Distribution channels.
• Customer communication. Templates for customer notifications. Channels (SMS, email, app, website).
• Regulator notification. Decision criteria for SAMA, NCA, SDAIA notification. Templates. Designated authority to notify.
• Media handling. Spokesperson, holding statements, escalation criteria.
• Supplier and partner notification. As appropriate.

Section 9 — Resources and logistics

• Alternate work locations. Addresses, capacity, access procedures.
• Equipment. Laptops, mobile devices, cards, tokens.
• Funds. Petty cash, emergency procurement authority.
• Transport. Arrangements for moving staff if needed.
• Welfare. Food, water, accommodation, medical.

Section 10 — External contacts

A consolidated contact directory that the recovery team can use without searching elsewhere:

• Internal recovery team (with alternates).
• Senior management.
• Key suppliers and service providers.
• Regulators (SAMA on-call, NCA contact, SDAIA contact, other sectoral regulators).
• Emergency services (Civil Defence 998, Police 999, Ambulance 997).
• Utilities (electricity, water, gas).
• Telecoms providers.
• Insurance.
• Legal counsel.

Contact details should be reviewed at least quarterly and after any organisational change.

Section 11 — Cyber-specific procedures

Cyber scenarios require additional handling beyond general continuity:

• Forensic preservation. Steps to preserve evidence before recovery begins.
• Containment. Actions to limit blast radius before recovery.
• Coordination with cyber incident response. Named handoff points to the cyber IR team.
• Backup integrity verification. Confirming backups are not themselves compromised.
• Communication restraint. Care with public communication during ongoing cyber incidents.

A continuity plan that does not cover cyber scenarios fails the SAMA CSF and NCA ECC resilience expectations.

Section 12 — Recovery validation and stand-down

• Validation checks. What has to be confirmed before declaring recovery complete.
• Stakeholder sign-off. Who must approve before stand-down.
• Communication of stand-down. Who is told.
• Post-incident review trigger. Date by which the post-incident review must take place.

Section 13 — Plan maintenance

• Review cadence. Annual at minimum; triggered by material change.
• Exercise cadence. Annual at minimum; type and depth defined.
• Change log. Versioned change history.
• Approval workflow. Who must approve material changes.

Appendix A — Exercise log

A record of every exercise of this plan: date, type (walk-through, tabletop, simulation, live), participants, observations, lessons learned, actions, action status.

Appendix B — Activation log

A record of every real-world activation: date, scenario, decisions made, recovery duration, actual versus planned RTO/RPO, lessons learned, actions.

How to use this template

1. Take the structure above as a starting point and tailor each section to the specific service.
2. Get sign-off from the business owner, the BCM lead and the executive sponsor before issuing.
3. Distribute to the named recovery team.
4. Run a tabletop exercise within 90 days of issue to validate that the plan is actionable.
5. Review and refresh on the defined cadence.

A plan that has been written, signed and shelved is not a plan. A plan that has been written, signed, exercised and refined is.

Get the downloadable template

The full template — as a Word document with all sections and appendices ready to fill in — is available on request. Contact us to receive a copy.

For the wider international BCM context, read our ISO 22301 Saudi Arabia guide. For the SAMA-specific BCM Framework, read our SAMA frameworks guide. To see the same plan template managed inside a unified BCM platform — with version control, exercise logs, activation logs and integrated linkage to the BIA and the cyber risk register — read about GRC Vantage's BCM module, supported from our offices in Riyadh and Dammam.