If you have been reading the ECC-2:2024 control list looking for the industrial control systems domain, stop looking. It is not there.
ECC-1:2018 had five domains. ECC-2 has four: governance, defense, resilience, third party and cloud. Domain 5, industrial control systems, was not renumbered and was not folded into the defense domain. It left the document. All four of its controls, 5-1-1 through 5-1-4, have no ECC-2 successor at all.
They did not stop being obligations. Operational technology now sits under a standard of its own, the NCA Operational Technology Cybersecurity Controls, OTCC-1:2022, published two years before ECC-2 removed the domain. OTCC extends the ECC baseline for ICS/OT estates in critical facilities, and the facility’s classification determines how much of the standard applies. The mechanism is concrete: NCA’s Facility Level Identification Tool assigns each facility one of three levels based on criticality and availability impact, HSE impact, and impact on the national economy and security. Level 1 carries 151 controls and subcontrols, level 2 carries 117, level 3 carries 56, and the levels nest, so a level 1 facility answers for everything below it. Read in that order, and for a critical facility, the removal is housekeeping: the NCA does not restate in ECC what another NCA standard governs. Read from inside an entity that built its OT posture out of ECC-1 domain 5, it is a scope change and a governance problem arriving at the same time. One seam is worth knowing: OTCC-1:2022 still names compliance with ECC-1:2018 as a mandatory prerequisite and maps itself to ECC-1 domain 5, and the NCA has not reissued it against ECC-2, so the two current documents point at each other across a superseded edition.
What domain 5 asked for
Four main controls. The first said define your ICS/OT cybersecurity requirements. The second said implement them. The fourth said review them periodically. That is the same governance triple you find throughout ECC-1, and on its own it says nothing specific about operational technology.
The substance sat in one control, 5-1-3, whose ten subcontrols list the minimums: network segmentation, isolation of safety instrumented systems, monitoring, restrictions on removable media and mobile devices, hardening, vulnerability and patch management, anti-malware.
Read that list as a controls engineer and two things stand out. It is correct: every item belongs. And it is ten subcontrol lines, while each line is a program.
“Network segmentation” in a plant commissioned before anyone drew a network diagram means a zone and conduit design, a survey of every flat path between the business network and the process network, and a conversation with operations about the data flows that will break when you close them. “Vulnerability and patch management” means a controller the vendor will not support if you patch it outside a validated firmware release, an HMI running an operating system that went end of life during the last turnaround, and a maintenance window you get twice a year instead of twice a month.
None of that fits in a four-control domain. It was never meant to. Domain 5 was a placeholder holding open a space in ECC until a real OT standard existed. Deep enough to name the disciplines, too thin to govern them.
What changes for an entity that was “ECC compliant”
Three things, and the third is the one that bites.
Scoping moves to the facility. ECC scopes the entity. OTCC’s applicability is driven by OT facilities and their criticality, which means one entity can carry different obligation depth across its own sites. So the first deliverable is not a control matrix, it is a facility register: which sites, which systems inside them, which classification each one lands in. Confirm this against the official OTCC document rather than a consultant’s summary. Getting the classification wrong in either direction is expensive.
The control depth is OT-native. The four-domain spine will look familiar to anyone who has run an ECC program, so the architecture does not surprise. The control text underneath it does. This is a standard written for people who know that you cannot run an authenticated scan against a PLC to populate an asset field, that remote vendor support is a permanent inbound path and not an exception, and that an engineering workstation is the most valuable host in the estate. The one-line list in ECC-1 5-1-3 expands into whole subdomains. If your OT evidence today is a policy and a diagram, the honest expectation is that most of it is a starting point rather than a submission.
A governance seam appears where there wasn’t one. ECC-2 has not stopped applying to you. Corporate IT, ERP, email, the identity platform: still ECC-2. The plants: OTCC. Two standards, two assessment calendars, two evidence libraries, and if nobody intervenes, two owners and two risk registers.
If a vendor tells you that ECC-2 removed the ICS controls so your OT scope has shrunk, ask where OTCC sits in their answer, and ask whether your facilities are classified as critical. For a critical facility the requirement did not shrink: it moved, and it got considerably longer. For ICS that sits outside a critical facility the honest answer is different and worse. ECC-1 domain 5 was the only mandatory OT baseline those systems had, OTCC applies to them as strong encouragement rather than obligation, and nothing mandatory replaced what ECC-2 removed.
Two frameworks, one risk reality
The split is a documentary fact. It is not a risk fact. Ransomware that lands in corporate IT and stops a line because scheduling, historian and MES all authenticate against a shared domain controller is one event with one root cause and one consequence. Run two registers and you get two teams each rating half of that path, each rating their half as tolerable, and nobody accountable for the sentence that joins them.
I designed an integrated IT/OT risk assessment framework mapped to NCA OTCC and ECC covering 50+ industrial control systems at a defense manufacturer.
What makes a single register work, in the order the work has to happen:
One asset model, two asset profiles. A single inventory with a single identifier space, so a path that starts on a laptop and ends at a controller is traceable in one query. But an OT asset carries attributes an IT asset does not: its zone, its conduits, whether it performs a safety function, its vendor support state, who holds patch approval authority, and what physically happens if it stops. Same model, extra fields, different discovery method. Populate the OT side passively and from the drawings, the vendor contracts and a walk-down with the controls engineers.
One taxonomy and one scale. Shared threat categories, shared likelihood scale, shared treatment states, and critically, a consequence scale that can express safety, environmental and production impact rather than only data and regulatory outcomes. This is the single most common failure in merged registers. If the top of your consequence scale reads “regulatory penalty and reputational damage,” every OT risk you rate against it comes out looking smaller than the plant knows it is, and the committee will de-prioritize accordingly. Fix the scale once at enterprise level and let both sides inherit it.
One reporting line. One register, one heat map, one committee. The moment IT risk and OT risk become separate agenda items, the committee is free to assume that somebody else owns the connection between them.
Where the registers may not merge
Two places where forcing convergence is the wrong instinct.
Safety instrumented systems. An SIS is not an availability requirement with a security wrapper. It is the last barrier between a process upset and someone getting hurt, and its integrity is governed by a functional safety regime with its own lifecycle, verification and change authority. The security assessment of an SIS documents that it is isolated, that its engineering interface is controlled, and that any proposed security change is routed through the safety process rather than the security process. You reference the safety case in your risk register. You do not absorb it, and you do not push remediation into safety logic outside the functional-safety lifecycle: changes to a safety instrumented system go through the management-of-change process under IEC 61511 and IEC 61508, with the cybersecurity engineering informed by IEC 62443. ECC and OTCC do not spell that rule out, but the plant manager will, and the assessor will side with the plant manager.
Change control. Keep two boards. IT change control optimizes for speed with a rollback path. OT change control optimizes for not disturbing a running process, which means vendor validation, testing on a replica or waiting for a turnaround, and an approval chain that includes operations and safety. Merge them and you get one of two failures: OT changes approved at IT cadence, which is how a line goes down, or IT changes slowed to turnaround cadence, which is how your patch SLA collapses. One register, two boards. The register records the risk and the agreed treatment; each board decides how its treatment executes under its own rules. What you do need is a shared trigger, so that any change to a shared dependency, identity, DNS, time, the DMZ, the remote access path, is reviewed on both sides before it lands.
What to do first, in order
For an entity that has just worked out that OTCC applies to it:
- Confirm applicability and scope by facility, in writing. Which sites, which systems, which classification, verified against the official OTCC document and signed by someone who can be held to it. Everything downstream depends on this answer.
- Build the OT asset inventory passively, and start now. Do not wait on a tool purchase. Drawings, vendor support contracts, a walk-down with the controls engineers, and an owner recorded for every asset. If you hold an ECC-1 domain 5 evidence pack, mine it: the segmentation diagrams and the SIS isolation evidence carry forward even though the controls did not.
- Name one accountable owner for the seam. Not “IT security owns IT and the plant owns OT.” Someone owns the boundary itself: the DMZ, the shared identity and directory services, the jump hosts, the remote access paths, the data flows leaving the plant. Unowned seams are where the incidents live.
- Run the first gap assessment at domain level, not control level. You want the shape of the gap in four weeks, not a perfect matrix in six months. Control-by-control rigor belongs to the second pass, once scope is settled and you know which facilities carry which depth.
- Fix the consequence scale before you rate anything. If the enterprise scale cannot express injury or lost production, amend it before you rate anything against it.
- Commit to a date for the first combined report. One IT and OT risk report, one register, one governance committee, with a date on the calendar. A dated report to a real committee is what forces the asset model, the taxonomy and the ownership questions to actually resolve. Nothing else reliably does.
The honest read
Domain 5 came out of ECC because it had done its job. If domain 5 was your OT program, what you had was a compliance line item the framework’s own thinness let you satisfy, and the removal has made that visible.
The tempting response now is to stand up a second program, because there is a second document, a second assessor and a second calendar. Resist it. There is one estate facing one adversary, and the board has to be told plainly what the risk is. The two frameworks should feed one register.
Educational, not legal advice. Verify against official NCA sources.