A common misreading in the Saudi financial sector is that SAMA "does not allow cloud." The reality visible in SAMA's own public framework documents is more precise and more useful: cloud is treated as a form of outsourcing and third-party risk, permitted under conditions, with the burden of proof on the regulated entity. Banks and fintechs that fail cloud reviews rarely fail on technology — they fail on process: no workload classification, no materiality analysis, no exit plan, no evidence.
This article turns the expectations scattered across SAMA's Cyber Security Framework, its outsourcing rules and general third-party requirements into one sequential checklist. Two caveats before the list, both important. First, the rulebook evolves — SAMA updates circulars and rules, and the binding source is always the current text on SAMA's official rulebook, not any secondary summary, including this one. Second, this is practical guidance, not regulatory advice; your compliance function owns the interpretation for your licence class.
The regulatory landscape in four layers
- SAMA Cyber Security Framework (CSF). First issued in May 2017, applying to SAMA-regulated "Member Organizations" (banks, insurers, financing companies and others). It explicitly contemplates hybrid and public cloud: organizations are expected to define, implement and monitor cyber-security controls within a cloud computing policy, and to embed security requirements before, during and when exiting outsourcing contracts.
- SAMA outsourcing rules. Outsourcing arrangements require due diligence, appropriate approvals and ongoing monitoring; for material arrangements, SAMA's prior non-objection is the established expectation. What counts as "material" is exactly the kind of detail to confirm against the current rulebook for your entity type.
- National frameworks that stack on top. The NCA's Essential Cybersecurity Controls and Cloud Cybersecurity Controls apply their own provider/tenant split — our NCA CCC guide maps it — and cloud providers serving the Kingdom fall under the CST regulatory framework, which we unpack in the CCRF explainer.
- PDPL. Customer data is personal data; the transfer rules apply on top of everything sectoral. See the PDPL hosting guide.
The four layers agree on one philosophy: you can delegate operation, but you cannot delegate accountability.
The 15-point checklist
Phase 1 — Before you shortlist a provider
1. Classify the workload. Core banking, payment processing and systems holding customer financial data sit at one end; the corporate website, careers portal and marketing campaign sites sit at the other. Most cloud programmes that stall tried to start at the wrong end.
2. Run a materiality assessment. Document whether the arrangement could, if it failed, materially affect operations, customers or compliance. This single document determines your approval path — and its absence is the most common audit finding.
3. Check your own cloud policy exists. The CSF expects a defined, approved cloud computing policy before adoption, covering hybrid and public cloud. If your policy predates your cloud ambitions, update it first.
4. Confirm the provider's regulatory standing. CST registration status and category, NCA-relevant certifications where applicable, and — for data location — which specific region will host you, not which brand.
5. Establish data location and access geography. Where does primary data live, where do backups and replicas go, and from which countries can support staff reach systems? In-Kingdom hosting options simplify every later step; Skyline Cloud's data-residency page shows how a provider should answer this in plain terms.
Phase 2 — Diligence and contract
6. Perform documented due diligence. Financial standing, security posture, incident history, subcontracting chain, exit feasibility. Keep the evidence file — the point is not to do diligence but to be able to show it.
7. Obtain non-objection where required. If the materiality assessment says the arrangement is material, engage SAMA before committing. Build the review time into the project plan rather than discovering it at contract signature.
8. Contract the audit and examination rights. Your right (and effectively your regulator's) to audit, inspect and receive reports must be written, not assumed. Standard hyperscaler paper often needs negotiated addenda here.
9. Contract incident notification. Define what the provider must report, how fast, and through which channel — aligned to your own obligation to notify SAMA of incidents. Vague "commercially reasonable efforts" language fails this test.
10. Contract sub-outsourcing controls. The provider's subcontractors are your risk. Require disclosure of the chain and notice (or consent) for changes.
11. Contract the exit. Data return in usable formats, deletion with written confirmation, transition assistance, and notice periods long enough to actually migrate. An exit clause you could not execute in practice is decoration.
Phase 3 — Operate and evidence
12. Map shared responsibility, control by control. For every CSF control relevant to the workload, write down who performs it — provider or you — and where the evidence lives. This mapping is the core artefact reviews ask for.
13. Monitor continuously, not annually. SLA performance, incident reports, certification renewals, subcontractor changes. Calendar it.
14. Test resilience and exit. Backup restoration drills, failover tests, and at least a desktop exercise of the exit plan. Untested plans are hypotheses.
15. Re-assess on change. New services, new regions, new data categories, or a provider acquisition all reopen the materiality question. Make re-assessment a trigger-based process, not a memory-based one.
An honest note on what belongs where
Not every workload in a bank or fintech is a SAMA-material system, and treating them all as if they were is how institutions end up hosting their careers page with the same governance as their core ledger. A sensible portfolio view:
| Workload | Typical treatment |
|---|---|
| Core banking, payments, customer financial data | Full checklist, materiality likely, non-objection path, strictest hosting choices |
| Internal systems touching customer data | Full checklist; materiality depends on scale and substitutability |
| Corporate website, marketing sites, campaign pages | Standard vendor management; in-Kingdom managed hosting is a clean, low-friction fit |
| Dev/test with synthetic data | Lightest tier — but keep real data out, verifiably |
For that third and fourth tier, a Saudi-hosted managed platform is often the pragmatic answer: Skyline Cloud's hosting plans run on Saudi-resident infrastructure with daily backups, free auto-renewing SSL and a 99.9% uptime SLA, billed in SAR with ZATCA-compliant invoices — and you can validate the whole setup with a free 14-day trial, no credit card, before it ever enters your vendor register. For the heavier tiers, the same discipline applies to whichever provider your assessment selects — and where physical or security infrastructure is part of the programme, our parent company's data-centre cybersecurity practice works alongside financial-sector IT teams.
Where the rules are still moving
Be transparent with your board about three open edges. First, materiality thresholds and approval expectations are periodically refined — verify the current outsourcing rules text before relying on last year's precedent. Second, the interaction between SAMA expectations, NCA cloud controls and CST provider categories is converging but still requires entity-level judgement. Third, hyperscaler regions inside the Kingdom are new enough that supervisory practice around them is still accumulating. None of these edges blocks adoption; all of them reward the documented, phased approach above.
Frequently asked questions
Can Saudi banks use public cloud at all?
Yes — SAMA's Cyber Security Framework explicitly contemplates hybrid and public cloud, subject to defined controls, and outsourcing rules govern the arrangement. The question is never "cloud or not" but "which workload, which provider, which controls, and with what approvals."
Does every cloud contract need SAMA non-objection?
No — the established expectation attaches to material outsourcing arrangements. That is precisely why the materiality assessment (checklist item 2) is the pivotal document; confirm the current rulebook definitions for your licence type.
Do fintechs face the same requirements as banks?
Fintechs licensed or sandboxed under SAMA fall under its supervisory expectations, applied proportionately to their activity. The checklist above scales down gracefully — smaller entities benefit even more from providers that answer location and exit questions in writing.
Does hosting in-Kingdom remove the need for this checklist?
No. Residency simplifies data-location and PDPL questions substantially, but diligence, contracts, monitoring and exit planning apply wherever the provider is. In-Kingdom hosting shortens the checklist; it does not delete it.
Start where the risk is lowest
The fastest way to build cloud competence under SAMA discipline is to run the full checklist on a genuinely low-material workload — the corporate site, a campaign page, a sandbox — and generate your evidence pack on something forgiving. Open a free 14-day Skyline Cloud trial (no credit card), host that first workload on Saudi-resident infrastructure, and let your second cloud decision be made by a team that has already done it once.
Comments
0 total · 0 threads