NCA OTCC: The Definitive Guide to OTCC-1:2022 (Every Domain, From the PDF)

If you run a plant in the Eastern Province, you have probably been sent a slide deck about the NCA's Operational Technology Cybersecurity Controls. There is a good chance it told you the OTCC mandates the Purdue Model, that it requires a data diode, that it comes with an "OTCC certificate," or that it applies to every company in Saudi Arabia.

None of those things are true. We know, because we read the document.

This guide is written against the PDF itself — Operational Technology Cybersecurity Controls (OTCC-1:2022), published by the National Cybersecurity Authority, Document Classification: Public, Sharing Indicator: White — with the Methodology and Mapping Annex and the NCA's own Assessment and Compliance Tool open beside it. Every control number, every count and every quoted requirement below comes from those files. Where the OTCC is silent, this guide says so plainly — and there is one place where we could not make the NCA's own numbers tie out, which we show you rather than smooth over.

One note before anything else, from the OTCC's own cover page: the Arabic version is the binding language. The English PDF is a translation. If you are going to argue a point with an assessor, argue it from the Arabic.

The 60-second answer

• The current version is OTCC-1:2022. There is no OTCC-2.
• It contains 4 main domains, 23 subdomains, 47 main controls and 122 subcontrols (OTCC, Introduction, p.9).
• It is an extension to the ECC — not a standalone standard. "Compliance with Essential Cybersecurity Controls (ECC 1:2018) is a mandatory prerequisite for the organization" (OTCC, p.11). You do the ECC first, then the OTCC on top.
• It applies to ICS in critical facilities owned and/or operated by government organizations, and to private-sector organizations owning, operating or hosting Critical National Infrastructure (CNI) — "whether they are in the kingdom or abroad." Everyone else is "strongly encouraged" (OTCC, p.10).
• There are three facility levels (L1, L2, L3), assigned by the NCA's Facility Level Identification Tool. The level decides how many controls bite.
• There is no OTCC certificate, no accredited-auditor scheme, no stated deadline, and no fine schedule. Compliance is assessed by self-assessment and/or NCA field audit.
• It has nothing to do with Aramco. The words "Aramco" and "SACS" appear zero times in the document.

What OTCC-1:2022 actually contains

Straight from the Introduction (p.9):

• 4 Main Domains. • 23 Subdomains. • 47 Main Controls. • 122 Subcontrols.

We did not take the NCA's word for it. We counted the control IDs in the PDF ourselves, and then parsed the NCA's own Assessment and Compliance Tool, which lists every control on one sheet. All three agree: 47 main controls, 122 subcontrols, 169 rows in total.

Note where the weight sits. Domain 2 carries 92 of the 122 subcontrols — 75% of the document. The OTCC is, overwhelmingly, a technical defence standard. If someone hands you an OTCC programme plan that is mostly policy templates, they have inverted it.

The control code reads left to right (Figures 3 and 4, p.15). In 2-4-1-9: 2 = main domain, 4 = subdomain, 1 = main control, 9 = subcontrol. And in the document title OTCC – 1 – 2022: 1 = version number, 2022 = year of issuance.

The 23 subdomains, in the right order

This is the table people get wrong, and it is the one an assessor works from.

A small honesty note, because it tells you we actually read it: the English PDF has a typo. In the control body on p.21, subdomain 1-8 is headed "Cybersecurity in Human Resources" — the same heading as 1-7. Figure 2 (p.14) and 1-8's own objective text both make clear that 1-8 is the Cybersecurity Awareness and Training Program. The Arabic is correct. This is exactly why the NCA makes the Arabic binding.

The renumbering trap: OTCC ≠ ECC

Here is the single most valuable thing in this article, and it is the exact mistake that has been made repeatedly in published Saudi compliance content — including, previously, on this site, which is why this guide was rewritten from the source.

The OTCC is an extension of the ECC, but it does not inherit the ECC's subdomain numbers. It renumbers from scratch. And because the OTCC has no Email Protection subdomain — there is no email in a distillation column — every Cybersecurity Defense subdomain from 2-4 onwards is shifted down by one relative to the ECC.

Read that twice. "2-12" means log management in the ECC and incident management in the OTCC. Same number. Two different requirements. Cite the wrong one in an audit response and you have told the assessor, in writing, that you have not read the standard.

