One standard for IT and OT, two ways of applying it

This is part 3 of 12 of the “Common language” series on industrial cybersecurity; it continues with part 4, recommended is not optional.

Picture a group IT security policy that says every machine is patched on a fixed monthly calendar. The automation engineer reads it, looks at the batch controller that has run the same firmware since commissioning, and files the policy under “not for us”. A few months later an auditor finds that the plant has no written rule at all. There is an IT rule nobody applies on the shop floor, and an OT practice nobody ever wrote down. This article is about that gap.

A shared vocabulary only holds if it is written down somewhere, and if that somewhere carries authority. That is the job of an organisation’s internal industrial cybersecurity standard: one short, enforceable document that says what is required, on which scope, and with what level of evidence. Without it, every site negotiates its own rules, every integrator turns up with its own architecture, and the first incident shows there was never a common reference.

Three functions, in this order

A good standard does three jobs. It fixes the language first: the glossary sits at the top of the document, not in an appendix, for the reasons the first article in this series gave.

It then states the hard points, as a short list of requirements, each written so that someone can verify it. “Every link between the control zone and the corporate network passes through an industrial DMZ” can be checked on a drawing and on a firewall. “The network must be secure” cannot be checked by anyone.

Finally, it serves as the reference for gaps. A site’s remediation plan is simply the list of differences between its actual state and the standard, ordered by risk.

Where the standard sits: four levels

It helps to picture four layers. At the top is what the organisation undergoes: regulation. That means NIS2 (Directive (EU) 2022/2555) and its national transpositions, sector rules such as EU GMP Annex 11 on computerised systems or the US FDA’s 21 CFR Part 11 on electronic records and electronic signatures, and incident notification duties. Below that is what it chooses: international references such as ISA/IEC 62443, ISO/IEC 27001:2022 and the NIST Cybersecurity Framework 2.0. Then comes what it writes: the internal standard, with its glossary, verifiable requirements, target security levels and exception rules. At the bottom is what each site applies: a gap analysis, a dated remediation plan, recorded exceptions and evidence of application.

Of the four levels, the internal standard is the only one the organisation fully controls, and the one that turns the others into something a site can act on. Regulation moves slowly and unevenly. NIS2 had to be transposed by 17 October 2024. The European Commission sent letters of formal notice to 23 Member States on 28 November 2024 and reasoned opinions on 7 May 2025; on 8 July 2026 it announced that it was referring Ireland, Spain, France and the Netherlands to the Court of Justice because they had yet to notify full transposition. The NIS2 article in this journal covers what the Directive asks of a site. A well-built internal standard does not need to wait for the last national decree.

Nor is the standard frozen. A completed remediation, a new regulatory obligation or a change in the international references should each trigger a review. A standard written once, circulated and never reopened slowly turns into an administrative fiction. Give it a named owner and at least one versioned review a year.

What should it cover?

A standard needs a skeleton detailed enough to audit and simple enough to write. The main OT references (ISA/IEC 62443, NIST SP 800-82 and the SANS paper The Five ICS Cybersecurity Critical Controls) point to a common set of concerns. EUCALEX groups them into seven domains, each with the question a site must be able to answer and the evidence that shows it can.

On a GMP site, most of the evidence column already has a home. The inventory overlaps the list of computerised systems, the backup test sits next to the data integrity controls, and the vulnerability register can follow the logic of the deviation and CAPA system. Write the standard so that it reuses those records. A second documentation system, built in parallel, is one nobody will maintain.

One document for IT and OT

Digitalisation has rubbed out most of the border between the two worlds. Historians, digital twins, predictive maintenance, remote supervision and shared identities keep adding points of contact, and attackers go for exactly those. Two separate standards, one for IT and one for OT, leave a grey zone at the seam, and that seam is where the risk collects. One document, one glossary and one governance close it.

But two regimes of application

A single document does not mean identical treatment. Each requirement should say explicitly how it applies on each side, because the power to enforce is not the same.

