A Practical Guide to NCA ECC and CSCC Compliance Using Picus
| June 16, 2026
What Is the National Cybersecurity Authority (NCA)?
The National Cybersecurity Authority (NCA) is Saudi Arabia's government body responsible for national cybersecurity policy, governance, and regulation, established by Royal Decree in 2017.
It sets mandatory controls for government entities, critical infrastructure operators, and organizations whose operations could affect national security. Its frameworks are not voluntary: organizations in scope must implement controls, demonstrate compliance, and accept audits.
What Is the Essential Cybersecurity Controls (ECC)?
The ECC is the NCA's baseline framework, defining the minimum controls in-scope organizations must implement.
Its domains span network and email security, vulnerability management, penetration testing, event logging, incident management, web application security, and cloud computing. What sets it apart is the inclusion of performance indicators within the controls: organizations must measure whether controls are working, not just deploy them.
What Is the Critical Systems Cybersecurity Controls (CSCC) and How Does It Relate to the ECC?
The CSCC applies to operators of critical systems in sectors such as energy and water treatment.
It is an extension of the ECC, not a replacement. An organization subject to the CSCC must also fully meet the ECC. What the CSCC adds is tighter cadences: six-monthly firewall reviews, monthly vulnerability assessments, and penetration testing at least twice a year.
Who Is in Scope for ECC and CSCC?
The ECC applies broadly to government entities, state-owned enterprises, financial institutions, telecom operators, and organizations in regulated sectors.
The CSCC applies specifically to operators of critical systems whose disruption could affect national security or essential services. Organizations in energy, utilities, transportation, and healthcare should assess whether their systems meet the NCA's definition of critical systems, rather than assuming sector membership alone determines scope.
What Does "Periodically" in ECC and CSCC Require in Practice?
The ECC requires periodic review across most of its control domains but does not prescribe a fixed interval for most of them.
The CSCC removes that ambiguity for critical systems: six months for configuration and firewall reviews, monthly for vulnerability assessments, twice yearly for penetration testing. For ECC-only organizations, the key is a defensible, risk-proportionate interpretation they can present to auditors.
What Does the NCA Expect from Evidence of Compliance?
Control presence is not the same as control effectiveness. Deploying a tool or writing a policy satisfies the implementation requirement, but meeting the periodic review requirement and the ECC's performance indicators requires evidence: test results, assessment findings, and documented remediation.
The NCA's direction of travel is toward continuous, evidence-backed assurance. A control that worked six months ago is not proof that it works today.
Validating NCA ECC and CSCC Compliance With Picus
The NCA's ECC and CSCC are built around one recurring demand: don't just implement controls, review them periodically and prove they still work. Done by hand ( a pentest here, an audit there) that proof goes stale the moment the environment changes.
The Picus Platform answers that demand continuously. Through Adversarial Exposure Validation (AEV), which combines agentic, autonomous Breach and Attack Simulation (BAS) and Autonomous Penetration Testing, Picus tests whether the risks identified in an entity's assessment are genuinely exploitable against its live controls, on whatever cadence the framework requires. Rather than relying on assumptions, it measures whether controls actually block and detect, maps high-risk attack paths to critical assets, separates exploitable exposures from theoretical ones, and tunes prevention and detection.
Every threat in the Picus Threat Library is mapped to MITRE ATT&CK, results feed real-time reports and dashboards, and each finding carries vendor-specific and vendor-neutral, ready-to-deploy mitigation guidance from the Picus Mitigation Library. Both libraries are curated by Picus Labs and updated continuously, including newly disclosed threats with available PoCs.
That combination of validation on any cadence, ATT&CK mapping, and current intelligence is what turns the NCA's "review periodically" obligations from an aspiration into something Saudi organizations can actually sustain.
Showing NCA ECC Compliance with Picus
The following sections map specific ECC controls to the Picus Platform's validation capabilities. Each section states the control, its objective, and its requirements, then shows how Picus Platform supports compliance with defensible, audit-ready evidence.
Domain 1 (Cybersecurity Governance)
1-8 Periodical Cybersecurity Review and Audit
|
Objective: To ensure that cybersecurity controls are implemented and in compliance with organizational policies and procedures, as well as related national and international laws, regulations, and agreements. Controls:
|
How the Picus Platform supports this requirement
The Picus Platform's threat emulation capability lets organizations run these reviews on a daily, weekly, or monthly basis, validating the prevention and detection capability of network and security controls and returning vendor-specific mitigations to block or detect attacks.
Because Picus has no stake in the controls it tests, the evidence it produces is objective and vendor-neutral. It is exactly what an independent reviewer needs for the audits 1-8-2 requires. Picus strengthens that independent review rather than standing in for the independent party the control calls for.
The platform's technical and management reports document simulation results, generate security scores, and track how posture changes over time, giving the cybersecurity function the documented findings, recommendations, and remediation plans that 1-8-3 expects.
Domain 2 (Cybersecurity Defense)
2-3, 2-4, 2-5, 2-7 Protecting Systems, Email, Networks, and Data
|
Objectives:
Controls: The cybersecurity requirements for each domain must be reviewed periodically (2-3-4, 2-4-4, 2-5-4, 2-7-4) |
How the Picus Platform supports this requirement
The Picus Platform addresses these domains through continuous, autonomous emulation.
For systems and processing facilities, scheduled simulations validate that controls block and detect the latest threats, drawing on a threat library that is updated daily.
For email, the library contains hundreds of email attacks that test whether malicious attachments and links are stopped by email security controls, on whatever cadence the organization needs.
For network security, hundreds of infiltration attacks exercise next-generation firewalls, IPS, IDS, web gateways, and proxies, with detailed reports showing where to improve.
For data protection, the platform simulates data exfiltration over HTTP, HTTPS, and TCP to confirm that controls actually prevent and detect data leaving the environment. In every case the periodic-review requirement is satisfied by running the validation on a schedule rather than as a one-off exercise.
Figure 1. Picus Security Control Validation, Data Exfiltration Attacks Module
2-10 Vulnerabilities Management
|
Objective: To ensure timely detection and effective remediation of technical vulnerabilities to prevent or minimize the probability of exploitation. Controls:
|
How the Picus Platform supports this requirement
The challenge most teams face here is not finding vulnerabilities, it is knowing which ones matter. Scanners routinely return thousands of findings, most flagged by theoretical severity alone.
The Picus Platform runs real attack simulations against live defenses to prove which vulnerabilities are genuinely exploitable in the actual environment and deprioritizes the rest. It then produces a single, transparent exposure score that blends CVSS, EPSS, KEV data, validated control effectiveness, and asset business criticality, which is precisely the classification by criticality and risk-based prioritization the control demands.
Step-by-step remediation guidance and ready-to-deploy mitigation rules close the validated gaps, integrations with CAASM, RBVM, and VM tools pull in context data, scheduled testing satisfies the periodic-review requirement, and daily threat updates keep the program aligned with current intelligence.
Figure 2. Picus Platform Assigns a Context-based Picus Score
2-11 Penetration Testing
|
Objective: To assess and evaluate the efficiency of the organization's cybersecurity defense capabilities through simulated cyber-attacks that discover unknown weaknesses within the technical infrastructure. Controls:
|
How the Picus Platform supports this requirement
The Picus Platform supports this in two complementary ways. Its breach and attack simulation capability tests controls and overall readiness against a wide range of advanced threats, surfacing misconfigurations and policy weaknesses that could be exploited.
Its autonomous penetration testing capability, driven by an AI decision engine, conducts autonomous, network-wide internal penetration testing to find high-risk paths to key assets, performing harvesting and attack actions such as privilege escalation, lateral movement, credential brute-forcing, and Kerberoasting, then prioritizing mitigation at the choke points where multiple paths converge.
2-15 Web Application Security
|
Objective: To ensure the protection of external web applications against cyber risks. Control: The cybersecurity requirements must be reviewed periodically (2-15-4) |
How the Picus Platform supports this requirement
The Picus Platform's threat library contains hundreds of web application attacks that let teams continuously test and review their web application firewalls.
Picus can test against the OWASP Top 10 and SANS Top 25 web application threats, and detailed summary reports show where controls need improvement and support the evidence required for compliance. Periodic runs keep the review continuous rather than a once-a-year event.
2-12 Cybersecurity Event Logs and Monitoring Management
|
Objective: To ensure timely collection, analysis, and monitoring of cybersecurity events for early detection of potential cyber-attacks in order to prevent or minimize negative impacts on operations. Control: The cybersecurity requirements must be reviewed periodically (2-12-4) |
How the Picus Platform supports this requirement
A logging control is only as good as its ability to turn an event into an alert. The Picus Platform integrates with SIEM, EDR, XDR, and SOAR platforms to give visibility into detection efficacy, confirming that controls capture logs and promptly raise alerts when threats are simulated.
It recommends missing log sources to onboard and supplies thousands of vendor-specific and SIGMA-based correlation rules. Its detection rule validation capability goes further, assessing SIEM rules for performance and hygiene, flagging missing, redundant, or obsolete rulesets, identifying logged events that never generate alerts, and measuring the delay between event and alert, all of which reduces false positives and shortens attacker dwell time. Running these simulations on a cycle delivers the continuous monitoring assurance the control expects.
Domain 4 (Third-Party and Cloud Computing Cybersecurity)
4-2 Cloud Computing and Hosting Cybersecurity
|
Objective: To ensure the proper and efficient remediation of cyber risks and implementation of cybersecurity requirements related to cloud hosting and cloud computing. Controls:
|
How the Picus Platform supports this requirement
The Picus Platform validates cloud security the way an attacker would test it. Through Breach and Attack Simulation, it runs discrete cloud attack actions across AWS, Azure, and GCP, such as IAM role escalation, malicious role CloudFormation updates, public bucket exposure, and metadata service abuse, each mapped to MITRE ATT&CK, and measures whether your cloud controls detect and prevent them.

