complianceotcc-1saudi-arabiacomplianceot-securitycritical-infrastructureindustrial-control-systems

Saudi Arabia OTCC-1 compliance: what auditors check versus what attackers exploit

Sienna VanceSienna VanceApril 29, 2026
Share:
Saudi Arabia OTCC-1 compliance: what auditors check versus what attackers exploit

Key takeaways

  • OTCC-1:2022 is mandatory for all organizations operating OT systems in Saudi critical infrastructure sectors including energy, water, manufacturing, and transportation, enforced by the National Cybersecurity Authority.

  • In Vulnox OT assessments, vulnerability scanners presented as OTCC-1 compliance evidence were routinely misconfigured: they could not authenticate against OT networks and were missing the PLC and HMI vulnerabilities auditors later flagged.

  • Network segmentation is the most common OTCC-1 gap: OT devices on flat or inadequately segmented networks remain reachable from IT environments, which is the exact attack path used in documented Saudi industrial incidents.

  • OTCC-1:2022 requires OT-specific incident response procedures, not adapted IT playbooks. Organizations using IT incident response plans for OT environments fail the operational validation portion of NCA audits.

  • Non-compliance penalties under the Saudi Cybersecurity Law include fines, operating license suspension, and criminal liability for responsible individuals — not just organizational sanctions.

  • Legacy OT systems without native authentication or encryption cannot be patched into compliance. OTCC-1:2022 compliance for these assets requires compensating controls documented in a risk acceptance framework, which most organizations have not built.

TL;DR

OTCC-1:2022 compliance in Saudi Arabia is not an IT security exercise with OT terminology added. The framework targets industrial control systems where a successful attack has physical consequences. Most organizations fail not because they ignore the controls but because they validate compliance with tools and evidence that cannot actually see what is happening on their OT networks. The audit passes. The exposure remains.

The vulnerability scanner that could not see the network it was scanning

A mid-sized manufacturing operator in the Eastern Province submitted its OTCC-1:2022 compliance evidence package ahead of an NCA audit. The package included 14 months of Nessus scan reports showing a manageable vulnerability count, a network diagram showing IT-OT segmentation, and a signed attestation from the CISO that vulnerability management procedures were in place. The auditors accepted the documentation and scheduled the on-site assessment. During that assessment, the Vulnox team ran authenticated OT-protocol scans against the same network the Nessus reports covered. The authenticated scan found 47 vulnerabilities the Nessus reports had not detected, including unauthenticated access to three Siemens S7 PLCs controlling a heat treatment line.

Turning point:

The Nessus scanner had never been configured to authenticate against the OT network. It was scanning from the IT segment, reaching only the IP addresses that responded to ICMP and standard TCP probes across the segmentation boundary. The PLCs were visible on the network. The scanner just could not talk to them in a language they understood. The compliance evidence documented the scanner running. It did not document the scanner finding anything. That distinction matters enormously when an auditor reads a vulnerability report versus when an attacker probes the same environment.

What OTCC-1:2022 actually controls and what it leaves to interpretation

OTCC-1:2022 is published by the Saudi National Cybersecurity Authority and builds on ISA/IEC 62443 and NIST SP 800-82, adapted for the Saudi regulatory context. It applies to OT systems in sectors the NCA designates as critical: energy, water, manufacturing, transportation, and others. The framework organizes its requirements around four functions: Protect, Detect, Respond, and Recover. Within those functions, specific control articles address access control, network segmentation, vulnerability management, configuration management, incident response, and security awareness.

The control language is risk-based, which creates interpretive flexibility that organizations consistently exploit in ways that create compliance gaps rather than close them. Risk-based language means an organization can argue that a particular control is not applicable given its risk profile. NCA auditors evaluate whether that risk determination is reasonable and documented. What they increasingly find is that risk exceptions have been applied to legacy systems not because a formal risk assessment was conducted but because implementing the control would have required operational downtime the organization was unwilling to schedule.

The framework's segmentation requirements are specific about the principle but not prescriptive about implementation. OTCC-1:2022 section 4.1 requires that OT networks be segmented from corporate IT networks and from the internet. What constitutes adequate segmentation is evaluated during audit based on the actual traffic flows observed, not the network diagram submitted in advance. Organizations with diagrams showing segmentation and configurations allowing IT-to-OT traffic on specific ports fail this control at the technical assessment stage even when the diagram-level review showed compliance.

Example

An energy sector client had implemented a next-generation firewall between its IT and OT segments. The firewall ruleset allowed RDP traffic from specific IT management hosts to OT systems for remote maintenance purposes. The maintenance use case was legitimate. The problem was that the allowed source hosts included a general-purpose IT workstation pool, not a dedicated jump server with privileged access management controls. Any compromised workstation in that pool had a compliant firewall path to OT systems. The segmentation architecture was documented. The segmentation effectiveness was not.

