NCA Cloud Cybersecurity Controls (CCC-2:2024): The Primary-Source Guide

If you take one thing from this page, take this: the NCA's Cloud Cybersecurity Controls no longer contain a data-residency requirement. The two sub-controls that required a provider to deliver cloud services from inside the Kingdom were deleted when the NCA published CCC-2:2024. They are gone. The document says so itself, in its own change log.

Almost every guide, vendor page and LinkedIn post you will find still says the opposite. They are describing CCC-1:2020, a superseded document, and they are describing it as if it were current.

This guide is written against the PDF itself — Cloud Cybersecurity Controls CCC-2:2024, published by the National Cybersecurity Authority, Document classification: Public, TLP: White — with CCC-1:2020 open beside it for comparison. Every control number, every count and every quoted requirement below comes from that document. Where the CCC is silent, this page says so plainly, because the most expensive mistake in Saudi compliance work is attributing a requirement to the NCA that the NCA never wrote.

The 60-second answer

• The current version is CCC-2:2024. It supersedes CCC-1:2020.
• CCC-2:2024 has 4 main domains and 24 subdomains, and it carries two separate control sets: 37 main controls / 94 subcontrols for the provider (CSP), and 18 main controls / 26 subcontrols for the tenant (CST) (CCC-2:2024, Figure 1, p.7).
• The customer is called the Cloud Service Tenant (CST) — not "subscriber", not "CSTP". A control is tagged P for provider or T for tenant, in the middle of the control number: 1-3-P-1-1 is a provider control, 1-3-T-1-1 is a tenant control.
• The data-localisation sub-controls (2-3-P-1-10 and 2-3-P-1-11 in CCC-1:2020) were deleted in CCC-2:2024. The NCA transferred data localisation to the National Data Management Office (NDMO) at SDAIA and instructs entities to refer to the NDMO "before taking any action in this regard" (CCC-2:2024, Annex D).
• It applies to government entities and to private-sector entities that own, operate or host Critical National Infrastructure (CNI) — as tenants; and to any CSP serving those tenants (CCC-2:2024, p.9).
• The CCC is an extension to the ECC. You do not comply with the CCC instead of the ECC. You comply with both (CCC-2:2024, p.10).
• There is no CCC certificate, no NCA-accredited auditor scheme, no "NCA-approved cloud provider" list created by this document, and no compliance deadline stated anywhere in it.

What CCC-2:2024 actually contains

Four main domains. Twenty-four subdomains. The subdomain names below are taken from Figure 2 (p.11):

Five plus seventeen plus one plus one is twenty-four. That is the arithmetic behind the NCA's own figure, and you can check it the same way we did.

You can check the control counts too, and we recommend you do, because it is the fastest way to prove to yourself that a guide has actually read the document. Count the P main controls in section 10 and you get 37. Count the P subcontrols and you get 94. Count the T main controls and you get 18; the T subcontrols, 26. All four match Figure 1 exactly.

How to read a CCC control number

This is the single most useful skill in the document, and it takes thirty seconds to learn (CCC-2:2024, Figure 4, p.12):

1  -  3  -  P  -  1  -  1
│     │     │     │     └── Subcontrol
│     │     │     └──────── Main control
│     │     └────────────── P = Provider (CSP), T = Tenant (CST)
│     └──────────────────── Subdomain
└────────────────────────── Main domain

The letter is the whole game. "A control is either applicable to the Provider (P) or the Cloud Tenant (T)" (CCC-2:2024, p.13). There is no shared control. Every one of the 55 main controls in this document belongs to exactly one party.

So 2-9-P-1-1 is a provider obligation and 2-9-T-1-1 is a tenant obligation, and they are not the same requirement — as you will see in a moment, they do not even carry the same frequency.

If a control number you have been given has no letter in it, it is not a CCC control. It is probably an ECC control, and that confusion is the subject of the next-but-one section.

The provider/tenant split — the part everyone gets backwards

This is the heart of the CCC and the reason it exists. The document does not write one set of controls and then apportion them by a "shared responsibility model" diagram. It writes two separate control sets, in the same subdomains, and states each side's obligation in its own words.

