NCA Cloud Cybersecurity Controls: who does what in the cloud

The NCA Cloud Cybersecurity Controls (CCC) address a gap that generic frameworks leave open: in cloud services, exactly who is responsible for which control. The controls are written for two audiences - the cloud service provider and the cloud tenant - so the boundary is defined by the regulator rather than negotiated in a contract.

Why a cloud-specific framework

Saudi organisations moved to cloud rapidly, and the ECC alone did not settle questions that only arise in shared-responsibility models: where data physically resides, who holds encryption keys, what happens on exit, and which party evidences which control. The CCC exists to make those answers explicit rather than assumed.

The two-sided structure

• Cloud service providers carry requirements for the platform: physical and infrastructure security, tenant isolation, availability, transparency to customers, incident notification, and support for customer obligations.
• Cloud tenants - the organisations consuming the service - carry requirements for what they put on the platform: classification, identity and access, configuration, monitoring of their own environment, and due diligence on the provider.

The recurring failure is a tenant assuming a provider's certification covers tenant-side controls. It does not. Provider assurance covers the platform; your configuration, identities and data handling remain yours to implement and evidence.

What the CCC emphasises

• Data classification driving requirements. Obligations scale with the sensitivity of what you are placing in the cloud - the more sensitive the data, the tighter the hosting, access and residency expectations.
• Data location and sovereignty. Where data is stored and processed matters, and certain categories carry in-Kingdom expectations. Include backups, replicas and support access in that analysis - these are routinely overlooked.
• Provider due diligence. Assessing and evidencing the provider's security posture, not accepting marketing claims.
• Contractual clarity. Security obligations, incident notification timelines, audit rights and data handling written into the agreement.
• Exit and portability. How you retrieve and securely delete data when the relationship ends - a control that is nearly impossible to retrofit.
• Monitoring your own tenancy. Logging and detection within the environment you control.

How it relates to the ECC

The Essential Cybersecurity Controls remain your baseline; the CCC extends them into cloud specifics. The ECC already contains a domain for third-party and cloud cybersecurity - the CCC provides the detailed expectations behind it. In practice most organisations run one control library, map both frameworks onto it, and evidence once.

Practical steps

1. Inventory your cloud estate - including SaaS acquired outside IT, which is where most surprises live.
2. Classify the data in each service; obligations follow classification.
3. Map data residency for primary storage, backups, replicas and support access paths.
4. Split the responsibility matrix per service: which controls are the provider's, which are yours, and where evidence for each comes from.
5. Review contracts for security, notification, audit rights and exit terms.
6. Automate tenant-side configuration checks - cloud drifts daily, so periodic manual review will always lag.
7. Document the exit plan before you need it.

Key takeaways

• The CCC assigns controls explicitly to providers and to tenants.
• Provider certification never covers tenant-side configuration and identity.
• Residency analysis must include backups, replicas and support access.
• Exit and deletion plans are expected - and cannot be retrofitted easily.