Saudi NCA OTCC Guide: Levels, Controls, Compliance

Any Saudi government organisation or critical infrastructure operator running industrial control systems has to meet a separate National Cybersecurity Authority control set for its operational technology, and most of the hard requirements sit there rather than in the ECC. The Operational Technology Cybersecurity Controls (OTCC-1:2022) set minimum cybersecurity requirements for industrial control systems (ICS) in critical facilities, scaled by a facility criticality level. This guide explains who the OTCC applies to, how facility levels decide which controls apply, what the identity, segmentation, removable media, logging, backup and third-party controls actually say, and how to run a compliance programme against it. It is written for OT security leads, plant engineering managers, GRC teams and the integrators and service providers who work inside Saudi critical facilities. Status line: checked against the NCA's OTCC page on 13 November 2026, which lists OTCC-1:2022 (published 2 June 2022, page last updated 29 October 2025) as the current version.

Key takeaways

OTCC extends the ECC, it does not replace it. The OTCC document says ECC compliance is a prerequisite, and ECC-2:2024 records that its old Domain 5 (Industrial Control Systems Cybersecurity) moved to the OTCC.
Facility level decides your control set. Each facility with OT/ICS is rated L1 (high), L2 (moderate) or L3 (low) with the NCA Facility Level Identification Tool; L1 applies 151 controls and subcontrols, L2 applies 117 and L3 applies 56.
Identity in OT is its own lifecycle. Control 2-2-1-1 requires OT identity and access management to be separate from and independent of IT, and 2-2-1-2 requires service accounts to be managed securely and separated from interactive logins.
No direct path from corporate to OT. Control 2-4-1-9 prohibits direct corporate to OT communication; access goes through a hardened jump host in a DMZ, and safety instrumented systems are segmented from other OT networks (2-4-1-3).
Many frequencies are yours to define. The document fixes an annual internal review (1-6-1) and an independent review at least every three years (1-6-2), but leaves log retention, backup frequency and most testing intervals to the organisation's own risk-based policy.

What the OTCC is and who it applies to

The NCA published the OTCC to raise the cybersecurity level of OT systems in the Kingdom. It describes itself as an extension of the Essential Cybersecurity Controls, aligned with international standards. The document defines ICS as a collective term for control systems and associated instrumentation, including the devices, systems, networks and controls used to operate or automate industrial processes. OT is the wider set of components (network devices, computers, servers, cybersecurity devices, infrastructure equipment and applications) that support operation, maintenance, monitoring and cybersecurity of the OT/ICS environment.

Entity	OTCC status	Practical note
Government organisations with ICS in critical facilities, inside or outside the Kingdom	Mandatory	Includes facilities owned or operated by the organisation
Private sector organisations that own, operate or host critical national infrastructure (CNI) with ICS	Mandatory	Hosting is in scope, so operators and service providers running OT on behalf of CNI owners should check carefully
Other organisations in the Kingdom	Strongly encouraged	Often required indirectly through procurement and contract terms (subdomain 4-1)
Integrators, OEMs and maintenance providers	Indirect	Bound through 4-1 procurement requirements, SDLC expectations and periodic third-party assessments

Two conditions in the document matter in practice. First, organisations must confirm that applying a control will not jeopardise operational continuity, which makes the safety and operations case part of every implementation decision. Second, the Arabic version is the binding text for interpretation; the English translation is for reference.

Version note: OTCC-1:2022 was written as an extension of ECC-1:2018. ECC-2:2024 has since replaced ECC-1:2018 and its change appendix states that the Domain 5 controls moved to the OTCC. Build your ECC baseline on ECC-2:2024 and keep a note of where your OTCC mapping references ECC-1 control numbers. See the Saudi NCA Essential Cybersecurity Controls Guide for the baseline itself.

Facility levels and how they set your control set

The OTCC is risk-tiered by facility, not by organisation. The Methodology and Mapping Annex describes two steps: rate each facility that contains OT/ICS with the Facility Level Identification Tool, then apply the controls for that level. Controls above the required set are encouraged, not mandated.

Level	Criticality (annex wording, summarised)	Controls and subcontrols that apply
L1	High: severe adverse effects on operations, assets, resources or health, safety and environment (HSE)	151, including all L2 and L3 controls
L2	Moderate: significant adverse effects	117, including L3 controls
L3	Low: moderate adverse effects	56

The annex lists nine criteria for the rating: impact on onsite or offsite population, environmental impact, national security, the Kingdom's reputation and public image, unauthorised disclosure of Secret or Top Secret data, disruption to the national economy, impact on a large number of beneficiaries, national infrastructure interdependencies, and facility interdependencies.

