OTCC: A Clear Guide to Saudi OT Cybersecurity in 2026

The OTCC — Saudi Arabia’s Operational Technology Cybersecurity Controls — became
considerably more important in 2024, and many organisations have not noticed. When the National
Cybersecurity Authority published ECC 2-2024 it deleted the ECC’s industrial control systems domain
and moved those controls here. If you operate OT in the Kingdom, the OTCC is now the control set that
governs it.

What the OTCC is, and why it absorbed the ECC’s ICS domain

NCA publishes OTCC-1:2022 as the control set for operational technology and
industrial control systems. It sits alongside the Essential Cybersecurity Controls rather than
replacing them: an entity in ECC scope that operates OT meets the ECC baseline and this set on top.

Under the previous edition, ECC-1:2018, industrial control systems were main domain 5 of the ECC
itself. ECC 2-2024’s list of updates records the change plainly — main domain 5 was deleted, and its
controls moved to the OTCC. The ECC went from five main domains to four.

That is a relocation, not a relaxation. The obligations did not go away; they moved to a document
many IT security teams have never opened.

The stale-sentence problem this creates

Any documentation written under ECC-1:2018 that says something like “ICS cybersecurity requirements
are covered by the ECC” was true when written and is false now. Worse, a mechanical version relabel
makes it *more* wrong: swapping “ECC-1:2018” for “ECC 2-2024” throughout a policy set produces a
confident, current-looking sentence asserting that the ECC covers controls it no longer contains.

When re-baselining a Kingdom document set, search for the subject that moved — ICS, OT, industrial
— before treating the version swap as routine. Our guide to
ECC 2-2024 covers the wider transition.

Why OT security is not IT security with different equipment

The reason OT warrants its own control set is that the engineering constraints invert several
assumptions IT security is built on.

Applying an IT policy set unchanged to an OT environment is how organisations end up with controls
that are formally documented and operationally ignored — which fails an assessment and, more
importantly, protects nothing.

Where it sits against IEC 62443

Organisations with international operations usually meet OT security through
IEC 62443, the global standard for
industrial automation and control systems. The two are complementary rather than competing: IEC 62443
supplies the engineering model — zones
and conduits, security levels,
the role split between asset owner, integrator and product supplier — while the OTCC is the Kingdom’s
regulatory instrument.

In practice a mature OT programme built on IEC 62443 will satisfy much of its substance, but the mapping has to be documented, and the national set is what an NCA assessment examines. Neither replaces
the other.

Standing up an OTCC programme

1. Inventory the OT estate. Most organisations discover they have more connected OT
   than they believed, and the unknown devices are the exposure. Nothing else works until this exists.
2. Establish the boundary. Where OT meets IT is where most incidents cross. Segment
   it deliberately —
   the Purdue model is the usual
   reference for how those layers are drawn.
3. Deal with remote access explicitly. Vendor and engineer access is the most common
   OT attack path and the hardest to remove, because maintenance depends on it. See
   OT secure remote access.
4. Write patching around the maintenance calendar, not against it. A patch policy OT
   engineers cannot follow is a policy that will be ignored —
   OT patch management covers the
   compensating-control approach.
5. Monitor passively. Active scanning can disrupt control systems; passive network
   monitoring is the norm and is what most OT-aware tooling provides.
6. Plan for incidents with safety in the room. An OT incident response plan without
   operations and safety engineering involved is an IT plan with different asset names.

What an OTCC assessment tends to find

OT programmes fail assessments in recognisable ways, and none of them is exotic.

• An incomplete asset inventory. Almost universal. Devices added by engineering or
  a vendor over the years, never recorded, frequently reachable.
• Flat networks described as segmented. A diagram showing zones, and a switch
  configuration that does not enforce them. Segmentation asserted rather than verified is the most
  common single finding.
• Vendor remote access with no controls around it. Standing accounts, shared
  credentials, no session recording, no approval step — kept alive because maintenance depends on it.