Figure 3. Picus Platform can simulate cloud-based attacks for Azure, AWS, and GCP.
The result shows exactly where configurations, identities, and access controls hold or break down, paired with actionable remediation guidance. This directly addresses 4-2-3's requirement to validate cloud configurations, identities, and access controls, with evidence that they are correctly implemented and effective rather than merely present.

Figure 4. Cloud-based attack TTPs with privileged access
Run on a schedule, this turns the periodic review of 4-2-4 into ongoing assurance over cloud posture against the ECC's cloud requirements, not a once-a-year snapshot.
Showing NCA CSCC Compliance with Picus
For organizations running critical systems, the CSCC layers stricter expectations on top of the ECC, mostly in the form of shorter cadences and tighter scope. The validation approach is the same, but the frequency and rigor increase. The following sections map the key CSCC controls to the Picus Platform in the same way.
Domain 1 (Cybersecurity Governance)
1-4 Periodical Cybersecurity Review and Audit
|
Objective: To ensure that critical-systems cybersecurity controls are implemented and in compliance with the CSCC. Controls:
|
How the Picus Platform supports this requirement
Scheduled simulations against critical systems produce scored, time-stamped records of what was tested, what was found, and what was remediated, which serve as the audit-ready evidence for both the annual internal review and the three-yearly independent review
Because Picus has no stake in the controls it tests, the evidence it produces is objective and vendor-neutral, exactly what the independent reviewer needs for the 1-4-2 audit. Picus strengthens that independent review rather than standing in for the independent party the control requires.
Domain 2 (Cybersecurity Defense)
2-3 Systems and Information Processing Facilities Protection
|
Objective: To protect critical systems and information processing facilities against cyber risks. Control: Critical-system configurations and hardening must be reviewed at least every six months (2-3-1-6). |
How the Picus Platform supports this requirement
The six-monthly hardening review becomes continuous when thousands of real-world threats are simulated against critical systems on a schedule. Each run validates that system and hardening controls block and detect current attacks, with vendor-specific mitigations and time-stamped reports that evidence the review against the required cadence.
2-4 Network Security Management
|
Objective: To protect critical-system networks from cyber risks. Controls:
|
How the Picus Platform supports this requirement
Hundreds of autonomous infiltration attacks, including advanced persistent threat-style campaigns, exercise next-generation firewalls, IPS, IDS, web gateways, and proxies to confirm that network controls block and detect what they are configured to stop.
Autonomous penetration testing capability of Picus Platform complements this by identifying and helping to close network paths to critical assets, and scheduled runs satisfy the six-monthly firewall and access-list review while continuously testing APT-layer protection.
2-9 Vulnerabilities Management
|
Objective: To ensure timely detection and remediation of technical vulnerabilities in critical systems. Controls:
|
How the Picus Platform supports this requirement
On critical systems, the CSCC's monthly assessment and its demand for immediate remediation of critical findings leave no room for chasing scanner noise. The Picus Platform separates the genuinely critical from the merely high-severity: it ingests vulnerability data from your existing VM tools, maps each CVE to real ATT&CK behaviors, and runs full kill-chain tests against live controls to prove which vulnerabilities are actually exploitable in the environment and which are already contained by layered defenses.
That evidence drives a Picus Score based on validated exploitability, so teams remediate the findings that truly threaten critical systems first. Scheduled monthly runs produce the time-stamped record the monthly assessment and remediation requirements expect, and after a patch is applied, the same test is re-run to confirm the exposure is actually closed rather than assumed.
2-10 Penetration Testing
|
Objective: To assess the cybersecurity defense capabilities of critical systems through simulated cyber-attacks. Controls:
|
How the Picus Platform supports this requirement
Picus Platform’s autonomous penetration testing capability conducts network-wide pentesting across that full scope, including lateral movement, privilege escalation, credential harvesting, Kerberoasting, and data exfiltration paths.
Scheduled on the six-monthly cadence, it automates the repetitive, network-wide portions of testing so the qualified team can concentrate on the judgment-driven work, supporting the engagement the control requires rather than replacing it.
2-12 Web Application Security
|
Objective: To protect critical-system web applications against cyber risks. Control: Secure session management and compliance with OWASP Top Ten standards for critical-system web applications (2-12-1) |
How the Picus Platform supports this requirement
The platform's threat library tests critical-system web applications against the OWASP Top Ten and SANS Top 25 web application threats, continuously validating web application firewalls and producing summary reports that show where controls need improvement and evidence the OWASP-alignment requirement.
2-11 Cybersecurity Event Logs and Monitoring Management
|
Objective: To ensure timely collection and monitoring of cybersecurity events on critical systems for early attack detection. Control: Logging must be enabled on all critical-system components, with alerting on the latest adversary behaviors (2-11-1). |
How the Picus Platform supports this requirement
A log that no one alerts on is invisible, so 2-11-1's real test is not whether logging is switched on but whether the log-to-alert chain fires against the latest attacks. Picus runs current adversary behaviors, drawn from a Threat Library that Picus Labs updates continuously, against critical-system components and measures, technique by technique, whether each event is logged with enough granularity and whether it raises an alert, showing which techniques trigger one and which slip through. Its detection rule validation capability flags missing, redundant, or obsolete rules and measures the delay between event and alert.
Where a behavior is logged but never alerts, Picus supplies ready-to-deploy detection content in vendor-specific and SIGMA formats, each mapped to its log source and MITRE ATT&CK technique, then re-runs the same behavior to confirm the alert now fires. This proves that monitoring across critical-system components detects the latest adversary behavior, not merely that logging is enabled.
Making NCA Compliance Resilient with Validation
The NCA's ECC and CSCC aim to ensure that the Kingdom's systems and critical infrastructure remain resilient because the controls protecting them work in practice, not just on paper.
The expansion of the ECC in its 2024 release to cover cloud, industrial control systems, and built-in performance indicators signals that this framework is maturing and enduring. Organizations should approach their NCA obligations as a long-term investment in continuous assurance, not a short-term compliance exercise.
Picus helps organizations move from periodic, assumption-based compliance to continuous, evidence-based assurance. By validating control effectiveness against real attack behavior, Picus turns NCA compliance into a living, defensible security posture, one that satisfies the expectations of auditors, the cybersecurity steering committee, and the Authorizing Official not just at the time of assessment, but continuously.
Get your demo and see how Picus helps Saudi organizations meet their ECC and CSCC obligations with audit-ready evidence.


