If you have been handed a "SAMA RTO/RPO tier table" — Tier 1 at 15 minutes, Tier 2 at one hour, and so on — throw it away. It is not a simplification of SAMA's rules. It is an invention. The word "tier" does not appear in SAMA's Business Continuity Management Framework, and neither does any recovery-time number at all.
What follows is the SAMA BCM Framework read straight from SAMA's own rulebook: what it is, what it actually requires, the deadlines that are real, and the widely-circulated specifics that are not. Every claim below carries a section number so you can check it yourself. Where SAMA states no figure, this guide says so plainly instead of inventing one — because inventing one is precisely how a bank ends up over-engineering an imaginary target while missing a real obligation.
The 60-second answer
- The instrument is the Business Continuity Management Framework, issued under Circular No. 381000058504, dated 1/6/1438H — 27/2/2017G. Status: In-Force.
- It is a separate instrument from the Cyber Security Framework. The CSF does not cover business continuity; CSF §1.3 refers you out to SAMA's business-continuity requirements. See our SAMA Cyber Security Framework guide.
- It has two chapters: Introduction (1.1–1.9) and Business Continuity Requirements (2.1–2.13).
- RTO, RPO and MAO are defined as concepts only (§1.2). SAMA sets no value for any of them. You derive them from your own Business Impact Analysis, and your BCM Committee endorses them (§2.4.4).
- There is no maturity model in the BCM Framework. (Maturity levels belong to the CSF and the IT Governance Framework, not to BCM.)
- The real deadlines are in §2.11 and §2.9.3 — and they are the ones the fake tier grid leaves out. They are listed below.
What the BCM Framework actually is
SAMA owns the framework and is responsible for periodically updating it; Member Organizations are responsible for adopting and implementing it (§1.5). Its stated applicability (§1.4) is:
"All organizations affiliated with SAMA ("the Member Organizations"); All banks operating in Saudi Arabia; All banking subsidiaries of Saudi banks; Subsidiaries of foreign banks situated in Saudi Arabia."
The rulebook additionally tags the framework's scope of application as the Banking Sector, Finance Sector, Payment Systems and Payment Services Providers, and Credit Bureaus.
Scope reaches beyond your own payroll. §1.3 states the framework "is applicable to the full scope of the Member Organization, including subsidiaries, employees, subcontractors, third-parties and customers." Your outsourced provider is inside your BCM perimeter, not outside it.
The real structure
Chapter 2 is the whole substance. Thirteen sections, each stating a Principle, an Objective, and numbered Control considerations:
| § | Section |
|---|---|
| 2.1 | BCM Governance |
| 2.2 | BCM Strategy |
| 2.3 | Business Continuity Policy |
| 2.4 | Business Impact Analysis (BIA) and Risk Assessment (RA) |
| 2.5 | Business Continuity Plan (BCP) |
| 2.6 | IT Disaster Recovery Plan (DRP) |
| 2.7 | Cyber Resilience |
| 2.8 | Crisis Management Plan |
| 2.9 | Testing (2.9.1 BCP Testing · 2.9.2 DRP Testing · 2.9.3 Executed Tests) |
| 2.10 | Awareness and Training |
| 2.11 | Communication |
| 2.12 | Periodic Documents Review |
| 2.13 | Assurance |
That is the entire architecture. There are no tiers, no classes, no grades, no bands.
Governance: the BCM Committee
SAMA names one body, and it is the BCM Committee (§2.1.3): "A BCM Committee should be established and mandated by the board of directors."
The rest of §2.1, in SAMA's own terms:
- The board of directors, or a delegated executive member, has ultimate responsibility for the BCM programme (§2.1.1), and must allocate sufficient budget (§2.1.2).
- Represented on the committee: CRO, COO, CIO, CISO, the BCM manager and other relevant departments (§2.1.4).
- A committee charter covering objectives, roles and responsibilities, minimum number of meeting participants, and meeting frequency — minimum quarterly (§2.1.5).
- A BCM function must be established (§2.1.6), and a BCM manager/head appointed with appropriate authority, qualifications and experience (§2.1.7).
Quarterly is the only cadence SAMA fixes here. Note what it is not: it is not a maturity target, and it is not a recovery-time commitment.
RTO, RPO and MAO: definitions, not numbers
This is the heart of the matter, so here is §1.2 verbatim:
Maximum Acceptable Outage (MAO) is defined as the time that would take for adverse impacts which might arise because of not providing a product/service or performing an activity, to become unacceptable.
Recovery Time Objective (RTO) is defined as the period following an incident within which, products or services must be resumed, activity must be resumed, or resources must be recovered.
Recovery Point Objective (RPO) is defined as the point to which, information used by an activity must be restored to enable the activity to operate on resumption. This can also be termed as "Maximum Data Loss".
Three definitions. Zero values.
The framework then tells you who produces the numbers — you do. Under §2.4.3, the Member Organization identifies and prioritizes its activities by performing a BIA, determining "(b) The recovery time objectives (RTOs), recovery point objectives (RPOs) and maximum Acceptable Outage (MAO)". Under §2.4.4, "The BCM committee should endorse the prioritized list, BIA results, RA and the defined RTOs, RPOs and MAOs." Under §2.4.6, the BIA and RA are updated annually and on major change.
The closest SAMA comes to signalling stringency is §2.4.9: Member Organizations "should ensure that RTOs are adequately defined for payment systems, customer related services, etc. considering the high availability of these operations and minimum disruption in the event of disaster." Read it carefully. SAMA points at payment systems as the place to be strict — and still declines to state a number. "Adequately defined" is the standard. Your BIA is the evidence.
Things that do not exist
This section is why this article exists. Each item below has been circulating in the Saudi market — in vendor decks, consultancy summaries and, until recently, on this very site. None of it is in SAMA's text.
❌ The SAMA "Tier 1–4" RTO/RPO grid
There is no tier grid. The word "tier" appears zero times in the Business Continuity Management Framework. There is no Tier 1, no Tier 2, no classification of systems into recovery bands by SAMA.
❌ A SAMA-mandated RTO of "15 minutes" or RPO of "1 hour"
No numeric recovery-time or recovery-point value appears anywhere in the framework. Not fifteen minutes, not one hour, not four hours, not twenty-four hours. Any document that attributes such a figure to SAMA is attributing it to a source that does not say it.
This matters more than it first appears. A bank that adopts the fake grid does not merely waste money engineering to an imaginary 15-minute RTO. It also, in the version that was previously published here, never sees the two deadlines that are real — because the grid replaced them. The institution over-complies with fiction and under-complies with fact, while believing itself ahead.
❌ A BCM "maturity level"
The BCM Framework contains no maturity model. There is no "BCM maturity level 3". Maturity levels 0–5 belong to the Cyber Security Framework and to the IT Governance Framework — different instruments, different circulars.
✅ …and the real obligations the fake grid left out
Here is what SAMA does put a clock on. All of these are real, and all of them are dated.
Reporting and deadlines — §2.11 Communication:
- Disruptive incidents classified "Medium" or "High" must be reported to SAMA "Banking IT Risk Supervision" immediately, with a post-incident report communicated after the Member Organization resumes normal operations.
- The approved programme for the coming year's BC and DR tests must reach SAMA "Banking IT Risk Supervision" by the end of January of every year.
- "Test results of business continuity and disaster recovery should be shared with SAMA within four weeks after the test."
- "The Member Organization should identify the improvements based on the test performed and provide an action plan to SAMA within two months after the submission of the test results."
- Media communication during an incident must be coordinated with SAMA Supervision.
- SAMA's approval must be sought when selecting a new site for the main or alternative data centre, or when relocating either.
Testing — §2.9:
- BCP simulation test exercises: at least once a year (§2.9.1.1), with scenarios that should take cyber security scenarios into consideration and cover activation of the crisis management team.
- A DR test combined with BCP: at least once a year (§2.9.2).
- On a failed test, re-testing must occur within defined timelines that "should not exceed the limit of three (3) months" (§2.9.3.2).
- Internal Audit — or a qualified external auditor — must observe the BC and DR testing activities as an independent participant (§2.9.3.3).
- All BCP and DRP test results must be reported to the BCM committee, senior management and the board of directors (§2.9.3.4).
That is a real regulatory calendar — an annual programme filed in January, tests run at least yearly and observed by audit, results to SAMA within four weeks, an action plan within two months, and a three-month ceiling on re-testing after failure. It is more demanding, more specific and more auditable than the invented tier grid. It is also the thing an examiner will actually ask for.
The SAMA BCM calendar at a glance
Every row below is a real obligation with a real section number. There is no row for "achieve a 15-minute RTO", because SAMA never wrote one.
| When | What | § |
|---|---|---|
| By end of January, every year | Submit the approved BC/DR test programme for the coming year to SAMA "Banking IT Risk Supervision" | 2.11 |
| At least once a year | BCP simulation test exercise | 2.9.1.1 |
| At least once a year | DR test combined with BCP | 2.9.2 |
| At least once a year | Update the BIA and RA (and on major change) | 2.4.6 |
| At least once a year | Assess vendor/supplier/service-provider capability to maintain service levels during disruption | 2.4.8 |
| At least once a year | Test the BCPs of key service providers for critical activities | 2.5.10 |
| At least once a year | Evaluate IT DRP effectiveness | 2.6.10 |
| Annually | BCM training programme for staff involved in BCM | 2.10.2 |
| Minimum quarterly | BCM Committee meets | 2.1.5(d) |
| Within 4 weeks of a test | Share BC/DR test results with SAMA | 2.11 |
| Within 2 months of submitting results | Provide SAMA an improvement action plan | 2.11 |
| Within 3 months, maximum | Re-test after a failed test | 2.9.3.2 |
| Immediately | Report "Medium" or "High" disruptive incidents to SAMA | 2.11 |
| Before the event | Obtain SAMA approval to select or relocate a main or alternative data centre | 2.11, 2.6.2 |
More of §2.4 that gets skipped
Three control considerations in the BIA/RA section deserve a callout, because they are where outsourced infrastructure actually bites:
- §2.4.7 — the risk assessment "should include risks associated with overall organization as well as data centers (primary and alternative), which are not owned by the Member Organization", explicitly citing "the timeframe needed to relocate to a new site" and requiring "a sufficient timeframe in the contractual agreement". If you rent your data centre or buy cloud, SAMA expects the relocation timeline to be in the contract.
- §2.4.8 — vendor, supplier and service-provider capability to support and maintain service levels for prioritized activities during disruptive incidents "should be assessed at least on a yearly basis".
- §2.4.9 — RTOs "adequately defined for payment systems, customer related services, etc." — the stringency signal, with no number attached.
How BCM connects to the other two frameworks
SAMA's three IT-related frameworks are designed to interlock, and the joins are explicit in the text. This matters because a fabrication in one document propagates into the others.
- The IT Governance Framework points at BCM. ITGF §3.3.10.2(a) requires the data backup management policy to consider "alignment with SAMA Business Continuity Management Framework", and §3.3.10.5(b) requires backup and restoration requirements to be defined in line with "the agreed RPO". Note the word agreed: the ITGF, like the BCM Framework, treats the RPO as a number you agree, not one SAMA hands you. Two separate SAMA frameworks decline to state an RPO value. That is not an oversight.
- The Cyber Security Framework points at BCM. CSF §3.4.3.4(f)(1) requires cloud contracts to ensure "business continuity requirements are met in accordance with the Member Organization's business continuity policy" — your policy, again, is the yardstick.
- BCM points back at the CSF. §2.7 refers you to the Cyber Security Framework for threat and vulnerability management.
- Data-centre outsourcing sits across all of it. ITGF §3.3.5.4 requires that "the outsourcing of data center should comply with the requirements published in SAMA circulars on the Rules of The Outsourcing and Cybersecurity Framework" — that is the Rules on Outsourcing, Circular 41027017 (dated 18/4/1441H — 15/12/2019G), alongside the CSF.
See our guides to the Cyber Security Framework and the IT Governance Framework.
The rest of Chapter 2, briefly
§2.5 Business Continuity Plan. Procedures for responding to disruptive incidents must collectively include key resources, defined roles and authorities, escalation, "a process to continue the critical activities within predetermined recovery objectives (RTO, RPO and MAO)", resumption to business-as-usual, communication guidelines, and cyber security requirements where relevant (§2.5.2). Sufficient alternative business workspace is required (§2.5.6), with the same logical, physical and environmental security controls as the primary site (§2.5.8). Key service providers for critical activities must have a BCP in place, tested at least yearly (§2.5.10).
§2.6 IT Disaster Recovery Plan. An alternative data centre is required at an appropriate location, chosen on the basis of a risk assessment confirming it "does not share the same risks of the main data center (e.g., geographical threat)" — and upon approval from SAMA (§2.6.2). Data, system, network and application configurations and capacities at the alternative site should be commensurate with the main site (§2.6.3), carrying the same logical, physical, environmental and cyber security controls (§2.6.4). Backups must have an offsite location (§2.6.6). Effectiveness of the IT DRP is evaluated at least yearly (§2.6.10).
§2.7 Cyber Resilience. Changes to infrastructure and software supporting critical services must undergo in-depth risk assessment and strict change management to avoid single points of failure (§2.7.1), with a periodic architectural review (§2.7.2). SAMA explicitly points here to the Cyber Security Framework for threat and vulnerability management.
§2.8 Crisis Management Plan. Must define criteria for declaring a crisis, a command centre and an emergency command centre, crisis-management team members and contacts, the steps during and after a crisis, a communication and media response plan, and the frequency of crisis management tests (§2.8.4).
§2.10 Awareness and Training. A training programme provided annually to employees involved in BCM (§2.10.2).
§2.12 Periodic Documents Review. A documented review/update process; every document must clearly show the date it was last reviewed and approved.
§2.13 Assurance. BCM must be reviewed/audited by a qualified independent internal or external party, with gaps and a remediation road map reported to senior management and the BCM committee.
What SAMA does not tell you
An honest guide has to mark its gaps rather than fill them.
- SAMA states no RTO, RPO or MAO value — for any system, including payment systems. If you need a defensible number, it comes from your BIA, not from a circular.
- SAMA does not define "critical activity" numerically. No revenue threshold, no customer-count threshold. §2.4 gives you the method (BIA and RA) and leaves the determination with you.
- SAMA does not publish a control count for the BCM Framework, and does not number controls in an
n-n-nstyle. Controls are numbered within their section (e.g. §2.9.3 item 2). - The BCM Framework does not set a maturity target, because it has no maturity model.
- Frequency of crisis-management tests is left to you — §2.8.4(g) requires you to define it, and names no number.
If you have seen any of these stated as a SAMA figure, you have seen a fabrication.
A realistic first 90 days
- Locate the primary source. Read the rulebook text, not a summary — including this one. Everything above is checkable in ten minutes.
- Stand up the BCM Committee properly (§2.1): board mandate, the named roles at the table, a charter, quarterly minimum.
- Run the BIA (§2.4) and let it produce your RTOs, RPOs and MAOs. Get the committee to endorse them (§2.4.4). That endorsement is your defensible answer to "why 4 hours?".
- Fix the calendar. Test programme to SAMA by end of January. Tests at least annually. Results to SAMA within four weeks. Action plan within two months. Re-test inside three months on failure.
- Check your data-centre paperwork. If you are selecting or relocating a main or alternative data centre, SAMA approval is required (§2.11, §2.6.2).
- Book the assurance review (§2.13) — independent, with a road map.
Where a hosting provider fits — and where it does not
Be clear-eyed about this, because vendor marketing in this market routinely overstates it.
No hosting provider can make you SAMA-compliant. BCM compliance is a governance programme: a committee, a BIA, plans, tests, reports and audit evidence. Infrastructure is an input to it, not a substitute for it. Any provider that claims otherwise is selling you the same kind of confident fiction as the tier grid.
What infrastructure can do is make specific control considerations easier to satisfy — an alternative site that demonstrably does not share the primary site's geographical risk (§2.6.2), an offsite backup location (§2.6.6), and capacity at the secondary site commensurate with the primary (§2.6.3).
Skyline Cloud operates an in-Kingdom region — Dammam, powered by Google Cloud — which keeps data in Saudi Arabia and gives you a Saudi-resident answer to the data-location questions that surface in every third-party review. For a SAMA Member Organization, the honest framing is that this is a candidate input to your BIA-driven design and to your §2.6 site risk assessment, and that the approval path in §2.11 and §2.6.2 remains yours to walk. For the many organizations in the Saudi market that are not SAMA-regulated but want the same discipline, it is simply a well-run local region. You can start a free 14-day trial and evaluate it against your own criteria before it goes anywhere near a vendor register.
Frequently asked questions
Does SAMA mandate a specific RTO or RPO?
No. SAMA's Business Continuity Management Framework defines RTO, RPO and MAO as concepts in §1.2 and states no value for any of them anywhere in the document. You determine them through your Business Impact Analysis (§2.4.3), and your BCM Committee endorses them (§2.4.4). Any "SAMA-mandated RTO" figure you have been shown is not from SAMA.
Is there a SAMA Tier 1–4 recovery tier grid?
No. The word "tier" does not appear in the framework at all. There is no SAMA classification of systems into recovery tiers. The tier grid is a fabrication that circulated widely in the Saudi market, and it is dangerous precisely because it omits the real deadlines in §2.11.
What deadlines does SAMA actually impose for BCM?
The concrete ones: the coming year's BC/DR test programme goes to SAMA "Banking IT Risk Supervision" by the end of January each year; test results go to SAMA within four weeks after the test; an improvement action plan follows within two months of submitting those results; a failed test must be re-tested within timelines not exceeding three months; and Medium or High disruptive incidents are reported to SAMA immediately (§2.11, §2.9.3).
Is business continuity part of the SAMA Cyber Security Framework?
No — they are separate instruments. The Cyber Security Framework (Circular 381000091275) refers business-continuity requirements out to SAMA's business-continuity requirements in its §1.3. The BCM Framework is Circular 381000058504. The CSF does contain a related but distinct control area, and the BCM Framework in turn points back to the CSF for threat and vulnerability management (§2.7). See our SAMA CSF guide.
How often must a bank test its BCP and DRP under SAMA rules?
At least once a year for BCP simulation exercises (§2.9.1) and at least once a year for a DR test combined with BCP (§2.9.2). Internal Audit or a qualified external auditor must observe the testing as an independent participant (§2.9.3.3), and results go to the BCM committee, senior management and the board (§2.9.3.4).
Does SAMA have to approve our data centre?
Yes, in the situations SAMA names. The alternative data centre requires approval from SAMA (§2.6.2), and SAMA's approval must be sought when selecting a new site for the main or alternative data centre, or when relocating either (§2.11).
Is there a BCM maturity level under SAMA?
No. The BCM Framework contains no maturity model. The 0–5 maturity levels belong to the Cyber Security Framework and the IT Governance Framework, which are different circulars.
How to check any SAMA claim in five minutes
The fabrications described above survived in the Saudi market for a long time because almost nobody checks. Checking is genuinely fast. Here is the whole method.
- Go to
rulebook.sama.gov.sa. This is SAMA's official online rulebook and the live authority. Note that legacysama.gov.sa/.../*.pdflinks no longer serve PDFs — they return an HTML shell. If a source cites one of those PDF URLs as its evidence, that source did not open it either. - Find the instrument and read its header. Every rulebook page carries the circular number, the Hijri and Gregorian dates, and a status field. If the status is not In-Force, stop. If the document your source names does not exist in the rulebook at all — as with the mythical "SAMA Cloud Rulebook" — stop.
- Navigate to the section number your source cites. A real citation resolves to a real page. An invented one does not resolve, or resolves to a section about something else entirely. This single step kills most fabrications outright.
- Search the text for the number. If someone claims SAMA mandates X, the string X should appear in SAMA's text. Search for "tier". Search for "15 minutes". Search for "SAR". If the number is not there, SAMA did not say it. A regulator that wanted a figure would have written the figure.
- Be equally rigorous about absence. The hardest discipline is writing "SAMA does not state a figure here" instead of supplying a plausible one. Every fabrication in the 2026 audit was, in its own way, someone declining to write that sentence.
Never accept a control ID, committee name, threshold or deadline from a consultancy blog, a vendor deck, a Big-4 marketing PDF or a LinkedIn post. Those are where the fabrications came from. Use them, at most, to locate a primary URL — then go read it.
Sources
Everything in this article is taken from SAMA's official online rulebook, which is the live authority. Legacy sama.gov.sa PDF links no longer serve the documents.
- Business Continuity Management Framework — Circular 381000058504 (SAMA Rulebook)
- §1.2 Definitions · §2.1 BCM Governance · §2.4 BIA and Risk Assessment
- §2.6 IT Disaster Recovery Plan · §2.9.3 Executed Tests · §2.11 Communication
- Cyber Security Framework — Circular 381000091275
This guide is a reading of the primary source, not regulatory advice. The binding text is the current version on SAMA's rulebook. If any statement here diverges from it, the rulebook wins — and we want to know.

Comments
0 total · 0 threads