SAMA Cyber Security Framework: The Definitive Guide (And What Does Not Exist)

There is no such thing as the "SAMA Cloud Rulebook."

It is worth saying that first, because a surprising amount of the Saudi compliance material circulating in 2026 tells banks to file a cloud pre-approval "under the SAMA Cloud Rulebook," cites a SAMA business-continuity "Tier 1–4 RTO/RPO grid," and quotes SAMA control numbers in the National Cybersecurity Authority's n-n-n format. None of those three things exist. They are inventions, and they are being copied between consultancy decks, vendor landing pages and LinkedIn posts faster than anyone is checking them.

This guide is written against SAMA's own published text — the SAMA Rulebook, the Saudi Central Bank's official online rulebook, which is where the in-force version of every instrument below actually lives. Every domain number, every subdomain, every maturity level, every deadline and every quoted requirement was read from that source. Where SAMA states no figure, this guide says "SAMA does not state a figure here" rather than supplying one — because inventing precision is the single most damaging thing you can do to a compliance officer, and it is exactly how the fabrications above got started.

The 60-second answer

• The instrument is the Cyber Security Framework (CSF), issued under Circular No. 381000091275, dated 28/8/1438H (24/5/2017G). It is still In-Force as of July 2026. There is no version 2.
• It has 4 main domains and 32 subdomains, numbered n.n.n — for example 3.3.15 Cyber Security Incident Management. Not n-n-n. That is the NCA's scheme, and it belongs to a different regulator.
• The maturity model has 6 levels — 0, 1, 2, 3, 4 and 5 (CSF 2.4). Not four. Not five.
• Every Member Organization must reach maturity level 3 as a minimum (CSF 2.4). Banks must additionally reach level 4 on four named subdomains.
• Cloud is not a separate SAMA instrument. It is one subdomain — CSF 3.4.3 Cloud Computing — sitting inside domain 3.4 Third Party Cyber Security.
• The SAMA cloud pre-approval is real. It is just not where the fabricators said it was: it is CSF 3.4.3.4(a)(2).
• The CSF contains no RTO or RPO figures at all, because business continuity is explicitly out of scope of the CSF (CSF 1.3). RTO/RPO live in a different document, and that document sets no numbers either.

What the CSF actually is

SAMA established the Framework "to enable Financial Institutions regulated by SAMA ('the Member Organizations') to effectively identify and address risks related to cyber security" (CSF 1.1). It is explicitly principle-based, also referred to as risk based (CSF 2.2) — it prescribes principles and objectives, and lists control considerations that "should be considered" in achieving them.

That word "considered" matters, and it is routinely mis-sold. The CSF is not a checklist you tick. CSF 2.2 states that where a control consideration cannot be tailored or implemented, the Member Organization "should consider applying compensating controls, pursuing an internal risk acceptance and requesting a formal waiver from SAMA." There is a formal waiver route, and it is documented in Appendix D — How to request a Waiver from the Framework. Anyone who tells you the CSF admits no exceptions has not read section 2.2.

The Framework "supersedes all previous issued by SAMA circulars with regard to cyber security" (CSF 1.1), with the superseded list at Appendix A. It draws on NIST, ISF, ISO, BASEL and PCI (CSF 1.1) — it is not a clone of any of them.

The real structure: 4 domains, 32 subdomains

CSF 2.1 states plainly: "The Framework is structured around four main domains." For each domain, subdomains are defined; each subdomain states a principle, an objective, and control considerations. Control considerations are uniquely numbered and "can consist of up to 4 levels" (CSF 2.1) — which is why you see citations like 3.4.3.4(b)(1).

Seven plus five plus seventeen plus three is thirty-two. If a proposal quotes you a different subdomain count, ask which document they read.

The full subdomain list, as published:

3.1 Cyber Security Leadership and Governance — 3.1.1 Cyber Security Governance · 3.1.2 Cyber Security Strategy · 3.1.3 Cyber Security Policy · 3.1.4 Cyber Security Roles and Responsibilities · 3.1.5 Cyber Security in Project Management · 3.1.6 Cyber Security Awareness · 3.1.7 Cyber Security Training

3.2 Cyber Security Risk Management and Compliance — 3.2.1 Cyber Security Risk Management · 3.2.2 Regulatory Compliance · 3.2.3 Compliance with (Inter)national Industry Standards · 3.2.4 Cyber Security Review · 3.2.5 Cyber Security Audits