This is not our inference. The OTCC states the mapping itself, in the opening line of nearly every control. OTCC 2-11-1 (event logs) opens: "In addition to subcontrols in the ECC control 2-12-3…". OTCC 2-12-1 (incidents) opens: "In addition to subcontrols in the ECC Control 2-13-3…". OTCC 2-13-1 (physical) opens: "In addition to subcontrols in the ECC Control 2-14-3…". Every row above is verifiable from the OTCC's own cross-references.

Governance renumbers too, and just as sharply — the OTCC drops the ECC's Cybersecurity Strategy and Cybersecurity Management subdomains entirely:

One reassuring finding: we checked every ECC subdomain the OTCC cross-references against both ECC-1:2018 and ECC-2:2024, and the subdomain names and numbers the OTCC relies on are identical in both versions. The OTCC's cross-references survived the ECC-2 update intact. That matters, because of the version drift in the next section.

OTCC, ECC and the domain 5 that disappeared

The relationship between these two documents is frequently mangled, so here it is precisely.

OTCC-1:2022 is an extension of the ECC. The Methodology and Mapping Annex is unambiguous: "applicable organizations must comply with ECC controls first, and then comply with the additional controls provided by the OTCC-1:2022 document." The OTCC body says the same in harder language: "Compliance with Essential Cybersecurity Controls (ECC 1:2018) is a mandatory prerequisite for the organization" (p.11).

So the OTCC does not stand alone. An organisation that has implemented the OTCC but not the ECC has not complied with the OTCC.

Now the wrinkle, and you will not find it in the vendor decks. ECC-1:2018 had a fifth main domain — "Industrial Control Systems Cybersecurity." When the NCA published ECC-2:2024, it deleted that domain and stated in its change log that the controls had moved to the OTCC. The OTCC's Mapping Annex contains the other half of that bridge: Table 1, "Relationship Between OTCC and ECC Domain 5," which maps each old ECC 5-x-x control to its OTCC successors. For example, ECC 5-1-3-1 (strict physical and virtual segmentation between industrial production networks and other networks) maps to OTCC 2-4-1-1, 2-4-1-2, 2-4-1-3, 2-4-1-6, 2-4-1-9, 2-4-1-10, 2-4-1-11, 2-4-1-12 and 2-4-1-13. Nine OTCC subcontrols where the ECC had one.

That is the honest summary of what happened: your OT obligations did not get lighter — they got unbundled into a document ten times more specific.

The version drift is real and you should know about it. OTCC-1:2022 names ECC-1:2018 as its prerequisite, because that was the current ECC when the OTCC was written. The NCA has since issued ECC-2:2024, and has not reissued the OTCC. The document on nca.gov.sa is still OTCC-1:2022. We are not going to invent an NCA position on that, because the NCA has not published one. What we can tell you, because we checked, is that every ECC control the OTCC points at still exists under the same number in ECC-2:2024 — so in practice the cross-references still work.

If you are new to the ECC side of this, our companion guide — NCA ECC: the definitive guide to ECC-2:2024 — covers it control by control.

Who is actually in scope

Applicability is where this kind of article most often lies, so here is the OTCC's Scope of Work section (p.10) quoted rather than paraphrased:

"These controls are applicable to Industrial Control Systems (ICSs) that reside in facilities that are deemed critical and owned and/or operated by government organizations (including ministries, authorities, establishments, and others), as well as private sector organizations owning, operating or hosting Critical National Infrastructures (CNIs), whether they are in the kingdom or abroad."

Unpack that into the four tests that actually decide it:

1. Is it an ICS? The OTCC defines this as broadly as it is possible to define it: "all devices, systems, or networks used to operate and/or automate industrial processes." Not just the DCS. The packaging line PLC counts.
2. Does it reside in a facility deemed critical? The OTCC defines a critical facility as one "where their destruction and/or dysfunction may lead to the disruption or discontinuity of the organization's operation." Note that this is a test against your own operational continuity — it is a lower bar than most people assume.
3. Who owns or operates it? A government organization, or a private-sector organization that owns, operates or hosts Critical National Infrastructure.
4. Where is it? Irrelevant. In the Kingdom or abroad, if you are one of the above.

And what if you are a private manufacturer who is not CNI? Then you are not in mandatory scope, and any consultant telling you otherwise is selling something. The OTCC's own words: "NCA strongly encourages all other organizations in the Kingdom to leverage these controls to implement best practices to improve and enhance their OT cybersecurity." Encouraged. Not mandated.