OTCC-1:2022 section 4.1 segmentation requirements must be validated through traffic analysis, not diagram review. Industrial protocol visibility tools that understand Modbus, DNP3, EtherNet/IP, and Profinet are required to validate what is actually crossing segmentation boundaries versus what firewall rules permit in theory.

What OT assessments find that compliance audits do not

Assessment base: Vulnox OT security assessments and OTCC-1:2022 gap analyses, 2024-2025, covering energy, manufacturing, and water sector clients in Saudi Arabia.

Authentication evidence does not reflect authentication enforcement

OTCC-1:2022 section 3.0 requires strong authentication for access to OT systems. In assessments, organizations routinely provide evidence of multi-factor authentication policies and user access reviews. What the evidence does not show is whether those authentication requirements actually apply to OT-native interfaces. HMI consoles, engineering workstation software, and PLC programming interfaces frequently retain default or shared credentials that exist outside the scope of the enterprise identity management system. The MFA policy covers Active Directory accounts. The Siemens TIA Portal installation uses a locally stored credential that has not been rotated in three years.

Implication:

Authentication compliance evidence measures the enterprise identity layer. OT-native authentication is a separate attack surface that standard compliance evidence does not reach. Auditors reviewing policy documentation and Active Directory configurations are not seeing the same environment an attacker with engineering workstation access would see.

Incident response plans describe IT procedures with OT terminology substituted

OTCC-1:2022 requires OT-specific incident response capabilities, including procedures for containing incidents without causing physical process disruptions. In Vulnox assessments, the incident response plans submitted for compliance review are consistently adapted from IT incident response templates. The OT-specific content consists of terminology changes: 'server' replaced with 'PLC,' 'application' replaced with 'SCADA.' The procedures themselves describe isolation, imaging, and reimaging workflows that are not safe to execute on live industrial control systems. No organization we assessed had tabletop-tested its OT incident response plan against a realistic scenario involving a compromised engineering workstation during active production.

Implication:

An incident response plan that has never been tested against OT operational constraints is a liability, not an asset. When a real incident occurs, operators following an untested plan in an OT environment risk escalating the incident from a cybersecurity event to a safety event. OTCC-1:2022 compliance documentation records that a plan exists. It does not record whether the plan would work.

Third-party and subcontractor OT access is outside the compliance scope organizations define

Organizations managing OTCC-1:2022 compliance typically define their compliance scope around assets they directly operate. Third-party maintenance contractors, OEM service technicians, and system integrators who access OT systems remotely or on-site are frequently outside that defined scope. In assessments, Vulnox has found active vendor remote access credentials that had not been reviewed or rotated since the initial system commissioning, vendor laptops connecting to OT networks without endpoint verification, and no logging of vendor access sessions to OT systems that OTCC-1:2022 section 4.3 requires for continuous monitoring.

Implication:

The supply chain access vector is the most reliable path into OT environments precisely because organizations treat it as someone else's compliance responsibility. NCA audits are beginning to examine vendor access controls more closely. Organizations that cannot produce access logs for third-party sessions to OT systems face a monitoring compliance gap regardless of how well-documented their internal access controls are.

More security tools does not mean better OT visibility

Common belief

Organizations approaching OTCC-1:2022 compliance often respond to identified gaps by deploying additional security tooling: OT-specific intrusion detection systems, asset discovery platforms, network monitoring solutions. The assumption is that more visibility equals better compliance posture and that deploying a recognized OT security platform closes the monitoring and detection gaps the framework requires.

What we found

In Vulnox assessments following OT security tool deployments, the most common finding is not that the tool is wrong but that its scope is narrower than the compliance documentation implies. Organizations report OT monitoring as a completed compliance control. The monitoring covers 60 to 70% of the OT asset inventory. The remaining 30 to 40% are the legacy assets with the highest density of unpatched vulnerabilities.

OT security tools are only as useful as their integration with the network they are supposed to monitor. In the majority of OT environments we assess, newly deployed monitoring platforms are connected to mirror ports or TAPs that capture traffic from a subset of the OT network. The subset is typically the most accessible part of the network, not the most critical. PLCs in older installations often use serial communications or proprietary industrial protocols that do not appear in Ethernet traffic captures at all. An OT monitoring platform generating clean dashboards from the portion of the network it can see creates the same compliance evidence problem as the misconfigured Nessus scanner: documentation of monitoring activity, not documentation of monitoring effectiveness.

The operational reality of OT environments also means that active scanning, which is standard practice in IT security, is frequently unsafe to run against production OT systems. Some PLC firmware versions respond to unexpected network probes by entering fault states. Organizations that discover this after a scanning tool disrupts a production process do not run the scanner again. They also do not update their compliance evidence to reflect that vulnerability scanning is now passive-only and covers a different scope than the compliance documentation describes.