What the provider (CSP) must do

A representative — not exhaustive — set, quoted by control number so you can check every one:

• 1-4-P-1-1 — "Positions of cybersecurity functions in CSP's data centers within the Kingdom must be filled with qualified and suitable Saudi nationals." (Note carefully what this says and does not say: it is a Saudisation requirement on cybersecurity roles in in-Kingdom data centres. It is not a requirement that the data centre exist.)
• 2-2-P-1-9 — Get the CST's approval before accessing any CST-related asset, whether by the CSP or the CSP's third parties.
• 2-2-P-1-11 — Provide CSTs with multi-factor authentication services for privileged cloud users.
• 2-3-P-1-2 — Separation and isolation of data, environments and information systems across CSTs, to prevent data commingling.
• 2-3-P-1-8 — Complete isolation and protection of multiple guest environments.
• 2-3-P-1-9 — Community cloud services provided to CSTs (government and CNI entities) shall be isolated from any other cloud computing provided to entities outside the scope of work.
• 2-4-P-1-3 — Protection from denial-of-service attacks, including DDoS.
• 2-4-P-1-6 — Isolation between the cloud service delivery network, the cloud management network and the CSP's own enterprise network.
• 2-6-P-1-3 — Secure disposal of the CST's data on termination or expiry of the contract.
• 2-6-P-1-5 — Provide CSTs with secure means to export and transfer data and virtual infrastructure. (Yes — the exit ramp is a control.)
• 2-7-P-1-1 — Strong encryption according to the advanced level in the National Cryptographic Standards (NCS-1:2020).
• 2-9-P-1-1 — Assess and remediate vulnerabilities on external components of the Cloud Technology Stack at least once every month, and on internal components at least once every three months.
• 2-9-P-1-2 — Notify CSTs of identified vulnerabilities that may affect them, and the safeguards in place.
• 2-10-P-1-1 — Penetration testing must cover the Cloud Technology Stack and be conducted at least once every six months.
• 2-11-P-1-3 — Activate and protect all event logs of activities and operations performed by the CSP at the tenant level, to support forensic analysis. (That is the provider logging itself, inside your tenancy, for your benefit.)
• 2-11-P-1-5 — Continuous monitoring using SIEM covering the full Cloud Technology Stack.
• 2-12-P-1-5 — Support the CST in legal proceedings and forensics, protecting the chain of custody.
• 2-12-P-1-6 — Real-time reporting to the CST of incidents that may affect the CST, if the incident is discovered.
• 2-15-P-3-2 — A secure key-retrieval mechanism, including "enforcement of trusted key storage, strictly external to cloud".
• 4-1-P-1-1 — Fulfil the NCA's requests to remove software or services from the marketplace offered to CSTs where they may be considered a cybersecurity threat to national entities.

What you, the tenant (CST), must do

Shorter — 18 main controls — but do not mistake short for weak. Several of these are obligations that no amount of provider paperwork discharges:

• 1-2-T-1-1/2/3 — Define acceptable risk levels for cloud services; carry your own accredited data classification into your risk methodology; keep and periodically monitor a cybersecurity risk register for cloud services.
• 1-3-T-1-1 — "Continuous or real-time compliance monitoring of the CSP with relevant cybersecurity legislation and contract clauses." This is the one that surprises people. You are required to monitor your provider continuously. A certificate in a procurement folder is not continuous monitoring.
• 1-4-T-1-1 — Screen or vet personnel with access to cloud service sensitive functions (Key Management, Service Administration, Access Control).
• 2-1-T-1-1 — Inventory of all cloud services and the assets related to them. (Shadow IT is a CCC finding.)
• 2-2-T-1-4 — MFA for privileged cloud users. The provider must offer it (2-2-P-1-11); you must use it.
• 2-3-T-1-1 — Verify that the CSP isolates the community cloud services provided to government and CNI tenants from cloud provided to out-of-scope entities. Note the verb: the provider must do it (2-3-P-1-9), and you must verify it. Assuming is not verifying.
• 2-4-T-1-1 — Protect the connection channel with the CSP.
• 2-6-T-1-1 — An exit strategy ensuring secure disposal of your data on termination or expiry.
• 2-6-T-1-2 — Use secure means to export and transfer data and virtual infrastructure.
• 2-7-T-1-1/2 — Strong encryption to the advanced level of NCS-1:2020, and encryption of data transferred into and out of the cloud.
• 2-9-T-1-1 — Assess and remediate vulnerabilities in your cloud services at least once every three months — note this is your cadence, and it is not the provider's monthly external cadence.
• 2-9-T-1-2 — Manage the vulnerabilities the CSP notified you about.
• 2-11-T-1-1/2 — Activate and collect login and cybersecurity event logs on cloud assets, and monitor all of them.
• 2-15-T-1 → T-4 — Key management: identified, documented and approved; applied; covering key ownership and secure key retrieval; and reviewed periodically.
• 3-1-T-1-1 — Disaster recovery and business continuity procedures for cloud, developed and implemented securely.

The nine subdomains where the tenant has no CCC control at all

The tenant has controls in 15 of the 24 subdomains. It has none in these nine:

Now read that table correctly, because misreading it is a genuine audit risk.

It does not mean you have no obligation for incident management, backup, or penetration testing. It means the CCC adds nothing on top of what the ECC already requires of you. The CCC states the rule explicitly: CST controls "are an extension and complement to the controls in the ECC. Therefore, the CSTs must ensure continuous compliance with the controls in both ECC and CCC" (CCC-2:2024, p.10). Your incident-management obligation lives in ECC 2-13. Your backup obligation lives in ECC 2-9. Your penetration-testing obligation lives in ECC 2-11. The CCC simply did not need to add a cloud-specific layer to them for the tenant.

And the same rule runs the other way, which is the fact commercial CSPs most often miss: "CSPs — within or outside the scope of the ECC — must ensure continuous compliance with the controls in both ECC and CCC" (CCC-2:2024, p.10). A private hosting company is not a government body and is not CNI, so it is not in the ECC's own scope — but the moment it serves an in-scope tenant, the CCC reaches back and binds it to the ECC anyway.

The four levels are data classifications, not provider tiers

Annex A divides the controls into four levels "using a top-down approach". The levels are classifications of the data, issued by the competent authority — not tiers of provider maturity, not service tiers, and emphatically not an RTO/RPO grid:

"The highest level of classification should be adopted when the content of an integrated set of data includes different levels" (Annex A). Mix public data with secret data in one system and the system is Secret.

Tables 2 and 3 of Annex A then map every control to those four levels, marking each ✔ Mandatory or ❖ Optional (Recommended), with footnotes that make individual subcontrols optional or not-applicable at particular levels. The ECC controls themselves are marked mandatory at all four levels.

We are deliberately not reproducing that matrix here. It is a dense two-page table with per-subcontrol footnotes, and a paraphrase of it is exactly the kind of artefact that gets copy-pasted into a compliance register and then quietly becomes wrong. Open Annex A (pp.29–33) and read your own level.

Things that do not exist

Every item in this section is a claim we found circulating in vendor material and consultancy blogs about the CCC. None of them is in the document.

1. A data-residency mandate ← the big one

You will read, constantly, that "the CCC requires Saudi data to stay in Saudi Arabia." It did. It does not.

CCC-1:2020 contained two sub-controls:

2-3-P-1-10 — "Provide cloud computing services from within the KSA, including systems used for storage, processing, and disaster recovery centers." 2-3-P-1-11 — "Provide cloud computing services from within the KSA, including systems used for monitoring, and support."

CCC-2:2024's change log (Annex D) lists both as Deletion, with this rationale, quoted in full:

"Controls related to data localization have been transferred from the document to the National Data Management Office (NDMO) at the Saudi Data and Artificial Intelligence Authority for as per the mandates, and entities must refer to the National Data Management Office regarding data localization before taking any action in this regard."

