“Data stays here” is a regulatory requirement across the GCC — but the architectural implications go well beyond choosing a local cloud region.
Saudi Arabia’s PDPL has been fully enforceable since September 2024, with 48 enforcement decisions issued by SDAIA in 2025–2026 alone. The NCA’s Cloud Cybersecurity Controls require data residency to be technically enforced, not just contracted. UAE data protection obligations apply across federal law, DIFC, and sector-specific frameworks simultaneously.
For GCC enterprises, compliance is not a cloud provider selection decision. It is an architecture decision — covering data classification, integration flows, key management, audit trails, and exit strategy. Most global architectures, by default, do not meet these standards.
Every GCC enterprise we work with has chosen a cloud provider with a local region. Most have also discovered that choosing the right provider is the starting point, not the end point. The architecture running on that infrastructure — how data flows, where keys are held, how integrations are designed — is where compliance is actually built or broken.
What Changed: From Policy to Enforcement
The data sovereignty conversation in GCC shifted materially between 2023 and 2026. The frameworks existed before. Enforcement is what changed.
Saudi Arabia’s PDPL came into full force on 14 September 2023, with a compliance grace period that expired on 14 September 2024. Since then, SDAIA’s enforcement committees have issued 48 violation decisions covering unauthorized processing, insufficient safeguards, unlawful disclosures, and non-compliant data handling.
Penalties reach SAR 5 million per breach — approximately USD 1.3 million — with repeat offenses doubling the applicable fine, and intentional violations involving sensitive personal data carrying potential criminal proceedings and imprisonment of up to two years.
The UAE operates a more layered framework. Federal Decree-Law No. 45 of 2021 on Personal Data Protection governs mainland UAE, with the DIFC and ADGM each maintaining their own data protection regimes.
The UAE’s National Cloud Security Policy, developed in 2023, establishes five cloud security principles and defines requirements for cloud users and providers across government and private sector entities.
Financial institutions in both countries face additional obligations — SAMA’s Cyber Security Framework in Saudi Arabia, the Central Bank of the UAE’s requirements — on top of the national frameworks.
Computer Weekly’s analysis from May 2026 captured the shift precisely: organizations across the Gulf have moved their primary question from “how do we use AI?” to “where does the data live?”
Data residency has become a design constraint that enters every significant technology decision in the region.
What”Data Residency” Actually Requires in Architecture Terms
Selecting a cloud provider with a Saudi Arabia or UAE region satisfies one condition. It does not satisfy the full set of requirements. The architecture running on that infrastructure has to be designed for compliance from the start.
Data Classification Comes First
Saudi PDPL distinguishes between public data, personal data, and sensitive personal data, each with different protection requirements. SDAIA applies a four-tier classification framework.
Applying that classification across an organization’s entire data inventory is the foundational step — without it, every downstream control decision lacks a reliable basis.
In practice, classification is more complex than it appears. Personal data appears in many places organizations do not initially map: logs, telemetry, backup copies, analytics pipelines, support ticketing systems, AI training datasets.
Under PDPL, these indirect data flows are in scope even if the primary application data is correctly stored in-Kingdom. A classification exercise that covers the primary database but misses the logging infrastructure is incomplete.
Residency Must Be Technically Enforced, Not Just Contracted
This is one of the most significant architectural implications of NCA compliance in Saudi Arabia. The NCA’s Cloud Cybersecurity Controls require data residency to be technically enforced — not merely promised in a contract.
Hyperscalers’ standard data residency commitments are contractual promises. Technical enforcement — at the network layer, not just in policy documents — is a separate requirement.
The NCA ECC Cloud Computing Control (Domain 4) requires cloud service agreements to include right-to-audit provisions. Negotiating these clauses at enterprise scale with major global hyperscalers can take six to twelve months and may result in a limited-scope arrangement that does not fully satisfy NCA auditors.
Architecture that reduces dependence on contractual assurances — by technically constraining where data can flow — provides a more durable compliance position.
Key Management Stays In-Jurisdiction
PDPL requires that encryption keys be stored within the organization or inside in-Kingdom cloud zones — not held by third-party platforms unless explicitly authorized.
The NCA’s CCC framework extends this: the CCC requires strong encryption aligned with National Cryptographic Standards and a documented key management process within the cloud service provider.
For enterprises using managed cloud services with default key management settings, this is frequently a gap. The default configuration of most cloud services holds encryption keys in the provider’s global key management infrastructure — not necessarily in the specific region where the data resides.
Customer-managed keys, with key vaults explicitly pinned to the in-Kingdom or in-UAE environment, are the architecture pattern that satisfies this requirement.
Integration Flows Are In Scope
Unsanctioned third-party integrations, unmanaged SaaS connectors, and automated workflows can violate cloud data privacy requirements even if the primary data never leaves the cloud.
This is a particularly relevant consideration for enterprises running complex enterprise integration environments — ERP connected to analytics platforms, CRM feeding marketing automation, operational systems exchanging data with cloud-hosted services.
Every integration that touches personal data is, under PDPL, a data processing activity that requires a lawful basis, documented purpose, and — for transfers outside Saudi Arabia — either SDAIA authorization or explicit data subject consent.
Cross-border transfers require justification, secured consent, and documentation of safeguards in the destination country. An enterprise integration architecture that was designed without these constraints in mind will require mapping and remediation once the compliance analysis is applied.
Audit Trails Are Mandatory
PDPL requires that all access, modification, or movement of personal data be logged, with those logs retained and reviewable. Absence of audit trails is treated as non-compliance.
For enterprises running distributed cloud architectures — multiple services, multiple environments, automated data flows — building a complete and auditable log of what happened to personal data, when, and under what authorization is an active architecture requirement, not a default feature.
The NCA ECC framework reinforces this at the cybersecurity level: organizations must report security incidents to CERT-SA within defined timeframes, with incident response capabilities available within Saudi Arabia.
An audit trail architecture that is complete enough to support a CERT-SA notification is a higher standard than what most standard cloud monitoring configurations provide by default.
Exit Strategy Is a Contract Requirement
NCA compliance requires a documented exit strategy from cloud service providers — an architecture that avoids vendor lock-in without a defined transition plan.
This means the cloud architecture needs to be designed with portability in mind: data in exportable formats, no hard dependencies on proprietary services that cannot be migrated, and a contractual guarantee of certified deletion and data export within a defined timeframe if the relationship ends.
The Current Provider Landscape in GCC
Understanding which providers are available in-region — and what that means for architecture — is part of the compliance planning decision.
Saudi Arabia
Three categories of providers serve KSA enterprises: global hyperscalers with Saudi regions, regional telco-cloud subsidiaries, and independent sovereign cloud providers.
Oracle is the most established hyperscaler with two live public cloud regions — Jeddah (since 2020) and Riyadh (since October 2024).
Microsoft confirmed its Saudi Arabia East datacenter region in February 2026, targeting Q4 2026 general availability — as of mid-2026, Saudi workloads route through Azure UAE North or Qatar Central.
AWS has committed $5.3 billion to build a Saudi Arabia cloud region with three Availability Zones, targeted for 2026, but as of mid-2026 the region has not been confirmed as generally available.
Regional telco-cloud providers — stc Cloud, Mobily Cloud — operate from in-Kingdom data centers with established NCA and SAMA compliance frameworks.
UAE
The UAE’s framework covers mainland, DIFC, and ADGM separately. The UAE National Cloud Security Policy defines requirements for cloud users and providers aligned with the UAE’s cybersecurity strategy.
G42’s Khazna operates substantial UAE data center capacity. Microsoft, AWS, and Google Cloud all have UAE regions operational.
The provider selection is a necessary but not sufficient step. What matters architecturally is whether the configuration of the chosen provider — including default data flows, logging infrastructure, support access, key management, and integration capabilities — meets the regulatory requirements, not whether the provider has a local region.
Five Architecture Decisions That Determine Compliance
1. Data Classification Before Cloud Design
Classification drives every subsequent architectural decision. Which data categories are present, where they originate, and what tier they fall into under PDPL determines what controls apply.
This mapping needs to cover not just primary application data but logs, telemetry, backups, AI training data, and integration payloads.
2. Residency Pinning at the Network Layer
Technical enforcement of data residency — not contractual assurance alone — means configuring cloud environments so data cannot route outside the designated jurisdiction.
This requires explicit configuration of storage policies, replication settings, backup destinations, and support access controls, not reliance on provider default settings.
3. Customer-Managed Keys in In-Region Vaults
Encryption keys need to be held within the organization’s control, in key vaults explicitly configured to reside in the in-Kingdom or in-UAE environment.
Default cloud key management arrangements frequently do not meet this requirement without explicit configuration.
4. Integration Mapping Against Compliance Requirements
Every data integration that touches personal data needs to be mapped against PDPL’s lawful basis requirements, purpose limitation, and cross-border transfer controls.
Integrations that route personal data through services hosted outside the jurisdiction need either explicit authorization or architectural redesign.
5. Audit Infrastructure as a First-Class Requirement
Logging of all personal data access, modification, and movement — with logs retained, queryable, and available for regulatory review — is a compliance requirement, not an optional monitoring feature.
The audit infrastructure needs to be designed alongside the application architecture, not added afterward.
Key Regulatory Requirements (2025–2026)
| Requirement | Saudi Arabia (PDPL / NCA) | UAE (Federal PDPL / DIFC) |
| Data residency | Default: personal data hosted in KSA. Cross-border transfers require SDAIA authorization or consent | Secret, sensitive, and confidential data must be stored in UAE; can be stored outside with equivalent security |
| Enforcement authority | SDAIA / NDMO | UAE Data Office; TDRA; sector regulators (CBUAE, health authorities) |
| Penalties | Up to SAR 5M per breach (~USD 1.3M); criminal liability for intentional violations | Up to AED 5M for severe violations |
| Enforcement status | Active — 48 decisions issued 2025–2026 | UAE Data Office not yet fully operational; sector-specific enforcement active |
| Cloud framework | NCA CCC (extends ECC) — applies to cloud service providers and tenants | UAE National Cloud Security Policy (2023); DIFC DP Law separately |
| Key management | Customer-managed keys in-region; NCS-compliant cryptography | Encryption standards required; sector-specific requirements vary |
| Audit rights | NCA ECC Control 4-2 requires right-to-audit in cloud agreements | Sector-specific requirements; DIFC framework includes audit obligations |
| Exit strategy | Documented exit strategy required in cloud agreements | No explicit universal requirement; DIFC framework addresses portability |
| AI and automated decisions | SDAIA oversight; PDPL applies to automated processing | TDRA established National AI Test and Validation Lab (May 2026) for AI model certification |
| Cross-border transfers | SDAIA authorization or explicit consent required; destination country risk assessment | Adequate security required for transfers; DIFC has separate adequacy framework |
What This Means for GCC CTOs and IT Architects
Design for compliance from the start, not as a retrofit
PDPL compliance shapes system architecture from the beginning — not just the hosting decision.
An architecture that routes logs to a global region, uses default key management, or sends integration payloads through non-local services will require rework when it is mapped against regulatory requirements. The rework is more expensive after deployment than before it.
Map all data flows, not just primary storage
Compliance gaps most often appear not in where the main database is hosted, but in indirect flows: telemetry sent to a global monitoring platform, backups replicating to a non-local region, AI training pipelines pulling from production data, support access opening a path to in-Kingdom data from outside the Kingdom.
A complete data flow map is the prerequisite for a reliable compliance assessment.
Treat key management as an architecture decision, not a configuration choice
Customer-managed keys held in in-region vaults are the architecture pattern that satisfies both PDPL and NCA CCC requirements.
Leaving key management to provider defaults and addressing it later during a compliance audit is a predictable source of remediation work.
Audit infrastructure needs to be built alongside the application, not after
The requirement to log and retain records of all personal data access and movement is not optional.
Building audit capability into the integration and application architecture from the start produces a more reliable and less expensive compliance posture than retrofitting it.
Plan the exit strategy before signing the contract
NCA compliance requires a documented exit strategy.
Enterprises that negotiate cloud service agreements without explicit data export, certified deletion, and transition support provisions will face this issue at renewal or termination. It is easier to negotiate before signature than after.
The compliance question in GCC is not ‘are we in the right cloud region.’ It is ‘does our architecture, in detail, meet what the regulations require.’ Data classification, key management, integration flow mapping, audit trails, exit planning — these are the decisions that determine whether a cloud deployment is compliant. Provider selection is the first step, not the last.
FAQ: Sovereign Cloud Architecture in GCC
Choosing a cloud provider with a Saudi Arabia or UAE region means the primary data storage infrastructure is in-jurisdiction. It does not mean the architecture is compliant.
Compliance requires data classification, technical enforcement of residency for all data flows (not just primary storage), customer-managed encryption keys in in-region vaults, documented audit trails, right-to-audit provisions in cloud agreements, and a documented exit strategy.
Each of these is an architecture decision independent of which provider is selected.
PDPL requires that personal data be hosted in Saudi Arabia by default. Cross-border transfers require either SDAIA authorization or documented consent and safeguards.
All access, modification, and movement of personal data must be logged, with logs retained and reviewable. Encryption must cover data at rest and in transit, with keys managed within the organization’s control.
Data classification under SDAIA’s four-tier framework determines which controls apply to which data. As of 2025–2026, SDAIA has issued 48 enforcement decisions, meaning compliance is an active regulatory expectation, not a future concern.
It satisfies the hosting requirement for data stored in that region’s primary storage service, provided the service is configured to store data in the designated region.
It does not automatically satisfy requirements for logs, telemetry, backup destinations, support access controls, key management, right-to-audit, and integration flows — all of which may default to configurations that route data outside the jurisdiction.
Each of these areas requires explicit configuration or contractual negotiation.
The NCA Cloud Cybersecurity Controls (CCC) is a framework published by Saudi Arabia’s National Cybersecurity Authority that applies to both cloud service providers and cloud service tenants — the organizations using cloud services.
It extends the NCA’s Essential Cybersecurity Controls (ECC) with specific requirements for cloud environments, covering data sovereignty, encryption, key management, incident response, audit rights, and exit strategy.
Government organizations in the Kingdom are in scope. Organizations adjacent to government — contractors, regulated entities in finance, energy, and telecom — should assess their obligations under CCC in addition to ECC.
The UAE operates a more layered framework. Federal Decree-Law No. 45 of 2021 governs personal data on the UAE mainland.
The DIFC and ADGM each have their own separate data protection regimes with their own enforcement authorities. Sector-specific regulators — CBUAE for financial services, health authorities for patient data, TDRA for telecoms — impose additional obligations.
The UAE National Cloud Security Policy establishes cloud-specific requirements. Saudi Arabia’s PDPL is more specifically enforced at the national level, while UAE compliance requires mapping against multiple parallel frameworks depending on the sector and jurisdiction.
Customer-managed keys held in key vaults explicitly configured to reside in the in-Kingdom or in-UAE environment is the architecture pattern that satisfies both PDPL’s requirement that keys not be held by third-party platforms without authorization, and NCA CCC’s requirements for encryption aligned with National Cryptographic Standards.
Default cloud key management configurations frequently hold keys in the provider’s global key management infrastructure, which may not pin keys to the specific regional environment where data is stored.
Every integration that touches personal data is a data processing activity under PDPL, requiring a lawful basis, documented purpose, and — for any flow that routes data outside Saudi Arabia — either SDAIA authorization or explicit consent.
Integrations to SaaS platforms, analytics tools, marketing automation, AI services, or any cloud-hosted service that receives personal data need to be mapped against these requirements.
Flows that cannot be justified under a lawful basis or that route data to unauthorized destinations need architectural redesign.
Usetech starts with a data flow mapping exercise — identifying all personal data that flows through an organization’s systems, where it resides, where it moves, and which regulatory requirements apply to each flow.
From that baseline, the architecture decisions on residency enforcement, key management, integration redesign, and audit infrastructure are grounded in the actual data picture rather than assumptions.
For GCC enterprises implementing data integration at scale, compliance requirements are incorporated into integration design from the outset, not reviewed at the end of the project.
About Usetech
Usetech is a technology company focused on practical digital transformation for enterprise and strategic-sector environments across MENA.
Usetech helps organizations improve operational control, infrastructure efficiency, data integration, and decision speed through AI, data, and engineering solutions adapted to real regional conditions.
Core focus areas include AI and operational platforms, infrastructure optimization, data integration and enterprise connectivity, smart industry and digital operations, and strategic technology consulting for MENA growth environments.
Ph.D. in Mechanical Engineering and am a Certified TOGAF 9 Enterprise Architect.