CST CRF Compliance Levels (CL1 to CL3): A Guide for ICT and Public-Sector Providers

Key Takeaways

• CST’s CRF applies to ICT-sector service providers and the public-sector organizations that depend on them, and it uses a risk-based, tiered structure.
• CL1 sets the foundational security baseline; CL2 adds advanced, structured requirements; CL3 shifts focus to continuous monitoring and improvement of the controls CL1 and CL2 already established.
• All three levels ultimately require evidence, not just documentation, and organizations must progress through the levels over time.
• Scoping, evidence collection, and cross-team ownership trip up most providers, not the control requirements themselves.
• Evidence collection and audit readiness carry the day-to-day burden, which is exactly where a governed AI teammate can hand hours back to the team.

If Saudi Arabia’s Communications, Space and Technology Commission (CST) licenses or regulates your organization, you’ve likely run into the term CRF. It stands for the Cybersecurity Regulatory Framework, the rulebook CST uses to raise the security bar across the Kingdom’s ICT sector, from telecom operators to hosting providers to the public-sector entities that depend on them.

The framework doesn’t run a single pass-or-fail test. It builds around three progressive Compliance Levels, CL1, CL2, and CL3, and understanding which one applies to you, and what it actually asks for, turns compliance into a manageable journey instead of a scramble before an audit.

This guide breaks down what each level covers, how the levels relate to each other, and what ICT and public-sector teams typically get stuck on when they try to close the gap.

What Is the CST CRF?

CST (formerly CITC) established the Cybersecurity Regulatory Framework for service providers in the ICT sector. Its purpose is straightforward: increase cybersecurity maturity across an industry that is both a target for attackers and critical infrastructure for the rest of the economy. Organizations that fall under CST’s regulatory scope must meet the relevant requirements and pass a compliance audit to prove it.

The framework organises its requirements into core control domains that repeat across all three levels, generally covering governance, asset management, risk management, logical security, physical security, and third-party security. The subject matter doesn’t change much between levels. How deep, how formal, and how continuously your team needs to monitor the controls does.

The Three Compliance Levels, Explained

CRF follows a risk-based, tiered approach. The level that applies to a given organization depends on factors like the size of the entity, the criticality of the services it provides, and its overall risk profile. The design is progressive: build a solid foundation at CL1 before adding the depth CL2 demands, and only then take on the continuous-improvement work CL3 expects.

CL1: The Foundational Baseline

CL1 covers the basic security controls. It marks the starting point for smaller licensed entities and lower-risk service providers, and it establishes the foundational cybersecurity hygiene that every other level builds on.

At this stage, organizations typically need to show that:

• Core governance and policy documentation exists, and someone accountable owns it
• The organization has identified and classified its assets, systems, and data
• Baseline risk management practices govern day-to-day decisions
• Fundamental logical and physical security controls protect the environment

CL2: Advanced, Structured Requirements

CL2 adds advanced requirements on top of the CL1 baseline. It applies to medium-sized operators and organizations with moderate risk exposure, and it demands more structure and formality than CL1, not just more controls.

Where CL2 typically raises the bar:

• Risk management becomes an active, structured process rather than a one-time exercise
• Governance requires clearer roles, escalation paths, and policy enforcement
• Independent, third-party validation enters the picture, including activities like penetration testing for in-scope systems
• Documentation must demonstrate that teams actually use the controls, not just that someone wrote them down

CL3: Efficiency Monitoring and Continuous Improvement

CL3 shifts the emphasis. Instead of asking whether the controls exist, it asks whether the organization continuously monitors and improves them. It applies to major operators and critical service providers carrying the largest user bases and the highest risk profiles, and it focuses on the ongoing efficiency and monitoring of the controls CL1 and CL2 already put in place.

What tends to define CL3:

• Continuous monitoring of control performance, not periodic checks
• A documented before-and-after trail that proves iterative improvement over time
• Independent compliance audits from a qualified third party, with formally documented results and remediation plans for regulatory review
• Maturity across every control domain at once, since a strong technical posture cannot offset weak governance or an undertrained workforce

Why Providers Get Stuck Between Levels

The three levels look simple on paper. In practice, most organizations trip over the same few things:

• Scoping. Confirming which level actually applies, and to which systems, services, and business units, often takes more work than the framework summary suggests.
• Evidence, not intent. A written policy doesn’t prove the team follows it. Auditors want records, approvals, and a trail, not a description of good intentions.
• Cross-team ownership. Governance, asset management, risk, and security operations usually sit with different teams. CRF expects them to move together.
• Keeping pace after the audit. CL2 and CL3 don’t reward a one-time push. Teams need to keep building the evidence trail, so the work doesn’t stop once the organization passes the audit.

Where Secure.com Fits

This is the part teams tend to treat as an afterthought, and it shouldn’t be. Compliance work under CRF is largely evidence work: teams have to collect, keep current, and produce controls posture, audit readiness, and trust reporting on demand.

Governed Defense, Powered by Offense. No More Grunt Work. No More Burnout. AI teammates attack your defenses, harden what they find, and hand your team back hundreds of hours a month. Your team sets the rules. AI teammates do the work. Attack. Harden. Prove. Repeat.

For a framework like CRF, that plays out concretely through the GRC AI Teammate, which owns controls, compliance posture, evidence collection, audit readiness, and trust reporting. It works inside the scope, permissions, and approvals your team sets, so it collects the control evidence CL1 through CL3 require and keeps that evidence current, instead of turning it into another manual chase before every audit cycle. And for CL2 and CL3 organizations specifically, where independent validation like penetration testing enters the picture, the Red AI Teammate attacks the environment within approved scope to find what’s genuinely exploitable, feeding real evidence into what the team hardens next rather than a theoretical risk list.

Both run on Security OS, the shared foundation behind every AI Teammate, and each one delivers value on its own from day one. Your team keeps authority over scope and approvals throughout. The goal isn’t fewer people on your compliance program, it’s hours back for the people already running it.

FAQs

Conclusion

CST didn’t design CRF to catch organizations out. It designed the framework to move the ICT sector toward a higher, provable standard of cybersecurity maturity, one level at a time. The organizations that handle it best treat CL1, CL2, and CL3 as a continuum rather than three separate deadlines, and they invest early in the unglamorous part: keeping evidence current, not just writing policies. Understanding where you sit today, and what the next level actually asks for, marks the difference between a compliance program that’s ready when the auditor calls and one your team rebuilds from scratch every cycle.