3.3 Cyber Security Operations and Technology — 3.3.1 Human Resources · 3.3.2 Physical Security · 3.3.3 Asset Management · 3.3.4 Cyber Security Architecture · 3.3.5 Identity and Access Management · 3.3.6 Application Security · 3.3.7 Change Management · 3.3.8 Infrastructure Security · 3.3.9 Cryptography · 3.3.10 Bring Your Own Device (BYOD) · 3.3.11 Secure Disposal of Information Assets · 3.3.12 Payment Systems · 3.3.13 Electronic Banking Services · 3.3.14 Cyber Security Event Management · 3.3.15 Cyber Security Incident Management · 3.3.16 Threat Management · 3.3.17 Vulnerability Management

3.4 Third Party Cyber Security — 3.4.1 Contract and Vendor Management · 3.4.2 Outsourcing · 3.4.3 Cloud Computing

Note what domain 3.3 tells you about SAMA's priorities: seventeen of the thirty-two subdomains are operations and technology. And note that cloud gets exactly one subdomain out of thirty-two. It is a third-party risk topic to SAMA, not a regime of its own.

The maturity model: six levels, not four

This is the most consistently mangled part of the CSF, so here it is verbatim from CSF 2.4: "The cyber security maturity model distinguishes 6 maturity levels (0, 1, 2, 3, 4 and 5)... In order to achieve levels 3, 4 or 5, a Member Organization must first meet all criteria of the preceding maturity levels."

The bar is level 3. CSF 2.4: "the Member Organizations should at least operate at maturity level 3 or higher."

The distinction between 3 and 4 is the one that decides audits, and it is simpler than most consultants make it. Level 3 is about existence and demonstrability — you have written it down, approved it, implemented it, and you can prove it, and you track KPIs (CSF 2.4.1). Level 4 is about effectiveness — you have defined key risk indicators (KRIs) with thresholds, and you periodically measure whether the control is actually working, not merely present (CSF 2.4.2). A control can be perfectly implemented and still sit at level 3 forever if you never measure its effectiveness.

Assessment is by periodic self-assessment against a SAMA questionnaire, and "the self-assessments will be reviewed and audited by SAMA" (CSF 2.3).

The level 4 obligation most banks get wrong

CSF 2.4.2 carries a note: "Additional requirements for Banks pursuant to circular No (29814/67)." That circular requires banks to reach maturity level 4 — not 3 — for all components of four specific subdomains:

• 3.3.14 Cyber Security Event Management
• 3.3.15 Cyber Security Incident Management
• 3.3.16 Threat Management
• 3.3.17 Vulnerability Management

with a roadmap to achieve it by the end of Q3 2022, a board-approved roadmap submitted to SAMA by the end of Q1 2019, quarterly reports from the end of Q2 2019, and "an in-depth annual report by the Bank's Internal Audit Department showing the level of compliance with the CSF's requirements compared to the maturity level required."

Those dates have all passed. The point is not the dates — it is that for these four subdomains the standing bar for a bank is level 4, permanently, and the annual internal-audit report is an ongoing obligation, not a one-off. If your GRC tool has every CSF subdomain targeted at level 3, it is mis-configured.

One honesty note: the SAMA Rulebook renders this circular's date inconsistently — the circular page shows "29814/67 dated 11/05/1440H", while the note in CSF 2.4.2 shows "dated 15/05/1440H (corresponding to 11/06/2020)". A 1440H date corresponds to 2019, not 2020, so the Gregorian rendering appears to be a rulebook typo. We are reporting the discrepancy rather than silently picking one. Verify the circular number — 29814/67 — with your SAMA supervisor.

Who is actually in scope

CSF 1.4 lists applicability as: all Banks, all Insurance and/or Reinsurance Companies, all Financing Companies, all Credit Bureaus, and the Financial Market Infrastructure — all operating in Saudi Arabia.

But the CSF text was written in 2017 and has not been amended, and SAMA's own rulebook now tags the CSF's scope of application differently: Banking Sector — Finance Sector — Payment Systems and Payment Services Providers — Credit Bureaus — Regulatory Sandbox.

Two things follow, and both matter:

1. Payment companies and fintechs are in scope, even though the 2017 text does not name them. The rulebook's applicability tagging includes Payment Systems and Payment Services Providers, Digital Banks, Money changers and the Regulatory Sandbox. If you are a licensed PSP or a sandbox fintech, the CSF applies to you.
2. Insurance is no longer in SAMA's rulebook scope. The 2017 text still names insurers, but insurance supervision in Saudi Arabia transferred from SAMA to the Insurance Authority, which began operating in November 2023. SAMA's rulebook no longer lists an insurance sector in its regulated-entity taxonomy. If you are an insurer, do not assume the SAMA CSF is still your governing cyber instrument — confirm with the Insurance Authority. We are flagging the conflict between the document text and the rulebook metadata rather than resolving it for you, because only your regulator can do that.

CSF 1.4 also carves out real exceptions. All domains apply to banks. For other financial institutions:

• 3.1.2 — alignment with the cyber security strategy of the banking sector is mandatory when applicable.
• 3.2.3 is excluded — however, if you store, process or transmit cardholder data or use SWIFT, then PCI DSS and/or the SWIFT Customer Security Controls Framework must be implemented.
• 3.3.12 (Payment Systems) is excluded.
• 3.3.13 (Electronic Banking Services) is excluded — however, if you provide online services to customers, multi-factor authentication must be implemented.

Those "however" clauses are where non-bank entities get caught. The exclusion is not a free pass.

Things that do not exist

This section is the reason this article was written. Each of the following is in active circulation in the Saudi market, and each is false.

❌ The "SAMA Cloud Rulebook"

It does not exist. There is no standalone SAMA cloud instrument under any name — not a "Cloud Rulebook," not a "Cloud Computing Framework," not "Cloud Computing Regulatory Rules."

We tested this against SAMA's own rulebook search. A full-text search of the entire SAMA Rulebook for "cloud" returns 7 results, and the only cloud-specific regulatory provision among them is CSF 3.4.3 Cloud Computing — together with its parent section 3.4 and a glossary entry. A search for the phrase "cloud rulebook" returns nothing at all.

The real instrument is CSF subdomain 3.4.3 Cloud Computing, inside domain 3.4 Third Party Cyber Security. That is the whole of SAMA's cloud-specific cyber rulemaking.

But — and this is the part that makes the fabrication genuinely dangerous — the pre-approval requirement it described is real. It is simply in a different place:

CSF 3.4.3.4(a)(2): "the Member Organization should obtain SAMA approval prior to using cloud services or signing the contract with the cloud provider."

So a compliance officer who read the fabricated article and filed a pre-approval did the right thing for the wrong reason. And a compliance officer who then discovered the "Cloud Rulebook" was fake, and concluded the pre-approval was fake too, would be under-complying with a real obligation. Both failure modes are caused by the same bad citation. The obligation is real; the instrument name was invented. Cite 3.4.3.4(a)(2).

What CSF 3.4.3 actually says, in full:

• It applies to hybrid and public cloud services only. CSF 3.4.3 states explicitly: "Please note that this requirement is not applicable to private cloud services (= internal cloud)." Internal/private cloud is out of scope of this subdomain.
• 3.4.3.4(a)(1) — a cyber security risk assessment and due diligence on the cloud service provider must be performed.
• 3.4.3.4(a)(2) — SAMA approval before using cloud services or signing the contract.
• 3.4.3.4(a)(3) — a contract including the cyber security requirements must be in place before using cloud services.
• 3.4.3.4(b)(1) — data location. This is quoted more often than it is read: "in principle only cloud services should be used that are located in Saudi Arabia, or when cloud services are to be used outside Saudi Arabia that the Member Organization should obtain explicit approval from SAMA."
• 3.4.3.4(c)(1) — the provider must not use your data for secondary purposes.
• 3.4.3.4(d)(1) — the provider must implement and monitor the controls determined in the risk assessment.
• 3.4.3.4(e)(1) — your data must be logically segregated and the provider must be able to distinguish it from other data at all times.
• 3.4.3.4(f)(1) — business continuity requirements must be met per your own BC policy.
• 3.4.3.4(g) — you must retain the right to review, audit and examine the cloud service provider.

Note carefully what 3.4.3.4(b)(1) does not say. It does not impose an absolute in-Kingdom data-residency ban. It says "in principle" in-Kingdom, with an explicit escape hatch: out-of-Kingdom is permitted with explicit SAMA approval. Vendor pages that describe SAMA as mandating absolute data residency are overstating it. In practice in-Kingdom is the path of least regulatory friction — but it is not the only lawful path, and misrepresenting it as such has led firms to make architecture decisions they did not need to make.