Where OTCC-1:2022 compliance programs consistently fail

Legacy system risk acceptance without documented compensating controls

OTCC-1:2022 acknowledges that legacy OT systems cannot always be brought into full control compliance. The framework allows for risk acceptance with compensating controls. What it requires is that the risk acceptance be formally documented, the compensating controls be specified, and the residual risk be reviewed on a defined schedule. In practice, organizations treat legacy system exceptions as a compliance escape valve rather than a structured risk management process. The exception is noted. The compensating controls are not specified. The review schedule does not exist. When NCA auditors examine legacy system documentation, the absence of a compensating control framework for accepted risks is a finding that undermines the entire risk-based compliance posture.

Configuration management as a point-in-time exercise

OTCC-1:2022 configuration management requirements under section 5.2 are interpreted by most organizations as a baseline documentation exercise. Devices are inventoried, configurations are captured, a baseline is established. What the framework also requires is change management processes that maintain that baseline over time and detection capabilities that identify unauthorized configuration changes. OT environments experience configuration drift from vendor firmware updates, emergency changes made during production incidents, and undocumented modifications made by operators solving immediate problems. Organizations with a clean baseline from their last audit and two years of undocumented changes between audits are not in compliance. They are in compliance with the state of the network as it existed at audit time.

Security awareness training that does not address OT attack vectors

OTCC-1:2022 section 5.1 requires security awareness training for personnel with access to OT systems. Most organizations fulfill this requirement with general cybersecurity awareness content adapted from IT training programs. OT engineers and operators receive phishing awareness training, password hygiene guidance, and social engineering scenarios built around corporate email and enterprise applications. The attack vectors specific to OT environments — USB-delivered malware targeting engineering workstations, social engineering of contractors to install remote access tools, manipulation of HMI configurations through physical access — are not covered. Personnel are trained to recognize threats to the network they use for email, not the network they use to control industrial processes.

Where OTCC-1 enforcement and OT threats are heading

  1. NCA will introduce mandatory OT security incident reporting with defined timelines by 2027, creating an evidence trail that will expose the gap between documented compliance posture and actual incident response capability across Saudi critical infrastructure operators.

    Mandatory incident reporting is the standard mechanism regulators use to generate real-world data on compliance program effectiveness. Current OTCC-1:2022 compliance is assessed through audits that examine documentation and conduct point-in-time technical assessments. Mandatory reporting would require organizations to demonstrate response capability under actual incident conditions, where the gap between documented procedures and operational reality becomes visible. The NCA's trajectory — increasing specificity in framework requirements, active audit enforcement, engagement with international OT security bodies — follows the same path European regulators took before NIS2 introduced mandatory reporting for OT-adjacent sectors.

    Confidence: mediumIf NCA has not issued mandatory OT incident reporting guidance by Q4 2027, the prediction is premature. An early signal would be NCA releasing consultation documents on incident notification timelines in 2025 or 2026.
  2. Supply chain attacks targeting Saudi OT environments through compromised vendor remote access will produce the first publicly documented OTCC-1-adjacent incident by 2027, driven by the current near-universal absence of vendor access logging and session control in assessed environments.

    The attack path exists and is unmonitored. Vendor remote access to OT systems in Saudi critical infrastructure is largely unlogged, uses credentials that are not rotated on defined schedules, and is outside the compliance scope most organizations have defined. The same attack vector produced documented incidents in European energy infrastructure between 2021 and 2024. Saudi critical infrastructure is a higher-value target given national economic concentration in the energy sector. The gap is structural, not incidental, and compensating controls are not being deployed at the rate the risk warrants.

    Confidence: highIf no publicly documented supply chain attack on Saudi OT infrastructure occurs before 2028, the timeline was wrong. The structural conditions for the attack path will still exist unless vendor access control practices change materially.

The compliance audit model is the wrong tool for OT security

OTCC-1:2022 is a well-constructed framework. The controls are appropriate for the threat environment. The problem is the audit model used to assess compliance. Point-in-time audits examining documentation and conducting limited technical assessments produce compliance certificates that reflect the state of the environment as it existed during a two-week assessment window. OT environments change constantly: firmware updates, configuration modifications, new vendor access credentials, production changes that alter network traffic patterns. A compliance certificate issued in January does not reflect what the environment looks like in September. Organizations know this and treat audit preparation as a discrete activity, separate from ongoing security operations. The result is environments that are audit-ready periodically and security-operationally sound inconsistently. For IT systems, this gap is significant. For OT systems controlling physical industrial processes, it is a safety issue.

Counterargument

