CCC 2: Cloud Cybersecurity Controls Saudi Arabia

Cloud adoption in Saudi Arabia has moved from "planning" to "production" inside the past three years. AWS launched its Riyadh region; Microsoft Azure opened its Saudi data centre; Google Cloud has a Saudi region live; Oracle and IBM have local infrastructure. Vision 2030 actively pushes government and enterprise workloads onto cloud and the regulatory layer underneath all of this is the National Cybersecurity Authority's Cloud Cybersecurity Controls, currently in their 2024 revision: CCC 2:2024.

If your organisation operates in the Kingdom and uses any cloud service or is a cloud service provider operating in or for the Kingdom CCC 2:2024 sets the minimum cybersecurity bar you have to clear. It is mandatory for government bodies and for private-sector operators of Critical National Infrastructure; it is strongly encouraged for everyone else, and in practice the major Saudi enterprises now expect their cloud vendors and tenants to align with it.

This guide is the definitive 2026 explainer: what CCC 2:2024 actually requires, how it is structured across the four domains, the critical distinction between CSP (Cloud Service Provider) and CST (Cloud Service Tenant) controls, what changed in the 2024 update particularly around data localisation and how CCC sits alongside the rest of the NCA stack (ECC, NCNICC, SAMA's framework, and PDPL).

1. What Is CCC 2:2024 and Why Was It Updated?
2. CSP vs CST: Who Must Comply
3. The Four Domains of CCC 2:2024
4. SaaS, PaaS, IaaS: Which Controls Apply Where
5. The Five Cloud Cybersecurity Levels
6. The 2024 Data Localisation Update
7. How CCC Sits Alongside ECC, NCNICC, SAMA, and PDPL
8. How SecurityWall Supports CCC 2:2024 Compliance

What Is CCC 2:2024 and Why Was It Updated?

The Cloud Cybersecurity Controls are the NCA's dedicated framework for cloud computing security. The original version CCC-1:2020 was issued in 2020 as a modular extension to the Essential Cybersecurity Controls (ECC) to address the cybersecurity risks specific to cloud service models that the general ECC did not cover in sufficient depth.

In 2024, the NCA released CCC 2:2024 an updated version that reflects four years of operational experience, alignment with the updated ECC 2:2024, and several substantive policy changes. The most significant of these was the removal of the strict data-localisation requirement that had previously mandated cloud service providers store, process, and conduct disaster recovery for in-scope data within the Kingdom. That requirement is now governed by the National Data Management Office (NDMO) at SDAIA rather than by CCC itself a meaningful shift we cover in detail below.

CCC was developed using international cloud security standards as a baseline ISO/IEC 27001, US FedRAMP, Singapore's Multi-Tier Cloud Security Standard (MTCS SS), Germany's C5, and the Cloud Security Alliance's Cloud Controls Matrix (CCM). The result is a framework that is internationally aligned but reflects Saudi-specific regulatory priorities including sovereignty considerations, Vision 2030 cloud-first ambitions, and the practical needs of government and critical-infrastructure cloud adoption.

Critically, CCC is a modular extension to ECC, not a replacement. Both CSPs and CSTs must comply with ECC first, and then add the additional CCC controls. There is no scenario in which a Saudi cloud operator complies with CCC but skips ECC; the two are stacked.

CSP vs CST: Who Must Comply

The defining structural feature of CCC is its split between two distinct sets of obligations one for the Cloud Service Provider (CSP) and one for the Cloud Service Tenant (CST). Most other Saudi cybersecurity frameworks apply a single set of controls to a single entity; CCC explicitly recognises that cloud security is a shared responsibility and codifies who is responsible for what.

Cloud Service Provider (CSP) any organisation that provides cloud computing services to CSTs within CCC's scope. This includes hyperscalers operating in or for the Kingdom (AWS, Azure, Google Cloud, Oracle, IBM Cloud) and local cloud service providers. CSP controls are identified with a P in the control notation for example, 1-3-P-1-1 is a CSP control.

Cloud Service Tenant (CST) — any organisation consuming cloud services. CST controls are identified with a T for example, 1-3-T-1-1. The CST track applies to:

• All government organisations in the Kingdom (ministries, authorities, public establishments) and their subsidiaries whether they are located inside or outside the Kingdom
• Private-sector organisations that own, operate, or host Critical National Infrastructure (CNI) and use cloud services
• All other organisations are strongly encouraged by the NCA to adopt CCC as best practice and in practice, major Saudi enterprises increasingly require it of suppliers

The notation in the controls follows a consistent structure: <Domain>-<Subdomain>-<P or T>-<Main Control>-<Subcontrol>. So 2-3-P-1-1 is the first subcontrol of the first control in the third subdomain of domain two, on the CSP track. This precision matters when scoping engagements and assigning ownership.

For organisations that are both CSPs and CSTs for example, a Saudi SaaS company that provides cloud services to clients while itself consuming cloud infrastructure from a hyperscaler both tracks apply. Compliance scope has to be mapped carefully to avoid duplicate work or, worse, missed controls.

The Four Domains of CCC 2:2024

CCC 2:2024 organises its controls into four main domains the same structural pattern used in the updated ECC 2:2024 with subdomains beneath each. The CSP and CST tracks each have their own set of controls inside the same domain structure.

The Cybersecurity Defence domain is the most operationally dense for both CSPs and CSTs covering everything from cryptographic key management to penetration testing, multi-tenancy isolation, and event logging. For CSPs, this is where the bulk of technical controls live (network segmentation, hypervisor security, customer data isolation, encryption-at-rest and in-transit, secure deletion). For CSTs, it covers what tenants must do inside their share of the cloud environment (identity management, IAM hygiene, data classification, encryption key control where supported).

The Third-Party and Cloud Computing Security domain is where CCC's cloud-specificity is most visible. It covers contractual requirements for CSP/CST relationships, sub-CSP risk (when a CSP uses another CSP), and critically exit and portability planning, so that a CST is never locked into a specific provider in a way that violates national security or business-continuity expectations.

For pentest scoping specifically, see our NCA penetration testing requirements guide the same methodology applies, with CCC-specific scope additions for cloud environments.

SaaS, PaaS, IaaS: Which Controls Apply Where

CCC explicitly recognises that the three primary cloud service models Software as a Service, Platform as a Service, and Infrastructure as a Service have different responsibility distributions between CSP and CST. The methodology document includes mapping tables (Table 4 for CSP controls, Table 5 for CST controls) that show which controls apply at each layer.

The shape of the responsibility model:

• SaaS: The CSP carries most security responsibility (the platform, the application, the data plane, the underlying infrastructure). The CST is primarily responsible for user access management, data classification, configuration of permitted features, and the data they put in. Examples: Microsoft 365, Salesforce, ServiceNow.
• PaaS: Responsibility is more balanced. The CSP secures the platform, runtime, and underlying infrastructure; the CST is responsible for the applications they deploy, the data, and access management. Examples: AWS Elastic Beanstalk, Azure App Service, Google App Engine.
• IaaS: The CST carries substantial security responsibility (operating systems, runtime, applications, data, access). The CSP is responsible for the physical infrastructure, the hypervisor, and network fabric. Examples: AWS EC2, Azure VMs, GCP Compute Engine.

In practice this means a Saudi government agency adopting an IaaS workload has more CCC controls to implement directly than the same agency adopting an equivalent SaaS service but the CSP behind the IaaS still has to satisfy its track of CCC controls regardless. The shared-responsibility model that AWS, Azure, and Google Cloud publish for their international markets maps reasonably cleanly to CCC's CSP/CST distribution, but the Saudi-specific layers particularly around data sovereignty and NCA approval require additional contractual work between provider and tenant.

For compliance scoping, our NCA gap assessment work begins with confirming which model your workload uses, then mapping the applicable CSP and CST controls against your current state.

The Five Cloud Cybersecurity Levels

CCC's Annex A defines five cybersecurity levels based on the sensitivity of the data being processed and the criticality of the cloud service. Higher levels apply more stringent controls; lower levels are sufficient for less sensitive workloads.

In broad terms the framework is precise but the principle is straightforward:

• Lower levels apply to public data, low-impact applications, and non-critical services
• Intermediate levels apply to internal business data, moderate-impact applications, and services where confidentiality and integrity matter but national-security implications are limited
• Higher levels apply to sensitive, restricted, or critical data typically government secrets, CNI operational data, or personal data of significant volume
• The highest levels typically apply to top-secret government data, defence-related workloads, and core CNI control systems

Determining the applicable level is one of the first steps in any CCC scoping exercise. It depends on the data classification (under the National Data Management Office's classification framework), the criticality of the cloud service to organisational operations, and the regulatory category the tenant falls into. Government bodies and CNI operators typically operate across multiple levels because they handle data of varying sensitivity.

The practical implication: not every cloud workload demands the highest level of CCC controls. A government office's collaboration tool used for unclassified communications operates at a different level than the same office's core financial systems. Scoping engagements honestly to the correct level avoids both under-protection (compliance gaps) and over-engineering (paying for controls you don't need).

The 2024 Data Localisation Update

The most significant change in CCC 2:2024 and the change most worth understanding in detail concerns data localisation. The original CCC-1:2020 contained explicit requirements that cloud service providers store, process, and conduct disaster recovery for CCC-scope data within the Kingdom. In the 2024 update, these requirements have been removed from CCC itself and the data-localisation responsibility transferred to the National Data Management Office (NDMO) at SDAIA (the Saudi Data and Artificial Intelligence Authority).

What this means in practice:

• CCC no longer prescribes data residency directly. Specific controls that had mandated in-country storage and DR have been deleted or renumbered. CSPs and CSTs operating under CCC look to NDMO's data classification and management framework for data-residency decisions.
• NDMO's framework is now authoritative on what data must reside in Saudi Arabia. This depends on data classification (Top Secret, Secret, Confidential, Public) and the regulatory category of the data holder. NDMO publishes specific controls and guidance and these apply alongside CCC, not as a replacement for it.
• For most workloads, the practical effect is greater flexibility. Organisations now have more choice in cloud DR strategies, multi-region architectures, and cross-border data flows for non-sensitive data provided NDMO's classification rules are followed.
• For sensitive workloads, expect the localisation bar to remain high. Top Secret and Secret data, CNI operational data, and government-classified workloads will continue to face strict in-country requirements through NDMO these have moved, not disappeared.
• Contractual reviews are warranted. Any existing cloud contracts written under CCC-1:2020 should be reviewed to confirm whether their data-residency clauses still align with NDMO's current expectations, or whether they were over-specified against an obsolete CCC version.

This change is also consistent with the broader ECC 2:2024 update, which similarly transferred data-localisation authority from ECC to NDMO. The NCA's regulatory architecture is now cleaner: NCA owns the cybersecurity controls; NDMO owns the data-residency and classification framework. They overlap by reference, not by duplication.

For privacy-side obligations on personal data specifically, see our PDPL compliance guide personal data localisation operates under PDPL alongside NDMO.

CCC does not exist in isolation. For most Saudi organisations using cloud services, three or four cybersecurity and data frameworks apply simultaneously. Understanding how they layer is essential to building a coherent compliance programme rather than running parallel — and often duplicative — workstreams.

Some practical combinations we see most often in scoping engagements:

• A government ministry using cloud productivity tools: ECC + CCC (both CSP track on the provider and CST track on the ministry) + NDMO + PDPL on personal data
• A Saudi bank using cloud infrastructure for digital banking: ECC + CCC + SAMA Cyber Security Framework + PDPL + NDMO five frameworks, one architecture
• A private SaaS startup serving local clients: Typically NCNICC (the private-sector controls released in early 2026) + PDPL + NDMO. CCC encouraged but not mandatory unless they handle CNI data
• A foreign cloud hyperscaler offering services to KSA tenants: CCC CSP track + NDMO data classification compliance + applicable PDPL provisions for personal data they process

The good news: a single well-scoped programme can satisfy all of these together, and a single penetration test can produce evidence across multiple framework requirements. The bad news: doing this badly running each framework as a separate workstream leads to duplicated effort, contradictory documentation, and the kind of compliance fatigue that produces gaps. Our NCA gap assessment is designed specifically to map the right combination for your specific position before any control work begins.

For startup-stage organisations, fintech and BNPL operators, AI companies, and healthcare organisations, we have separate vertical guides covering the sector-specific layering.

How SecurityWall Supports CCC 2:2024 Compliance

SecurityWall is an NCA-registered cybersecurity firm operating in the Kingdom, with a team holding OSCP, OSWE, CREST, CRT, CISM, and CISSP credentials, plus PCI SSC QSA and ASV accreditation. We run CCC engagements across both CSP and CST sides of the cloud relationship, alongside the wider NCA stack.

CCC Gap Assessment

• Full mapping of your current state against applicable CCC 2:2024 controls CSP or CST track, or both where applicable
• Determination of the cloud cybersecurity level your workloads require
• Identification of gaps prioritised by risk and effort
• Coordinated mapping to ECC 2:2024 (since both apply together)
• 2 to 3 week delivery from kick-off to final report

Cloud Penetration Testing for CCC

• Penetration testing scoped to CCC's Cybersecurity Defence domain covering external attack surface, internal cloud environment, web applications, APIs, IAM configurations, network segmentation, multi-tenancy isolation
• Methodology aligned with the NCA's penetration testing requirements applicable methodology stated explicitly in the report
• Findings cross-referenced to specific CCC controls (CSP and CST tracks as relevant)
• Retest included; findings closed, not just listed

Coordinated NCA Programmes

For organisations facing multiple Saudi frameworks simultaneously ECC + CCC, ECC + CCC + SAMA, CCC + PDPL + NDMO, and so on we run a single coordinated programme rather than parallel workstreams. One gap assessment, one penetration test, one evidence pack mapped to all applicable controls. See our dual NCA + SAMA compliance guide for the financial-sector pattern.

Delivered Through SLASH

Every CCC engagement we run is delivered through SLASH, our security orchestration and control platform. Findings appear in your dashboard the same day they are discovered, every piece of evidence sits under its finding for audit defensibility, and your team collaborates on remediation through threaded comments internal-only notes stay private to your team. Retest tracking moves findings from New → Ready for Retest → Resolved with full audit trail.

Related reading across the NCA cluster:

• What is the NCA? Saudi Arabia's National Cybersecurity Authority
• NCA ECC 2:2024 Requirements in Saudi Arabia
• NCA ECC Compliance Checklist
• NCNICC for Saudi Private Companies
• NCA Penetration Testing Requirements
• NCA Gap Assessment
• NCA and SAMA Dual Compliance
• PDPL Saudi Arabia Compliance Guide

Frequently Asked Questions

What is CCC 2:2024?

CCC 2:2024 is the 2024 update of Saudi Arabia's Cloud Cybersecurity Controls, issued by the National Cybersecurity Authority (NCA). It is a modular extension to the Essential Cybersecurity Controls (ECC) that sets minimum cybersecurity requirements for cloud computing services. It applies to both Cloud Service Providers (CSPs) and Cloud Service Tenants (CSTs), with separate control tracks for each. The 2024 version replaces CCC-1:2020 and introduces several changes, most notably the transfer of data localisation authority to the National Data Management Office (NDMO) at SDAIA.

Who must comply with CCC 2:2024?

CCC applies mandatorily to all government organisations in Saudi Arabia (ministries, authorities, public establishments, and their subsidiaries) and to private-sector organisations that own, operate, or host Critical National Infrastructure (CNI) using cloud services. It applies to both CSPs providing services to these entities and CSTs consuming the services. The NCA strongly encourages all other organisations in the Kingdom to adopt CCC as best practice.

What is the difference between a CSP and a CST under CCC?

A CSP (Cloud Service Provider) is any organisation providing cloud computing services hyperscalers like AWS, Azure, Google Cloud, Oracle, and local Saudi providers. A CST (Cloud Service Tenant) is any organisation consuming cloud services. CCC contains separate control tracks for each, identified by P or T in the control notation (for example 2-3-P-1-1 for a CSP control and 2-3-T-1-1 for a CST control). Organisations that are both CSP and CST must comply with both tracks.

How many domains and controls does CCC 2:2024 have?

CCC 2:2024 is structured around four main domains Cybersecurity Governance, Cybersecurity Defence, Cybersecurity Resilience, and Third-Party and Cloud Computing Security with 24 subdomains. Each domain contains controls split across CSP and CST tracks. The framework also defines five cloud cybersecurity levels in Annex A, with applicable controls scaling based on data sensitivity and service criticality.

Did data localisation requirements change in CCC 2:2024?

Yes. The 2024 update removed the strict data-localisation requirement that had mandated CSPs store and conduct disaster recovery for in-scope data within the Kingdom. Data-residency responsibility has been transferred to the National Data Management Office (NDMO) at SDAIA, which sets data classification and residency requirements based on the data's sensitivity. For most workloads this provides more flexibility; for Top Secret, Secret, and CNI operational data, strict in-country requirements continue to apply via NDMO.

Is CCC a replacement for ECC?

No. CCC is a modular extension to ECC, not a replacement. Both CSPs and CSTs must first comply with ECC 2:2024, and then add the additional CCC controls. There is no scenario in which an organisation complies with CCC but skips ECC. The two frameworks share the same four-domain structure and are designed to be operated together.

Does CCC apply to AWS, Azure, and Google Cloud regions in Saudi Arabia?

Yes. As Cloud Service Providers offering services to CSTs within CCC's scope, AWS (Riyadh region), Microsoft Azure (Saudi data centres), and Google Cloud (KSA region) all fall within CCC's CSP track. Tenants of these services who are in CCC's mandatory scope (government, CNI) must also comply with the CST track. Contractual relationships between hyperscalers and Saudi tenants typically include CCC alignment terms.

How does CCC relate to PDPL?

CCC governs cybersecurity for cloud services; PDPL governs personal data protection. They overlap when cloud services process personal data at which point both apply simultaneously. PDPL requirements (consent, data subject rights, lawful basis, breach notification) layer on top of CCC's cybersecurity controls. Most modern Saudi cloud deployments need to satisfy both, plus NDMO's data-classification framework.