The Saudi Cloud Migration Playbook: NCA ECC, Data Residency, and What Actually Ships

Most Saudi cloud migration projects do not fail on network throughput or Kubernetes maturity — they fail on data residency. Someone signs a hyperscaler contract before anyone has mapped which datasets qualify as Saudi Government Data under the Cloud Computing Regulatory Framework (CCRF), and which of those may legally leave the Kingdom. By the time the classification exercise happens, the landing zone is already built in the wrong region, the encryption keys are managed from a control plane outside Saudi Arabia, and the NCA Essential Cybersecurity Controls (NCA ECC) gap assessment turns into a rebuild instead of a review.

The cost of getting this sequence backwards is not abstract. A landing zone rebuild after go-live means re-provisioning identity, re-issuing keys, re-running the ECC self-assessment, and re-negotiating data processing terms with the cloud service provider (CSP) — work your team already did once, now redone under a live production SLA. For a regulated entity with a sector regulator layered on top (SAMA, for financial institutions — see our companion piece on the SAMA & NESA compliance blueprint), a residency finding during an examination can pause further data migration until remediation is verified, which stalls the rest of the program regardless of how well the technical build went elsewhere.

This playbook is the sequence D-Elite Solutions' engineering and security team uses to plan cloud migrations for Saudi enterprises: what NCA ECC actually asks of a cloud workload, what the CCRF says about where data — and the keys that protect it — are allowed to sit, how to build a landing zone that survives an NCA audit, and when the correct answer is not to migrate yet.

Key Takeaways

• NCA's ECC-2:2024 update folded third-party and cloud requirements into its main control domains rather than keeping cloud as a standalone fifth domain — your shared-responsibility matrix with the CSP needs to map to specific ECC subcontrols, not just "the CSP holds ISO 27001."
• Under the classification model the CCRF established, Saudi Government Data (split into top secret, secret, confidential, and public tiers) generally cannot leave the Kingdom, temporarily or permanently, unless expressly permitted by law; Non-Government Data classification is your own call, made against the CSP's declared security levels.
• CITC is now CST — the Communications, Space & Technology Commission. Confirm any CCRF-derived documentation you're relying on reflects the current regulator name and the 2023 Cloud Computing Services Provisioning Regulations, not the superseded CCRF v3 text.
• A region physically located in Saudi Arabia is necessary but not sufficient for "local." If your KMS root key, support tooling, or backup replication path touches a control plane outside the Kingdom, your residency claim is weaker than your architecture diagram suggests.
• Customer-managed keys (CMK) held in an in-Kingdom key store, with the key custodian role separated from the data custodian role, matter as much as where the encrypted bytes physically sit.
• Not every workload should move now. Some data classes and some ICS/OT environments are correctly kept on-premises-in-Kingdom or in a hybrid model until region maturity and your own ECC tier catch up.

NCA ECC and Cloud: The Control Domains Behind Every Saudi Cloud Migration Decision

The National Cybersecurity Authority (NCA) issues the Essential Cybersecurity Controls (ECC) — the baseline every Saudi organization in scope is expected to meet. Public compliance-advisory summaries of the ECC-2:2024 update (published by firms including Qualys and SecurityWall) describe a restructuring into four main domains — Cybersecurity Governance, Cybersecurity Defense, Cybersecurity Resilience, and Third-Party & Cloud Computing Cybersecurity requirements integrated across those domains — spanning roughly 28 subdomains and 108 main controls, down from 114 in the prior ECC-1:2018 version, with a new tiered compliance model (Essential, Advanced, Minimal) depending on the sensitivity of your organization's role. Treat the exact control count as directional rather than gospel: pull the NCA's own current published ECC-2:2024 document before you scope a formal assessment, since secondary summaries can lag the authority's own revisions.

What matters for a migration is not memorizing the control count — it's knowing where NCA's expectation of you stops and the CSP's obligation begins.

Shared responsibility split with your CSP

The Cloud Computing Regulatory Framework: What Can Leave the Kingdom, and What Can't

Cloud in Saudi Arabia is regulated by the Communications, Space & Technology Commission (CST) — the same authority formerly known as the Communications and Information Technology Commission (CITC), rebranded in December 2022. The original Cloud Computing Regulatory Framework version 3 (CCRF v3) set out a two-tier subscriber data classification model: Saudi Government Data, split into four levels (top secret, secret, confidential, public), and Non-Government Data. Under CCRF v3, Saudi Government Data could not be transferred outside the Kingdom for any purpose, temporarily or permanently, unless expressly permitted by law or regulation. Non-Government Data classification was left to the subscriber, matched against the CSP's declared security levels.

