NCA ECC: The Definitive Guide to ECC-2:2024 (Every Control, From the PDF)

Most of what is written about the NCA's Essential Cybersecurity Controls in 2026 is out of date, and the people writing it do not know that.

Search for "NCA ECC" and you will be told, confidently, that the ECC has 5 main domains, 29 subdomains and 114 controls. That was true. It was true of ECC-1:2018. It has not been true since the NCA published ECC-2:2024, which deleted an entire main domain, moved data-localisation out of the document altogether, and re-cut the control counts.

This guide is written against the PDF itself — ECC-2:2024, published by the National Cybersecurity Authority, Document Classification: Public, TLP: White — with ECC-1:2018 open beside it for comparison. Every control number, every count and every quoted requirement below comes from that document. Where the ECC is silent, this guide says so plainly, because the single most expensive mistake in Saudi compliance work is attributing a requirement to the NCA that the NCA never wrote.

The 60-second answer

• The current version is ECC-2:2024. It supersedes ECC-1:2018.
• ECC-2:2024 consists of 4 main domains, 28 subdomains, 108 main controls and 92 subcontrols (ECC-2, Introduction, p.7).
• ECC-1:2018 consisted of 5 main domains, 29 subdomains and 114 controls (ECC-1, Introduction). If a vendor quotes you 114, they are quoting a superseded document.
• Main domain 5 (Industrial Control Systems Cybersecurity) was deleted. Its controls moved to the OTCC — the Operational Technology Cybersecurity Controls (ECC-2, Appendix C).
• It applies to government agencies and to private-sector entities that own, operate or host Critical National Infrastructure (CNI). Everyone else is "strongly encouraged" (ECC-2, p.9).
• There is no ECC certificate, no accredited-auditor scheme, and — importantly — no compliance deadline stated anywhere in the document.

What ECC-2:2024 actually contains

The four main domains, and the number of subdomains under each, are set out in Figure 2 of the standard (p.11):

Ten plus fifteen plus one plus two is twenty-eight. That is the arithmetic behind the NCA's own figure, and you can check it in the same way we did.

The control code itself is read left to right (ECC-2, Figures 3 and 4, p.12). In 2-3-2-6: 2 = main domain, 3 = subdomain, 2 = main control, 6 = subcontrol. There is no letter, no prefix, no year embedded in the control number. That matters more than it sounds — see the renumbering trap below.

The Cybersecurity Defense subdomains, in the right order

This is the section that gets misquoted most often, and it is the section engineers actually build against. Straight from Figure 2 (p.11):

Commit those four bolded rows to memory. A very large amount of published Saudi "compliance content" — including, until recently, some of ours, which is why this guide has been rewritten from the source — cites 2-10 for log management and 2-11 for incident response. Both are wrong, in both ECC-1:2018 and ECC-2:2024. In both versions, 2-10 is vulnerabilities and 2-11 is penetration testing. Logging is 2-12. Incident management is 2-13.

If your SIEM design document, your board pack or your consultant's gap assessment cites "ECC 2-10" for log retention, it was not written from the standard.

The renumbering trap: ECC ≠ CSCC ≠ CCC

The NCA's other control sets are extensions of the ECC — compliance with the ECC is a prerequisite for them — but they do not inherit the ECC's subdomain numbers. Each document renumbers from scratch. This single fact causes more bad citations than anything else in Saudi compliance work.

Verified against the control bodies of each PDF:

Read that table twice. "2-12" means log management in the ECC, web application security in the CSCC, and incident management in the CCC. Three different standards, one control number, three completely different meanings. Cite the wrong one in an audit response and you have told the assessor, in writing, that you have not read the standard.

Two further notes, both verifiable:

• CSCC-1:2019 has no incident-management subdomain of its own. Its Cybersecurity Defense domain runs 2-1 to 2-13 and stops at Application Security. That is not an omission — the requirement still binds you, via ECC 2-13, because ECC compliance is a prerequisite for the CSCC (CSCC, p.12).
• The CCC uses a different code shape entirely. Its controls carry a P (Cloud Service Provider) or T (Cloud Service Tenant) infix — for example 1-4-P-1-1 and 1-1-T-1. If a control number has a letter in it, it is not an ECC control.

