GRC · CST Regulations · ICT Sector
Quick Answer
CST CRF (the Cybersecurity Regulatory Framework) is issued by the Communications, Space & Technology Commission (CST) — formerly CITC — and sets mandatory cybersecurity requirements for licensed ICT Service Providers in Saudi Arabia: telecom operators, ISPs, and hosting/data center providers.
CRF uses a risk-based approach with three progressive Compliance Levels — CL1, CL2, and CL3 — spanning six control domains: governance, asset management, risk management, logical security, physical security, and third-party security. Many ICT licensees also fall under NCA ECC and must satisfy both frameworks together.
Saudi Arabia's ICT sector carries a regulatory weight that most other industries don't: it is both a target and critical infrastructure for the rest of the economy. CST's Cybersecurity Regulatory Framework exists specifically to raise the security bar for the licensees that keep the Kingdom's communications, hosting, and connectivity services running. Here's how it works and how to build a roadmap through it.
The Communications, Space & Technology Commission (CST) — known until its rebrand as CITC — is the regulatory body overseeing Saudi Arabia's Information and Communications Technology (ICT) and postal sectors. The Cybersecurity Regulatory Framework (CRF) is CST's binding cybersecurity standard for the licensees it regulates. Its stated purpose is to raise cybersecurity maturity across the ICT and telecom sector, protect critical infrastructure and sensitive data, build trust in resilient ICT services, and support the digital-transformation goals of Vision 2030.
CST's mandate goes beyond CRF alone — it issues a broader set of regulatory documents covering licensing, service quality, consumer protection, and technical standards for the sector. CRF is the piece of that regulatory library specifically concerned with cybersecurity, and it sits alongside CST's other cybersecurity-adjacent instrument, the Cloud Computing Regulatory Framework (CCRF), covered later in this guide.
ICT licensees occupy a structurally different position from most regulated organizations: they are simultaneously a potential target and part of the infrastructure everyone else depends on to communicate, transact, and operate online. A cybersecurity incident at a telecom operator or a major hosting provider doesn't just affect that company — it can cascade into every business and government service that relies on its connectivity or infrastructure. That systemic dependency is exactly why CST maintains a dedicated, sector-specific cybersecurity framework rather than relying solely on the general national baseline.
CRF applies to licensed Service Providers in the ICT sector — telecom operators, internet service providers, hosting and data center providers, and similar CST licensees. If your organization holds a CST license to deliver communications, connectivity, or hosting services in the Kingdom, CRF is a binding requirement, not an optional best-practice framework.
Scope determination is generally straightforward compared to some of Saudi Arabia's other cybersecurity frameworks: if CST has issued your organization a license to operate as an ICT service provider, CRF applies. There is no separate size or revenue threshold that exempts smaller licensees — the compliance level (CL1, CL2, or CL3) a licensee is expected to reach may vary with the nature and scale of the services it provides, but the requirement to be on the CRF pathway does not.
CRF takes a risk-based, progressive approach. Rather than requiring every licensee to implement the full control set on day one, it defines three Compliance Levels that organizations advance through over time:
| Level | Focus Area | Typical Controls | Assessment Emphasis |
|---|---|---|---|
| CL1 | Foundational security | Basic governance, asset inventory, access control, baseline hardening | Are the fundamentals in place? |
| CL2 | Advanced requirements | Formal risk management, deeper logical and physical controls, third-party oversight | Is coverage broad and formalized? |
| CL3 | Efficiency and continuous improvement | Continuous monitoring, metrics-driven refinement of CL1/CL2 controls | Is the program maturing and self-improving? |
The progression is intentional: CL1 establishes the baseline, CL2 builds depth and formality, and CL3 shifts the emphasis from "do the controls exist" to "are the controls continuously monitored and improved." Licensees are expected to move through these levels over time rather than attempt CL3 requirements before CL1 is solid.
Across all three compliance levels, CRF organizes its requirements into six core domains:
Cybersecurity strategy, policy, roles, and organizational accountability for the licensee's security program.
Inventory and classification of the network infrastructure, systems, and data the licensee is responsible for protecting.
Structured identification, assessment, and treatment of cybersecurity risk specific to ICT service delivery.
Identity and access management, network security, encryption, and technical controls protecting systems and data in transit and at rest.
Protection of data centers, network operation centers, and physical infrastructure supporting ICT service delivery.
Oversight of vendors, subcontractors, and supply-chain partners that touch the licensee's ICT infrastructure or customer data.
These six domains apply at every compliance level — what changes as a licensee progresses from CL1 to CL3 is not the list of domains, but the depth, formality, and evidentiary rigor expected within each one. A CL1 organization might satisfy the Risk Management domain with a basic, informally maintained risk list; a CL3 organization is expected to run a structured, periodically reviewed risk management process with clear ownership and measurable outcomes.
CRF is a sector-specific overlay, not a replacement for NCA ECC. ECC is the national cybersecurity baseline that applies to government entities and Critical National Infrastructure (CNI) operators regardless of sector. CRF adds ICT-specific depth on top of that baseline for CST licensees. In practice, many ICT licensees — particularly major telecom operators and large hosting providers — are also designated CNI, which means they need to satisfy ECC's national baseline and CRF's sector-specific requirements at the same time. Read our companion guide to NCA ECC-2:2024 for how the national baseline is structured.
GHS Perspective
The ICT licensees we work with rarely struggle with CL1 — foundational controls are usually already in place from general IT operations. Where programs stall is the CL2-to-CL3 transition: moving from "we have the control" to "we can prove the control is continuously monitored and improving." That shift needs process and tooling, not just policy documents.
A practical progression for licensees building or maturing their CRF program:
Licensees that treat CL1 through CL3 as one continuous maturity curve — rather than three separate certification projects — typically progress faster, because governance and risk management work done for CL1 directly informs the monitoring priorities that matter most at CL3. GHS supports ICT licensees through this progression with GRC advisory and technical assessment services, and tracks multi-framework evidence — CRF alongside ECC where both apply — inside ComplyOS.
CST also issues an adjacent framework, the Cloud Computing Regulatory Framework (CCRF), specifically for cloud service providers. Where CRF covers the general obligations of ICT service providers, CCRF addresses requirements unique to cloud service delivery — data handling, multi-tenancy security, and cloud-specific risk controls. If your organization is both a CST-licensed ICT service provider and a cloud service provider, expect both CRF and CCRF to apply, with overlapping but distinct evidence requirements.
In practice, most large hosting and data center providers fall into exactly this dual-scope position: they hold an ICT service provider license subject to CRF, and they also offer cloud infrastructure or platform services subject to CCRF. Rather than running two disconnected compliance programs, it's more efficient to build a single control library that maps evidence to both frameworks, since a meaningful share of the underlying requirements — governance, access management, physical security — genuinely overlap.
CRF assessments generally combine documentary review — policies, risk registers, asset inventories — with technical verification of controls actually in operation, such as access logs, encryption configuration, and monitoring evidence. Assessors are typically most interested in whether controls are consistently applied across the licensee's full infrastructure footprint, not just in a sample environment. Licensees that maintain living documentation and centralized evidence — rather than reconstructing it ahead of each review — consistently move through assessments faster and with fewer follow-up findings. This is also where the CL1-to-CL3 distinction matters most: a CL1 assessment checks whether a control exists, while a CL3 assessment checks whether it has been continuously effective over the review period.
GHS maps your ICT licensee's current controls against CL1, CL2, and CL3, and builds a practical roadmap — including any overlapping NCA ECC or CCRF requirements.
