The NCA cybersecurity controls are not one document. Saudi Arabia’s National
Cybersecurity Authority publishes a family of control sets, each with its own scope, its own edition
and its own numbering — and picking the wrong one, or citing a superseded edition, is the most common
error in Kingdom compliance documentation.
The seven NCA cybersecurity controls, and what each covers

The Essential Cybersecurity Controls are the baseline. The others extend it into specific domains,
and several are written explicitly as extensions of the ECC rather than as replacements for it.
| Control set | Current edition | Covers |
|---|---|---|
| ECC — Essential | ECC 2-2024 | The baseline: 4 domains, 28 subdomains, 109 controls |
| CCC — Cloud | CCC-2:2024 | Cloud service providers and cloud tenants |
| CSCC — Critical Systems | CSCC-1:2019 | Systems whose failure has national impact |
| DCC — Data | DCC-1:2022 | Data cybersecurity across its lifecycle |
| OTCC — Operational Technology | OTCC-1:2022 | OT and industrial control systems |
| TCC — Telework | TCC-1:2021 | Remote and hybrid working |
| OSMACC — Social Media | OSMACC | Organisations’ social media accounts |
Always confirm the edition of any of the NCA cybersecurity controls on NCA’s own regulatory
documents pages before citing one. Two of these
have moved recently and a great deal of secondary material still quotes the old numbers.
🔴 CSCC is Critical Systems, not Cloud
This is the single most expensive confusion in NCA cybersecurity controls documentation, and the
acronyms invite it.
CSCC is the Critical Systems Cybersecurity Controls. CCC is the Cloud Cybersecurity
Controls. They are different documents with different scopes and unrelated lineages.
The cloud lineage is CCC-1:2020 → CCC-2:2024. CSCC-1:2019 remains the current
Critical Systems edition and has not been superseded. Anyone “updating” CSCC-1:2019 citations because
they look outdated next to a 2024 cloud edition is corrupting correct references — a mistake that is
very easy to make in bulk and hard to spot afterwards.
Two editions that genuinely did move
ECC-1:2018 → ECC 2-2024. The baseline changed structurally: main domain 5,
Industrial Control Systems Cybersecurity, was deleted and its controls moved to the OTCC. Our guide to
ECC 2-2024 covers what that means for existing
documentation.
CCC-1:2020 → CCC-2:2024. The cloud controls were reissued, with changes including
the treatment of data localisation. See
the Cloud Cybersecurity
Controls.
Which NCA cybersecurity controls apply to you
The ECC sets the scope for the family. Its controls apply to government agencies in the Kingdom
— ministries, authorities, establishments and others — and to their affiliated companies and entities
inside and outside the Kingdom, as well as to all private sector entities owning,
operating or hosting Critical National Infrastructure.
From that baseline, the extensions attach by activity rather than by sector:
- You use cloud services, or you are a cloud provider → CCC applies, and the
provider and tenant obligations are different. - You operate industrial control systems or OT → OTCC applies. Since ECC 2-2024 it
is the only place those controls live. - You run systems designated critical → CSCC applies on top of the ECC.
- Your people work remotely → TCC applies.
- Your organisation runs social media accounts → OSMACC applies. It is routinely
forgotten because it does not feel like a security control set.
The practical implication is that a single organisation is usually in scope for several of the NCA
cybersecurity controls at once, and its documentation has to cite them accurately rather than naming
the ECC alone.
Alignment clauses that cite the right edition.
The NCA Cybersecurity Toolkit ships 83 editable documents — 31 policies with 34 matching technical standards, plus procedures, checklists, forms and registers — citing ECC 2-2024, CCC-2:2024, CSCC-1:2019, DCC-1:2022 and OTCC-1:2022, in the policy-and-standard hierarchy the Kingdom expects.
How the NCA cybersecurity controls expect documentation to be structured
The Kingdom’s convention is a two-layer hierarchy that differs from the ISO habit of a single
policy per topic. A policy states intent and mandate; a technical
standard beneath it states the configuration that satisfies it. Access control gets a policy
and an access control standard; network security gets a policy and a network security standard.
That is why a credible NCA document set has roughly as many standards as policies, and why a pack
built only of policies looks thin to an assessor. Below both sit procedures, and beneath those the
forms and registers that produce evidence.
Documents alone are not compliance
The NCA cybersecurity controls are assessed against practice. A policy asserting that privileged access is reviewed
quarterly is worth nothing without the review records. When scoping an NCA programme, budget for the
registers and logs as seriously as for the policy set — they are what the assessment actually
examines.
Keeping citations to the NCA cybersecurity controls current
The recurring failure in Kingdom documentation is not missing controls. It is a document set that
names the right frameworks in the wrong editions — and it fails quietly, because a confident sentence
citing ECC-1:2018 looks exactly like a correct one.
Three habits prevent it.
- Keep one alignment clause, in one form. Policy sets typically carry a boilerplate
sentence naming the frameworks the document aligns to. If that sentence is written eight slightly
different ways across a document set — with different dashes, spacing and colons — then any future
find-and-replace will catch some instances and miss others, and you will ship a half-updated pack. - Record which edition each document was written to, inside the document, not in
someone’s memory. - Re-read the source when an edition moves, rather than swapping the label. ECC
2-2024 is the proof: relabelling an ICS sentence from the 2018 edition produces a statement that is
newly false, because those controls left the ECC entirely.
Where to check, and what not to trust
Read editions from NCA’s own regulatory documents pages. Two traps are worth knowing: legacy short
PDF paths on nca.gov.sa can still serve superseded editions, and search results summarising the
control sets are frequently a year or more behind. On a framework family where two of seven sets moved
recently, a cached summary is not evidence.
Compliance is measured, and the measurement is the deliverable
The NCA cybersecurity controls are assessed rather than certified, and each control is judged on
its implementation level rather than as a simple pass or fail. That changes how a programme should be
run: partial implementation is a recordable position, not a failure to hide, and a defensible
programme is one that knows exactly where it sits on every control and why.
Practically, that means maintaining a per-control record — implemented, partially implemented, not
applicable, with the justification — from the start rather than assembling it before an assessment.
The organisations that struggle are the ones reconstructing that position retrospectively across
several control sets at once.
Sequencing an NCA programme
Because several sets usually apply at once, the sequencing question — which of the NCA cybersecurity
controls to tackle first — decides how long the programme takes. The answer is almost always the ECC,
for a structural reason rather than a political one: the extensions are written as additions to the
baseline, so governance, asset management, access control and incident management built once for the
ECC are reused by every set that follows.
After the baseline, order by exposure rather than by document length. If your critical processes run
on cloud platforms, CCC comes next; if they run on plant, OTCC does. TCC and OSMACC are small enough to
absorb late, but they are also the two most often discovered mid-assessment, so put them on the plan at
the start even if the work happens at the end.
Frequently asked questions
How many NCA cybersecurity controls frameworks are there?
There are seven NCA cybersecurity controls sets: ECC, CCC, CSCC, DCC, OTCC, TCC and OSMACC, with the ECC as the baseline the others
extend.
What is the difference between CSCC and CCC?
CSCC is Critical Systems; CCC is Cloud. Different documents, different scopes, unrelated version
lineages. CSCC-1:2019 is current; the cloud set went CCC-1:2020 → CCC-2:2024.
Which edition of the ECC is current?
ECC 2-2024, which replaced ECC-1:2018 and reduced the framework from five main domains to four.
Do these apply to companies outside Saudi Arabia?
They can. The ECC scope explicitly reaches affiliated companies and entities of Saudi government
agencies both inside and outside the Kingdom.
Is there an NCA certification?
No. The NCA cybersecurity controls are mandatory for entities in scope, assessed for compliance rather than certified
the way ISO 27001 is.
Where this leaves you
Treat the NCA cybersecurity controls as a family rather than a document. Establish which of the
seven sets apply to your activities — most organisations are in scope for three or four — then confirm
each edition on NCA’s own pages rather than from a summary. Keep one consistently worded alignment
clause so a future edition change is a single reliable edit, and remember the two traps: CSCC is
Critical Systems rather than Cloud, and the ECC’s industrial control systems domain no longer exists.
Then budget for evidence. The NCA cybersecurity controls are assessed against what you actually do,
and the registers and logs take longer to accumulate than the documents take to write.
References
- NCA regulatory documents — the published control sets and guidelines.
- Essential Cybersecurity Controls (ECC 2-2024).
- Cloud Cybersecurity Controls (CCC-2:2024).
More on NCA compliance
- The NCA control sets — you are here
- ECC 2-2024 explained
- Cloud Cybersecurity Controls
- The OTCC
- NCA ECC compliance for Saudi firms
All of these are covered by the NCA Cybersecurity Toolkit, or start with the free ISO templates.