In practice, plenty of Eastern Province suppliers get pulled in contractually rather than by regulation — because their customer is in scope and pushes requirements down the chain. That is a real obligation, but it comes from the contract, not from the NCA. Know which one you are answering to, because they have different escalation paths.

The safety carve-out almost nobody quotes

The Statement of Applicability (p.10) contains a sentence that has no equivalent in the ECC, and it is the most important sentence in the document for anyone who actually runs a plant:

"Every organization within the scope of this document that owns or operates Industrial Control Systems (ICS) technologies must comply with all applicable controls in this document after ensuring that applying applicable controls will not jeopardize the continuity of the organization's operation."

The NCA is explicitly telling you: do not break the plant to pass the audit. This is not a loophole, and it is not a licence to skip controls you find inconvenient — the OTCC tells you exactly what to do instead, in 1-3-1-6: where a cybersecurity requirement cannot be implemented in the OT/ICS environment, "the specific justifications for not applying those requirements must be documented and approved by the respective cybersecurity function and the Authorizing Official." And 1-3-1-7: where risk is accepted, alternative controls must be defined, documented, approved by the Authorizing Official, implemented "for a defined period of time," and the risk continuously reassessed.

That is the mechanism. A documented, approved, time-boxed exception with compensating controls is a compliant answer. An undocumented gap is a finding. The difference between the two is paperwork you can produce in an afternoon — and it is the single cheapest thing you can do before an assessment.

The three facility levels — and the one place the numbers do not tie out

The OTCC does not apply uniformly. Every critical facility is assigned a level, and the level decides how many controls bind you. The criteria (p.12) are:

• the criticality, consequences and impact on the organization's business and services' availability;
• the negative impact on Health, Safety, and/or Environment (HSE);
• the negative impact on national economy, national security or social influence.

Note that HSE sits alongside business impact as a first-class criterion. This is an OT standard written by people who understand that the worst case is not a data breach.

Table 1 (p.12) states:

Your level is assigned using the NCA's OTCC-1:2022 Facility Level Identification Tool (p.11). It is a per-facility determination, not a per-company one: a group can easily run an L1 refinery and an L3 warehouse, and the same control set does not apply to both.

Now the honest part. We tried to reproduce those three figures and we could not.

The OTCC has 47 main controls and 122 subcontrols — 169 items. The NCA's own Assessment and Compliance Tool lists all 169 on one sheet, each tagged with a control level. We parsed it. Counting every row, we get L1 = 169, L2 = 139, L3 = 77. Counting only "leaf" controls (subcontrols, plus the main controls that have no subcontrols beneath them) we get L1 = 150, L2 = 120, L3 = 60. Neither reconciles with Table 1's 151 / 117 / 56.

We are not going to invent a reconciliation, and we are certainly not going to publish a per-control level grid derived from arithmetic that does not close — that is precisely the species of confident-sounding fabrication this guide exists to correct. What we will tell you is the practical consequence, which is unaffected:

Do not scope your programme from Table 1's totals. Scope it from the per-control L1/L2/L3 marks — they are printed in the three right-hand columns of every control table in the PDF, and they are in the Control Level column of the NCA's Assessment and Compliance Tool. Those marks are the operative instruction. The summary totals are a summary.

If you are an L3 facility, this matters a great deal to your budget: most of the OTCC does not apply to you. Roughly a third of it does. Find out your level before you buy anything.

The only hard numbers in the document

Compliance marketing is full of thresholds the NCA supposedly demands. Here is the complete list of the ones the OTCC actually states.

Vulnerability assessment frequency (2-9-1-3) and penetration testing frequency (2-10-1-3) — and these are the only two controls in the entire document with a numeric periodicity that varies by level:

Quarterly penetration testing of a live production ICS at an L1 facility sounds alarming, and the NCA knows it. 2-10-1-2 requires that penetration testing be conducted "with limited or no impact on the production environment, or on an identical separate environment," and 2-10-1-4 requires that "alternative testing methods (such as passive testing mechanisms) must be defined and implemented to collect relevant information when a potential impact to operational production environment may occur."

So the honest reading is: passive assessment on a replica is an anticipated and compliant answer. You are not required to fire an exploit at a running SIS.

The two other real periodicities, both in governance:

• 1-6-1 — the organization's cybersecurity function must review OTCC implementation at least annually.
• 1-6-2 — implementation must be reviewed by independent parties within the organization, outside the cybersecurity function, at least once every three years.