Also real, and separate: CSF 3.4.2.3(a) requires "the approval from SAMA prior to material outsourcing." And SAMA does maintain a genuine standalone outsourcing instrument — the Rules on Outsourcing, Circular No. 41027017, dated 18/4/1441H (15/12/2019G), scope: Banking Sector. That is the document people are probably groping for when they invent a "Cloud Rulebook."

❌ The SAMA "Tier 1–4" RTO/RPO grid

It does not exist. There is no SAMA tier grid, and there is no SAMA-mandated RTO or RPO figure — no "15 minutes," no four-hour tier, no numbers of any kind.

Start with where RTO/RPO actually live. They are not in the CSF at all. CSF 1.3 explicitly pushes business continuity out of its own scope: "For business continuity related requirements please refer to the SAMA Business Continuity Minimum Requirements."

The real instrument is the Business Continuity Management Framework, issued under Circular No. 381000058504, dated 1/6/1438H (27/2/2017G) — scope: Banking Sector, Finance Sector, Payment Systems and Payment Services Providers, Credit Bureaus.

And the BCM Framework defines RTO, RPO and MAO as concepts only (BCM 1.2):

Recovery Time Objective (RTO) — "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) — "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'."

Maximum Acceptable Outage (MAO) — "the time that would take for adverse impacts... to become unacceptable."

Definitions. Not thresholds. We searched the complete text of the BCM Framework: the word "tier" does not appear once, and the document contains no numeric time thresholds at all — not a single figure in minutes, hours or days anywhere in it.

SAMA does not state an RTO or RPO figure here. It requires you to derive your own, through a Business Impact Analysis (BCM 2.4), and it requires your BCM committee to endorse them: "The BCM committee should endorse the prioritized list, BIA results, RA and the defined RTOs, RPOs and MAOs" (BCM 2.4). The only steer SAMA gives is directional — Member Organizations "should ensure that RTOs are adequately defined for payment systems, customer related services, etc. considering the high availability of these operations."

So if an auditor asks for your RTO, the defensible answer is not a number you copied from a grid. It is: "here is our BIA, here is the RTO it produced, and here is the BCM committee minute endorsing it." A number lifted from a fabricated tier table is worse than useless — it is a number you cannot defend the derivation of.

✅ …and the two real deadlines the fake grid left out

Here is the genuinely expensive part. While the fabricated tier grid was inventing RTO thresholds SAMA never wrote, it omitted the two hard, numeric deadlines SAMA actually does impose. Both are in BCM 2.11 (Communication):

1. Test results — within four weeks. "Test results of business continuity and disaster recovery should be shared with SAMA within four weeks after the test."
2. Action plan — within two months. "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."

These are real, they are numeric, and they are the two dates that should be in your compliance calendar. A firm following the fabricated grid would have been diligently over-engineering an imaginary 15-minute RTO while missing both.

The other genuine BCM obligations, for completeness:

• BCM 2.9.1 — BCP simulation test exercises "at least once a year."
• BCM 2.9.2 — a DR test combined with BCP "at least once a year."
• BCM 2.11 — report all disruptive incidents classified "Medium" or "High" to SAMA "Banking IT Risk Supervision" immediately; a post-incident report follows after normal operations resume.
• BCM 2.4 — the BIA and Risk Assessment must be updated annually and on major change.
• BCM 2.1 — the BCM committee meets on a minimum quarterly basis.

Note "immediately" in BCM 2.11. SAMA does not state a figure here — there is no "within 72 hours," no "within 24 hours." Anyone quoting you an hour-count for SAMA incident notification is inventing it. The same is true in the CSF: CSF 3.3.15 requires that the Member Organization "should inform 'SAMA IT Risk Supervision' immediately when a medium or high classified security incident has occurred and identified" — again, no number.

While you are in 3.3.15, note an obligation that almost never appears in third-party summaries and that has real consequences: you must obtain a 'no objection' from SAMA IT Risk Supervision before any media interaction related to the incident. That belongs in your incident-response runbook and your comms plan, and most runbooks we have seen do not have it.

❌ SAMA control numbers in n-n-n format

If you see a "SAMA control 2-12-1," you are looking at cross-contamination between two different regulators' schemes.

Dots are SAMA. Hyphens are NCA. They are different regulators, different documents and different obligations, and a citation that mixes the two is a reliable signal that whoever wrote it never opened either document. The two frameworks also do not map cleanly onto one another — do not let a vendor "cross-walk" you out of doing both if both apply.