Mixed facilities: a facility takes the level of its most critical system, so one L1 safety system pulls the whole site to L1.
Separated facilities: facilities that are genuinely isolated from each other can carry different levels and different control sets. The isolation has to be real and evidenced, otherwise the higher level applies.
Record the rationale: keep the completed tool output, the criteria scores and the sign-off per facility. It is the first thing an assessor will ask for, and it is the basis for every "not applicable" you claim.

For the consequence-based thinking behind such ratings, see the Consequence-driven OT Risk (CCE) Guide and the OT Cyber Physical Risk and Safety Guide.

Structure of the control set

The document states 4 main domains, 23 subdomains, 47 main controls and 122 subcontrols. Unlike ECC-2:2024, there is no cloud domain, and Domain 4 is third-party only.

Domain	Subdomains	OT-specific emphasis
1 Cybersecurity Governance	1-1 Policies and procedures; 1-2 Roles and responsibilities; 1-3 Risk management; 1-4 ICS project management; 1-5 Change management; 1-6 Periodical review and audit; 1-7 Human resources; 1-8 Awareness and training	Security in the OT project lifecycle and acceptance testing; changes validated in a separate environment first; vetting of everyone with OT access, including contractors
2 Cybersecurity Defense	2-1 Asset management; 2-2 Identity and access management; 2-3 System and processing facilities protection; 2-4 Network security management; 2-5 Mobile devices; 2-6 Data and information protection; 2-7 Cryptography; 2-8 Backup and recovery; 2-9 Vulnerability management; 2-10 Penetration testing; 2-11 Event logs and monitoring; 2-12 Incident and threat management; 2-13 Physical security	Separate OT identity, zone segmentation and DMZ, removable media scanning, safety system protection, offline backups including engineering files, low-impact vulnerability assessment
3 Cybersecurity Resilience	3-1 Cyber resilience aspects of business continuity management	Continuity planning that covers OT recovery
4 Third-Party Cybersecurity	4-1 Third-party cybersecurity	Security in OT procurement, supplier SDLC, periodic supplier assessments

The annex describes the relationship to the ECC at subdomain level: 20 ECC subdomains are extended with OT-specific controls, one subdomain is new, two are modified and four have no OT-specific controls. Change management (1-5) is the clearest OT addition: 1-5-3-2 requires changes to be validated in a separate environment before production, 1-5-3-3 requires the security of a functionally equivalent replacement device to be validated before use, 1-5-3-4 restricts exceptional changes and 1-5-3-5 requires automated configuration and asset change detection.

Identity and access requirements

Subdomain 2-2 is where OTCC differs most from typical IT practice, and where machine and service identities matter most. Engineering workstations, historians, HMIs and PLC programming software all run on shared, service and vendor accounts that rarely appear in corporate identity programmes.

Control	Requirement (paraphrased)	What it means in practice
2-2-1-1	OT identity and access lifecycle separate from and independent of IT, centrally managed	A dedicated OT directory or domain with no trust that lets a compromised corporate admin reach OT
2-2-1-2	Service accounts managed securely and separated from interactive logins	Inventory every OPC, historian, backup and vendor service account; deny interactive logon; assign an owner
2-2-1-3	Default credentials changed, disabled or removed	Include controllers, switches, serial gateways and safety system engineering tools, not just Windows hosts
2-2-1-6	Dual approval and explicit privilege escalation for sensitive OT actions	Two-person approval for logic downloads, safety system changes and firmware updates
2-2-1-7	Remote access restricted and enabled only when justified, with prior risk assessment, trusted MFA, encryption, limited privileges, and monitored and recorded sessions	Remote access off by default, opened per request and time window
2-2-1-8, 2-2-1-9	Secure, complex password standards; secure storage of OT asset passwords	A vault or equivalent for device and shared credentials, with check-out logged
2-2-1-10	Identities and access rights reviewed after incidents, role changes or OT architecture changes	Event-driven reviews on top of periodic ones
2-2-1-11	Access revoked immediately when no longer needed	Contractor end dates enforced by the system, not by memory

Two related controls sit outside 2-2: 2-3-1-4 applies least privilege and least functionality to systems, and 2-4-1-10 allows DMZ remote access points to connect to OT only when needed, with MFA and recorded sessions for a limited time. See the OT and ICS Identity and Access Guide and the OT Remote Access Guide for design patterns, and the OT Third-Party and Integrator Access Guide for vendor accounts.

Network, systems and data controls

