NCA CSCC: Critical Systems Cybersecurity Controls

The Critical Systems Cybersecurity Controls (CSCC – 1: 2019) are the NCA's higher-assurance control set for the systems whose failure would hurt more than the organisation that owns them. They sit on top of the Essential Cybersecurity Controls, and they are the point at which Saudi cybersecurity regulation stops being about your risk and starts being about the Kingdom's.

The hardest part of CSCC compliance is not implementing the 32 controls. It is the step before that: deciding which of your systems are critical. Get the identification wrong in one direction and you are running a heavyweight control regime across your whole estate. Get it wrong in the other and you have an unprotected system that the NCA considers nationally significant.

What makes a system "critical"

The NCA's definition is impact-based, not technology-based:

Any system or network whose failure, unauthorized change to its operation, unauthorized access to it, or to the data stored or processed by it; may result in negative impact on the organization's businesses and services' availability, or cause negative economic, financial, security or social impacts on the national level.

To operationalise that, the CSCC gives seven identification criteria. A system is a candidate for critical classification if its compromise would cause:

Two of those criteria are quantified, and they are the ones that make the exercise tractable. Criterion 3 anchors "significant financial loss" to 0.01% of GDP rather than to the organisation's own materiality threshold — a deliberately national yardstick. Criterion 4 sets the user-impact test at 5% of the population, which for a Saudi entity is a defined and checkable number rather than a matter of judgement.

What counts as part of a critical system

Criticality does not stop at the application. The CSCC lists ten components, eight of them technical:

• Network — connecting devices (routers, switches, gateways), firewalls, IDS/IPS, and APT protection devices
• Databases, storage assets, middleware
• Servers and operating systems, applications
• Encryption devices
• Peripherals — including printers and scanners
• Individuals in supporting roles — users, technical staff with significant and sensitive privileges, operators and service providers
• Documents relating to all of the above

That list is where scope inflates in practice. A critical application implies a critical database, the servers under it, the network path to it, the printer it sends to, the runbook that describes it, and the named people who operate it. Organisations that scope CSCC as "the application" and then discover the peripherals and documentation clauses during assessment usually have to redo the exercise.

Scope and structure

The CSCC applies to systems deemed critical by the organisations that own or operate them — government organisations in the Kingdom or abroad (ministries, authorities, establishments, embassies and others), and subsidiaries of government or private organisations. Compliance is mandated under item 3 of article 10 of the NCA's mandate, Royal Decree No. 57231 dated 10/11/1439H and Royal Decree No. 7732 dated 12/2/1440H.

The four domains are Cybersecurity Governance (strategy, risk management, cybersecurity in IT project management, periodical review and audit, human resources), Cybersecurity Defense (13 subdomains from asset management through application security), Cybersecurity Resilience (BCM aspects), and Third-Party and Cloud Computing Cybersecurity.

As with the rest of the NCA family, CSCC controls are written as increments to named ECC controls, and continuous ECC compliance is a prerequisite for CSCC compliance. Appendix A of the document maps the relationship between the two control sets.

The controls that change how you operate

Most CSCC controls tighten a frequency or add an assurance step. A handful change the operating model outright, and those are the ones to plan around.

Remote access from outside the Kingdom is prohibited

Subcontrol 2-2-1-1 prohibits remote access to critical systems from outside the Kingdom of Saudi Arabia — full stop. Subcontrol 2-2-1-2 then restricts remote access from inside the Kingdom, requiring each access attempt to be verified by the organisation's security operations centre and remote-access activity to be continuously monitored.

A global vendor's follow-the-sun support model is incompatible with CSCC 2-2-1-1. If a critical system is supported from Bangalore, Dublin or Dubai overnight, that support arrangement has to be redesigned — not documented as a compensating control.

The same domain requires multi-factor authentication for all users (2-2-1-3) and again for privileged users and the systems used to manage critical systems (2-2-1-4), secure password storage using hashing (2-2-1-6), securely managed service accounts with interactive login disabled (2-2-1-7), and — a control that surprises many DBAs — prohibition of direct database access for all users except database administrators (2-2-1-8), with users reaching data only through applications and security solutions limiting the visibility of classified data even to administrators.

Saudi nationals in critical roles, Saudi companies for outsourcing

Two nationality-linked controls sit either side of the employment boundary:

• 1-5-1-2 — technical support and development positions for critical systems must be filled with experienced Saudi professionals. 1-5-1-1 additionally requires screening or vetting of candidates working on critical systems.
• 4-1-1-2 — outsourcing and managed services of critical systems must rely on Saudi companies and organisations, in accordance with relevant legislative and regulatory requirements. 4-1-1-1 requires screening or vetting of the outsourcing companies and their personnel.