Three consequences, all of which matter commercially:

1. Data localisation is now an NDMO/SDAIA question, not an NCA CCC question. If someone tells you the NCA CCC forbids you from processing abroad, ask them to cite the control. There isn't one.
2. This does not mean localisation stopped mattering. It means the requirement moved. Sector regulators, the NDMO's own policies and your own data classification may still put your data in the Kingdom — and for a lot of government workloads they will. But cite the right instrument.
3. The arithmetic proves it. CCC-1:2020 had 96 CSP subcontrols. CCC-2:2024 has 94. Two deleted sub-controls; two fewer subcontrols. The numbers reconcile exactly, which is how you know this is a real change and not an editing slip.

2. Control 2-3-P-1-10 means "host in the Kingdom"

Not any more — and this one is a live trap, because the number was reused. In CCC-1:2020, EDR was 2-3-P-1-12. Delete two sub-controls above it and everything shifts up. In CCC-2:2024, 2-3-P-1-10 is the EDR control: "Modern technologies, such as Endpoint Detection and Response (EDR) technologies…".

So a 2020-era citation of "2-3-P-1-10" and a 2024-era citation of "2-3-P-1-10" refer to two completely unrelated requirements. Put the old meaning in an audit response against the current document and you have told the assessor you are working from a superseded PDF.

3. CCC subdomain numbers are the same as ECC subdomain numbers

They are not, and this is the most common bad citation in Saudi compliance work. The CCC has no email-protection subdomain; the ECC does (ECC 2-4). From that point on, every domain-2 subdomain number is offset by one.

Verified against the control bodies of both PDFs — and you can confirm it without trusting us, because each CCC control names the ECC control it extends:

"2-12" means event-log management in the ECC and incident management in the CCC. And the CCC adds three subdomains the ECC's Defense domain does not have at all: 2-15 Key Management, 2-16 System Development Security, 2-17 Storage Media Security.

The tell is the letter. If the control number has a P or a T in it, it is a CCC control. If it does not, it is not.

4. An "NCA cloud certificate" or an "NCA-approved CSP list"

The CCC creates no certificate, no accreditation scheme, and no register of approved providers. Search the document for a certification body and the only thing you will find is 2-7-P-1-2, which is about certificate authorities in the PKI sense — issuing X.509 certificates — and has nothing to do with certifying a company.

What the document actually says about assessment is one sentence: "NCA evaluates entities' compliance with the CCC through multiple means such as self-assessments by the entities, periodic reports of the compliance tool or on-site audits" (p.10). It also says the NCA will issue a "CCC-2:2024 Assessment and Compliance Tool" — future tense, in the current document.

So: self-assessment, the NCA's tool, and NCA on-site audits. Not a certificate you buy. If a vendor is selling you "NCA CCC certification", they are selling you something the NCA has not created.

5. A compliance deadline

There is no date in the document. Not in Implementation and Compliance, not in the annexes. CCC-1:2020 said the NCA would grant a compliance period "as deemed appropriate by NCA"; CCC-2:2024 does not restate even that. Any specific deadline you have been quoted for CCC compliance was invented by whoever quoted it. The obligation is stated as continuous compliance, which is a stronger thing than a deadline anyway.

6. "Tier 1–4 providers"

The four levels are levels of data classification (Top Secret / Secret / Confidential / Public), applied to controls. They are not a provider rating. No provider is "Level 3 certified". A workload has a level; a company does not.

7. "CSTP"

The document's term for the customer is Cloud Service Tenant (CST). Not CSTP, not "cloud service subscriber". The abbreviation table (Annex C) lists exactly: CSP = Cloud Service Provider, CST = Cloud Service Tenant, CTS = Cloud Technology Stack. Note that CST and CTS are different things one letter apart, and mixing them up in a document you send to an assessor is not a good look.

8. NCA CCC and Aramco CCC are the same thing

They share an acronym and nothing else. NCA CCC = Cloud Cybersecurity Controls, a control framework from the national regulator, which you comply with. Aramco CCC = Cybersecurity Compliance Certificate, a supplier certificate under Aramco's SACS-002, which you obtain. If a procurement officer asks for "the CCC", find out which one they mean before you spend a riyal. We cover the distinction in our NCA ECC guide.

