Saudi cloud rules are set by the Communications, Space and Technology Commission (CST), and they work through classification. Data is classified into four levels, cloud providers register in four categories, and the category a provider holds determines which classification of customer data it is permitted to carry. Your architecture question is therefore not "is this provider allowed in Saudi Arabia" but "is this provider registered for the classification of the data I am about to put in it".
For Saudi public sector data the constraint is sharper still: it generally may not leave the Kingdom at all — including for caching, redundancy or backup. That single clause decides your disaster recovery design before you have drawn it.
Engineering context, not legal advice. CST is the authority on the framework in force, and classification of your specific data is a question for your organisation and its counsel.
The framework, and which version you are reading about
CST approved the Cloud Computing Services Provisioning Regulations, version 4, on 8 October 2023, superseding the earlier Cloud Computing Regulatory Framework (CCRF) v3 from 10 October 2023.
That matters because a great deal of the guidance in circulation — including material that still ranks well — describes CCRF v3. If a document you are relying on talks about the CCRF without mentioning the 2023 provisioning regulations, it predates the current regime. Check the version before you build an architecture on it.
CST is also the successor body to the former Communications and Information Technology Commission (CITC), so older material appears under that name.
Four levels, four categories
Data classification levels. Cloud-hosted data is classified across four levels, commonly rendered Public, Confidential, Secret and Top Secret — Level 1 through Level 4. Residency, sovereignty and processing-location requirements tighten as the classification rises.
Provider registration categories. Cloud service providers register with CST in one of four categories — Qualification, A, B and C — and the category determines which classification of subscriber data the provider may handle. Providers in higher registration classes may carry more sensitive tiers, including government workloads.
The practical consequence is a two-sided check at design time. Classify the data, establish the provider's registration, and confirm the two are compatible. "It is a major international cloud with a Saudi region" does not by itself answer the question, because the registration category, not the presence of a region, is what governs.
Both the level names and the category letters here come from secondary summaries of CST's regulations rather than from a document we retrieved directly from CST. Treat them as the shape of the regime and confirm the current wording with CST before relying on it for a compliance decision.
The public-sector clause that drives architecture
If you build for Saudi government entities, this is the sentence that matters most: public sector data generally cannot be transferred outside the Kingdom — including for caching, redundancy, or backup — unless explicitly permitted.
Most default cloud architectures violate this without anyone choosing to. The usual suspects:
- Cross-region backup, which is the recommended default in nearly every cloud provider's own documentation.
- A CDN with global points of presence, caching responses wherever the requester is.
- Managed services with implicit multi-region behaviour — global databases, replicated object storage, some queueing and search services.
- Log aggregation, error tracking and APM shipping to a vendor's region of choice, typically the US or the EU.
- Email and notification providers relaying through wherever their infrastructure sits.
- Backups of backups — a snapshot copied to a "safe" account in another region during an incident, six months ago, by someone acting sensibly.
Two of those deserve special attention because they are so rarely reviewed. Observability is a data flow. Logs contain personal data far more often than teams expect — request payloads, identifiers, stack traces with arguments. Pointing an error tracker at a default endpoint can move regulated data offshore continuously, invisibly, and with no record of the decision.
And a CDN is a copy, not a pipe. Caching a response at an edge location is storing it there. For public-sector workloads, edge behaviour has to be configured deliberately rather than left at defaults.
Designing for this properly
Classify first, then choose infrastructure. The classification determines the provider category, which determines the shortlist. Reversing that order — picking the platform and then checking — produces the expensive kind of rework.
Write down the data flow, including the ones you did not design. Every third-party SaaS in the request path or the observability path is a place data goes. Backups, analytics, support tooling, feature flags, session replay. The list is always longer than the architecture diagram.
Design disaster recovery within the constraint. If cross-border replication is unavailable, in-Kingdom redundancy is the answer — multiple availability zones, a second in-Kingdom region where the provider offers one, or a second registered provider. What you cannot do is quietly keep the offshore copy because it is more convenient.
Make residency testable. A residency requirement that exists only in a document drifts the first time someone adds a managed service. Assert it: infrastructure-as-code policies that refuse non-approved regions, a periodic audit of where each service actually stores data, and alerts on new cross-region configuration. This is the same discipline as the personal-data inventory described in our Saudi PDPL architecture guide — generate the fact, do not maintain a document about it.
Remember CST is not the only regime in play. ZATCA's own guidance notes that while e-invoicing solutions may reside on the cloud, additional non-tax regulations apply — it names the National Cybersecurity Authority explicitly. For industrial workloads the NCA's operational-technology controls are a regime of their own — see the OT boundary in the Eastern Province. PDPL applies to personal data independently. Sector regulators add their own: SAMA for financial services, whose rules on outsourcing and data are their own subject. CST tells you where the data may sit; it does not settle everything else.
Where this bites in practice
Multi-tenant SaaS with Saudi customers. If one tenant is a government entity, that tenant's data inherits the residency constraint while your other tenants do not. Either the whole platform runs to the strictest requirement, or tenancy is genuinely separable at the storage and backup layer. Decide before the first government customer signs, because retrofitting separation is close to a rebuild.
Existing products entering the market. The honest assessment is usually that the application is portable and the operational surface is not — the logging, the backups, the third-party integrations, the support tooling. Budget for that rather than for a region change.
AI and model inference. Sending data to a model endpoint is a cross-border transfer if the endpoint is outside the Kingdom. In-Kingdom capacity has been expanding, but the question to answer is where inference actually runs for the specific service and tier you are calling, not where the vendor has a presence. We wrote about one instance of this in Saudi Arabia's AI training copyright exception and in-Kingdom Azure.
For where regulated data comes from in the first place, see Saudi government platform integrations.
Frequently asked questions
Which regulator sets cloud rules in Saudi Arabia?
The Communications, Space and Technology Commission (CST), successor to CITC.
What is the current framework?
The Cloud Computing Services Provisioning Regulations v4, approved 8 October 2023, superseding CCRF v3 from 10 October 2023. Confirm the version in force with CST.
How many data classification levels are there?
Four, commonly rendered Public, Confidential, Secret and Top Secret, with requirements tightening as classification rises.
What are the provider registration categories?
Four — Qualification, A, B and C — determining which classification of subscriber data a provider may handle.
Can Saudi government data be backed up outside the Kingdom?
Generally no. Public sector data ordinarily may not be transferred outside Saudi Arabia, including for caching, redundancy or backup, unless explicitly permitted.
Does using a cloud provider's Saudi region make us compliant?
Not on its own. The provider's registration category and your data's classification have to be compatible, and your architecture has to keep the data in-region in practice — backups, CDN and observability included.
Do these rules apply to private-sector data too?
The classification framework applies generally; the strictest residency language concerns public sector data. Your own classification determines your obligations.
Is CST the only regulator we need to satisfy?
No. PDPL governs personal data, the National Cybersecurity Authority publishes controls that may apply, and sector regulators such as SAMA add their own requirements.
Sources
- CST — Communications, Space and Technology Commission
- Cloud Computing Registration — my.gov.sa service listing
- Communications, Space and Technology Commission — overview
- National Cybersecurity Authority (NCA)
- ZATCA — Detailed Guidelines for E-Invoicing (PDF) — cloud hosting and the NCA reference
Classification levels and registration categories above are drawn from secondary summaries of CST's regulations. CST is the authority; verify the current framework and your own classification before making a compliance decision on it.