Together with the remote-access prohibition, these three controls mean the operating model for a critical system is substantially in-Kingdom: Saudi staff in the support and development roles, Saudi suppliers for managed services, and no offshore remote access. This is a procurement and workforce plan, not a security configuration.

Hosting: still in-Kingdom, from a different document

Subcontrol 4-2-1-1 requires hosting of critical systems and any part of their technical components to be either inside the organisation, or within cloud services provided by government organisations or Saudi companies compliant with the NCA's Cloud Cybersecurity Controls — taking the classification of the hosted data into account.

The assurance cadence

CSCC replaces "periodically" with numbers throughout. The ones to put in a calendar:

Six-monthly penetration testing across all technical components of every critical system, by a qualified team (2-10-1-2), is the line item that most often forces a change in testing budget and vendor arrangements.

Implementation and how the NCA assesses it

The document sets out three obligations in sequence: identify critical systems using the criteria; implement the controls on the identified systems within the compliance period defined by the NCA, managing cybersecurity risks during that period; and ensure continuous compliance after it. The NCA evaluates compliance through self-assessments and on-site audits, by whichever mechanism it considers appropriate.

Note the middle obligation carefully. The NCA expects risk to be assessed and managed during the compliance period — so the gap between identifying a critical system and finishing its controls is itself something you must be able to show you governed, with those risks on the register and scored on the NFCRM matrix.

A CSCC readiness sequence

1. Run a documented critical-systems identification against the seven criteria, scoring each candidate system and recording the reasoning for both inclusions and exclusions.
2. Expand each identified system to its ten components — network path, database, storage, middleware, servers, applications, encryption devices, peripherals, people and documentation.
3. Confirm the ECC baseline on those systems. CSCC increments a control set you must already hold.
4. Fix the operating-model controls first — offshore remote access, non-Saudi support and development staffing, non-Saudi managed services, and hosting location. These have procurement and HR lead times measured in months; the technical controls do not.
5. Put the frequencies in a calendar with owners, and instrument the ones you can — patch cycles, vulnerability scans, access reviews.
6. Book the independent review. The three-yearly review by parties outside the cybersecurity function needs planning and, usually, budget.

How GRC Vantage supports CSCC compliance

GRC Vantage's compliance module carries the CSCC library mapped control-by-control to its ECC parents, so the two assessments share evidence rather than duplicating it, and a critical-systems register that scores each candidate system against all seven identification criteria — producing the documented rationale an NCA assessment asks for first. Each identified system carries its component inventory, so scope covers the network path, the database, the people and the documentation rather than just the application.

The recurring obligations — monthly patching and scanning, quarterly access reviews and recovery tests, six-monthly penetration tests and firewall reviews, the annual and three-yearly reviews — are scheduled as evidence-bearing tasks with owners and reminders, so the cadence is demonstrable rather than asserted. Third-party controls under 4-1 and hosting under 4-2 sit in the vendor workflow alongside your CCC provider assurance.

For the full framework family, see the NCA frameworks pillar guide and our NCA ECC compliance guide. To scope a critical-systems identification exercise, talk to our team.

Frequently asked questions

What is the NCA CSCC?

The Critical Systems Cybersecurity Controls (CSCC – 1: 2019) are the NCA's control set for systems whose compromise would have national-level impact. They comprise 4 main domains, 21 subdomains, 32 main controls and 73 subcontrols, and they extend the Essential Cybersecurity Controls — continuous ECC compliance is a prerequisite.

How do I identify a critical system?

Apply the seven CSCC criteria: impact on national security; impact on the Kingdom's reputation; financial losses above 0.01% of GDP; impact on services to more than 5% of the population; loss of life; unauthorised disclosure of Top Secret or Secret data; and impact on the operations of one or more vital sectors.

Does the CSCC prohibit offshore support for critical systems?

Effectively, yes. Subcontrol 2-2-1-1 prohibits remote access to critical systems from outside the Kingdom, 1-5-1-2 requires technical support and development positions to be filled by experienced Saudi professionals, and 4-1-1-2 requires outsourcing and managed services to rely on Saudi companies.

Can critical systems be hosted in a public cloud?

Only inside the organisation, or in cloud services from government organisations or Saudi companies that comply with the NCA's Cloud Cybersecurity Controls, with the classification of the hosted data taken into account (4-2-1-1). This requirement is unaffected by CCC-2:2024's removal of its own in-Kingdom delivery subcontrols.

How often must critical systems be penetration tested?

At least once every six months, with the scope covering all technical components of the critical systems and testing conducted by a qualified team (2-10-1 and 2-10-2).