That is it. Every other frequency in all 169 controls is the word "periodically." The NCA sets requirements, not service levels. The frequency you choose for everything else must be defensible against your own risk assessment — and that is what gets probed.

IT/OT segmentation: what subdomain 2-4 actually requires

Subdomain 2-4 (Networks Security Management) is where most OTCC programmes live or die. Main control 2-4-1 has sixteen subcontrols. Here is what they actually say — this is the architecture the NCA is describing, in its own terms:

Two of these are the ones people underestimate.

2-4-1-11 — proxies for all machine-to-machine traffic. Not just for humans. Your historian replication, your OPC feed to the ERP, your maintenance-management integration: all of it. This is the control that quietly forces an architecture change, and it is the one most likely to be found broken, because M2M paths get built by whoever needed the data and never appear on a diagram.

2-4-1-16 — the network documentation control. It sounds like the boring one. It is the one that gets you. An assessor cannot verify 2-4-1-1 through 2-4-1-15 without a current, accurate network diagram showing zones, conduits and data flows. If your diagram is wrong, every other segmentation control is unevidenced by definition. In practice this is the first artefact requested and the most common reason a plant fails an OT assessment while having genuinely decent security.

The OTCC also defines Choke Point in its glossary (Appendix A): "a single point through which all incoming and outgoing network traffic is funneled."

The Purdue Model: what the OTCC actually says

Nothing. That is not a rhetorical flourish — we grepped the document.

The word "Purdue" appears zero times in OTCC-1:2022. So do "Level 3.5," "air gap," "data diode" and "unidirectional gateway." The words "IEC," "62443" and "NIST" appear zero times in the controls document as well.

What the OTCC actually specifies is a zone-and-conduit architecture: segment the OT/ICS environment from everything else (2-4-1-1); segment zones from each other according to their assigned level (2-4-1-2); funnel traffic through choke points (2-4-1-2); forbid direct corporate↔OT communication (2-4-1-9); mediate it through a hardened jump host in a dedicated DMZ (2-4-1-9, 2-4-1-13); proxy all M2M traffic (2-4-1-11); and put SIS in its own segment (2-4-1-3).

If you build a textbook Purdue model with a Level 3.5 DMZ, you will satisfy those controls comfortably. That is why the confusion exists, and Purdue remains an excellent way to organise the problem. But you should be clear about the logic, because it changes what you can say to an assessor:

Purdue is a means of compliance, not the requirement. A modern plant that has abandoned strict Purdue layering — because it has cloud historians, wireless sensors and remote vendor support — is not automatically non-compliant. It has to demonstrate the properties the OTCC actually asks for: defined zones, enforced segmentation, choke points, no direct corporate path, mediated remote access, and an accurate diagram. Conversely, a plant that has drawn a beautiful Purdue diagram and then run a flat VLAN underneath it is non-compliant, and the diagram makes it worse, because now the documentation is false.

Where does 62443 come in? The Methodology and Mapping Annex — a separate document from the controls — states that the OTCC was built on ISA/IEC 62443 (specifically 62443-2-1, 62443-3-2:2020 and 62443-3-3:2013), the NIST Cybersecurity Framework, NIST SP 800-53 rev4, NIST SP 800-82 rev2, NOG 104, NERC CIP v6, and the US DoE C2M2. That lineage is why the OTCC reads like 62443 in Saudi clothing — the zones, the conduits, the levels. But the controls document cites none of them, and being 62443-certified does not make you OTCC-compliant. The mapping runs the other way: it exists so you can reuse 62443 work as evidence, not so you can substitute it.

What an assessor actually asks an industrial operator for

The NCA assesses through "self-assessment by the Organization and/or audit field visits by NCA or designated third-parties" (p.11). There is no third-party certification body to buy your way through.

The scoring vocabulary is not a maturity model. From the NCA's own Assessment and Compliance Tool, every control gets exactly one of four values:

• Implemented (مطبق كليًا)
• Partially Implemented (مطبق جزئيًا)
• Not Implemented (غير مطبق)
• Not Applicable (لا ينطبق على الجهة)

There is no "Level 3 of 5." A control is done, half-done, not done, or out of scope. That is a harsher scale than most IT people are used to, and it rewards a small, complete, well-evidenced scope over a large, half-finished one.

Based on what the controls actually demand evidence of, this is the artefact list worth having ready — every item traceable to a control ID:

1. The facility level determination, from the Facility Level Identification Tool. Everything else is scoped by it (1-3-1-4 requires exactly this: "Appropriate level assignment to facilities which include (OT/ICS) must be conducted based on approved methodology").
2. An electronic OT/ICS asset inventory, produced by an automated collection tool, stored securely, with named asset owners and a criticality rating per asset (2-1-1-1 through 2-1-1-5). "Automated" is in the text — a spreadsheet somebody maintains by hand is a partial.
3. The network architecture document — zones, data flows, connectivity, interdependencies, current (2-4-1-16).
4. The exception register — every control you cannot implement, with justification approved by the cybersecurity function and the Authorizing Official, plus its compensating controls and expiry (1-3-1-6, 1-3-1-7).
5. Evidence that OT identity management is separate from IT (2-2-1-1: "Identity and access management lifecycle for OT/ICS is separated and independent from Information Technology (IT) including centrally managed identity and access management solutions"). One Active Directory spanning the corporate network and the plant floor is a finding against this control, and it is extremely common.
6. Default-credential remediation records (2-2-1-3).
7. Remote access records — risk assessment before grant, MFA, encrypted channel, time-boxed, least privilege, monitored and recorded sessions (2-2-1-7). Vendor support access is where this is usually lost.
8. Application whitelisting on OT assets (2-3-1-6), and dedicated hardened Engineering Workstations and HMIs for management and maintenance (2-3-1-7).
9. Removable media controls — scanned in an isolated environment, restricted in production (2-3-1-8, 2-3-1-9).
10. Offline, centralized backups that include configuration files and engineering files — not just data (2-8-1-1, 2-8-1-2). The engineering-file requirement is explicit and routinely missed; a backup that cannot restore a PLC program is not a backup for OTCC purposes.
11. Vulnerability assessment and penetration test reports at the cadence your level demands (2-9-1-3, 2-10-1-3), including the passive/alternative methods used where active testing was unsafe (2-10-1-4).
12. Event logs and audit trails enabled on all OT/ICS assets (2-11-1-1), with monitoring of every remote access session (2-11-1-6), alerting on new or unauthorized devices joining the OT network (2-11-1-8), and OT-specific threat intelligence tuning your SIEM (2-11-1-9).
13. An OT incident response plan integrated with the IT plan, crisis management and the BCP (2-12-1-1), with SIS recovery procedures in it (2-12-1-5), tested by cyber-attack simulation exercises (2-12-1-7).
14. BCP/BIA/DRP that actually incorporate OT (3-1-1-3, 3-1-1-4), a defined safe mode the plant can run in after a cyber-induced failure (3-1-1-5), and tabletop exercises (3-1-1-6).
15. Personnel screening for everyone with OT access — including contractors and subcontractors (1-7-1).
16. Third-party evidence: cybersecurity requirements in the procurement lifecycle (4-1-1-1), a documented SDLC from contractors and vendors building anything deployed in your OT environment (4-1-1-3), and periodic assessments and audits of those third parties (4-1-1-4).

If you want the logging and incident-response half of that list taken down to log sources, stack and run-books, our SOC guide does it — and is equally careful about which requirements are the NCA's and which are merely industry practice.

Things that do not exist

Every item below circulates in published material about the OTCC. Every one of them is false, and we verified each against the PDF.

