Key Takeaways
- The NCA issues ECC as the national cybersecurity baseline and CCC as the layer that governs cloud providers and cloud tenants separately.
- CST (formerly CITC) issues CRF as a sector-specific overlay for licensed ICT and telecom providers, and CRF does not replace ECC.
- Many organizations, especially cloud-hosting ICT licensees classified as critical national infrastructure, sit inside all three frameworks at once.
- Each framework runs its own cadence: ECC expects periodic self-assessment and audit, CCC ties directly to data classification and residency, and CRF pushes licensees through three progressive compliance levels (CL1, CL2, CL3).
- Running three separate spreadsheets for three frameworks multiplies evidence-collection work and creates the exact mismatches inspectors flag first.
- A governed, continuous approach, one that keeps evidence current and lets attack results drive hardening priorities, replaces the scramble-before-audit cycle with a defensible, always-on posture.
If your organization operates in Saudi Arabia and touches government systems, cloud infrastructure, or a CST telecom license, you likely answer to more than one cybersecurity regulator. Saudi Arabia doesn’t run a single unified cybersecurity code. Instead, two separate authorities, the National Cybersecurity Authority (NCA) and the Communications, Space & Technology Commission (CST), each publish their own control sets, and those control sets frequently apply to the same organization at the same time.
This piece breaks down three of the frameworks security and GRC teams run into most: ECC, CCC, and CRF. It explains what each one covers, how they stack on top of each other, and why treating compliance as a once-a-year audit sprint no longer holds up once you’re managing three frameworks with three different cadences.
CST CRF at a Glance
Saudi Arabia’s Cybersecurity Regulatory Framework, broken into the four things ICT and public-sector teams need to know before anything else.
Who It Applies To
ICT-sector service providers and the public-sector organizations that depend on them.
3 Compliance Levels
CL1 → CL2 → CL3, a progressive structure that builds one stage on the last.
Risk-Based Tiering
Your level depends on entity size, service criticality, and overall risk profile.
Evidence Over Intent
Every level ultimately requires proof, not just policy documents on a shelf.
Three Regulators, Three Frameworks, One Compliance Headache
The NCA regulates cybersecurity at the national level. It issues the Essential Cybersecurity Controls (ECC) as the baseline every in-scope organization must meet, and it layers additional control sets, including the Cloud Cybersecurity Controls (CCC), on top of that baseline depending on what an organization operates.
CST regulates the ICT and telecom sector specifically. It issues the Cybersecurity Regulatory Framework (CRF) as a binding standard for its own licensees: telecom operators, internet service providers, and hosting or data center providers.
CL1 → CL2 → CL3: The Compliance Journey
CRF is progressive by design. Each level builds directly on the one before it.
The Baseline
Smaller entities & lower-risk providers
- Governance & policy ownership
- Asset identification & classification
- Baseline risk management
- Core logical & physical controls
Structured & Formal
Medium operators & moderate risk exposure
- Active, structured risk management
- Clear roles & escalation paths
- Independent third-party testing
- Proof controls are actually used
Monitor & Improve
Major operators & critical service providers
- Continuous control monitoring
- Documented before/after improvement
- Independent third-party audits
- Maturity across every domain
These two regulatory tracks run in parallel, not in sequence. A cloud hosting provider that also holds a CST telecom license can find itself accountable to the NCA for ECC and CCC and to CST for CRF, all inside the same calendar year, often to different assessors asking for overlapping evidence.
ECC: The Baseline Every In-Scope Organization Must Meet
The Essential Cybersecurity Controls sit at the center of the NCA’s framework family. ECC sets the minimum cybersecurity expectations for government entities, critical national infrastructure operators, and a wide range of private-sector organizations that handle sensitive systems or data.
The current version, ECC-2:2024, organizes 108 main controls and 92 subcontrols across four top-level domains:
- Cybersecurity Governance: strategy, policy, risk management, human resources, awareness, and audit
- Cybersecurity Defence: asset management, identity and access management, network security, data protection, vulnerability management, penetration testing, logging and monitoring, and incident management
- Cybersecurity Resilience: business continuity as it relates to cybersecurity
- Third-Party and Cloud Computing Cybersecurity: supplier and cloud provider obligations
ECC-2:2024 removed the old Industrial Control Systems domain that existed in ECC-1:2018 and moved those requirements into a dedicated OT framework, so ECC itself now focuses purely on the four domains above. The update also widened the Saudi-nationals staffing requirement to cover all cybersecurity positions and pointed cryptography requirements at the National Cryptographic Standards.
ECC writes every control as a testable, outcome-based statement. It doesn’t prescribe a specific vendor or technology, but it does require the organization to produce evidence that the outcome exists. That evidence requirement is exactly where teams start to feel the weight of running ECC alongside CCC and CRF: the same asset inventory, the same access control policy, and the same incident log end up serving three separate assessors.
CCC: The Rules For Cloud Providers And Cloud Tenants
The Cloud Cybersecurity Controls recognize that cloud security splits across two parties, so the NCA defines two distinct control sets inside CCC rather than one generic cloud policy.
For Cloud Service Providers (CSPs) operating in the Kingdom, CCC covers:
- Governance and certification
- Infrastructure security and tenant segmentation
- Customer data protection
- Incident notification obligations
- Audit rights and exit assistance for customers
For Cloud Tenants consuming those services, CCC covers:
- Cloud strategy and policy
- Data classification before data moves to cloud
- Due diligence on the chosen provider
- Configuration baselines and identity federation
- Encryption and key management
- Ongoing monitoring, plus exit and portability planning
CCC ties directly into data classification and residency expectations. For an organization handling sensitive or critical data, CCC generally means that data either stays inside Saudi Arabia or moves to a provider that carries NCA-recognized controls and a Saudi-region presence. Any organization running a SaaS tool that touches regulated data falls inside CCC’s tenant obligations, whether or not that organization considers itself “cloud-first.”
CRF: The Sector-Specific Layer For ICT Licensees
CST built the Cybersecurity Regulatory Framework specifically for the organizations it licenses: telecom operators, internet service providers, hosting providers, and data center operators. CRF exists because ICT licensees sit in a structurally different position from most regulated organizations. They’re simultaneously a potential target and part of the infrastructure the rest of the economy depends on, so a single incident at a major provider can cascade into every business that relies on its connectivity.
CRF applies a risk-based, progressive model. Rather than demanding the full control set on day one, it moves licensees through three Compliance Levels:
- CL1 (Foundational): basic governance, asset inventory, access control, and baseline hardening
- CL2 (Advanced): formal risk management, deeper logical and physical controls, and third-party oversight
- CL3 (Continuous Improvement): ongoing monitoring and metrics-driven refinement of the CL1 and CL2 controls already in place
Across all three levels, CRF organizes its requirements into six domains: Governance, Asset Management, Risk Management, Logical Security, Physical Security, and Third-Party Security. The domains stay constant as a licensee progresses; what changes is the depth and evidentiary rigor CST expects inside each one. A CL1 organization can satisfy Risk Management with an informal risk list. A CL3 organization needs a structured, periodically reviewed process with named ownership and measurable outcomes.
CRF does not replace ECC. CST built it as a sector-specific overlay, and many ICT licensees, particularly large telecom operators and hosting providers, also carry a critical national infrastructure designation. Those organizations satisfy ECC’s national baseline and CRF’s sector-specific requirements at the same time, not one instead of the other.
How ECC, CCC, and CRF Stack On Top Of Each Other
What Auditors Actually Expect, Level by Level
The control domains barely change across CRF. What changes is how deep, how formal, and how continuously your team has to prove it.
| Control Area | CL1 | CL2 | CL3 |
|---|---|---|---|
| Governance | Core policies exist with a clear, accountable owner | Defined roles, escalation paths, and policy enforcement | Full maturity across every control domain, not just security |
| Risk Management | Baseline practices guide day-to-day decisions | Active, structured process rather than a one-time exercise | Continuously monitored and iteratively improved over time |
| Validation | Internal review of fundamental controls | Independent third-party testing, incl. penetration testing | Independent audits with documented remediation plans |
| Monitoring Cadence | Point-in-time hygiene checks | Periodic, formal review cycles | Continuous monitoring of control performance |
| Evidence | Documentation shows controls exist | Documentation shows controls are actually used | A documented before-and-after trail proving improvement |
Picture a mid-sized hosting and data center provider operating in Riyadh. It runs the following obligations simultaneously:
- ECC applies because the provider’s systems qualify as critical national infrastructure.
- CCC applies on the provider side because it sells cloud infrastructure to customers, and it may also apply on the tenant side wherever the provider itself consumes another vendor’s cloud service.
- CRF applies because CST licensed the provider to deliver hosting and connectivity services, and the provider must progress through CL1, CL2, and eventually CL3.
None of these three frameworks cancels out the others. ECC sets the floor. CCC adds cloud-specific depth wherever cloud infrastructure sits in the picture. CRF adds sector-specific depth because CST licensed the organization directly. A team that treats each framework as an isolated project ends up building three governance structures, three risk registers, and three evidence stores for what is largely the same underlying set of controls: access management, encryption, monitoring, and third-party oversight show up in all three frameworks under slightly different names.
Why Point-In-Time Compliance Breaks Under Three Overlapping Frameworks
Each framework runs on a different clock. ECC expects periodic self-assessment and audit. CCC ties into ongoing data classification and provider due diligence. CRF pushes licensees through a maturity curve where CL3 explicitly checks whether a control has stayed effective over time, not just whether it existed on the day of the review.
A once-a-year, spreadsheet-driven compliance sprint cannot keep pace with that. By the time a team finishes documenting evidence for ECC, the CCC tenant obligations have shifted because a new SaaS vendor came online, and the CRF assessor is asking whether the access control policy from six months ago still reflects reality. Inspectors across all three frameworks consistently flag the same failure pattern: evidence that’s accurate on paper but stale in production, and control statements that contradict each other because three separate teams maintained three separate versions of the truth.
Continuous compliance solves the actual problem. Instead of reconstructing evidence before each audit, a continuously monitored control library keeps evidence current at all times, so an ECC self-assessment, a CCC provider review, and a CRF CL2-to-CL3 progression all pull from the same live source. The work of proving a control is effective becomes a byproduct of running the control, not a separate project bolted onto it every quarter.
How Secure.com Turns ECC, CCC, and CRF Into One Governed, Continuous Program
Security work in Saudi Arabia is growing faster than most GRC and security teams can absorb, and running ECC, CCC, and CRF as three disconnected workstreams multiplies that gap instead of closing it. Secure.com delivers Governed Defense, Powered by Offense: AI teammates that attack to expose real gaps, harden defenses, and prove the outcome, inside customer-defined scope, permissions, and approvals.
One Control Statement, Three Frameworks
Owns controls, compliance posture, evidence collection, audit readiness, and trust reporting, so one control statement can serve ECC, CCC, and CRF at once instead of three separate evidence trails.
Posture Mapped to CCC Obligations
Owns cloud and infrastructure posture, misconfigurations, drift, exposure, and remediation, mapping directly onto tenant and provider obligations under CCC.
FAQs
What is ECC in Saudi Arabia?
What is CCC and who does it apply to?
What is CRF and who issues it?
Does CRF replace NCA ECC?
Can one organization fall under ECC, CCC, and CRF simultaneously?
Why does continuous compliance matter more than a once-a-year audit?
Conclusion
ECC, CCC, and CRF don’t compete with each other. They stack. ECC sets the national floor, CCC adds cloud-specific depth for providers and tenants, and CRF adds sector-specific depth for CST’s ICT licensees. Any organization that operates cloud infrastructure under a CST license, and a meaningful share of Saudi Arabia’s ICT sector does exactly that, needs to satisfy all three at once, on three different cadences, in front of two different regulators.
Running three frameworks as three disconnected projects guarantees duplicated work and the evidence mismatches inspectors catch first. Running them as one governed, continuously monitored program turns that same work into a single control library that serves every framework it touches. That shift, from proving compliance once a year to proving it continuously, is what separates teams that pass their next audit from teams that dread it.