On 10 October 2023, CST issued updated Cloud Computing Services Provisioning Regulations that superseded CCRF v3. We could not independently confirm from primary CST publications whether the 2023 regulations preserve the government-data residency wording verbatim or modify it — treat "Saudi Government Data stays in the Kingdom" as the safe planning baseline, but have legal counsel pull the current CST-published text before you finalize any data flow diagram that assumes a relaxation of that principle.

Separately, if your organization handles data for or alongside government entities, the National Data Management Office (NDMO), under the Saudi Data & AI Authority (SDAIA), maintains its own national data governance and classification standards. We were not able to independently verify NDMO's exact current tier names for this piece — treat NDMO as a second classification lens that may apply on top of CCRF, and pull the current NDMO documents directly rather than relying on secondary summaries.

The operational implication: classification is a decision your data owners make before you pick a region or a CSP, not an exercise you retrofit after the contract is signed.

In-Kingdom Regions: What "Local" Actually Means in Your Contract

Because region build-out timelines shift, treat this table as a starting point for due diligence, not a substitute for it. Confirm current general-availability status, availability zone count, and CST registration status for the specific service directly with the provider before you commit to a residency claim in a customer contract.

"Local" is a contract clause, not a pin on a map

A region physically inside Saudi Arabia answers only the first of several questions you need closed:

• Support access. Can CSP support staff access production data from outside the Kingdom for troubleshooting, and under what authorization?
• Backup and DR replication target. Does your disaster recovery configuration replicate to a region outside KSA by default?
• Telemetry and logging. Does the CSP's own operational telemetry from your tenant route through a global console outside the Kingdom?
• CDN and edge caching. Does your content delivery layer cache regulated data at edge points outside KSA?
• Licensing. Is the specific legal entity operating the KSA region itself CST-registered to provide that cloud service category domestically? This is separate from where the data center physically sits.

Landing Zone Architecture for Regulated Saudi Workloads

A landing zone is the governed multi-account (or multi-subscription) structure workloads land into — built once, before any regulated workload migrates. The structure below is provider-agnostic; substitute AWS Organizations/Control Tower, Azure Management Groups, or GCP Resource Manager for the primitives.

Organization: KSA-Production
├── ou-security
│   ├── acct-log-archive        # immutable, write-once logging, in-Kingdom region only
│   └── acct-security-tooling   # SIEM forwarder, key management, threat detection
├── ou-workloads-regulated
│   ├── acct-prod-restricted    # data requiring in-Kingdom residency (Gov't Data tiers)
│   └── acct-prod-confidential  # Non-Government Data classified "confidential"
├── ou-workloads-general
│   └── acct-prod-general       # no residency constraint
└── ou-sandbox
    └── acct-dev-test

Guardrails (deny by default):
  - Deny CreateBucket/StorageAccount outside the approved KSA region list
  - Deny KMS key creation outside the approved KSA region
  - Deny public network ACL widening on regulated OUs
  - Require tag "data-classification" on every storage resource

Enforce the guardrails as policy-as-code — service control policies, Azure Policy, or OPA/Gatekeeper for Kubernetes — not as a review checklist someone runs manually before each deployment. A guardrail that depends on a human remembering to check it is not a guardrail your NCA ECC evidence file should rely on.

Identity, Encryption and Key Management: Why the Key's Residency Matters as Much as the Data's

Customer-managed keys (CMK) — sometimes discussed alongside Bring Your Own Key (BYOK) and Hold Your Own Key (HYOK) models — let you control the cryptographic key protecting your data separately from the CSP's own default-managed key. This matters because the default managed key's lifecycle is controlled by the CSP's global key management service (KMS), which may involve control-plane operations that touch infrastructure outside Saudi Arabia depending on the service, even when the encrypted data itself sits in the KSA region.