The other SAMA instruments that actually exist

Cloud and BCM are not the only places people invent documents. Here is the real inventory, from the Cyber Risk Control chapter of the SAMA Rulebook, with the real circular numbers.

Two of these are routinely missed:

• The CRFR is the instrument for non-bank entities — finance companies, PSPs, money exchangers and sandbox fintechs. If you are a fintech asking "does the CSF apply to me," the CRFR is very likely the document you should be reading alongside it.
• The IT Governance Framework (43028139) is separate from the CSF and applies to banks and credit bureaus. IT governance obligations are not all inside the CSF, and treating the CSF as the whole of your technology-regulation surface is a common and expensive scoping error.

What SAMA does not tell you

An honest guide has to include this section, because the fabrications all grew in these gaps. On each of the following, SAMA states no figure, and any specific number you are given is someone's opinion wearing a regulator's clothes:

• No RTO or RPO values. Derived by you, via BIA.
• No incident-notification hour count. The word is "immediately" (CSF 3.3.15, BCM 2.11).
• No patching or vulnerability-remediation SLAs. CSF 3.3.17 requires a vulnerability management process; it does not say "critical within 15 days."
• No password length, rotation period or key length. CSF 3.3.5 and 3.3.9 state principles, not parameters.
• No log-retention period in the CSF.
• No prescribed encryption algorithms in the CSF.
• No named certification. There is no "SAMA CSF certificate" and no accredited-auditor scheme. Compliance is established through self-assessment against SAMA's questionnaire and SAMA's own review and audit (CSF 2.3) — not by buying a certificate from anyone.

Where you need a number for these, the defensible move is to derive it from your own risk assessment and have it approved internally — and to be able to show the derivation. That is precisely what maturity level 3 means.

A realistic first 90 days

1. Fix your citations before you fix anything else. Search your policy set, your GRC tool and your board packs for "Cloud Rulebook," for any RTO/RPO tier table attributed to SAMA, and for SAMA controls written with hyphens. Every hit is a defect, and every hit is currently exposing you.
2. Set the right target per subdomain. Level 3 across the board; level 4 on 3.3.14, 3.3.15, 3.3.16 and 3.3.17 if you are a bank. Check your GRC tool's targets — this is where mis-configuration hides.
3. Do the gap assessment against the questionnaire, not against a vendor's spreadsheet. SAMA's own circulars describe the sequence: assess, build a board-approved roadmap, report progress.
4. Find your cloud pre-approvals. For every hybrid or public cloud service in production: was SAMA approval obtained before contract signature (3.4.3.4(a)(2))? Is the data in-Kingdom, or do you hold explicit SAMA approval for it being outside (3.4.3.4(b)(1))? Do your contracts carry the audit right (3.4.3.4(g))? This is the single most common gap.
5. Put the two real BCM dates in the calendar — test results to SAMA within four weeks of the test, action plan within two months of the results.
6. Add the media 'no objection' step to your incident runbook (CSF 3.3.15).
7. Derive your RTOs from a BIA and get the BCM committee to endorse them in writing. The minute is the evidence.

Where a hosting provider fits — and where it does not

Be clear about the boundary, because vendors blur it. The Member Organization is the regulated party. CSF 1.5 is unambiguous: SAMA mandates the Framework; "the Member Organizations are responsible for adopting and implementing" it. No supplier can absorb that. A hosting provider cannot make you CSF-compliant, and any provider claiming it can is telling you something the Framework does not permit them to say.

What infrastructure can do is remove specific, named obstacles:

• Data location (3.4.3.4(b)(1)). Hosting in-Kingdom keeps you on the "in principle" path and avoids needing explicit SAMA approval for offshore data. Skyline Cloud runs an in-Kingdom region — Dammam, powered by Google Cloud, which is the relevant fact for this control.
• Data segregation (3.4.3.4(e)(1)) and secondary-use prohibition (3.4.3.4(c)(1)) are contract-and-architecture questions you should be putting to any provider in writing.
• Audit rights (3.4.3.4(g)). Ask, before signature, whether the provider will contractually grant the right to review, audit and examine. If they will not, you have a 3.4.3 gap on day one.
• Business continuity (3.4.3.4(f)(1)) must meet your BC policy — the one whose RTOs came out of your BIA.

Everything else — governance, risk management, IAM, the maturity evidence — stays yours. That is not a sales limitation; it is what CSF 1.5 says.