In IT, a rule is decided and imposed. It is pushed through central configuration and checked automatically, and a gap is a non-conformity to be corrected.

In OT, the same rule can often only be prescribed, strongly recommended and adapted. The objective is set centrally; the method is worked out system by system. Patching is an engineering decision under management of change (MOC), agreed with the vendor and tied to a shutdown window. Checks are often manual and the evidence is documentary. A gap becomes a recorded exception with a compensating measure. That is not laxity: the reasons are known, and they can be written down.

One rule for the OT column, and it is not up for discussion: what cannot be applied in OT is never simply dropped. It is compensated, recorded, dated and reviewed.

Why OT cannot simply be ordered

Better to write these reasons into the standard than to let them come back later as case-by-case excuses.

The priorities differ. IT protects confidentiality first, while NIST SP 800-82 puts integrity and availability first in OT, then confidentiality, with safety as an overarching priority. A measure that improves the first at the expense of the others is a bad measure on a plant.

Some OT systems are technically limited: unsupported operating systems, controllers with no native authentication, devices with no spare memory or CPU to run an agent, firmware that cannot be changed without requalification.

Protocols, hardware and software are different too. Modbus in its classic form, OPC Classic, much of the PROFINET installed base and proprietary fieldbuses usually come without a directory service, without native encryption, and without the tooling the office world takes for granted. Secured variants exist (OPC UA builds in encryption and signatures; Modbus has a TLS-based security protocol), but the installed base changes slowly. Even routine IT habits can backfire. NIST warns that active scans “may cause device instability or interfere with the device process state”, which is why passive monitoring is preferred on production networks.

Tolerance for downtime and latency is close to zero. A “harmless” reboot is a production stop, and a small added delay or jitter can upset a fast control loop or an interlock. And the vendor’s liability is engaged: modifying a qualified system, whether it carries a SIL rating, GMP validation or a type approval, can put a certification or a warranty at stake.

The same requirement, two treatments

In practice, each line of the standard carries two columns. EUCALEX tags each one with a requirement level: required, required with adaptation, strongly recommended or not applicable. That scale is the subject of the next article. A few examples show how it works.

Notice the last two rows: remote access and backups are as strict in OT as in IT. Where OT gets flexibility, it comes with conditions attached, never as a blanket exemption.

Where to start

Most organisations already have an IT security policy and a scattering of OT practices. The work is to merge them, not to start from a blank page.

1. Put the current IT policy next to the seven domains and mark, line by line, whether it is applied, ignored or impossible in the plant.
2. Write the glossary first. Then rewrite each requirement so that someone who did not write it can check it.
3. Add the OT column to every requirement, with its level and, where the level is not “required”, the compensating measure expected.
4. Name the owner of the document and put the first versioned review in the calendar, along with the events that bring it forward.
5. Run the gap analysis on one site, and treat that site’s remediation plan as the first test of whether the standard can be applied at all.

Five common mistakes

• Two standards, one seam. A separate IT policy and OT policy leave the historian, the DMZ and shared identities belonging to neither.
• Copying the IT policy onto the plant. A rule that cannot be applied is not applied, and after that nobody believes the rest of the document either.
• Requirements nobody can check. “The network must be secure” produces arguments, not evidence.
• Flexibility with no conditions. An OT column that says “best effort” is an exemption under another name.
• A standard never reopened. Without an owner and a review date, the document describes the site as it was the day it was written.

One document and two regimes: that is how a group keeps a common requirement and still applies it credibly on the plant floor.

References

• European Commission, Commission refers Ireland, Spain, France and the Netherlands to the Court of Justice for failing to transpose the rules on cybersecurity (NIS2), 8 July 2026. digital-strategy.ec.europa.eu
• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, September 2023. nvlpubs.nist.gov
• NIST Cybersecurity Framework (CSF) 2.0, CSWP 29, 26 February 2024. nvlpubs.nist.gov
• SANS, The Five ICS Cybersecurity Critical Controls, R. M. Lee and T. Conway, November 2022. sans.org