NCA CCC: Cloud Cybersecurity Controls Explained

The Cloud Cybersecurity Controls (CCC – 2: 2024) are the NCA's minimum cybersecurity requirements for cloud computing in Saudi Arabia, and they are unusual among the NCA's control sets in one important respect: they contain two separate control populations in one document — one for the Cloud Service Provider, one for the Cloud Service Tenant. Which controls apply to you depends on which side of the contract you sit, and on how the data is classified.

The 2024 revision also removed something significant. The two subcontrols in CCC-1:2020 that required cloud services to be delivered from inside the Kingdom have been deleted — not relaxed, but moved to a different regulator. That single change is the one most cloud programmes need to understand before they read anything else in the document.

What the CCC is

The CCC is an extension to the Essential Cybersecurity Controls, not a replacement for them. Almost every CCC control is written as an addition to a named ECC control — "In addition to the ECC control 1-4-1, the Authorizing Official shall also…" — which means the CCC only makes sense on top of a working ECC baseline.

The NCA developed it after a mapping study against international cloud standards: US FedRAMP, Singapore's Multi-Tier Cloud Security Standard (MTCS SS), Germany's C5, the Cloud Security Alliance's Cloud Controls Matrix (CCM), and ISO/IEC 27001. Compliance is mandated under Article 10(3) of the NCA's mandate and Royal Decree No. 57231 dated 10/11/1439H.

The asymmetry is deliberate and tells you how the NCA sees the risk: the provider carries roughly three and a half times the control burden of the tenant. But the tenant does not get to point at that ratio and relax — the CST's 26 subcontrols sit on top of the full ECC, and they cover exactly the areas a tenant cannot delegate.

Who is in scope

Cloud Service Tenants (CSTs) in scope are government agencies in the Kingdom — inside or outside it — including ministries, authorities, establishments, other entities and their companies and sub-entities, together with all private sector entities that own, operate or host Critical National Infrastructure (CNI), where those entities currently use or are planning to use any cloud service.

Cloud Service Providers (CSPs) in scope are any CSP providing cloud services to a CST that is itself in scope. The NCA gives two examples of providers outside scope: those serving only non-Saudi entities outside the Kingdom, and those serving only individuals and non-CNI private sector entities — in both cases, provided they serve no in-scope CST.

The "planning to use" clause matters for tenants. An entity that has not yet migrated but has a cloud programme on the roadmap is already in scope, which makes the CCC a pre-migration design input rather than a post-migration compliance exercise.

The four domains

The CCC uses four main domains and 24 subdomains, shared across both control populations:

Domain 2 carries 17 of the 24 subdomains, and three of them — key management, system development security and storage media security — are cloud-specific additions that do not exist as standalone ECC subdomains. If you are mapping CCC onto an existing ECC programme, those three are where the genuinely new work sits.

Reading the control numbering

CCC control IDs carry the audience in the identifier. A control numbered 1-3-P-1-1 applies to the Provider; 1-3-T-1-1 is the Tenant equivalent. The tiers run: main domain, subdomain, P/T, main control, subcontrol. Green-coloured numbers inside the control text (for example 1-3-2) are cross-references to ECC subdomains or controls.

The four levels: controls scale with data classification

Compliance with the CCC is not uniform. Controls are tiered across four levels, applied top-down according to the classification of the data in the cloud service:

Classification is determined by the competent authority, not by the entity's own judgement, and Annexes A tables mark each subdomain as mandatory (✔) or optional / recommended (❖) at each level for CSPs and CSTs separately.

One rule in that annex deserves to be lifted out, because it drives more scope than anything else in the document: where an integrated data set contains different classification levels, the highest classification applies to the whole set. A workload that is 95% public data and 5% confidential data is a Level 3 workload. In practice this means data segregation is not a tidiness exercise — it is the difference between two very different control burdens, and it has to be designed in before migration, not discovered during assessment.

The 2024 change: data localisation moved to NDMO

CCC-1:2020 contained two provider subcontrols requiring cloud services to be delivered from within the Kingdom:

• 2-3-P-1-10 — provide cloud computing services from within the Kingdom, including systems used for storage, processing and disaster recovery centres.
• 2-3-P-1-11 — provide cloud computing services from within the Kingdom, including systems used for monitoring and support.

Both were deleted in CCC-2:2024. The NCA's stated rationale in Annex D is that data localisation requirements "have been transferred from the document to the National Data Management Office (NDMO) at the Saudi Data and Artificial Intelligence Authority", and that entities must refer to the NDMO on localisation before taking any action.

Data localisation did not disappear from Saudi cloud compliance in 2024. It changed owner. The requirement left the NCA's control set and became a data-governance question for SDAIA's National Data Management Office — which means the answer no longer lives in your cybersecurity assessment.

The practical consequences are worth being precise about:

