ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
The Cloud Cybersecurity Controls are Saudi Arabia’s cloud-specific control set, and
the thing most guidance gets wrong about them is that they are two obligations, not one. The CCC
places requirements on the cloud service provider and on the organisation consuming the
service, and the two lists are different.
The National Cybersecurity Authority publishes the CCC as an extension of the Essential
Cybersecurity Controls rather than a replacement for them. If you are in ECC scope and you use cloud,
you meet the ECC and the CCC — the cloud set adds to the baseline, it does not substitute for it.
The current edition is CCC-2:2024, which replaced CCC-1:2020. That matters more
than a version bump usually would, because a great deal of secondary material — and NCA’s own legacy
short PDF path — still serves the 2020 edition. Read the version off NCA’s regulatory documents pages
rather than from a search result or a cached file.
The Cloud Cybersecurity Controls distinguish between:
Each carries its own controls. A tenant cannot discharge its obligations by pointing at its
provider’s compliance, and a provider’s attestation covers the provider’s controls, not the tenant’s
configuration of them. This is the same shared-responsibility logic familiar from other cloud
frameworks, expressed as two explicit control sets.
The practical consequence: if you are a tenant, your first task is not implementing controls. It is
establishing which controls are yours — and getting that split in writing from the provider.
Splitting the Cloud Cybersecurity Controls between the two parties is the first thing to establish
and the thing most often left vague. Broadly:
| Area | Typically the provider (CSP) | Typically the tenant (CST) |
|---|---|---|
| Physical and platform | Data centres, hypervisor, platform hardening | — |
| Identity and access | The IAM service itself | Your users, roles, privileges and reviews |
| Data | Encryption capability, storage durability | Classification, key management, retention |
| Configuration | Secure defaults where offered | What you actually deployed |
| Monitoring | Platform logging availability | Enabling, collecting and reviewing it |
| Exit | Data return and secure deletion | Requiring both in the contract |
This table is a starting point for the conversation, not a substitute for it. The real split depends
on the service model — the tenant’s share grows considerably from SaaS to PaaS to IaaS — and it should
be written down per service, agreed with the provider, and reviewed when you adopt a new one.
Data residency is the question every organisation asks first about cloud in the Kingdom, and the
answer moved with CCC-2:2024. The 2024 edition’s update annex records the deletion of a subcontrol
covering the provision of cloud services from within the Kingdom — including hosting, processing and
disaster recovery centres — noting that data-localisation requirements have been transferred
elsewhere.
That is a genuine change in where the obligation lives, not a relaxation of it, and it is exactly
the kind of movement that a document set written against CCC-1:2020 will describe incorrectly. If your
cloud policy quotes a localisation control by number, check that the number still exists and still
says what you think.
Localisation obligations in the Kingdom also arrive from outside the CCC — sectoral regulators and
data protection rules carry their own requirements. Treat the CCC as one input, not the whole answer.
Cloud policy and standard, citing CCC-2:2024.
The NCA Cybersecurity Toolkit ships 83 editable documents including a Cloud Computing and Hosting Cybersecurity policy, a third-party cybersecurity policy, and the data protection, cryptography and access control standards a cloud tenant is assessed on — with alignment clauses citing ECC 2-2024, CCC-2:2024, CSCC-1:2019, DCC-1:2022 and OTCC-1:2022.
The most common failure in cloud compliance anywhere is assuming a provider’s attestation covers
everything running on their platform. It covers the services and regions named in it, operated as
specified. Your identity configuration, your storage permissions, your key management and your
monitoring remain yours.
Ask providers three specific questions about the Cloud Cybersecurity Controls: which services are in scope of their attestation, which
regions, and what they expect the tenant to do. A provider that cannot answer the third question
clearly is a provider whose shared-responsibility model you will end up writing yourself.
Two providers is not twice the work; it is twice the work plus the reconciliation. Each carries a
different shared-responsibility boundary, a different set of native controls and a different logging
model. A tenant control that is satisfied by a platform feature on one provider may need building on
another.
The workable approach is to hold your obligations in one place — a single register of the Cloud
Cybersecurity Controls
that are yours, with a column per provider showing how each is met. That keeps the assessment
conversation about your controls rather than about the platforms, and it makes adding a third provider
an extension rather than a rewrite.
It also exposes the gap nobody looks for: a control satisfied on your primary platform and quietly
unmet on the one holding a single workload somebody stood up eighteen months ago.
How much of the Cloud Cybersecurity Controls falls to you depends heavily on what you have bought,
and the gradient is steep.
With SaaS, the provider operates most of the stack; your obligations concentrate on
identity, access, data classification, retention and the contract. With PaaS you add
application security, secrets handling and much of the logging configuration. With
IaaS you own nearly everything above the hypervisor — patching, hardening, network
controls, backup — and the provider’s share shrinks to the platform itself.
An organisation running all three, which is common, has three different boundaries to document.
Writing one cloud policy that assumes a single split is how tenant controls get missed on whichever
model was not front of mind when it was drafted.
What are the Cloud Cybersecurity Controls?
NCA’s cloud-specific control set, published as an extension of the ECC, placing distinct obligations
on cloud service providers and on cloud service tenants.
Which edition of the Cloud Cybersecurity Controls is current?
CCC-2:2024, which replaced CCC-1:2020. Confirm on NCA’s regulatory documents pages, because older
copies of the 2020 edition remain in wide circulation.
Do the CCC replace the ECC for cloud workloads?
No. The CCC extends the ECC. An organisation in ECC scope using cloud services meets both.
Does using a compliant provider make us compliant?
No. Tenant controls are yours regardless of the provider’s status, and the split should be documented
between you.
Must data stay inside the Kingdom?
Localisation requirements exist but the CCC-2:2024 update annex records that a localisation subcontrol
was removed from the CCC and the requirements transferred elsewhere. Check the current position across
the CCC, sectoral rules and data protection law rather than relying on a single clause.
The Cloud Cybersecurity Controls extend the ECC rather than replacing it, and they split
obligations between the provider and you. Confirm you are on CCC-2:2024 rather than the 2020 edition,
classify the data before designing the architecture, get the responsibility split written down per
service, and cover exit as deliberately as entry.
Above all, resist the assumption that a compliant provider makes you compliant. Your identity
configuration, your key management, your storage permissions and your monitoring remain yours under
the Cloud Cybersecurity Controls no matter whose platform they run on.
All of these are covered by the NCA Cybersecurity Toolkit, or start with the free ISO templates.
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026