Data residency requirements in Saudi Arabia, and who sets them

A client asks whether their data has to be hosted in Saudi Arabia. The expected answer is yes or no, and there is usually a vendor in the room who has already said one of them with confidence. The accurate answer is that it depends on who the data belongs to and how that owner classifies it, and that the rule most often cited for the confident version is no longer in the document it is cited from.

That is worth knowing before you choose a region, because the cost of being wrong is not a fine. It is a migration, and a migration of a running system is the most expensive kind of rework there is.

What the cloud controls cover, and who they bind

The relevant document is the National Cybersecurity Authority’s Cloud Cybersecurity Controls, current version CCC-2:2024. It is published openly, classified Public, and it is the thing to read rather than a summary of it. The full set of NCA frameworks sits on the authority’s own regulatory documents page.

Two things about its scope matter immediately. First, it binds two different parties: cloud service providers and cloud service tenants, with separate control sets for each. If you are a business buying hosting rather than selling it, most of the provider obligations are not yours, and a vendor quoting provider controls at you as though they were your compliance burden is selling something.

Second, the document states that it is governed by and implemented in accordance with the laws of the Kingdom and subject to the exclusive jurisdiction of its courts, and that the Arabic version is the binding language for all matters of meaning or interpretation. The English text is a translation. For anything contractual, that distinction is not pedantry.

The four levels, and why your own data probably is not level one

The controls are applied in four levels, and the level is set by how the data is classified rather than by how important the system feels. Level 1 applies to data classified top secret, level 2 to secret, level 3 to confidential, and level 4 to public, in each case based on what the competent authority has issued.

There is one rule inside that worth copying into your own notes: the document says the highest level of classification should be adopted when a combined set of data includes different levels. A single export that joins a public reference table to a confidential one is treated as confidential. This is the most common way a system that was scoped as low sensitivity quietly becomes a higher tier, and it happens in reporting pipelines more than in the primary application.

Note also that the 2024 revision changed its own vocabulary: what the previous version called confidential data and information, this one calls sensitive data and information. If you are comparing a 2020 era compliance memo against the current controls, the terms do not line up and the memo is probably describing deleted requirements.

The two subcontrols that were deleted, and where the question went

This is the part that changes the answer. The previous version of the controls, CCC-1:2020, contained two provider subcontrols, numbered 2-3-p-1-10 and 2-3-p-1-11. The first required providing cloud computing services from within the Kingdom including the systems used for storage, processing and disaster recovery centres. The second required the same for the systems used for monitoring and support.

Both were deleted. The current document records the deletion in its own list of updates, and gives the reason: controls related to data localization have been transferred out of the document to the National Data Management Office at the Saudi Data and Artificial Intelligence Authority, and entities must refer to that office regarding data localization before taking any action.

So the residency requirement was not relaxed and it was not tightened. It was moved, and it was moved to a body whose mandate is data governance rather than cybersecurity. The practical consequence is that reading the cloud controls end to end will no longer tell you where your data may sit, and anyone who answers the residency question by pointing at the NCA controls is answering from a version that is at least a revision out of date.

Personal data is a different question again

Classification levels govern data the state has classified. Personal data is governed separately, by the Personal Data Protection Law and its transfer regulation, which set conditions for moving personal data outside the Kingdom rather than a blanket prohibition on doing so.

We are deliberately not going to restate the conditions here in the confident voice, because this note is about architecture decisions and that is a legal question with a current text that needs reading rather than paraphrasing. The point for a build decision is narrower and it is reliable: personal data and classified data are two separate regimes, they can both apply to one system, and satisfying one of them tells you nothing about the other. A system holding ordinary customer records for a private company is in the second conversation, not the first.

What actually decides your hosting region

In practice the decision is made by your customer’s obligations, not by your own reading of a framework. Four questions settle almost every case.

That last row is easy to miss and it is a real constraint rather than a soft one. The controls require that cybersecurity positions in a provider’s data centres inside the Kingdom be filled with qualified Saudi nationals. If your plan was in Kingdom hosting operated entirely by a remote team, that is a staffing question and not only an infrastructure question.

A practical order for the decision

Settle it in this order and you will not have to revisit it.

• Ask the customer for their classification in writing before you pick a region. If they cannot produce one, you are not dealing with classified data and the conversation is about personal data instead.
• Separate the stores. Personal data, operational data and analytics exports do not have to live in the same place, and keeping them separate is what makes a future residency requirement a configuration change rather than a rebuild.
• Write the region into the architecture as a parameter, not an assumption. The cost of this is one day at the start.
• Read the current text yourself, in Arabic if the decision is contractual, and date your note. Everything in this area has a version.
• Do not let backups and disaster recovery out of scope. The deleted subcontrols named disaster recovery explicitly, which tells you it was a live issue, and a secondary region is the thing people forget to check.

Separating the stores has a second payoff that has nothing to do with compliance: it is also what stops the hosting bill climbing for reasons nobody can explain, which we covered in what actually drives a cloud bill up. The backup side of it is in a backup strategy in plain terms, and the access questions that sit next to residency are in a security checklist you can verify yourself.

The honest limits

Three of them, and they are the reason this note does not end with a recommendation.

We are a software company and not a law firm. Everything above is a reading of a published control document, which is a fair thing to do and a different thing from legal advice. Where the answer carries contractual weight, the Arabic text and a Saudi qualified adviser are the sources, and the control document itself says as much about its own binding language.

The second limit is that the residency question now sits partly outside the document we can point you at. We can tell you with confidence that the two localisation subcontrols were deleted and where the document says the mandate went, because that is written down in the controls themselves. We cannot tell you the current localisation position in the same voice, and you should be suspicious of anyone who does without naming a version and a date.

The third is that none of this is an argument for or against hosting in the Kingdom. In Kingdom regions have got considerably easier to buy than they were, and if your customers are Saudi the latency and the procurement conversation often favour it regardless of whether anything compels it. The decision that goes wrong is not choosing the wrong region. It is choosing a region on the strength of a rule somebody half remembered, and finding out in year two that the rule had moved.

If the wider question behind this one is whether to commit to the market at all rather than where to put a database, the regulatory side of that commitment is laid out from the business development angle in BDG Labs’ read on the Saudi regional headquarters programme and when to say no to it.