A Saudi government body or critical infrastructure operator that moves workloads to the cloud does not leave the National Cybersecurity Authority's controls behind: the Cloud Cybersecurity Controls (CCC) split the duties between the cloud provider and the tenant, and both must comply. CCC-2:2024 supersedes CCC-1:2020 and sits on top of the Essential Cybersecurity Controls (ECC), adding cloud-specific requirements for cloud service providers (CSPs) and cloud service tenants (CSTs). This guide explains who is in scope, how the four classification levels change what applies, which controls matter most for identity, keys and logging, and how to prepare evidence for NCA assessment. It is for security and compliance leads at Saudi public bodies and CNI operators, and at providers serving them. The baseline is covered in the Saudi NCA Essential Cybersecurity Controls Guide; this page covers only what the CCC adds.
Key takeaways
- Two audiences, one document. Each CCC control is numbered for either the provider (P) or the tenant (T), for example 2-2-P-1-3 for provider MFA and 2-2-T-1-4 for tenant MFA.
- The provider carries most of the load. CSPs have 37 main controls and 94 subcontrols; CSTs have 18 main controls and 26 subcontrols, across 4 domains and 24 subdomains.
- Data classification sets the bar. Controls are tiered into Level 1 (Top Secret) to Level 4 (Public), and a data set mixing classifications takes the highest level.
- ECC still applies. In-scope CSPs and CSTs must comply with both ECC and CCC, whether or not they were otherwise in ECC scope.
- Localisation moved out of the CCC. CCC-2:2024 deleted the old in-Kingdom provision subcontrols and refers entities to the National Data Management Office (NDMO) at SDAIA for data localisation.
What it is and who it applies to
The CCC is an NCA control set that extends the ECC to cloud computing, setting minimum requirements for both sides of a cloud relationship. Entities must take the measures needed for continuous compliance, citing Article 10(3) of the NCA's mandate and Royal Decree No. 57231. The Arabic text is the binding version.
| Party | In scope | Out of scope examples given by the NCA |
|---|---|---|
| Cloud service tenant (CST) | Saudi government organisations inside or outside the Kingdom (ministries, authorities, establishments), their companies and entities, and private sector organisations owning, operating or hosting critical national infrastructure, when they use or plan to use cloud services | Other organisations, which the NCA encourages to adopt the controls voluntarily |
| Cloud service provider (CSP) | Any CSP providing cloud services to in-scope CSTs | CSPs serving only non-Saudi entities outside the Kingdom, or only individuals and private entities that do not own, operate or host CNI |
The practical trigger for a provider is therefore its customer list: once one in-scope tenant signs, the CSP's controls apply to the services delivered to that tenant. For a tenant the trigger is its own status as government, government affiliate or CNI operator.
Structure and key requirements
CCC-2:2024 keeps the ECC domain structure. Control references follow Domain-Subdomain-P/T-Control-Subcontrol, and green references in the document point to the related ECC control.
| Domain | Subdomains |
|---|---|
| 1 Cybersecurity Governance | 1-1 Roles and Responsibilities; 1-2 Risk Management; 1-3 Compliance with Standards, Laws and Regulations; 1-4 Cybersecurity in Human Resources; 1-5 Cybersecurity in Change Management |
| 2 Cybersecurity Defence | 2-1 Asset Management; 2-2 Identity and Access Management; 2-3 Information System and Processing Facilities Protection; 2-4 Networks Security Management; 2-5 Mobile Devices Security; 2-6 Data and Information Protection; 2-7 Cryptography; 2-8 Backup and Recovery Management; 2-9 Vulnerabilities Management; 2-10 Penetration Testing; 2-11 Event Logs and Monitoring Management; 2-12 Incident and Threat Management; 2-13 Physical Security; 2-14 Web Application Security; 2-15 Key Management; 2-16 System Development Security; 2-17 Storage Media Security |
| 3 Cybersecurity Resilience | 3-1 Cybersecurity Resilience Aspects of Business Continuity Management |
| 4 Third-Party Cybersecurity | 4-1 Supply Chain and Third-Party Cybersecurity |
Levels and applicability
Annex A tables 2 (CSP) and 3 (CST) mark each subcontrol as mandatory or optional at each level, with footnotes for exceptions; some incident subcontrols such as 2-12-P-1-2, 2-12-P-1-3 and 2-12-P-1-8 are optional at certain levels. Map every cloud service to the classification of the data it holds before deciding which controls apply.
Controls that change day-to-day operations
| Area | Provider control | Tenant control |
|---|---|---|
| Tenant isolation | 2-3-P-1-2 separate data, environments and systems between tenants; 2-3-P-1-9 isolate community cloud for government and CNI from out-of-scope customers | 2-3-T-1-1 verify that isolation of community cloud services |
| Data protection and exit | 2-6-P-1-1 no stack data outside production without controls such as masking; 2-6-P-1-3 secure disposal of tenant data at contract end; 2-6-P-1-5 secure export of data and virtual infrastructure | 2-6-T-1-1 exit strategy with secure disposal; 2-6-T-1-2 secure export |
| Cryptography | 2-7-P-1-1 strong encryption at the advanced level of the National Cryptographic Standards (NCS-1:2020); 2-7-P-1-2 certificates from a trusted or secure self-operated certification authority | 2-7-T-1-1 same NCS advanced level; 2-7-T-1-2 encrypt data moving into or out of the cloud |
| Vulnerability and testing | 2-9-P-1-1 assessments at least monthly for external and every three months for internal components; 2-10-P-1-1 penetration testing at least every six months | 2-9-T-1-1 assessments at least every three months |
| Logging and monitoring | 2-11-P-1-1 enable and protect logs across the cloud technology stack; 2-11-P-1-5 continuous SIEM monitoring of the full stack; 2-11-P-1-7 automated monitoring of remote access sessions | 2-11-T-1-1 collect login and security logs for cloud assets; 2-11-T-1-2 monitor all enabled logs |
| Incidents | 2-12-P-1-6 real-time reporting to the tenant of incidents that may affect it; 2-12-P-1-5 forensic support preserving chain of custody | No 2-12 tenant subcontrols; tenant ECC incident controls apply |
| Supply chain | 4-1-P-1-1 remove marketplace software or services when the NCA requests; 4-1-P-1-2 security documentation from suppliers | 1-3-T-1-1 continuously monitor the provider's compliance with legislation and contract clauses |
Identity and NHI requirements
Subdomain 2-2 is where the CCC is most specific, and most of it applies to machine identities as much as people.
- Generic accounts (2-2-P-1-1): providers must manage generic account credentials so accountability is preserved and they are not tied to one named person. Shared service accounts on the provider's stack need vaulting, check-out and session attribution.
- MFA for privileged users: 2-2-P-1-3 for provider privileged users and staff with access to the cloud technology stack; 2-2-P-1-11 requires providers to offer MFA to tenants; 2-2-T-1-4 requires tenants to use it for privileged cloud users. Automation that cannot do MFA should use short-lived, federated credentials rather than exemptions.
- Full credential lifecycle (2-2-T-1-1): tenants manage identity and access for all cloud credentials, which includes access keys, service principals, API tokens and workload identities, from creation to revocation. See the Cloud Workload Identity Guide.
- Confidential credentials (2-2-T-1-2): keep user IDs, credentials and access rights confidential, which in practice means secrets out of code and configuration. See the Secrets Management Guide.
- Provider access to tenant assets (2-2-P-1-9): the provider or its third parties need the tenant's approval before accessing any tenant-related asset, and 2-2-P-1-10 requires the ability to end a remote session immediately and block future access.
- Password storage (2-2-P-1-5) and brute force detection (2-2-P-1-4, 2-2-T-1-5): secure hashing and failed-login thresholds.
- Key ownership (2-15): both sides must define cryptographic key ownership and a secure recovery mechanism, for example key backups held strictly outside the cloud; providers must also activate and monitor key audit trails (2-15-P-3-3). See the BYOK, HYOK and External Key Management Guide.
The CCC does not name service accounts or API keys explicitly, but the tenant duty covers "all cloud credentials", so an assessor will expect a machine credential inventory with owners.
Implementation steps
- Confirm scope. Tenants record their legal status; providers list in-scope tenants and the services they consume.
- Classify and assign levels. Map each workload to Level 1 to 4 from the data it holds, applying the highest level to mixed data sets, then derive the mandatory subcontrols from Annex A.
- Build a responsibility matrix. Split each P and T control and the related ECC controls between provider and tenant teams, with contract clauses where the tenant depends on the provider. The Shared Responsibility Matrix Template is a starting point.
- Close identity gaps first. Inventory human and machine cloud credentials, enforce privileged MFA, remove long-lived keys where federation exists, and set up approval workflow for provider access.
- Set key management and encryption. Align algorithms to NCS-1:2020 advanced level, document key ownership and recovery outside the cloud, and log key use.
- Wire logs and incident reporting. Providers run SIEM over the stack and agree the real-time incident reporting channel with each tenant; tenants ingest login and security logs.
- Plan exit. Tenants write the exit strategy with secure disposal and export; providers document their disposal process. The Cloud Exit Plan Template helps.
- Self-assess and remediate. Run the NCA self-assessment, track gaps in the cloud risk register (1-2-P-1-3, 1-2-T-1-3) and retest.
Decision guidance. A small tenant using one software service at Level 4 can often meet its tenant controls through configuration and contract: privileged MFA, credential lifecycle, log collection, exit strategy and provider monitoring. A large ministry or CNI operator running Level 2 or Level 3 workloads across several providers needs a central cloud control team, one credential inventory spanning every provider, and a key management model that keeps recovery material outside each cloud. Providers face the opposite choice: serve in-scope tenants from a dedicated community cloud region that meets 2-3-P-1-9 isolation, or apply CCC controls across a shared platform. The first narrows audit scope; the second avoids running two operating models. Whichever route is chosen, document the reasoning in the risk register so the assessor sees a decision, not an accident.
Evidence and assessment
The NCA evaluates compliance through self-assessment, periodic reports through its compliance tool, and on-site audits, and says it will issue a CCC-2:2024 Assessment and Compliance Tool. The document itself sets no deadline, so follow any timetable the NCA communicates to your sector.
| Control area | Evidence an assessor will ask for |
|---|---|
| Scope and levels | Legal status record, service inventory with classification level per service, Annex A applicability list |
| Identity (2-2) | MFA enforcement reports for privileged users, credential inventory including machine credentials with owners, provider access approval records, session termination test |
| Cryptography and keys (2-7, 2-15) | Algorithm and certificate inventory against NCS-1:2020, key ownership register, key recovery test, key audit logs |
| Vulnerability and testing (2-9, 2-10) | Monthly, quarterly and six-monthly scan and test reports with remediation tickets |
| Logging and incidents (2-11, 2-12) | SIEM coverage map, log protection settings, incident reports to tenants with timestamps, root cause analyses |
| Exit and third parties (2-6, 4-1) | Exit strategy, disposal certificates, supplier security documentation, compliance monitoring of the provider |
Measure progress with a small set of indicators: percentage of privileged cloud users with MFA, percentage of machine credentials with a named owner and rotation date, age of the oldest open high-severity vulnerability against the monthly and quarterly cycles, SIEM log source coverage of the stack, and time from provider incident detection to tenant notification.
Mapping to other frameworks
| CCC area | Related ECC subdomain | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|---|
| 2-2 Identity and Access Management | ECC identity and access management | AC-2, AC-6, IA-2, IA-5 | PR.AA-01 |
| 2-3 Tenant isolation | ECC information system protection | SC-7, AC-4 | PR.DS-01 |
| 2-6 Data protection and exit | ECC data and information protection | MP-6, SC-28 | PR.DS-01 |
| 2-7 Cryptography, 2-15 Key Management | ECC cryptography | SC-8, SC-12, SC-13, SC-17 | PR.DS-02 |
| 2-9 Vulnerabilities, 2-10 Penetration Testing | ECC vulnerability management and penetration testing | RA-5, CA-8 | DE.CM-01 |
| 2-11 Logs, 2-12 Incidents | ECC event logs and incident management | AU-2, AU-9, IR-4, IR-6 | RS.CO-02 |
| 4-1 Supply chain | ECC third-party and cloud cybersecurity | SA-9, SR-6 | GV.SC-07 |
Providers that already hold cloud assurance certifications can reuse much of that evidence, but the CCC adds Saudi-specific elements: NCS-1:2020 cryptography, community cloud isolation for government and CNI, NCA marketplace removal requests and the classification levels. The Cloud Security Alliance CCM and STAR Guide covers the common cloud control matrix used for that reuse.
Common pitfalls
- Tenant assumes the provider's compliance covers it: the tenant has its own 26 subcontrols plus ECC, and 1-3-T-1-1 requires it to monitor the provider continuously.
- Machine credentials missing from the inventory: privileged MFA reports look clean because service principals and access keys are not counted as "cloud credentials".
- Keys recoverable only inside the cloud: 2-15 expects key backups and trusted storage strictly outside the cloud; a provider-only key store fails that test.
- Outdated localisation assumptions: teams still cite the deleted CCC-1:2020 in-Kingdom subcontrols instead of checking current NDMO requirements.
- Wrong level applied: a mixed data set is assessed at the level of its majority data rather than the highest classification present.
- No real-time incident channel: the contract is silent on how the provider meets 2-12-P-1-6, so notifications arrive by email days later.
Practitioner checklist
- Record CCC scope: tenant legal status or provider's in-scope tenant list.
- Assign a classification level to every cloud service and derive Annex A applicability.
- Maintain a P and T responsibility matrix linked to ECC controls and contract clauses.
- Inventory all cloud credentials, human and machine, with owners and rotation dates.
- Enforce MFA for privileged cloud users and approval for provider access to tenant assets.
- Align encryption to NCS-1:2020 advanced level and test key recovery outside the cloud.
- Meet the scan cadence: monthly external, quarterly internal, six-monthly penetration tests for providers.
- Agree and test the real-time incident reporting channel between provider and tenant.
- Write and test the exit strategy, including secure disposal and export.
- Check NDMO requirements for data localisation rather than the deleted CCC-1:2020 clauses.
Standards and references
- National Cybersecurity Authority: Cloud Cybersecurity Controls (CCC-2:2024)
- National Cybersecurity Authority: Essential Cybersecurity Controls (ECC-2:2024)
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- Cloud Security Alliance: Cloud Controls Matrix
- National Cybersecurity Authority: Official website
Related NHI Mgmt Group resources: Saudi NCA Essential Cybersecurity Controls Guide · Saudi Arabia PDPL Guide · Cloud Security Guide · Global Cybersecurity Regulatory Map. This guide summarises the NCA Cloud Cybersecurity Controls and is not legal advice.