How Saudi organisations get from “we have a firewall” to audit-ready NCA compliance in 12 months, without stopping the business.
The National Cybersecurity Authority (NCA) has moved from advisory body to active regulator. For organisations designated within Saudi Arabia’s critical sectors — energy, government, telecommunications, healthcare, transport, finance-adjacent services and the Vision 2030 giga-projects — compliance with NCA’s control frameworks is no longer a recommendation. It is an audited obligation, and the audit requests are getting more specific every cycle.
This guide explains what the NCA control frameworks actually require, where Saudi organisations most often fall short, and a phased 12-month implementation path that our engineers use when scoping compliance programmes. It is written for IT directors, CISOs and operations leaders — not lawyers.
Scope note: this article is practical guidance based on published NCA frameworks and field experience; it is not legal advice, and control applicability always depends on your NCA classification and sector regulator. Verify current framework versions against the official NCA publications at nca.gov.sa.
The framework landscape: ECC and CSCC
NCA’s baseline is the Essential Cybersecurity Controls (ECC-2:2024) — the control set that applies to government entities and the organisations within NCA’s scope. The current version is organised into four main domains, 28 subdomains, 108 main controls and 92 subcontrols. Layered above it, the Critical Systems Cybersecurity Controls (CSCC-1:2019) extend the ECC for organisations that own or operate national critical systems, adding 32 main controls and 73 subcontrols across the same four domains. Operational technology and industrial control systems are covered by a separate extension, the Operational Technology Cybersecurity Controls (OTCC-1:2022), and no longer sit inside the ECC. The four ECC domains are:
Governance — cybersecurity strategy, policy, roles and responsibilities, asset management, human-resources security, awareness and training, and periodic review. The regulator’s first questions are almost always governance questions: who owns cybersecurity, and can you show the documents?
Defence — identity and access management, privileged access management, network segmentation, encryption at rest and in transit, endpoint protection, email and web protection, vulnerability management, patching SLAs, logging and monitoring.
Resilience — incident response capability, business continuity and disaster recovery planning, backup integrity, and — critically — evidence that plans have been tested, not just written.
Third-party and cloud security — due diligence on vendors and contractors with access to your environment, contractual security clauses, and cloud arrangements aligned to NCA’s cloud control expectations, including data-residency decisions.
Who must comply — and how you find out
Applicability follows your designation, not your self-image. An organisation learns it is in scope through NCA correspondence, through its sector regulator, or through contractual flow-down — a growing share of Saudi enterprise and giga-project contracts now require NCA alignment from suppliers as a condition of award. If your customers operate critical infrastructure, their third-party security obligations become your compliance requirements whether or not NCA has written to you directly.
The practical consequence: mid-market Saudi companies serving banks, government, energy or the giga-projects need an ECC-aligned control posture to keep winning that work.
The 12-month implementation plan
The failure pattern we see most often is the audit sprint — nothing for two years, then a panicked quarter before an audit. The alternative is a phased year that an ordinary IT team can actually sustain:
The plan below is EIE’s indicative planning model. NCA sets compliance expectations through its own correspondence and the sector regulators; the durations here are planning assumptions, not statutory deadlines or predicted outcomes.
| Phase | Window | Focus | Exit evidence |
|---|---|---|---|
| 1 — Assess | Months 0–2 | Control-by-control gap assessment against every applicable ECC (and, where designated, CSCC) control; asset inventory rebuilt; risk register started | Scored current-state map; prioritised gap list; leadership briefing |
| 2 — Remediate priority gaps | Months 2–6 | The controls that decide audits: MFA everywhere, privileged access management, network segmentation, patching SLAs, centralised logging | Closed-gap log with before/after evidence per control |
| 3 — Operationalise | Months 6–9 | Incident-response runbooks written and exercised; backup restore tests; awareness training with attendance records; vendor due-diligence pack | Tabletop exercise report; restore-test log; training register; third-party register |
| 4 — Audit-ready | Months 9–12 | Internal mock audit; evidence pack assembly in NCA reporting format; residual-risk acceptance signed by leadership | Mock-audit report; complete evidence pack; board sign-off |
Two rules make the plan survivable. First, evidence is produced as you go — a control without a dated artifact does not exist as far as an auditor is concerned. Second, one owner per control domain; committees remediate nothing.
The ten controls where Saudi organisations most often fail
From assessment work across enterprise environments, the recurring gaps are remarkably consistent:
- Asset inventory that reflects reality — including OT, IoT, building systems and the forgotten test server.
- Privileged access management — shared admin accounts and vendor logins with standing access are the most common single finding.
- Network segmentation — flat networks where a compromised laptop can reach the building-management system.
- Patching SLAs with proof — a policy exists; the evidence that critical patches land inside the window usually does not.
- Centralised logging with retention — logs that exist only on the device that was compromised are not logs.
- Incident-response capability — a written plan that has never been exercised, with no defined 2 a.m. call tree.
- Backup integrity — backups that have never survived a restore test, or that sit on the same network they protect.
- Third-party due diligence — no security assessment of the contractors who hold credentials to your systems.
- Awareness training — no records, or a single onboarding slide from years ago.
- Encryption coverage — data at rest on file servers and backups is the usual blind spot, not the website’s TLS.
If you fix only this list, you have addressed the majority of what a first NCA audit will probe.
What the evidence pack looks like
Auditors ask for artifacts, and the organisations that pass keep them current rather than reconstructing them under pressure: the cybersecurity policy set with review dates; the asset register; the risk register with treatment decisions; access-review records; patching reports against SLA; log-retention configuration; the incident-response plan plus the report of its last exercise; backup restore-test logs; training attendance; vendor security assessments and contract clauses; and, for CSCC-designated organisations, the additional sector-specific artifacts your regulator defines. Assemble it once, then maintain it quarterly — the maintenance cost is a fraction of the reconstruction cost.
Common mistakes that stall programmes
Buying tools before the gap assessment (the tool becomes shelfware aimed at the wrong gap). Treating compliance as an IT project rather than an operating cadence with leadership ownership. Writing policies copied from templates that describe controls you do not run — auditors read them against reality. And scoping consultants to “make us compliant” without transferring the operating knowledge, which guarantees the same engagement again in three years.
Where EIE fits
Elite Ideas Establishment delivers the technical side of NCA readiness for Saudi organisations: the control-by-control gap assessment (about four to six weeks in our planning model), remediation engineering (segmentation, PAM, logging, backup architecture), managed monitoring aligned to NCA reporting expectations, and the audit-ready evidence pack — from our Jeddah headquarters with Kingdom-wide service coverage, with a Saudi engineering team and a technology heritage in the Kingdom that dates to 1985 through our predecessor ETE. If your next contract or your regulator has put NCA compliance on your desk, the assessment is the right first step. Talk to our team →
Frequently asked questions
How long does NCA ECC/CSCC implementation take for a mid-market Saudi organisation?
In EIE’s planning model the initial gap assessment runs about four to six weeks. Remediation depends on the gap profile — most mid-market environments plan three to nine months to close priority gaps, with the full audit-ready cadence in place inside twelve months. These are planning assumptions, not regulator deadlines or predicted outcomes.
Do the NCA controls apply to companies that are not designated critical infrastructure?
Directly, applicability follows NCA designation and sector regulators. Practically, ECC alignment increasingly arrives through contracts: critical-sector customers must assess their suppliers, so vendors to banks, government and giga-projects need an ECC-aligned posture to win and keep that work.
What is the difference between ECC and CSCC?
ECC is the baseline control set for organisations within NCA’s scope. CSCC — the Critical Systems Cybersecurity Controls — is an extension of the ECC for organisations that own or operate national critical systems, so those organisations comply with both. Operational technology is covered by the separate OTCC extension.
What evidence do NCA audits actually request?
Dated artifacts per control: policies with review history, asset and risk registers, access reviews, patching reports, log configuration, exercised incident-response plans, restore-test logs, training records and third-party assessments — in the reporting structure NCA defines.
Sources and further reading: National Cybersecurity Authority — Essential Cybersecurity Controls (ECC-2:2024), Critical Systems Cybersecurity Controls (CSCC-1:2019) and Operational Technology Cybersecurity Controls (OTCC-1:2022). Framework versions are updated by NCA; always implement against the current published version.
Related: Cybersecurity & Compliance services · SAMA CSF quarterly self-assessment checklist · PDPL DSAR playbook