The one number in the entire document

Here is a finding worth the price of the whole guide, and it is the opposite of what most compliance marketing implies.

In the entire control body of ECC-2:2024, there is exactly one explicit numeric time threshold:

2-12-3-5 — "Retention period of cybersecurity event logs (shall be at least 12 months)."

That is it. One number. Every other periodicity in all 108 main controls is expressed as "periodically" — periodic review, periodic audit, periodic penetration testing. The NCA does not state how often you must pen-test. It does not state how often you must audit. It does not state a maximum time to detect, a maximum time to respond, or a deadline for reporting an incident to the NCA.

Control 2-13-3-3 requires "Reporting cybersecurity incidents to the NCA." It attaches no timeframe. Not four hours, not 24, not 72. The document simply does not say.

This is not a loophole and it is not an excuse to do nothing. It is a design choice: the NCA sets requirements, not service levels. The frequency you choose must be defensible against your own risk assessment — and that is what an assessor probes. But you should know, when a vendor tells you "the NCA requires mean-time-to-detect under 15 minutes," that they have invented it. It is not in the standard. Ask them for the control number and watch what happens.

The only place a stricter, real number appears is in the CSCC, for critical systems:

CSCC 2-11-2 — "With reference to ECC subcontrol 2-12-3-5, retention period of cybersecurity's critical systems event logs must be 18 months minimum."

So: 12 months under the ECC, 18 months if the system is a critical system under the CSCC. Both are quotable. Both are real.

What changed from ECC-1:2018 → ECC-2:2024

Appendix C of ECC-2 is a formal change log, and it is the most useful three pages the NCA has published. The changes that actually alter engineering and hiring decisions:

Main domain 5 was deleted. ICS/OT cybersecurity is no longer in the ECC. Appendix C states the controls "moved to the OTCC (Operational Technology Cybersecurity Controls)." If you run plants, refineries, utilities or manufacturing lines, your OT obligations did not disappear — they moved to a different document, and you now have to comply with two.

Sub-control 4-2-3-3 was deleted — the data-localisation rule. In ECC-1:2018, 4-2-3-3 read: "Entity's information hosting and storage must be inside the Kingdom of Saudi Arabia." In ECC-2:2024 that sub-control no longer exists. Appendix C explains why: "Controls related to data localization have been transferred from the document to the National Data Management Office (NDMO) at the Saudi Data and Artificial Intelligence Authority."

Be very careful how you read that, because it is easy to get backwards. It does not mean data residency stopped mattering in Saudi Arabia. It means the mandate now sits with NDMO/SDAIA rather than inside the ECC — and it continues to bind you through the PDPL, through NDMO's own rules, and through sector regulators. What it does mean is this: anyone who tells you "ECC control 4-2-3-3 requires you to host in the Kingdom" is citing a control that has been withdrawn. The obligation is real. That citation is not.

Control 2-7-3 (data privacy) was likewise deleted and referred to NDMO.

Control 1-2-2 was broadened — and this one has payroll consequences. ECC-1 required that the head of the cybersecurity function (e.g. CISO) and "related supervisory and critical positions" be filled by full-time, experienced Saudi cybersecurity professionals. ECC-2:2024 now reads:

1-2-2 — "All cybersecurity positions shall be filled out with full-time and qualified Saudi cybersecurity professionals."

Not the head. Not the supervisors. All cybersecurity positions. If you are planning an in-house SOC, this is the control that shapes your hiring plan before you have bought a single licence.

Sub-control 2-4-3-5 was tightened. ECC-1 asked for validation of the entity's email domains "(e.g. using Sender Policy Framework (SPF))." ECC-2 now requires validation "by using Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM), and Domain Message Authentication Reporting and Conformance (DMARC)." SPF alone is no longer sufficient. If you have never published a DMARC record, that is now a named gap — our walkthrough on SPF, DKIM and DMARC covers the mechanics.