What an assessor actually asks for

You do not have to guess. The NCA publishes an implementation guide for providers — Guide to Cloud Cybersecurity Controls – Cloud Service Providers Implementation (GCCC-CSP-2:2026), Document classification: Public, TLP: Clear — and for each sub-control it lists "Control implementation guidelines" and "Expected deliverables". That "Expected deliverables" line is, in practice, the evidence list.

Quoted directly from GCCC-CSP-2:2026:

Read that list again as a tenant. Almost every provider deliverable is something you can ask your provider for today, in writing, before you sign. If the provider cannot produce the architectural design documentation for tenant isolation, or a sample incident notification, they are not ready to serve an in-scope CST — and under 1-3-T-1-1 the failure to have checked becomes your finding, not only theirs.

Tenants have a companion guide too: Guide to Cloud Cybersecurity Controls – Cloud Service Tenants Implementation (GCCC-CST-1:2023). Read it with one eye open: its version number tells you it was written against CCC-1:2020, before the localisation deletion.

Are you even in scope?

The CCC's scope (p.9) is narrower than the noise around it suggests:

In scope as a tenant (CST):

• Any government agency in the Kingdom — including ministries, authorities, establishments and other entities, and their companies and sub-entities — whether located inside or outside the Kingdom.
• All private-sector entities owning, operating or hosting Critical National Infrastructure (CNI) that use, or plan to use, any cloud service.

In scope as a provider (CSP): any CSP that provides cloud services to a tenant in the list above. The provider does not opt in or out; the customer's status pulls the provider into scope.

