Data residency in Saudi Arabia: which data stays in the Kingdom, and where it can run

Data residency describes where data physically lives: the country where it is stored and processed. Data localization is the requirement that some of it stays in a given country. In Saudi Arabia both questions arrive in almost every cloud, software and monitoring purchase, usually late.

No public page lists, for every organisation, the data that must stay in the Kingdom. The answer is assembled from four sources, each best read in the authority's own text.

• Your data classification. SDAIA's National Data Management Office publishes the national data management standards, which include data classification. Your policy gives each class its level, and most hosting decisions follow the level.
• The NCA controls in your scope. The National Cybersecurity Authority publishes the Essential Cybersecurity Controls and, for cloud, the Cloud Cybersecurity Controls (CCC), an extension of the essential controls; the current edition on NCA's list is CCC-2:2024. Whether they apply to you, and what they say about hosting, is in the current text. See our NCA ECC guide for how scope is described.
• Personal data rules. The Personal Data Protection Law is overseen by SDAIA, which publishes a Regulation on Personal Data Transfer outside the Kingdom setting the conditions under which personal data may be sent abroad. Our PDPL guide covers the law in general terms.
• Your sector and your contracts. A sector regulator, a government client or a contract can set stricter terms than the general rules.

We do not quote control or article numbers here; they are revised, and copying them from summaries is how wrong requirements spread.

Most residency gaps are not in the main database but in the copies around it.

• Logs and traces. Application logs are free text that routinely carries user identifiers, ID numbers in error messages and internal hostnames. Sending them abroad sends that content too.
• Backups and disaster recovery. A backup in a second region is a second location, and needs the same answer as the main system.
• Support access. A vendor engineer abroad who connects to production, or receives an extract, is processing data outside the Kingdom.
• SaaS features. Analytics, search, AI assistants and session recording can each send data to the vendor's site.

None of this is a reason to avoid SaaS; it is a reason to list the copies on the same map as the systems.

Monitoring is where residency most often stops a project. Metrics are mostly aggregates; traces can carry identifiers in URLs and queries; logs can carry anything.

Take Datadog, which Interkey implements. It is SaaS: data lands on the Datadog site chosen when the account is created, and as of November 2026 none of its sites is in the Middle East. There are three designs: send everything, where no telemetry class must stay; put a control point inside the Kingdom that filters, masks and routes data before anything leaves; or keep a self-hosted stack in the Kingdom for classes that may not leave at all. Most Saudi estates choose the second.

The observability data residency guide covers this in depth, including how to design a split you can defend in an audit. The same thinking applies to any monitoring or logging tool.

Relatedobservability data residency guide

Interkey helps where residency has to become a running estate. We are a Google Cloud partner and an AWS partner, and build on both, in-Kingdom options included, and on private infrastructure. Interkey also sells Datadog licences in Saudi Arabia, implements the platform and supports it, including the in-Kingdom control point.

We do not decide your classification or interpret the law; those decisions belong to your compliance owner and legal counsel. We do not recommend a provider before the classification exists. And if you already have a clear residency map and a team that keeps it current, there is little for us to add.