Sub-control 2-5-3-9 was added: "Protecting against Distributed Denial of Service (DDoS) attacks to limit risks arising from these attacks." New in ECC-2.

Control 2-8-3 was rewritten to require, at minimum, "the requirements in the National Cryptographic Standards, published by NCA," with the appropriate standard level chosen according to data sensitivity and your risk assessment. ECC-1's generic "approved cryptographic standards" language is gone; there is now a named NCA document you are expected to implement against.

Control 1-7-1 was deleted ("The entity must comply with related national cybersecurity laws and regulations"), and 1-7-2 was rewritten to bite only where nationally-approved international agreements impose cybersecurity requirements.

Scope was widened. ECC-2 applies to government agencies and "their affiliated companies and entities (inside and outside the kingdom)" — the parenthetical is new.

Several MFA sub-controls (2-2-3-2, 2-4-3-2, 2-15-3-5) were rewritten away from a blunt "use MFA" toward defining "the suitable authentication factors and their numbers as well as the suitable authentication techniques based on the result of impact assessment of authentication failure and bypass." In other words: justify your authentication design with an impact assessment. Turning on MFA everywhere and calling it done is no longer the shape of the answer.

CCC means two different things. Do not confuse them.

This trips up suppliers in the Eastern Province constantly, and the two documents have nothing to do with each other:

• NCA CCC = Cloud Cybersecurity Controls. A control framework. The current edition is CCC-2:2024, which supersedes CCC-1:2020. It has 4 main domains and 24 subdomains, with separate control sets for providers and tenants: 37 main controls / 94 subcontrols for CSPs, and 18 main controls / 26 subcontrols for CSTs (CCC-2:2024, Figure 1). You comply with it. Full breakdown in our NCA CCC guide — including the two data-residency sub-controls CCC-2:2024 deleted.
• Aramco CCC = Cybersecurity Compliance Certificate. A certificate, issued by an Aramco-authorised audit firm, proving you meet Aramco's SACS-002 standard. You obtain it. We cover it separately in our SACS-002 guide.

One is a framework from the national regulator. The other is a supplier certificate from an oil company. If a procurement officer asks for "the CCC," find out which one they mean before you spend a riyal.

How the NCA actually assesses you

There is no ECC certificate. There is no NCA-accredited auditor list of the kind Aramco maintains. What the standard says (ECC-2, p.9) is that the NCA evaluates compliance "through multiple means, such as self-assessment by the entities, periodic reports of the compliance tool, and/or field auditing visits, in accordance with the mechanism deemed appropriate by the NCA." The NCA also states it will issue an ECC-2:2024 Assessment and Compliance Tool to organise that measurement.

Compliance is anchored in Article 10(3) of the NCA's Statute and High Order No. 57231, dated 10/11/1439H, under which in-scope entities "shall take all necessary measures to ensure ongoing and continuous compliance."

Note the phrase: ongoing and continuous. Not "by year end." The document sets no deadline, no grace period and no transition window — we looked, and there is none. Compliance is a continuing state, assessed when the NCA decides to assess it.

Two other structural controls worth knowing before your first assessment, both from domain 1:

• 1-2-1 — a cybersecurity department "shall be established within the entity," independent from the IT and Communications Department (pursuant to High Order No. 37140, dated 14/08/1438H), with a recommendation that it report directly to the head of the entity. Cybersecurity reporting to the IT manager is a structural finding, not a technical one, and you cannot patch your way out of it.
• 1-8-2 — implementation of controls must be reviewed and audited by parties other than the cybersecurity department, independently. The team that builds the controls cannot be the team that signs off on them.

Where a hosting provider fits — and where it does not

