CST Cybersecurity Regulatory Framework (CRF): A Guide for Saudi ICT Providers A compliance guide from Sumrite.

Many ICT providers in Saudi Arabia know the NCA’s Essential Cybersecurity Controls well but treat the CRF as a once-off submission from 2020. CST’s decision makes the CRF an ongoing obligation with assigned compliance targets and periodic reporting. This guide explains how the framework works and where it sits next to the NCA and SAMA rulebooks covered in our SAMA Cyber Security Framework guide series.

What is the CST Cybersecurity Regulatory Framework (CRF)?

The CST Cybersecurity Regulatory Framework (CRF) is a comprehensive set of cybersecurity requirements and controls for service providers in Saudi Arabia’s information and communications technology (ICT) and postal sectors, aimed at raising the sector’s cybersecurity maturity. CITC announced it on 13 August 2020, built on international best practice and local cybersecurity frameworks, in coordination with the NCA.

The key dates, as published on cst.gov.sa:

1. 1

   29 May 2019

   CITC publishes the draft CRF (version 1.0) for public consultation.

2. 2

   13 August 2020

   [CITC announces the CRF](https://www.cst.gov.sa/en/media-center/news/CITC-Issues-the-Regulatory-Framework-CRF-for-Service-Providers-in-ICT-and-Postal-Sectors) for ICT and postal service providers.

3. 3

   Decision No. 424/1442

   [CST lists the approving decision](https://www.cst.gov.sa/en/regulations-and-licenses/decisions/Regulation-404) with a decision date of 15/09/2020; the framework enters into force on 16/10/1442H.

4. 4

   10 November 2022

   Cabinet Decree No. 235 (07/04/1444H) renames CITC the [Communications, Space and Technology Commission](https://www.cst.gov.sa/en/about/who-we-are).

Because of the rename, providers and auditors still use “CITC CRF” and “CST CRF” interchangeably. They are the same framework. CST lists the current document on its regulations page for the CRF.

Who must comply with the CST CRF?

The CST CRF applies to organisations licensed or registered by CST, and to those otherwise subject to CST, in the ICT and postal sectors. In practice that means telecom operators, internet and data service providers, hosting and data-centre operators, cloud service providers and postal operators holding a CST licence or registration.

The CRF regulations page on cst.gov.sa describes the framework as mainly concerning organisations licensed or registered by CST and those subject to it. The draft text CITC published for consultation in May 2019 applied the controls to licensed service providers (LSPs), their subsidiaries, staff, third parties and customers, and allowed for some controls not applying to every provider; for example, secure software development controls only apply where the provider develops software or has it built by a third party.

CST’s approving decision treats one group differently. Providers classified as sensitive national infrastructure are excluded from the decision’s reporting clause according to what they receive from CST, so those providers should follow CST’s direct instructions rather than the general timeline.

What are the CST CRF compliance levels?

The CST CRF has three cumulative compliance levels: level 1 (basic controls), level 2 (advanced requirements) and level 3 (monitoring efficiency and continuous improvement), and CST assigns each provider a target level and date based on its criticality. A provider cannot claim a higher level without meeting every control in the levels below it.

Compliance level	Focus in the CRF text	Typical evidence
Level 1	Basic security controls	Policies, asset inventory, access control, patching, basic logging
Level 2	Advanced requirements in addition to level 1	Internal audit, penetration testing, vulnerability management process, incident management
Level 3	Monitoring efficiency and continuous improvement of level 1 and 2 controls	Metrics, trend reviews, documented improvement of processes

The level definitions come from the version 1.0 CRF text that CITC published on its consultation page. The approving decision then set the process for assigning levels:

The draft text also says CITC (now CST) monitors compliance through facility inspections, compliance workshops and active and reactive audits, and may ask for self-assessments, documents and top-risk reports at any time.

What domains does the CST CRF cover?

The CST CRF text is organised into six domains: Governance, Asset Management, Cybersecurity Risk Management, Logical Security, Physical Security and Third Party Security. Logical Security is the largest domain and holds most of the technical controls, including vulnerability management and penetration testing.

1 Governance

Strategy, cybersecurity management, compliance, audit, awareness and training, customer awareness, project management, human resources.

2 Asset Management

Asset discovery and classification, BYOD, acceptable use, maintenance, secure disposal.

3 Cybersecurity Risk Management

Risk assessment, risk treatment and monitoring.

4 Logical Security

Cryptography, change, vulnerability and patch management, network security, logging and monitoring, IAM and PAM, incident and malware handling, backup, hardening, secure development, email and web protection, penetration testing.

5 Physical Security

Securing equipment and areas, physical access, environmental protection, off-site assets.

6 Third Party Security

Cloud services and outsourcing services.

This structure is taken from the version 1.0 text on the CST consultation page. Confirm control numbering against the approved copy CST provides to your organisation, because the final text may have changed after consultation.

What does the CST CRF require for penetration testing?

The CRF text includes a Penetration Testing control, 4.16, at compliance level 2, requiring providers to define penetration testing requirements and a process for scope and frequency, and to report results so remediation is triggered. It gives “at least once quarterly on the critical information assets” as an example frequency.

The control in the version 1.0 CRF text has five parts:

• 4.16.1: define penetration testing requirements, including purpose, objectives and frequency;
• 4.16.2: define a process covering scope and frequency using standard methodologies, such as grey box and white box testing;
• 4.16.3: use the vulnerabilities report to guide the tests, depending on the methodology;
• 4.16.4: report the penetration test report to relevant departments to trigger remediation, such as patching;
• 4.16.5 (level 3): continuously review and improve the penetration testing requirements, methods and processes.

The same text gives monthly vulnerability scans of critical systems and at least annual audits of critical systems as examples. A quarterly cadence on critical assets is far more frequent than the annual baseline in SAMA penetration testing, so many ICT providers move to continuous penetration testing rather than four separate projects. Typical scope covers core and edge network infrastructure, customer portals and web applications, provisioning and partner APIs, and cloud platforms.

How does the CST CRF relate to NCA ECC and CCC?

The CST CRF sits alongside the NCA’s Essential Cybersecurity Controls rather than replacing them: the CRF text references NCA ECC and NCA’s Critical Systems Cybersecurity Controls, and states that it is not intended to overwrite any issued regulatory framework. A provider in scope of both works to both.

The NCA ECC-2:2024 document applies to government entities and private-sector entities that own, operate or host Critical National Infrastructure, which describes many large telecom and data-centre operators. Its penetration testing subdomain, 2-11, requires periodic tests of all internet-facing services. Cloud providers also face NCA’s Cloud Cybersecurity Controls; see our guide to NCA CCC cloud cybersecurity controls and the NCA CCC compliance page.

Framework	Regulator	Who it covers	Penetration testing
CST CRF	CST	ICT and postal service providers licensed or registered by CST	Control 4.16 (level 2); quarterly example for critical assets
NCA ECC-2:2024	NCA	Government entities and CNI owners, operators and hosts	2-11: periodic tests of internet-facing services
SAMA CSF	SAMA	SAMA-regulated financial institutions	3.2.4: annual tests of customer and internet-facing services

Providers that host or run services for banks will meet SAMA requirements through their customers’ third-party clauses under SAMA CSF 3.4. Our NCA ECC vs SAMA CSF guide explains how to run one control register across frameworks, and the NCA ECC compliance guide covers ECC in full.

How should an ICT provider prepare for CST CRF compliance?

An ICT provider should prepare for CST CRF compliance by confirming its assigned compliance level, self-assessing every control up to that level, closing gaps with evidence, and keeping a reporting rhythm that matches CST’s requests. Map CRF controls to NCA ECC where both apply so evidence is collected once.

How Sumrite helps

Sumrite supports Saudi ICT, hosting and cloud providers end to end with our verified NCA-registered partner firm, and has served 100+ Saudi clients across Riyadh, Jeddah, Dammam and other cities. We deliver the penetration testing and vulnerability assessment evidence the CRF Logical Security domain depends on, mapped to CRF 4.16 and to NCA ECC 2-11 where both apply, with retests and a report format that feeds straight into your remediation process. Saudi teams can start on our Saudi Arabia page, and our Saudi penetration testing guide maps every test type to the national frameworks.