The counterargument is that continuous compliance monitoring is operationally impractical for OT environments where stability is a security requirement and any active assessment carries disruption risk. Point-in-time audits represent a realistic compromise between security validation and operational continuity. There is validity to that. OT patching cycles are measured in years, not weeks, for legitimate operational reasons. But the compromise should be acknowledged for what it is: a practical concession, not a security equivalence. Organizations that treat audit compliance as security equivalence are making a different and more dangerous mistake.

One concrete action for this week

Pull the scope definition from your last OTCC-1:2022 compliance assessment or gap analysis and identify which OT assets are explicitly included. Then walk the OT network and count the assets that are not in that scope definition. Legacy PLCs, serial-connected field devices, engineering workstations running unsupported operating systems, and vendor remote access endpoints are the categories most commonly excluded. If the count of out-of-scope assets exceeds 20% of your total OT asset inventory, your compliance program is measuring the part of the environment that is easiest to document, not the part that represents the greatest risk. That gap is where the next audit finding will come from, and it is where an attacker will go first.

Further Reading

Frequently Asked Questions

Who must comply with Saudi Arabia OTCC-1:2022 and what are the penalties for non-compliance?

Any organization operating OT systems in Saudi Arabia's designated critical infrastructure sectors — energy, water, manufacturing, transportation — must comply with OTCC-1:2022 as enforced by the National Cybersecurity Authority. Non-compliance penalties under the Saudi Cybersecurity Law include substantial fines, suspension of operating licenses, and criminal liability for individuals responsible for cybersecurity failures. The framework applies to both public and private entities.

What does an OTCC-1:2022 gap analysis actually examine?

A proper OTCC-1:2022 gap analysis examines network segmentation effectiveness through traffic analysis, not just diagram review; authentication enforcement at the OT-native level including HMI and PLC credentials, not just enterprise identity management; vulnerability scanner configuration and scope to verify it can authenticate against OT protocols; incident response plan applicability to OT operational constraints; and vendor remote access logging and credential management. Document review alone misses the operational gaps NCA auditors are increasingly probing.

How does OTCC-1:2022 network segmentation get assessed during an NCA audit?

NCA auditors validate segmentation through actual traffic analysis, not the network diagram submitted in advance. A firewall showing IT-OT separation on paper fails if the ruleset permits RDP or other management traffic from general IT workstation pools to OT systems without dedicated jump server controls. Vulnox assessments have found organizations with documented segmentation architectures and active lateral traffic paths between IT and OT segments that neither the organization nor its previous auditor had detected.

What is the difference between IT and OT vulnerability management under OTCC-1:2022?

OT vulnerability management cannot use standard active scanning approaches safely. Some PLC firmware versions enter fault states when exposed to unexpected network probes. Safe OT vulnerability assessment requires authenticated scanning using industrial protocols, passive traffic analysis, and manual inspection of device configurations. In Vulnox assessments, vulnerability scanners presented as compliance evidence were routinely misconfigured — scanning from the IT segment and unable to authenticate against OT devices, producing reports that showed far fewer vulnerabilities than authenticated OT-protocol scanning revealed.

How should organizations handle legacy OT systems that cannot meet OTCC-1:2022 controls?

OTCC-1:2022 allows risk acceptance for legacy systems that cannot be brought into full control compliance, but requires formal documentation of the accepted risk, specification of compensating controls, and a scheduled review process. Most organizations treat legacy exceptions as an undocumented carve-out rather than a structured risk management process. NCA auditors examine whether compensating controls are specified and whether the risk acceptance has been reviewed on schedule — not just whether an exception was noted.

What OT-specific incident response requirements does OTCC-1:2022 impose?

OTCC-1:2022 requires incident response procedures designed for OT operational constraints, not adapted IT playbooks. OT incident response must account for the risk that containment actions like network isolation or system reimaging can cause physical process disruptions or safety events. Standard IT isolation procedures applied to live industrial control systems can escalate a cybersecurity incident into a safety incident. No organization in Vulnox's assessment base had tabletop-tested its OT incident response plan against a realistic scenario involving a compromised engineering workstation during active production.

What does OTCC-1:2022 require for third-party and vendor access to OT systems?

OTCC-1:2022 section 4.3 requires continuous monitoring that covers vendor and contractor access sessions to OT systems. In practice, third-party remote access credentials are frequently outside the compliance scope organizations define, access sessions are not logged to OT-level audit trails, and vendor credentials are not rotated on defined schedules. Vulnox assessments have found active vendor remote access credentials unchanged since initial system commissioning. NCA audits are examining vendor access controls with increasing specificity.

Related Articles

GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard

GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard

GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.

GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong

GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong

GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.

GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard

GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard

GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.

Ready to Secure Your Digital Assets?

Get a comprehensive vulnerability assessment for your website today.