Segmentation (2-4-1-1, 2-4-1-2): OT is segmented logically or physically from other networks, and internal zones are segmented by level with traffic directed through choke points. This maps naturally to IEC 62443 zones and conduits; see the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
Safety systems (2-4-1-3, 2-3-1-5): safety instrumented systems (SIS) are segmented from other OT networks, and SIS controllers must run in appropriate modes at all times, with changes to other modes only in exceptional cases for a specified time. Monitor key switch and run/program mode state as a security signal.
Corporate to OT (2-4-1-9, 2-4-1-11 to 2-4-1-13): no direct corporate to OT communication; a hardened jump host in the DMZ, proxies for machine-to-machine traffic between corporate and OT, dedicated gateways, and a dedicated DMZ for systems such as historians that need corporate services.
Protocols and wireless (2-4-1-14, 2-4-1-4, 2-4-1-5): industrial protocols and ports restricted to the minimum needed; wireless restricted and segmented.
Removable media (2-3-1-8, 2-3-1-9): external storage media scanned for malware in an isolated, secure environment, and use in production restricted unless secure transfer mechanisms are in place. A kiosk outside the OT zones plus a one-way or controlled transfer path is the common pattern; see the Removable Media and USB Control Guide.
Patching (2-3-1-3, 2-4-1-15): patches follow vendor guidance and formal change management, and production patches must be vendor-certified and tested in a separate environment first. See the OT Patch Management Guide.
Data (2-6-1-1 to 2-6-1-4): data protected at rest and in transit by classification, DLP for classified data, secure wiping of configuration and stored data before decommissioning, and limits on using OT data outside production without strict controls.
Cryptography (2-7): cryptographic technologies in OT must align with the NCA National Cryptographic Standard (NCS-1:2020). Plan for legacy devices that cannot meet it by placing compensating controls on the conduit rather than the device.
Backup (2-8-1-1 to 2-8-1-4): backups for all OT assets in centralised, offline locations, including critical configuration and engineering files, at a frequency set by classification and risk, with access, storage and transfer secured. See the OT Backup, Recovery and Golden Image Guide.

Monitoring, testing and incident response

Subdomain 2-11 asks for more than log collection. Event logs and audit trails are enabled for all OT assets (2-11-1-1), failed access attempts to monitoring systems are logged (2-11-1-2), logs get continuous in-depth review (2-11-1-3), user behaviour analytics is performed (2-11-1-4), uploads and downloads to OT assets including SIS are detected (2-11-1-5), all remote sessions are monitored (2-11-1-6), malicious events are detected and analysed (2-11-1-7), new or unauthorised devices trigger alerts (2-11-1-8) and OT threat intelligence tunes SIEM alerting (2-11-1-9). The OTCC document does not set a log retention period: define one in policy and make sure it is at least what your ECC baseline requires. See the OT Network Security Monitoring Guide.

Vulnerability assessments must have limited or no impact on production (2-9-1-1), critical vulnerabilities are remediated in a timely manner (2-9-1-2) and assessments run periodically (2-9-1-3); penetration tests are also periodic (2-10-1-3). Prefer passive discovery and vendor advisories over active scanning of controllers; see the ICS Advisory Triage and OT Vulnerability Management Guide and the OT Penetration Testing Guide.

For incidents, 2-12-1-2 requires formal response and root cause analysis, 2-12-1-4 an incident communications plan, 2-12-1-5 SIS recovery procedures inside recovery and continuity plans, and 2-12-1-7 testing through cyber attack simulation exercises. Reporting to the NCA follows the ECC incident subdomain; the OTCC does not set its own deadline. See the OT Incident Response Guide.

Implementation steps

Confirm scope and baseline. Record the legal basis (government or CNI) and confirm ECC-2:2024 compliance status, since the OTCC builds on it.
Inventory facilities and assets. List every facility containing OT/ICS and its systems, including SIS, remote sites and vendor-hosted components (2-1). Without this the level rating is guesswork; see the OT Asset Visibility Guide.
Rate each facility. Complete the Facility Level Identification Tool against the nine criteria with operations, HSE and engineering in the room. Get the result signed off.
Run the gap assessment. Use the NCA Assessment and Compliance Tool (published as a spreadsheet on the OTCC page) for the controls at each facility's level. Record evidence, owner and gap per control.
Write the frequencies and thresholds the document leaves open. Log retention, backup frequency, vulnerability assessment and penetration test intervals, access review cycles. Approve them through governance so they become auditable commitments.
Prioritise by consequence. Typical first wave: corporate to OT path through a DMZ jump host, remote access with MFA and recording, default credential removal, service account separation, offline backups of engineering files.
Change safely. Validate every control change in a test environment or during a planned outage (1-5-3-2), with a written rollback, for example keeping the previous firewall rule set and jump host configuration ready to restore.
Bind third parties. Add OTCC-derived clauses to OT procurement and maintenance contracts (4-1-1-1), require documented SDLC from suppliers (4-1-1-3) and schedule supplier assessments (4-1-1-4).
Review and audit. Internal review at least annually (1-6-1) and independent review at least every three years (1-6-2), feeding a remediation plan.

Decision guidance