• Default credentials on control equipment. Still routine, and often justified on
  the grounds that the device is “not connected”, which the asset inventory then contradicts.
• No OT-specific incident plan. An IT plan with OT asset names, written without
  operations or safety engineering, that nobody has exercised.

What these share is that none is fixed by writing a document. Each needs an engineering change,
which is why an OT programme should be scoped as a technical project with documentation attached
rather than the reverse.

Start with the inventory, always

If time or budget forces a single first step, make it the asset inventory. Segmentation cannot be
designed without knowing what is on the network, remote access cannot be controlled without knowing
which devices vendors reach, and patching cannot be prioritised without knowing what is running. Every
other control depends on it, and it is the one that consistently takes longer than planned.

Incident response is where the two worlds actually collide

An OT incident forces a decision an IT incident rarely does: whether to keep running. Isolating a
compromised system is the reflex response in IT and can be the wrong one in OT, where disconnecting a
controller may create exactly the safety event the programme exists to prevent.

That decision cannot be made in the moment by whoever is on the security rota. It has to be agreed
in advance, with operations and safety engineering, and written into the plan: which systems may be
isolated unilaterally, which require an operational decision, who can authorise a shutdown, and what
happens when the security team and the plant manager disagree at three in the morning.

Exercising it matters more here than anywhere else, because the people who must act have day jobs
that do not involve security tooling.

A note on IEC 62443

Teams with an existing industrial security programme usually ask how the OTCC relates to IEC 62443,
the international series most OT engineers already know. They are compatible in intent and different
in form: IEC 62443 is a technical series organised around zones, conduits and security levels, while the Saudi set is a national one organised around governance, protection, resilience and third
parties.

Work done for IEC 62443 — the zone and conduit model in particular — supports its segmentation expectations directly, and the asset inventory serves both. What IEC 62443 will not give you is the compliance artefacts, because the assessment is against the OTCC’s own controls.
Treat the international series as the engineering method and the Saudi set as the obligation.

Frequently asked questions

What does OTCC stand for?
Operational Technology Cybersecurity Controls, published by Saudi Arabia’s National Cybersecurity
Authority. The current edition is OTCC-1:2022.

Why did the ECC remove its industrial control systems domain?
ECC 2-2024 deleted main domain 5 and moved those controls to the OTCC, consolidating OT requirements
in one place. The ECC now has four main domains.

Does the OTCC replace the ECC for OT operators?
No. An organisation in ECC scope that operates OT meets the ECC baseline and the OTCC in addition.

How does the OTCC relate to IEC 62443?
IEC 62443 is the international engineering standard; the Saudi control set is the regulatory instrument. A
programme built on IEC 62443 covers much of the substance, but the mapping must be documented and the national set is what is assessed.

We only have a few PLCs — are we in scope?
Scope follows the ECC: government entities and their affiliates, and private organisations owning,
operating or hosting Critical National Infrastructure. If you are in ECC scope and operate any industrial control systems, these controls apply to them.

Where this leaves you

The OTCC did not appear from nowhere in 2024 — it absorbed obligations that were already yours,
from a document your IT team was probably reading. If you operate industrial control systems in the
Kingdom, check three things: that your documentation points at the OTCC rather than at the ECC’s
deleted domain 5, that your asset inventory is real, and that your segmentation is enforced rather
than drawn.

None of those is a documentation task, which is the honest summary of such a programme. The policies matter, but the controls are satisfied by engineering, and the assessment looks at the
engineering.

References

• NCA regulatory documents — where the control sets are published.
• Essential Cybersecurity Controls (ECC 2-2024) — Appendix C records the domain 5 deletion.

More on NCA compliance and OT security

• The OTCC — you are here
• ECC 2-2024 explained
• The NCA control sets
• Cloud Cybersecurity Controls
• IEC 62443 explained

All of these are covered by the NCA Cybersecurity Toolkit, or start with the free ISO templates.