Subdomain 4-2 (Cloud Computing and Hosting Cybersecurity) is where most private-sector entities meet the ECC for the first time. It is short. In ECC-2:2024, control 4-2-3 requires that cloud and hosting cybersecurity requirements include, as a minimum, only two things:

4.2.3.1 — "Protection of entity's data by cloud and hosting service providers in accordance with its classification level and returning data (in a usable format) upon service completion."

4.2.3.2 — "Separation of the entity's environment (especially virtual servers) from environments of other entities within the cloud computing service provider."

That is the whole minimum list. Two sub-controls: protect it according to its classification and give it back in a usable format, and keep my environment separated from other tenants'.

Note what 4-2-3 also says: these apply "in addition to the applicable controls in the Main Domains (1), (2), and (3) and Subdomain (4.1)." Moving to a hosting provider does not shed your governance, defence or resilience obligations. It adds a supplier to them.

So here is the honest framing, and it is the one we would want if we were buying:

No hosting provider can make you ECC-compliant. The ECC binds the entity. It does not certify vendors, and there is no such thing as an "ECC-certified host." Any provider — including us — who tells you that buying their plan makes you compliant is telling you something the standard does not support. What a provider can do is make specific controls easy to evidence instead of expensive to argue about.

Concretely, when you assess any Saudi hosting provider against 4-2-3, ask for exactly this:

1. Where is the data, physically? (Not an ECC control any more — but still your obligation via NDMO/SDAIA and the PDPL.)
2. Tenant separation — how is my environment isolated from other customers? (4-2-3-2)
3. Data return — on exit, do I get my data back in a usable format, and how? (4-2-3-1)
4. Backups — what is taken, how often, and can I restore without a support ticket? (Feeds subdomain 2-9.)
5. Email authentication — can I publish SPF, DKIM and DMARC on my domain? (2-4-3-5.)
6. Encryption in transit — is TLS on by default, and does it renew without me remembering? (2-8-3.)

Skyline Cloud is a managed Saudi hosting platform, and we will describe it in exactly those terms and no further: infrastructure in the Kingdom with SAR billing and Arabic support; per-account environment separation; daily backups; free auto-renewing SSL (90-day certificates that renew themselves from S Panel, so nobody has to diarise it); DNS you control, so publishing SPF, DKIM and DMARC records is a five-minute job rather than a ticket; and a 99.9% uptime SLA. Plans run from SAR 49/month (Shared) through SAR 119/month (Dedicated) to SAR 199/month (Cloud — 4GB RAM, 100GB NVMe, auto-scaling, high availability, global CDN).

What that buys you is not a certificate. It is a shorter, cheaper conversation about 4-2-3, and less to explain in the parts of domain 2 that touch your hosting. The governance, the risk register, the Saudi cybersecurity staffing under 1-2-2 and the independent audit under 1-8-2 are still yours.

You can start a free 14-day trial — no credit card and look at the control panel, the backup schedule and the DNS records yourself before you take anyone's word for any of it.

A realistic first 90 days

If you are starting from nothing, this is the order we would work in — governance first, because governance findings are the ones you cannot fix in a sprint:

1. Read the actual PDF. It is public and it is 56 pages. You will finish it in an afternoon and you will out-argue most consultants.
2. Fix your org chart (1-2-1). An independent cybersecurity function. This is a decision, not a project, and everything downstream depends on it.
3. Staff it under 1-2-2. All cybersecurity positions, full-time, qualified Saudi professionals. Start recruiting before you start buying tools.
4. Build the asset inventory (2-1). You cannot log, patch, back up or classify what you have not listed.
5. Classify the data (2-7). 4-2-3-1 is expressed in terms of classification level — without classification, the cloud control is unanswerable.
6. Turn on logging and set retention to at least 12 months (2-12-3-5) — 18 if any system is a critical system under the CSCC.
7. Write the incident response and escalation plan, including reporting to the NCA (2-13-3-1, 2-13-3-3). The standard gives you no deadline, so define your own and defend it.
8. Arrange the independent review (1-8-2) before the NCA arranges one for you.

