Explainer · Saudi Arabia · Data residency · SaaSIn the Kingdom, but sovereign? A plain guide to data residency and SaaS
Your software vendors say they are "data resident."
Here is what that means in the Kingdom, and what it does not.
Since 14 September 2024, the Kingdom's Personal Data Protection Law has been fully enforceable. Every organisation in Saudi Arabia that handles personal data, every bank, insurer, telco, retailer, hospital, and government body, now operates under a maturing data protection regime overseen by the Saudi Data and Artificial Intelligence Authority (SDAIA). In response, the software vendors that supply these organisations have offered reassurance in a handful of recurring phrases: data resident in region, local zone, in-Kingdom hosting, sovereign cloud. For a business leader who is neither a lawyer nor a systems architect, these phrases are comforting and nearly impossible to evaluate. This piece is an attempt to explain, in plain terms, three things: what the Kingdom's rules are trying to achieve, what the vendors are actually claiming, and what the difference between the two means for the business that signs the contract.
None of this is a new debate. Globally, an entire vocabulary has grown up around it, from the dry legal language of extraterritorial jurisdiction to the pointed industry coinage of sovereign washing for marketing that dresses residency up as sovereignty. Much of that analysis is extensive and, in places, excellent; the references at the end are a good place to start. But almost all of it is written for lawyers and compliance teams. This piece is written for the people who actually make the call, the business leader and the risk manager, and it sets out to demystify the language rather than to litigate the law.
The spirit of the regulation
Begin with intent rather than text. The Kingdom's data rules are often read from the outside as compliance friction. They are better understood as a national principle that runs through Vision 2030: data about Saudi citizens and residents, and data critical to the Kingdom's economy, is a national asset, and should be governed by Saudi law and answerable to Saudi oversight. The point is not to keep data in a particular building for its own sake. It is to ensure that when a question is asked of that data, who may see it, who may move it, under whose law it sits, the answer is one the Kingdom controls. The shorthand is sovereignty, and it is the spirit behind every rule that follows.
The actual rules: three layers that work together
Saudi data governance is not a single statute but a stack of three complementary regimes, each administered by a different authority and each adding a layer of obligation.
| Regime | Authority | What it requires |
|---|---|---|
| PDPL Personal Data Protection Law |
SDAIA | Royal Decree M/19 (2021), amended M/148 (2023); in force 14 Sep 2023, fully enforced from 14 Sep 2024. Personal data of individuals in the Kingdom must generally be processed inside the Kingdom; transfer abroad is permitted only under defined safeguards, with a mandatory risk assessment (SDAIA guideline, Feb 2025) for continuous or large scale transfers of sensitive data. |
| CCC Cloud Cybersecurity Controls |
NCA | An extension of the Essential Cybersecurity Controls (ECC). The CCC (updated as CCC-2:2024) classify cloud hosted data by sensitivity level and require that sensitive data remain within approved jurisdictions, with controls to prevent unauthorised cross border movement and preserve the Kingdom's digital sovereignty. |
| CSF Cyber Security Framework |
SAMA | Applies to banking, insurance, and fintech. In-Kingdom hosting of sensitive customer data, transaction records, and operationally critical systems, and, increasingly, the expectation that administrative access and encryption keys remain under Saudi jurisdiction, not only the data itself. |
Read together, the three layers say something more specific than "keep the data in the country." They say: keep the data here, classify it by how sensitive it is, restrict how and when it may leave, and, in the most regulated sectors, keep the means of access to and control over that data here as well. That last clause is where most of the confusion between vendors and buyers begins.
What the SaaS providers actually claim
When a vendor responds to these rules, the claim almost always takes the same form: "Your data is stored in an approved region. We are data resident." Hosting inside the Kingdom is a real requirement and meaningful work. But the phrase rewards close reading, because "data resident" is often used to describe residency in a region that is not Saudi Arabia. The reassurance usually arrives in a few familiar phrases, each of which can be entirely true and still describe data that lives abroad.
| What the vendor says | What it can also mean |
|---|---|
| "Your data is hosted in region." | The region may be the EU or Asia Pacific. "In region" rarely means "in the Kingdom." |
| "We offer full data residency." | Residency where? Residency in Dublin or Singapore is still residency, just not in Saudi Arabia. |
| "Enterprise grade, sovereign ready cloud." | "Sovereign ready" is a marketing aspiration, not a certification. Ask what it has actually been certified against. |
| "Fully compliant with local data protection requirements." | Often compliant via the transfer mechanism: by sending the data abroad lawfully, not by keeping it in the Kingdom. |
| "Your data is encrypted at rest and in transit." | True, and beside the point. Encryption does not decide which government can compel the key holder to decrypt it. |
To see the gap in practice, it helps to look at what widely deployed business software, from CRM to workplace collaboration to customer data platforms, actually publishes about where its data lives. Three examples, drawn from vendors' own public documentation with names withheld because the pattern matters more than the brand, make the point.
| SaaS category | Published data centre regions (per the vendor's own documentation) | In-Kingdom region? |
|---|---|---|
| Global CRM & sales cloud |
Regional application instances across North America, Europe, and Asia Pacific; customers are assigned an instance at onboarding. A Middle East application region is emerging, but is not the default. | Not by default |
| Workplace collaboration & productivity suite |
Dozens of global cloud regions; residency commitments cover major geographies and are expanding across the GCC, but many workloads keep a multi region footprint unless specifically configured. | Configure / varies |
| Customer data & personalisation platform |
Documentation describes hosting on a major public cloud's European region (Dublin, Ireland) across three availability zones, offered to customers who want their data within the territorial scope of the GDPR. | Not listed |
Read plainly, the pattern is consistent: where a platform's published regions do not include Saudi Arabia, the personal data of Saudi individuals processed through it resides, and is processed, outside the Kingdom by default. A European or Asian region may be a perfectly lawful destination under the PDPL's transfer regime, provided the required safeguards, consent, and risk assessment are in place. But it is the opposite of residency inside the Kingdom, and a buyer who hears "we are data resident" without asking "resident where?" may be agreeing to exactly the cross border transfer that the regulation is designed to make a deliberate, documented decision rather than an accidental default. The phrasing rewards a moment of introspection, and the question it raises is best resolved in writing, before signature, not after.
What it means in practice, in plain terms
Residency is still only the first question. Here is the distinction without the jargon. Imagine your data is kept in a building.
Residency is the answer to: where is the building? If the building is inside the Kingdom, your data is resident in the Kingdom. Sovereignty is the answer to two further questions: who holds the keys to the building, and whose law decides when those keys must be handed over? It is entirely possible to have a building inside Saudi Arabia whose keys (the administrative access, the management systems that run it, the encryption keys that unlock the data) are held by a company headquartered in another country, and are therefore reachable by that country's courts and laws.
Two consequences follow, both easy to miss in procurement. Encryption is not sovereignty: it protects data from unauthorised parties, but it does not change which government can compel the key holder to produce it. And "in region" is not "control inside the Kingdom": a data centre run by a company headquartered abroad sits inside the Kingdom yet remains, as a corporate entity, subject to its parent's home country law. The data has not moved; the jurisdiction that can reach it has not. Closing that gap is exactly what the SAMA expectation, that access and keys remain under Saudi jurisdiction, is written to do.
The questions worth asking
None of this means a Saudi enterprise should avoid global software. It means the residency claim should be the beginning of the conversation, not the end of it. Five plain questions separate a residency claim from a sovereignty answer:
- Residency. Where is the data physically stored and processed?
- Control. Who holds the administrative access and the encryption keys, and in which country is that entity incorporated?
- Jurisdiction. Under whose law could the vendor be compelled to disclose our data, and could that happen without our knowledge?
- The quiet back door. Where does the management plane, the system that operates the service, run, and who can reach it for support?
- Reversibility. If we needed to move this data and these workloads to an arrangement hosted and governed entirely inside the Kingdom, how long would it take and what would it cost?
Residency tells you where your data sleeps. Sovereignty tells you who holds the keys, and whose law decides when the door is opened.
What compliance actually requires: what to look for
The shift in mindset that matters most: under the PDPL, compliance is the controller's responsibility, the Saudi organisation's, and cannot be delegated to a vendor's marketing claim. A reassuring sentence in a sales deck is not a defence in an audit. What a company needs is the ability to demonstrate, in writing and on demand, that it knows where its data is, who can reach it, and under what law. The checklist below is what that looks like in practice.
| What to have in place | Regime | Why it matters | |
|---|---|---|---|
| 1 | A data classification map: what personal, sensitive, and operationally critical data you hold, and where each class sits. | NCA CCC | You cannot protect, or lawfully place, data you have not classified. |
| 2 | A data location clause in the contract: the actual region(s), named, in the agreement, not the brochure. | PDPL · NCA | Turns "we are data resident" into an enforceable, specific commitment. |
| 3 | Transfer safeguards and a risk assessment for any data that leaves the Kingdom (SCCs/BCRs, adequacy, SDAIA risk assessment). | PDPL | If data goes abroad, the transfer must be deliberate, safeguarded, and documented. |
| 4 | Clarity on encryption key custody: who holds the keys, in which country; ideally bring your own key, or key management inside the Kingdom. | NCA · SAMA | Residency without key control is not sovereignty. The key holder is the access point. |
| 5 | An exit and portability plan: how, and how quickly, you could move the data and workloads to an arrangement hosted entirely inside the Kingdom. | NCA · BCM | If the regulator's expectation tightens, or the vendor cannot meet it, you need a route home. |
The common thread across all five is that none of them is satisfied by a claim. Each is satisfied by evidence: a clause, a key inventory, a risk assessment, a tested exit plan. The vendor's reassurance is the start of that evidence gathering, never the substitute for it.
The takeaway
The spirit of the Kingdom's data regime is sovereignty, not geography for its own sake. A data centre inside Saudi Arabia is a necessary step and a genuine one, but it is not, by itself, the whole of what the PDPL, the NCA controls, and the SAMA framework are reaching for. For the business leader evaluating a software vendor, the most useful habit is simple: when a vendor says "we are data resident," hear it as the answer to one question, and ask the other four. The regulation is doing the same.
What kind of substrate can be resident, sovereign, and accountable at once is a question this series will keep returning to.