• Do not read the deletion as permission. The CCC no longer tests localisation; it explicitly directs entities to NDMO before acting. An organisation that moved a workload offshore citing the CCC deletion, without an NDMO position and without checking PDPL transfer rules, has answered the wrong regulator's question.
• Your CCC evidence pack changes. If your CSP assurance file still contains a "hosted in-Kingdom" attestation mapped to 2-3-P-1-10, that mapping is stale. The attestation may still be commercially valuable, but it no longer maps to a live CCC control.
• Personnel requirements did not move. Control 1-4-P-1-1 still requires that cybersecurity positions in a CSP's data centres within the Kingdom be filled by "qualified and suitable Saudi nationals", and 1-4-P-1-2 requires periodic screening or vetting of personnel inside the Kingdom with access to the Cloud Technology Stack. In-Kingdom staffing obligations survive the localisation deletion.

The other 2024 change is terminological but flows into documentation: "Confidential Data/Information" was renamed "Sensitive Data/Information" throughout the definitions.

How compliance is assessed

The NCA evaluates CCC compliance through self-assessments, periodic reports from the compliance tool, and on-site audits. It publishes a dedicated CCC-2:2024 Assessment and Compliance Tool to structure the exercise — the same pattern as its other control sets.

Note what this means for the CSP/CST split in practice. Both parties are separately assessable. A tenant cannot satisfy the CST controls by producing the provider's certification, and a provider cannot rely on its tenants' assessments. The contract is where the two populations meet: your provider's evidence for the 94 CSP subcontrols is something you should be contracting for, receiving on a schedule, and reviewing — not assuming.

A practical CCC readiness sequence

1. Confirm which population you are in — CSP, CST, or both. Organisations that consume cloud and provide a SaaS product to Saudi government customers are in both, with two separate control sets to evidence.
2. Classify the data before you scope the controls. The level determines what is mandatory. Classify at the level of the integrated data set, applying the highest-classification rule.
3. Baseline the ECC first. CCC controls are written as increments to named ECC controls. Assessing CCC against a weak ECC baseline produces findings you cannot close without going back to the ECC anyway.
4. Split the register by P and T. Assign every control an owner, and for every P control you depend on, name the evidence you will request from the provider and how often.
5. Resolve localisation with NDMO, separately. Treat it as a data-governance workstream with SDAIA, not a CCC control, and document the position you land on.
6. Close the three cloud-specific subdomains. Key management, system development security and storage media security are where ECC-mature organisations most often find genuine gaps.

How GRC Vantage supports CCC compliance

GRC Vantage's compliance module ships the full CCC-2:2024 library with the CSP and CST populations held as separate, filterable control sets, and the four classification levels wired into scoping — so selecting a workload's level produces the mandatory control list rather than the whole document. Because CCC controls are written as extensions to named ECC controls, the platform links each one to its ECC parent, so an ECC assessment and a CCC assessment share evidence instead of duplicating it.

Provider-side controls are tracked in the vendor and third-party workflow with the evidence you expect from each CSP recorded against the specific subcontrol it satisfies and a re-request schedule attached, so provider assurance is a monitored obligation rather than a certificate in a folder. Risks arising from cloud gaps flow into the register on the NFCRM matrix, and the platform runs inside the Kingdom with teams in Riyadh and Dammam.

For the full NCA family, see our NCA frameworks pillar guide. To work through what CCC means for a specific migration, talk to our team.

Frequently asked questions

What is the NCA CCC?

The Cloud Cybersecurity Controls (CCC – 2: 2024) are the NCA's minimum cybersecurity requirements for cloud computing in Saudi Arabia. They extend the Essential Cybersecurity Controls and contain two control populations: 37 main controls and 94 subcontrols for Cloud Service Providers, and 18 main controls and 26 subcontrols for Cloud Service Tenants, across 4 domains and 24 subdomains.

Who must comply with the CCC?

Cloud Service Tenants in scope are Saudi government agencies (inside or outside the Kingdom) and their companies and sub-entities, plus private sector entities owning, operating or hosting Critical National Infrastructure that use or plan to use cloud services. Cloud Service Providers are in scope if they serve any in-scope tenant — regardless of where the provider is based.

Does the CCC still require data to be hosted inside Saudi Arabia?

No. CCC-2:2024 deleted subcontrols 2-3-P-1-10 and 2-3-P-1-11, which had required cloud services — including storage, processing, disaster recovery, monitoring and support — to be provided from within the Kingdom. The NCA transferred data localisation to the National Data Management Office at SDAIA, and entities must refer to the NDMO before acting on localisation. Localisation obligations may still apply; they simply no longer come from the CCC.

How do the four CCC levels work?

Controls are tiered by data classification: Level 1 (Top Secret), Level 2 (Secret), Level 3 (Confidential) and Level 4 (Public), with each subdomain marked mandatory or optional at each level for CSPs and CSTs. Where an integrated data set spans classifications, the highest classification applies to the whole set.

Does complying with the ECC mean I comply with the CCC?

No. The CCC is an extension: its controls are written as additions to specific ECC controls, and both CSPs and CSTs must comply with the ECC and the CCC. Notably, CSPs must comply with both even if they fall outside the ECC's own scope.