Everything after that is engineering. Our companion guide, Building a SOC for NCA compliance, takes steps 6 and 7 down to the log sources, the stack and the run-books — and is equally careful about which requirements are actually the NCA's and which are merely industry practice.

Frequently asked questions

Is ECC-1:2018 still valid? ECC-2:2024 is the current version and supersedes it. The NCA's own Update and Review table lists ECC-1 (2018) and ECC-2 (2024), with Appendix C documenting the changes. Always download the latest from nca.gov.sa rather than trusting a cached copy — the standard says so itself, in the disclaimer on its cover page.

How many controls does the ECC have? ECC-2:2024: 108 main controls and 92 subcontrols, across 4 main domains and 28 subdomains. ECC-1:2018 stated 114 controls across 5 domains and 29 subdomains. The two are not comparable figures, and quoting 114 in 2026 dates your document instantly.

Does the ECC require me to host my data in Saudi Arabia? ECC-2:2024 does not contain a data-localisation control. ECC-1's 4-2-3-3 required in-Kingdom hosting and storage; ECC-2 deleted it and transferred data-localisation to the NDMO at SDAIA (Appendix C). Residency obligations still apply to most entities — through the PDPL, NDMO rules and sector regulators — but they no longer come from the ECC, and citing 4-2-3-3 today is citing a withdrawn control.

What is the ECC deadline? The document does not state one. It requires "ongoing and continuous compliance" under Article 10(3) of the NCA's Statute and High Order No. 57231. There is no published grace period in the PDF.

Does the NCA require 24/7 security monitoring? The ECC does not say "around the clock" anywhere. The CSCC does — control 2-11-1-4, "Monitoring critical systems security events around the clock" — and it applies to critical systems. If you are ECC-only, the ECC requires "continuous monitoring of cybersecurity event logs" (2-12-3-4) without defining staffing hours.

Does the NCA publish MTTD/MTTR targets? No. There are no mean-time-to-detect or mean-time-to-respond figures anywhere in the ECC, and no incident-reporting deadline. Any such number you are shown is a vendor's opinion, not a requirement. Make them show you the control ID.

Am I in scope if I am a private company? Only if you own, operate or host Critical National Infrastructure — or if you are an affiliate of a government agency. Otherwise the NCA "strongly encourages" you to adopt the ECC as best practice. In practice, many entities are pulled in contractually by customers who are in scope.

Where did the ICS controls go? Main domain 5 was deleted from the ECC and its controls moved to the OTCC (Operational Technology Cybersecurity Controls), per Appendix C.

Sources

All control numbers, counts and quotations in this article were taken from these documents directly. They are published by the NCA at Document Classification: Public / Open, and they — not this page — are the authority.

• NCA — Essential Cybersecurity Controls ECC-2:2024 (PDF, 56pp — counts p.7; scope p.9; subdomains Fig.2 p.11; coding Figs.3–4 p.12; controls 2-12 & 2-13 pp.25–26; subdomain 4-2 p.31; change log Appendix C pp.42–47)
• NCA — Essential Cybersecurity Controls ECC-1:2018 (PDF — superseded; 5 domains / 29 subdomains / 114 controls, Introduction)
• NCA — Critical Systems Cybersecurity Controls CSCC-1:2019 (PDF — 4 domains / 21 subdomains / 32 main controls / 73 subcontrols; controls 2-11-1-4 and 2-11-2)
• NCA — Cloud Cybersecurity Controls CCC-2:2024 (PDF — current edition; 4 domains / 24 subdomains; CSP 37/94, CST 18/26; P and T control coding). Supersedes CCC-1:2020 (CSP 37/96).
• NCA — Telework Cybersecurity Controls TCC-1:2021 (PDF — 3 domains / 16 subdomains / 21 main controls / 42 subcontrols)

Last verified against the NCA's published PDFs in July 2026. Standards change. The download on nca.gov.sa is always the authority — and if this page and the PDF ever disagree, the PDF is right and we want to know.