Separate OT directory or shared one: 2-2-1-1 points to a separate, independent OT identity lifecycle. A small site with a handful of HMIs may use local accounts managed through a vault rather than a full domain; a large plant usually needs a dedicated OT domain with no trust to corporate.
Physical versus logical segmentation: 2-4-1-1 allows either. Physical separation suits SIS and L1 cores; logical separation with industrial firewalls suits L2 and L3 zones where data flows to historians are needed.
Splitting facilities to lower a level: separating a low-criticality site from an L1 site can reduce its control set, but only if the isolation is real. Shared remote access, shared directories or shared engineering laptops usually defeat the argument.
Building on IEC 62443: if you already run an IEC 62443-2-1 programme, map rather than rebuild; the annex maps OTCC to 62443-2-1, 3-2 and 3-3. See the IEC 62443 Guide.

Framework mapping

The Methodology and Mapping Annex maps OTCC controls to ISA/IEC 62443-2-1, 62443-3-2:2020 and 62443-3-3:2013, the NIST CSF, NIST SP 800-53 Rev. 4, NIST SP 800-82 Rev. 2, NOG 104, NERC CIP v6 and DOE C2M2, and states that the OTCC takes precedence where it conflicts with a referenced standard. NIST has since published SP 800-82 Rev. 3 (September 2023), which supersedes Rev. 2. The ATT&CK for ICS mapping below is NHI Mgmt Group's own, to help defenders see which techniques each control addresses.

OTCC control	ATT&CK for ICS technique addressed
2-2-1-7, 2-4-1-10 remote access	T0822 External Remote Services
2-2-1-2, 2-2-1-3 service accounts and defaults	T0859 Valid Accounts
2-3-1-8, 2-3-1-9 removable media	T0847 Replication Through Removable Media
2-3-1-5, 2-4-1-3 SIS modes and segmentation	T0858 Change Operating Mode; T0880 Loss of Safety
2-11-1-5 upload and download detection	T0843 Program Download
2-4-1-9, 2-4-1-12 no direct corporate to OT	T0886 Remote Services

Evidence and measurement

The OTCC states that the NCA assesses compliance through self-assessment, NCA audit field visits or audits by NCA-designated third parties. Evidence has to be current, not assembled the week before a visit.

Facility rating records: completed tool output and sign-off per facility.
Access evidence: remote session recordings, approval tickets, service account register, default credential sweep results.
Network evidence: zone diagrams, firewall rule reviews, DMZ jump host hardening baseline.
Operational evidence: backup restore test results, change records showing test environment validation, exercise reports.

Metrics that show the programme is working:

Percentage of OTCC controls at each facility's level assessed as compliant, by facility.
Percentage of remote OT sessions with MFA, approval and recording (target 100%).
Number of OT service and shared accounts without a named owner or with interactive logon allowed.
Percentage of OT assets, including SIS and engineering files, with an offline backup restored successfully in the last test cycle.
Median days from a critical ICS advisory to remediation or compensating control.
Number of unauthorised device alerts (2-11-1-8) and their mean time to triage.

Common failure patterns

Rating the organisation, not the facility. One level applied across all sites either over-burdens low-criticality sites or under-protects the L1 site.
OT domain trusting corporate. A trust or shared admin group lets a corporate identity compromise walk straight into OT, defeating 2-2-1-1.
Permanent vendor VPNs. Always-on integrator access with shared credentials fails 2-2-1-7 and is a common initial access route.
Backups without engineering files. Server images are backed up but PLC logic, SIS configuration and project files are not, so recovery stalls (2-8-1-2).
"Periodic" never defined. Leaving frequencies undefined in policy means there is nothing to measure against, which is itself a finding.
Active scanning in production. Running IT vulnerability scanners against controllers conflicts with 2-9-1-1 and can disrupt operations.

Practitioner checklist

Confirm in writing whether each facility is in scope and record its level with the Facility Level Identification Tool.
Confirm the ECC-2:2024 baseline is in place before claiming OTCC compliance.
Run the NCA Assessment and Compliance Tool for each facility's control set and keep evidence per control.
Remove any direct corporate to OT path and route access through a hardened DMZ jump host.
Make remote access on request only, with MFA, encryption, least privilege and recorded sessions.
Separate service accounts from interactive logins and remove default credentials on every device class.
Segment SIS and monitor mode changes and logic downloads.
Keep offline backups including engineering and configuration files, and test restores.
Define log retention, backup and testing frequencies in approved policy.
Put OTCC requirements into OT procurement and maintenance contracts and assess suppliers periodically.

Standards and references

Related NHI Mgmt Group resources: Saudi NCA Essential Cybersecurity Controls Guide · Saudi NCA Cloud Cybersecurity Controls (CCC) · OT Security Guide · OT and ICS Identity and Access Guide. This guide summarises the NCA OTCC-1:2022 and is not legal advice.

Saudi NCA OT Cybersecurity Controls (OTCC) Guide: Facility Levels, Key Controls and Compliance Steps