"OTCC certification." There is no such thing. No certificate, no accredited auditor scheme, no certification body. The word "certified" appears exactly once in the entire document — in 2-4-1-15, requiring that patches be certified by the vendor. Compliance is established by self-assessment and NCA field audit. If a firm offers to "certify you to OTCC," they are selling a service the NCA does not recognise. (Aramco's CCC is a real certificate — but that is a different organisation and a different standard. See below.)

A Purdue Model mandate. Zero mentions. Zones, choke points, DMZ and jump hosts are required. Purdue is one way to deliver them.

An air gap, a data diode, or a unidirectional gateway requirement. Zero mentions of any of them. 2-4-1-9 requires that direct corporate↔OT communication be prevented and routed through a hardened jump host in a DMZ — that is a mediated path, which is explicitly not an air gap. Anyone quoting the OTCC to sell you a data diode is quoting a document that does not mention data diodes.

An OTCC deadline or grace period. Not stated anywhere. The obligation is "continuous compliance" under Article 10(3) of the NCA's mandate and Royal Decree 57231 dated 10/11/1439H. There is no published transition window, and no date after which something happens.

OTCC fines. No penalty schedule, no SAR amounts, no enforcement tariff appears in the document. Consequences flow from the NCA's mandate, not from a price list in the OTCC.

An OTCC RTO/RPO grid. This is the OT twin of a fabrication we have seen attributed to SAMA, so be alert to it. RTO and RPO appear exactly once in the OTCC's control body — in 3-1-1-3, which requires that OT/ICS cybersecurity requirements "be incorporated into the Business Continuity Plan (BCP), Business Impact Analysis (BIA), Recovery Time Objectives (RTO), and Recovery Point Objectives (RPO)." They are named as concepts you must incorporate. The OTCC states no RTO or RPO figure, and no per-level RTO/RPO table exists. If you have been shown one, someone made it up.

"OTCC applies to all companies in Saudi Arabia." It does not. It applies to ICS in critical facilities of government organizations, and to private-sector owners/operators/hosts of Critical National Infrastructure. Everyone else is "strongly encouraged."

"OTCC is Aramco's standard" / "OTCC replaces SACS-002." The words "Aramco" and "SACS" appear zero times in the OTCC. They are unrelated documents from unrelated bodies. See the next section.

"OTCC covers cloud." The word "cloud" appears zero times in the OTCC. The NCA's cloud document is the CCC. Different document.

"ECC 2-10 and 2-11 cover logging and incident response." They do not — in either standard. In the ECC, 2-10 is Vulnerabilities and 2-11 is Penetration Testing; logging is 2-12 and incidents are 2-13. In the OTCC, 2-9 is Vulnerabilities and 2-10 is Penetration Testing; logging is 2-11 and incidents are 2-12. This specific error is endemic.

"OTCC-2" or a 2024 revision. As of this writing, the document published at nca.gov.sa is OTCC-1:2022. The NCA reserves the right to update it, and says so — always download it rather than trusting a cached copy.

"ISO 27001 gets you OTCC compliance." ISO 27001 is not named in the OTCC, and no certification substitutes for the controls. Nor does IEC 62443 certification — the Annex maps to 62443 so you can reuse evidence, not so you can skip controls.

OTCC vs Aramco SACS-002 — and the two different things called "CCC"

This confusion costs Eastern Province suppliers real money, so let us be blunt.

They are not alternatives, and neither supersedes the other. An Aramco contractor operating a critical facility in the Kingdom can easily be subject to both, for different reasons, and would satisfy them with overlapping but non-identical evidence. Our primary-source guide to the Aramco side is here: Saudi Aramco SACS-002: what Aramco actually asks contractors for.

And then there is "CCC," which means two entirely unrelated things depending on who is saying it:

• NCA CCC = Cloud Cybersecurity Controls (CCC-1:2020). A control framework, an extension to the ECC, for cloud. Nothing to do with OT. You comply with it.
• Aramco CCC = Cybersecurity Compliance Certificate. A certificate, issued by an Aramco-authorised audit firm, proving you meet SACS-002. You obtain it.

One is a framework from the national regulator. The other is a supplier certificate from an oil company. If a procurement officer asks you for "the CCC," find out which one they mean before you spend a riyal. Published compliance content confuses these two constantly — and cross-contaminating them is how you end up citing an NCA cloud control in an Aramco supplier submission.

Where an IT provider fits — and where it does not

Time for the part where we are honest against our own commercial interest, because on this topic the temptation to oversell is enormous and the standard does not support it.

No IT company can make you OTCC-compliant. The OTCC binds the organization that owns or operates the ICS. It does not certify vendors, it does not recognise vendor certifications, and there is no such thing as an "OTCC-compliant supplier." The controls that will decide your assessment — segmentation of the plant network (2-4), separation of OT identity from IT identity (2-2-1-1), an automated asset inventory (2-1-1-2), hardened engineering workstations (2-3-1-7), SIS controller modes (2-3-1-5), a defined safe mode (3-1-1-5) — are engineering work inside your plant, done by people who understand your process. Anyone who tells you a product or a hosting plan discharges them is telling you something the document does not support.

What an IT partner can honestly do is the IT side of the IT/OT boundary, which is where a surprising amount of the OTCC's evidence burden actually lands:

• The corporate zone and the DMZ. 2-4-1-9, 2-4-1-11, 2-4-1-12 and 2-4-1-13 are, in practice, corporate-network engineering: the jump host, the proxies, the dedicated gateways, the DMZ itself. This is ordinary — if demanding — IT infrastructure work.
• Identity separation (2-2-1-1). Getting the plant out of the corporate Active Directory is an IT project, and it is one of the most commonly failed controls.
• Logging and monitoring (2-11). Log collection, retention, SIEM tuning and alerting on new devices are IT capabilities pointed at OT data sources. Our SOC guide covers the shape of this.
• Backups that include engineering files (2-8-1-2). Centralized, offline, and covering PLC/DCS configuration — not just the historian database.
• Documentation (2-4-1-16) and the exception register (1-3-1-6, 1-3-1-7). Unglamorous, decisive, and the cheapest findings to avoid.

Skyline is an IT company based in Dammam, Eastern Province — which is to say, in the middle of the customer base this standard was written for. Skyline Cloud is our managed hosting platform, with an in-Kingdom region — Dammam, powered by Google Cloud — SAR billing, Arabic support, per-account environment separation, daily backups, free auto-renewing SSL, DNS you control, and a 99.9% uptime SLA. Plans run from SAR 49/month (Shared) to SAR 199/month (Cloud — 4GB RAM, 100GB NVMe, auto-scaling, high availability, global CDN). You can start a free 14-day trial with no credit card.

We will describe it in exactly those terms and no further. A hosting platform is not an OT control, and nothing on that list appears in the OTCC. If your problem is subdomain 2-4, what you need is a network engineer and a site visit, not a server. We would rather tell you that than sell you a plan that does not answer your question.

A realistic first 90 days

If you are starting from nothing, this is the order we would work in — because the scoping decisions are the ones that cannot be undone later, and the cheap findings are the ones that hurt most.

1. Read the actual PDF. It is public, it is TLP:White, and the controls run about 20 pages. You will finish it in an afternoon and out-argue most consultants.
2. Determine your facility level with the NCA's Facility Level Identification Tool (1-3-1-4). Nothing downstream can be scoped until this is done, and an L3 facility that plans for L1 will waste a great deal of money.
3. Confirm you are actually in scope. Government ICS in a critical facility, or private CNI. If you are neither, you are "encouraged," and your obligation may be contractual rather than regulatory — which changes who you are answering to.
4. Do the ECC first, or in parallel. It is a mandatory prerequisite (OTCC p.11). An OTCC programme built on no ECC foundation does not comply with the OTCC.
5. Build the automated asset inventory (2-1-1-1 → 2-1-1-5). You cannot segment, patch, back up or monitor what you have not listed — and "automated" is in the text.
6. Draw the true network diagram (2-4-1-16). Not the one on the wall. The real one, with the M2M paths nobody put on the wall. Expect this to be uncomfortable.
7. Close the corporate↔OT direct paths (2-4-1-9, 2-4-1-11). Jump host in a DMZ, proxies for machine-to-machine. This is the big engineering item and it deserves the bulk of the budget.
8. Separate OT identity from IT identity (2-2-1-1) and kill default credentials (2-2-1-3).
9. Open the exception register (1-3-1-6, 1-3-1-7) the day you start, and put every control you cannot safely implement into it, with justification, approval and compensating controls. A documented exception is compliant. A silent gap is a finding.
10. Turn on logging across OT assets (2-11-1-1) and get remote-access sessions monitored and recorded (2-2-1-7, 2-11-1-6).
11. Fix backups to include engineering and configuration files, offline (2-8-1-1, 2-8-1-2).
12. Schedule the reviews (1-6-1 annual, 1-6-2 independent every three years) before the NCA schedules one for you.

Frequently asked questions

How many controls does the OTCC have?

47 main controls and 122 subcontrols, across 4 main domains and 23 subdomains (OTCC-1:2022, Introduction, p.9). We verified this three ways: the NCA's stated figure, a count of the control IDs in the PDF, and a parse of the NCA's own Assessment and Compliance Tool. All three agree.

Is the OTCC a standalone standard?

No. It is an extension to the ECC, and "Compliance with Essential Cybersecurity Controls (ECC 1:2018) is a mandatory prerequisite for the organization" (OTCC, p.11). You implement the ECC first, then the OTCC on top of it.

Does the OTCC apply to my factory?

Only if your ICS sits in a critical facility owned or operated by a government organization, or if you are a private-sector organization owning, operating or hosting Critical National Infrastructure. Otherwise the NCA "strongly encourages" adoption but does not mandate it. Many suppliers are nonetheless pulled in contractually by customers who are in scope.

Is there an OTCC certificate?

No. There is no OTCC certificate and no accredited-auditor scheme. Compliance is assessed by self-assessment and/or field audit by the NCA or a designated third party (OTCC, p.11). The word "certified" appears once in the whole document, and it refers to vendor-certified patches. Aramco's CCC is a real certificate, but that is a different standard from a different organisation.

Does the OTCC require the Purdue Model?

No. "Purdue" appears zero times in the document. The OTCC requires segmentation into zones, choke points, a DMZ, a hardened jump host, proxied machine-to-machine traffic and segregated SIS (subdomain 2-4). A Purdue architecture satisfies those requirements comfortably, but it is a means of compliance, not the requirement itself.

Does the OTCC require an air gap or a data diode?

No. Neither term appears. 2-4-1-9 requires that direct corporate-to-OT communication be prevented and routed through a hardened jump host in a DMZ — that is a mediated connection, which is the opposite of an air gap.

How often must I pen-test my ICS?

2-10-1-3 sets it by facility level: every 3 months at L1, 6 months at L2, 12 months at L3. The same cadence applies to vulnerability assessment under 2-9-1-3. Testing must have limited or no impact on production, or be run on an identical separate environment (2-10-1-2), and passive alternatives must be defined where active testing could disturb operations (2-10-1-4).

What is the OTCC compliance deadline?

The document does not state one. It requires continuous compliance under Article 10(3) of the NCA's mandate and Royal Decree 57231 dated 10/11/1439H. There is no published grace period or transition window in the PDF.

Does the OTCC set RTO and RPO targets?

No. RTO and RPO are named once, in 3-1-1-3, as things your BCP and BIA must incorporate. The OTCC states no RTO or RPO figures and contains no per-level RTO/RPO table. Any such grid you are shown was invented.

What happened to ECC domain 5?

ECC-1:2018 had a fifth main domain covering Industrial Control Systems Cybersecurity. ECC-2:2024 deleted it and moved the controls to the OTCC. The OTCC's Methodology and Mapping Annex contains Table 1, "Relationship Between OTCC and ECC Domain 5," mapping each old ECC 5-x-x control to its OTCC successors.

Is the OTCC the same as Aramco's SACS-002?

No, and they have no formal relationship. The OTCC is a regulatory framework from the NCA binding critical-facility operators. SACS-002 is a contractual standard from Saudi Aramco binding its suppliers. The words "Aramco" and "SACS" appear zero times in the OTCC. A contractor operating a critical facility may well be subject to both. See our SACS-002 guide.

Which language version governs?

Arabic. The OTCC's cover page states that "the Arabic version will be the binding language for all matters relating to the meaning or interpretation of this document." The English PDF is a translation, and it contains at least one heading error (subdomain 1-8). Argue from the Arabic.

Sources

Every control number, count and quotation above was taken from these documents directly. They are published by the NCA at Document Classification: Public / TLP: White, and they — not this page — are the authority.

• NCA — Operational Technology Cybersecurity Controls (OTCC-1:2022) (PDF — counts p.9; scope and applicability p.10; ECC prerequisite, assessment means and the two tools p.11; levels Table 1 p.12; domains Figure 2 p.14; coding Figures 3–4 p.15; controls pp.16–36; Choke Point definition Appendix A)
• NCA — OTCC Methodology and Mapping Annex (OTCC-1:2022) (PDF — ECC relationship and "comply with ECC first"; international standards list; Table 1, "Relationship Between OTCC and ECC Domain 5")
• NCA — OTCC-1:2022 Assessment and Compliance Tool (XLSX — all 169 controls with per-control level marks; the four-value compliance scale)
• NCA — OTCC controls page (the canonical download location)
• NCA — Essential Cybersecurity Controls ECC-2:2024 and ECC-1:2018 (PDFs — used to verify that the ECC subdomains the OTCC cross-references are numbered identically in both versions)

The NCA also publishes a Guide to Operational Technology Cybersecurity Controls (OTCC) Implementation (GOTCC-1:2023). We retrieved it, but its body is published as page images rather than machine-readable text, so we have not quoted from it and nothing in this article rests on it.

Last verified against the NCA's published documents in July 2026. Standards change. The download on nca.gov.sa is always the authority — and if this page and the PDF ever disagree, the PDF is right and we want to know.