Frequently asked questions

Is there a SAMA Cloud Rulebook? No. No standalone SAMA cloud instrument exists under any name. Cloud is CSF subdomain 3.4.3, inside domain 3.4 Third Party Cyber Security.

Do I really need SAMA approval before using a public cloud service? Yes — but cite it correctly. CSF 3.4.3.4(a)(2): SAMA approval before using cloud services or signing the contract. Separately, CSF 3.4.2.3(a) requires SAMA approval prior to material outsourcing.

Does SAMA ban storing data outside Saudi Arabia? No. CSF 3.4.3.4(b)(1) says "in principle" only in-Kingdom cloud services should be used, or — for services outside Saudi Arabia — the Member Organization must obtain explicit approval from SAMA. It is a controlled exception, not a prohibition.

What RTO does SAMA require? None. SAMA does not state a figure. RTO, RPO and MAO are defined as concepts in the BCM Framework 1.2; you derive your own values via a Business Impact Analysis and have the BCM committee endorse them (BCM 2.4).

How many maturity levels are there? Six — 0 through 5 (CSF 2.4). Minimum required is level 3. Banks must reach level 4 on subdomains 3.3.14–3.3.17.

How quickly must I notify SAMA of a cyber incident? "Immediately," for medium- or high-classified incidents (CSF 3.3.15; BCM 2.11). SAMA does not state an hour count. Also: obtain SAMA's 'no objection' before any media interaction about the incident.

Does the CSF apply to fintechs and payment companies? Yes. The 2017 text does not name them, but SAMA's rulebook applies the CSF to Payment Systems and Payment Services Providers, Digital Banks, Money changers and the Regulatory Sandbox. Non-banks should also read the CRFR.

Does the CSF still apply to insurers? Unclear from the document alone, and you should confirm with your regulator. CSF 1.4 (written 2017) names insurers, but insurance supervision moved to the Insurance Authority in November 2023 and SAMA's rulebook no longer lists an insurance sector. Ask the Insurance Authority, not a blog.

Is there a SAMA CSF certificate? No. Compliance is assessed by self-assessment against SAMA's questionnaire, reviewed and audited by SAMA (CSF 2.3).

Can I get an exemption from a control? There is a formal route: compensating controls, internal risk acceptance, and a formal waiver request to SAMA — see CSF 2.2 and Appendix D.

Sources

Every domain number, subdomain, maturity level, control ID, circular number, quotation and deadline in this article was read from SAMA's own published text at the SAMA Rulebook. SAMA — not this page — is the authority.

• Saudi Central Bank — SAMA Rulebook (the official online rulebook; the in-force text of every instrument below)
• SAMA — Cyber Security Framework, Circular No. 381000091275, 28/8/1438H / 24/5/2017G, In-Force (scope 1.3–1.4; structure 2.1; principle-based & waiver 2.2; self-assessment 2.3; maturity model 2.4; levels 2.4.1–2.4.3)
• SAMA — CSF 3.4.3 Cloud Computing (pre-approval 3.4.3.4(a)(2); data location 3.4.3.4(b)(1); segregation (e); BC (f); audit rights (g))
• SAMA — CSF 3 Control Domains (the 4 domains and all 32 subdomains, 3.1.1 → 3.4.3)
• SAMA — Circular Re. Cyber Security Framework (maturity level 3 minimum; the level-4 requirement for banks on 3.3.14–3.3.17 under circular 29814/67)
• SAMA — Business Continuity Management Framework, Circular No. 381000058504, 1/6/1438H / 27/2/2017G, In-Force (RTO/RPO/MAO definitions 1.2; BIA 2.4; testing 2.9; the four-week and two-month deadlines, 2.11)
• SAMA — Rules on Outsourcing, Circular No. 41027017, 18/4/1441H / 15/12/2019G, In-Force
• SAMA — Cyber Risk Control (the complete inventory of SAMA's cyber instruments — note what is not in it)

Last verified against the SAMA Rulebook in July 2026. Note that the legacy PDF URLs under sama.gov.sa/en-US/RulesInstructions/CyberSecurity/ no longer serve the PDFs; the Rulebook is the live authoritative source. Regulations change. If this page and the Rulebook ever disagree, the Rulebook is right — and we want to know.

This article is guidance, not legal advice, and it is not a substitute for your own reading of the instruments or for consultation with your SAMA supervisor.