NCA CCC Compliance Checklist (Free Template)

The Cloud Cybersecurity Controls are the hardest NCA control set to turn into a checklist, because there isn't one list — there are two. CCC-2:2024 contains a Cloud Service Provider control set and a Cloud Service Tenant control set, and which applies depends on which side of the contract you sit. Organisations that both consume cloud and sell a SaaS product to Saudi government customers are on both.

This is the structured NCA CCC compliance checklist, organised by the framework's four domains with the provider and tenant split held throughout. A downloadable working copy is available at the end.

Before you start: two scoping decisions

Which population are you in?

Role	In scope if…	Controls
Cloud Service Tenant (T)	You are a Saudi government agency (or affiliate, inside or outside the Kingdom), or a private entity owning, operating or hosting CNI — and you use or plan to use cloud.	18 main · 26 sub
Cloud Service Provider (P)	You provide cloud services to any in-scope tenant — regardless of where you are incorporated or where your data centres sit.	37 main · 94 sub

What is the data classified as? Controls are tiered across four levels — Level 1 (Top Secret), Level 2 (Secret), Level 3 (Confidential), Level 4 (Public) — with each subdomain marked mandatory or optional at each level. Where an integrated data set spans classifications, the highest classification applies to the whole set.

How to use this checklist

1. Mark the current state — compliant, partially compliant, or non-compliant.
2. Tag every line P or T so ownership is unambiguous.
3. For every P control you depend on, name the evidence you will request from the provider and how often.
4. Note the evidence reference and the assessment date.
5. Identify the gap and the action required to close it.

Domain 1 — Cybersecurity Governance

1-1 Cybersecurity roles and responsibilities. Roles and RACI assignment documented and approved for all cloud stakeholders, including the Authorizing Official. Required of both P and T.

1-2 Cybersecurity risk management. Acceptable risk levels defined for the cloud service and communicated to the tenant where relevant. Data classification factored into the risk methodology. A cloud-specific risk register maintained and monitored.

1-3 Compliance with cybersecurity standards, laws and regulations. Applicable requirements identified and tracked for the cloud environment specifically.

1-4 Cybersecurity in human resources. Screening or vetting of personnel with access to the Cloud Technology Stack, repeated periodically. Cybersecurity policies signed as a precondition of access. Assets returned on termination. Provider-side: cybersecurity positions in the CSP's in-Kingdom data centres must be filled with qualified and suitable Saudi nationals.

1-5 Cybersecurity in change management. Change control covering the cloud environment, with cybersecurity requirements embedded.

Domain 2 — Cybersecurity Defence

Seventeen of the twenty-four subdomains sit here. Three have no standalone ECC equivalent and are where ECC-mature organisations find genuine gaps — they are marked below.

2-1 Asset management. Inventory of cloud assets with owners, kept current.

2-2 Identity and access management. Least privilege, MFA, privileged access controls, periodic review of cloud identities.

2-3 Information system and processing facilities protection. Hardening, patching and configuration baselines for cloud workloads.

2-4 Networks security management. Segmentation, perimeter controls and traffic restriction within the cloud environment.

2-5 Mobile devices security. Controls for devices accessing cloud services.

2-6 Data and information protection. Protection applied by classification level, with return of data in a usable format on service completion.

2-7 Cryptography. Aligned to the National Cryptographic Standards, with the strength level chosen on data sensitivity.

2-8 Backup and recovery management. Backup scope, frequency and restoration testing for cloud-hosted data.

2-9 Vulnerabilities management. Scanning and remediation SLAs covering the cloud estate.

2-10 Penetration testing. Cloud environment in scope, by a qualified team.

2-11 Cybersecurity event logs and monitoring management. Log collection, retention and monitoring across cloud services.

2-12 Cybersecurity incident and threat management. Incident handling covering cloud events, with provider notification obligations defined contractually.

2-13 Physical security. Data centre physical controls — largely a provider obligation the tenant must evidence.

2-14 Web application security. Secure standards for cloud-hosted applications.

2-15 Key management. No standalone ECC equivalent. Key generation, storage, rotation, escrow and destruction across the cloud service, with the tenant's control over its own keys made explicit.

2-16 System development security. No standalone ECC equivalent. Security across any application, platform, middleware, OS, hypervisor or network stack forming part of the Cloud Technology Stack.

2-17 Storage media security. No standalone ECC equivalent. Handling, sanitisation and disposal of storage media in the cloud environment.

Domain 3 — Cybersecurity Resilience

3-1 Cybersecurity resilience aspects of BCM. Cloud services covered by the continuity programme, with recovery objectives that account for provider dependencies and the tenant's own obligations.

Domain 4 — Third-Party Cybersecurity

4-1 Supply chain and third-party cybersecurity. The provider's own supply chain assessed and controlled; for tenants, the provider itself assessed and monitored as a third party, with evidence requested on a schedule rather than assumed.

Reading the control numbering

CCC identifiers carry the audience in the code. 1-3-P-1-1 is a provider control; 1-3-T-1-1 is the tenant equivalent. The tiers run: main domain, subdomain, P/T, main control, subcontrol. Numbers appearing in green inside the control text are cross-references to ECC subdomains or controls.

Build the P/T flag into the control library from the start. Teams that import the CCC as a flat list either assess themselves against provider controls they will never own, or assume a provider control is covered without ever asking for the evidence.

Data localisation — read this before you scope

If your CSP assurance file still maps an in-Kingdom hosting attestation to 2-3-P-1-10, that mapping is stale. The attestation may remain commercially useful; it no longer satisfies a live CCC control.

How the NCA assesses compliance

Through self-assessment, periodic reports from the compliance tool, and on-site audits. The NCA publishes a CCC-2:2024 Assessment and Compliance Tool to structure the exercise. Both parties are separately assessable — a tenant cannot satisfy the T controls by producing the provider's certification.

Get the downloadable checklist

The full checklist — a working spreadsheet with the P/T split, the four classification levels as columns, and state, owner, evidence reference and target date fields — is available on request. Contact us to receive a copy.

For the framework in depth, read NCA CCC: Cloud Cybersecurity Controls explained. For the wider family, see the NCA frameworks complete list, and for the baseline beneath it the NCA ECC 2:2024 checklist.