Explicitly outside scope (the document's own examples): CSPs serving only non-Saudi entities outside the Kingdom; and CSPs serving individuals and private-sector entities that are not CNI — provided they do not serve in-scope tenants.

Everyone else: the NCA "strongly encourages all other entities in the Kingdom to leverage these controls." Encouraged, not bound.

Two definitions worth knowing, because they decide arguments. A CSP is "any natural or legal person… who provides cloud computing services to the public, either directly or indirectly through data centers (both inside and outside the Kingdom), and manages them in whole or in part" (Annex B). The Cloud Technology Stack (CTS) is the whole layered architecture — "Data Center infrastructure, LAN, storage/compute/hyper convergence hardware, hypervisor, cloud management platform, virtual appliances, OSs, application software, O&M platforms, cloud security technologies" (Annex B). When a control says "covering the full Cloud Technology Stack", that is the scope it means.

That CSP definition is worth a second read. The NCA explicitly contemplates a provider that delivers services indirectly, through data centres it does not itself own, inside or outside the Kingdom. Reselling or building on another operator's infrastructure does not put you outside the definition — and it does not dilute your obligations one bit.

Where a hosting provider fits — and where it does not

Skyline sells cloud hosting into the Kingdom, so let us be precise about the boundary rather than vague about it.

A provider can carry the P controls. We run our in-Kingdom region — Dammam, powered by Google Cloud — and provider-side obligations such as tenant isolation, DDoS protection, vulnerability cadence, tenant-level logging, incident notification and secure data export are ours to evidence, not yours.

A provider cannot carry the T controls, and you should be suspicious of any provider that implies it can. Nobody can classify your data for you (1-2-T-1-2). Nobody can maintain your cloud risk register for you (1-2-T-1-3). Nobody can continuously monitor us on your behalf — 1-3-T-1-1 makes that literally your control. And nobody can write your exit strategy (2-6-T-1-1), because an exit strategy is a plan to leave us.

The honest summary: the CCC splits into a set we must evidence to you, and a set you must evidence to the NCA. Any vendor promising "full CCC compliance" as a product is describing something the document does not permit them to sell.

Two claims we will not make, because they need to be true and verifiable, not marketing: we do not claim to hold ISO 27001, and we do not claim to own a data centre. When we say the region is powered by Google Cloud, that is the point of the sentence, not a footnote to it.

A realistic first 90 days as a tenant

1. Establish whether you are in scope at all. Government entity, or private-sector CNI owner/operator/host? If neither, the CCC is guidance you are encouraged to use, not law that binds you. Do not spend a year complying with a document that does not apply to you.
2. Classify the data first. Everything in Annex A hangs off it, and until you know whether the workload is Level 2 or Level 4 you cannot know which controls are mandatory. Remember the mixing rule: the highest classification in the set wins.
3. Get your ECC house in order. The CCC is an extension. A CCC programme sitting on a broken ECC baseline will fail on the baseline.
4. Inventory your cloud services (2-1-T-1-1) — the real list, including the SaaS a department bought on a card.
5. Ask your provider for the deliverables listed above, by control number. Their answer, or absence of one, is your due diligence record.
6. Stand up continuous monitoring of the provider (1-3-T-1-1) — contractual reporting, incident notification paths, and a named owner. This is the control most tenants discover late.
7. Write the exit strategy (2-6-T-1-1) before you migrate, not after. It is far easier to negotiate an export path while you still have not signed.
8. Take localisation to the NDMO, not to the CCC. Post-2024, that is where the question lives.

Frequently asked questions

Is CCC-1:2020 still valid? No. CCC-2:2024 supersedes it. If your evidence pack cites CCC-1:2020 control numbers, at minimum re-check every sub-control in subdomain 2-3, where the numbering shifted.

Does the CCC require my data to stay in Saudi Arabia? The CCC does not — not since CCC-2:2024 deleted 2-3-P-1-10 and 2-3-P-1-11. Other instruments may. Refer to the NDMO at SDAIA, exactly as the NCA's change log instructs.

Do I need the ECC as well? Yes. Both, for tenants and providers alike. The document says so twice on page 10.

Is there a CCC certificate? No. Self-assessment, the NCA's compliance tool and NCA on-site audits.

What is the difference between CST and CTS? CST is the Cloud Service Tenant — you. CTS is the Cloud Technology Stack — the provider's layered infrastructure. One letter, two very different things.

We are a private company with no CNI. Are we bound? Not by the CCC's scope clause. You are "strongly encouraged" to use it, and it is a good framework, but it does not bind you.

How often must penetration testing be done? For the provider, at least once every six months, covering the Cloud Technology Stack (2-10-P-1-1). The CCC places no penetration-testing control on the tenant — your obligation there comes from ECC 2-11.

Sources

All control numbers, counts and quotations in this article were taken from these documents directly. They are published by the NCA and they — not this page — are the authority.

• NCA — Cloud Cybersecurity Controls CCC-2:2024 (PDF, Document classification: Public, TLP: White — components Fig.1 p.7; scope p.9; implementation p.10; subdomains Fig.2 p.11; coding Fig.4 p.12; controls pp.14–28; levels Annex A pp.29–33; terminology Annex B; abbreviations Annex C; change log Annex D p.43)
• NCA — Cloud Cybersecurity Controls CCC-1:2020 (PDF — superseded; CSP 37 main / 96 subcontrols; contains the deleted 2-3-P-1-10 and 2-3-P-1-11)
• NCA — Guide to Cloud Cybersecurity Controls – Cloud Service Providers Implementation, GCCC-CSP-2:2026 (PDF, Public / TLP: Clear — implementation guidelines and Expected deliverables per sub-control)
• NCA — Guide to Cloud Cybersecurity Controls – Cloud Service Tenants Implementation, GCCC-CST-1:2023 (PDF — written against CCC-1:2020)
• NCA — Essential Cybersecurity Controls ECC-2:2024 (PDF — used to verify the ECC↔CCC subdomain offset; ECC 2-12 event logs, 2-13 incident management)
• NCA — Cloud Cybersecurity Controls page (the canonical download location; always check it for a newer edition)

Last verified against the NCA's published PDFs in July 2026. Standards change. The download on nca.gov.sa is always the authority — and if this page and the PDF ever disagree, the PDF is right and we want to know.