Common questions about Saudi Arabia's Essential Cybersecurity Controls: what they require, who must comply, and how to approach compliance.
The Essential Cybersecurity Controls (ECC) is the foundation of Saudi Arabia's national cybersecurity regime. This FAQ covers the questions that come up most often when compliance and security teams first engage with ECC: scope, structure, audits, and how it relates to international frameworks they may already follow.
The Essential Cybersecurity Controls (ECC) is the baseline cybersecurity standard issued by Saudi Arabia's National Cybersecurity Authority. It defines the minimum cybersecurity requirements for in-scope entities operating in the Kingdom, organized across four main domains: Cybersecurity Governance, Cybersecurity Defense, Cybersecurity Resilience, and Third-Party & Cloud Computing Cybersecurity. Each domain breaks down into subdomains and then into specific controls and sub-controls.
ECC is issued by the National Cybersecurity Authority (NCA), Saudi Arabia's specialized cybersecurity authority established by Royal Order No. 6801. Compliance for in-scope entities is mandatory under NCA's Statute (Article 10(3)) and High Order No. 57231. It is a statutory obligation, not voluntary guidance. NCA is also empowered to evaluate compliance and issue corrective orders.
Yes. The current version, ECC-2:2024, replaced the original ECC-1:2018. The 2024 revision restructured several subdomains, added new controls (notably around web application security and updated cloud-computing requirements), and clarified scope language. Entities currently aligned with ECC-1 need to perform a gap analysis against ECC-2 to identify newly-required controls and update their evidence accordingly.
ECC applies to government agencies in the Kingdom (ministries, authorities, and affiliated entities), and to private-sector entities that own, operate, or host Critical National Infrastructure (CNI). NCA strongly encourages all other entities in the Kingdom to adopt ECC as a baseline, but only government and CNI entities are formally required.
Only if they own, operate, or host Critical National Infrastructure. A typical private company that does not touch CNI is not formally bound, though many adopt ECC voluntarily because it's the de facto cybersecurity baseline in the Kingdom, and because sector regulators (notably SAMA for finance and CITC for telecom) routinely reference NCA controls in their own frameworks.
ECC applies to entities operating in the Kingdom, including affiliates and subsidiaries of foreign-headquartered companies. The geographic scope is the regulated activity in the Kingdom, not the location of the parent. Foreign companies bidding for Saudi government contracts are routinely asked to demonstrate ECC alignment as part of vendor due diligence.
Not as a binding requirement, but ECC is the practical baseline. If you're contracting with the Saudi government or with CNI operators, expect ECC alignment to be required by contract. NCA has also issued sector-specific controls (Cloud, Operational Technology, Data, Non-Critical Private Sector) that build on ECC, so understanding ECC remains useful even when a more specific framework applies.
ECC organizes its requirements across four main cybersecurity domains: Governance (strategy, policies, risk management, awareness), Defense (asset management, identity and access, network and endpoint controls, cryptography, vulnerability and incident management), Resilience (business continuity), and Third-Party & Cloud Computing Cybersecurity. Each domain breaks down into subdomains, then into specific controls with associated sub-controls.
Cybersecurity Governance covers strategy, policies, roles, risk management, compliance with laws and regulations, periodic audit, HR cybersecurity, project-management security, and awareness. Cybersecurity Defense is the largest domain by volume. It covers identity and access, network security, mobile devices, data protection, cryptography, backups, vulnerability management, penetration testing, monitoring, incident response, physical security, and web application security. Cybersecurity Resilience covers cybersecurity aspects of business continuity management. Third-Party and Cloud Computing Cybersecurity covers vendor management plus cloud-specific controls.
Yes. The Cloud Computing and Hosting Cybersecurity subdomain (4-2) is mandatory for any entity that uses or plans to use cloud or hosting services. NCA also publishes a separate Cloud Cybersecurity Controls (CCC) document with deeper cloud-specific requirements, which CNI-related cloud deployments are expected to follow on top of ECC.
NCA evaluates compliance through three mechanisms, used at its discretion: self-assessment by entities, periodic reports submitted via NCA's compliance tool, and on-site field audits. Compliance is not a one-time certification. It is an ongoing obligation, with audit cadence and depth determined by the entity's risk profile and sector.
Yes. NCA provides the ECC Assessment and Compliance Tool, released alongside ECC-2:2024, which structures the self-assessment process. Entities are expected to use this tool when reporting compliance status to NCA, and to keep their assessments current as the control environment evolves.
There's no single mandated cadence. Ongoing compliance is the standard. In practice, regulated entities perform a formal internal assessment annually, with quarterly or sector-specific reporting depending on their oversight regime. NCA can initiate a field audit at any time, so the practical posture is continuous readiness rather than periodic catch-up.
For an organization starting from a mature ISO 27001 baseline, six to nine months is realistic. From a low maturity baseline, twelve to eighteen months is more typical, with the bulk of the time going to policy authoring, evidence collection, and rolling out tooling for monitoring, vulnerability management, and identity and access. Governance work typically takes longest because it requires senior-leadership decisions, not just engineering work.
Three areas consistently. First, documenting risk-based decisions: auditors expect traceable rationale, not just outputs. Second, evidence of continuous control operation: point-in-time evidence isn't enough; auditors want to see that controls operated over the assessment period. Third, third-party cybersecurity: the Third-Party domain expects vendor cybersecurity to be assessed and contractually enforced, which catches teams without a vendor-management program off-guard.
The official ECC document is published in both Arabic and English, but the Arabic version is the binding legal language. For internal documentation, Arabic is strongly preferred but not strictly required. What matters is that auditors can verify implementation. Entities engaging with NCA directly or with Arabic-medium regulators should expect to produce key artefacts in Arabic.
ECC is more prescriptive than ISO 27001. Where ISO 27001 leaves control selection to the organization (via Statement of Applicability against Annex A), ECC specifies the controls and sub-controls directly. The two frameworks overlap substantially in the Defense domain, but ECC adds explicit cloud and operational-technology pathways that ISO 27001 doesn't cover by default. ISO 27001 is portable globally; ECC is jurisdiction-specific.
A lot of it, yes. SOC 2's Trust Services Criteria overlap meaningfully with ECC's Defense and Governance domains: access controls, monitoring, incident response, change management, and vendor-management evidence translates directly. What SOC 2 typically doesn't cover: cloud-computing requirements at ECC's specificity, operational-technology controls, and the depth of vendor cybersecurity expected by ECC's Third-Party domain.
For in-scope entities, non-compliance is a statutory violation. Practical consequences range from regulatory orders to remediate, to ineligibility for government contracts, to reputational consequences with sector regulators. NCA coordinates with sector regulators (SAMA for finance, CITC for telecom, and others) who apply their own penalties for cybersecurity failures on top of NCA's own enforcement.
Some controls are conditional rather than universal. The cloud-computing subdomain only applies if you use cloud, for example. For genuinely-inapplicable controls, the official position is documented non-applicability with rationale, not exemption. NCA expects the Statement of Applicability to be defensible; "we chose not to implement this" is not an accepted position.
Kevala supports NCA ECC out of the box. Talk to us.