A customer-managed key pinned to an in-Kingdom KMS instance, with the key custodian role assigned to someone other than your infrastructure or data administrator (separation of duties — an identity and access theme threaded through NCA ECC's Defense domain), gives you three things a default key doesn't:

1. Evidence of who could decrypt — a documented, auditable custody chain for the cryptographic root of trust.
2. An independent revocation lever — you can cut off decrypt access without depending on the CSP's own break-glass process.
3. A stronger examination position — you can demonstrate the cryptographic root of trust never left Kingdom custody, even where the CSP's own global control plane sits elsewhere.

Practical build checklist:

• Use CMK wherever the service supports it for restricted or confidential-tier workloads.
• Rotate keys on a defined schedule and log every key-use event to your SOC.
• Document the key custodian role separately in your RACI — it should not be the same person who administers the workload.
• For any service that doesn't yet support in-region CMK, treat that as a go/no-go gate for hosting classified data on that specific service — not a footnote to work around later.

Logging, Monitoring and SOC Integration

Event logging and monitoring sits across NCA ECC's Defense and Resilience domains — this is not an optional add-on to a cloud migration, it's a landing zone prerequisite. Forward tenant-level control-plane and data-plane logs to a centralized, immutable log archive in-Kingdom, and integrate that archive with your SOC's SIEM — in-house or via an MSSP — with defined coverage per log source.

Set your log retention period to match the current NCA ECC control text and any sector overlay (for example, SAMA's cybersecurity framework for financial institutions) rather than a generic industry default. Retention duration is one of the figures most likely to shift across ECC revisions, so pull the current mandated minimum from the regulator's text at assessment time rather than carrying forward a number from a prior engagement.

The Seven-Step Migration Sequence

1. Data discovery & classification. Classify every dataset against the CCRF's Government/Non-Government model — and, for public-sector counterparties, the NDMO classification lens — before any region or CSP decision.
2. NCA ECC gap assessment. Score current state against the ECC-2:2024 domains, scoped to the workloads you intend to migrate. The result is your remediation backlog, not a pass/fail gate.
3. CSP and region selection with a CST-registration check. Shortlist only CSPs registered with CST for the service categories you need, in regions with confirmed operational status.
4. Landing zone build. Account structure, guardrails, key management, and log archive — before any workload lands, not alongside the first migration.
5. Pilot migration on a non-regulated workload. Validate the landing zone, guardrails and monitoring end-to-end on something that isn't classified data first.
6. Regulated workload migration with a documented data protection impact review. Migrate restricted or confidential workloads only after the pilot proves the guardrails hold, with sign-off from the data owner and security.
7. Cutover, decommission and continuous compliance monitoring. Decommission the source environment on a defined schedule, and fold the workload into ongoing ECC self-assessment and SOC coverage — go-live is not the finish line.

Vendor and CSP Due Diligence: The Approval Workflow

• CSP is registered with CST for the relevant cloud service category
• CSP provides a data processing addendum specifying sub-processor locations
• CSP discloses whether support or troubleshooting access to production data can originate from outside the region
• CSP supports customer-managed keys, in-region, for the services you plan to use
• CSP's incident notification SLA is defined in writing and meets your internal escalation timeline
• CSP provides an exit/portability plan — export format, timeline, and any egress cost cap
• Independent attestation (ISO 27001, SOC 2, or equivalent) is current and scoped to the region you're using, not just the provider's global entity
• Internal approval chain — data owner sign-off, security architecture review, legal review of the DPA, and CISO or equivalent final approval — is logged for audit

Phased Roadmap

Durations are a reasoned planning estimate that scales with workload count and your current ECC maturity — not a fixed quote for any specific engagement.

Cost and Timeline Realism: A Worked Example

Take a mid-size regulated workload set as a planning example: roughly 40 VM-equivalents of compute and 15 TB of classified data, landing zone built from scratch. This is a reasoned estimate for planning purposes, not a quote — your actual figures depend on provider, region, and current pricing:

• Landing zone build (guardrails, key management, log archive, IAM): roughly 3–5 engineering weeks at blended senior cloud engineer/security architect effort.
• ECC gap assessment and remediation backlog closure: scales with your current control maturity — a team starting from a partial ECC-1:2018 baseline typically carries materially less remediation than a team starting from zero.
• Data migration itself (15 TB over a private or dedicated connection): bandwidth-bound, not compute-bound. Model the transfer window against your actual link speed rather than assuming public-internet throughput.
• CMK and KMS integration: roughly 1–2 engineering weeks, mostly application-side changes to call the region-pinned KMS.
• Pilot plus regulated cutover: add 20–30% schedule contingency specifically to the regulated-workload phase — DPIA sign-off and legal review cycles are typically the most variable part of the schedule, not the engineering work.

A mid-size regulated migration commonly runs four to seven months end to end when classification and the ECC baseline are done properly up front — versus significantly longer when a landing zone has to be rebuilt after a residency finding surfaces mid-project.

When Not to Migrate Yet: The Hybrid and On-Premises-in-Kingdom Case

• If your classification exercise places a material share of your workload in the top-secret or secret Saudi Government Data tiers — or your public-sector counterparty applies an equivalent NDMO tier — and no CST-registered CSP option is confirmed to meet that residency requirement for the specific service you need, the correct call is on-premises-in-Kingdom or an already-approved government cloud, not a hyperscaler migration on a hopeful timeline.
• If your organization hasn't closed its current-state NCA ECC gap assessment, migrating first and remediating controls afterward inverts the correct order. You inherit a live production environment carrying an unresolved control gap — a materially worse audit position than the same gap sitting in a pre-production landing zone.
• ICS/OT environments with hard real-time control loops and no validated cloud-connected failover path are a hybrid case by default: keep the control loop on-premises-in-Kingdom, and consider cloud only for the historian, analytics, and reporting layers that don't sit in the real-time path.
• If your target CSP's in-Kingdom region doesn't yet support customer-managed keys for the service you need, or the CSP won't confirm support-access boundaries in writing, delay the classified-workload migration specifically — you can still migrate the non-regulated portion of your estate on the current timeline.
• Cost is a legitimate reason to phase rather than block. If the worked estimate above doesn't clear your organization's return threshold for a given workload, a hybrid approach — migrate what has a clear compute or scale benefit, keep classified data on-premises-in-Kingdom — is a defensible strategy, not a failure to modernize.

Anti-Patterns and Common Mistakes

• Signing the CSP contract before the data classification exercise is complete.
• Treating "the CSP has a Saudi Arabia region" as equivalent to "our residency obligation is satisfied," without checking key residency, support-access boundaries, and CST registration for the specific service.
• Using the CSP's default managed encryption keys for classified workloads because customer-managed keys add a sprint to the schedule.
• Running the NCA ECC gap assessment against your current on-premises environment only, then assuming the result still holds once workloads move to a fundamentally different shared-responsibility model.
• Skipping the pilot migration and taking a regulated workload straight into production in the new landing zone.
• Treating log retention and SOC integration as a post-go-live task rather than a landing zone prerequisite.
• Assuming CCRF v3's exact residency wording still applies verbatim after the 2023 Cloud Computing Services Provisioning Regulations, without checking the current CST-published text.

FAQ

Is AWS or Azure legal to use in Saudi Arabia for regulated data? Yes, subject to conditions: the specific CSP entity must be registered with CST for the relevant service category, the data's classification under the CCRF model must be matched to a region and contract terms that satisfy residency requirements, and — for Saudi Government Data specifically — the data generally cannot leave the Kingdom absent an express legal exception.

What is the difference between NCA ECC and the SAMA cybersecurity framework? NCA ECC is the national baseline the Essential Cybersecurity Controls set for organizations in scope across the Kingdom. SAMA's cybersecurity framework is a sector-specific overlay for banks, insurers and financial institutions regulated by the Saudi Central Bank, and it typically layers additional requirements on top of, not instead of, NCA ECC.

Can Saudi government data be stored outside Saudi Arabia? Under the classification model the CCRF established, Saudi Government Data — split into top secret, secret, confidential and public tiers — generally cannot be transferred outside the Kingdom, temporarily or permanently, unless expressly permitted by law or regulation. Confirm current wording with CST and legal counsel before relying on any exception.

Does CITC still exist, or is it CST now? CITC was rebranded to the Communications, Space & Technology Commission (CST) in December 2022, with an expanded mandate that now includes space-sector oversight. Any current cloud licensing or CCRF-related documentation should reference CST as the regulator.

What is a customer-managed key, and do I need one in Saudi Arabia? A customer-managed key (CMK) is an encryption key you control the lifecycle of, rather than relying on the CSP's default managed key. For classified or restricted-tier data in Saudi Arabia, an in-Kingdom CMK — with the key custodian role separated from your infrastructure administrator — strengthens your residency and audit position materially.

How long does a cloud migration take for a Saudi enterprise under NCA ECC? For a mid-size regulated workload set, plan on roughly four to seven months end to end when data classification and the NCA ECC gap assessment are completed before the landing zone build starts. Skipping that sequencing is the most common cause of multi-month schedule slippage.

Related Reading

• SAMA & NESA Cybersecurity Compliance Blueprint — the sector-specific overlay financial institutions in the Kingdom and wider GCC need on top of NCA ECC.
• B2B DevSecOps & Security Compliance Roadmap — how to build compliance checks into the pipeline that ships your landing zone changes.
• KVKK Data Protection Compliance Roadmap — a useful comparison point if your Saudi migration also touches Turkish-processed data.
• Monolith to Microservices Migration Playbook — the architectural decomposition work that often runs in parallel with a regulated cloud migration.

Talk to D-Elite Solutions

D-Elite Solutions' engineering and security team designs and audits landing zones against NCA ECC and CCRF requirements for enterprises operating in the Kingdom, across regulated sectors including financial services and healthcare. Book a session at https://www.d-elite.solutions/en/free-consultation and we'll review your current data classification and CSP shortlist against NCA ECC and CST registration status, and flag the residency risks worth fixing before you sign — no obligation.