Who decides, who executes, who checks? Roles in industrial cybersecurity

This is part 5 of 12 of the “Common language” series on industrial cybersecurity; it continues with part 6, six actions in six months.

One sentence comes up on almost every industrial site: “I thought IT was taking care of that.” The network in the administration building has an owner. The switch an integrator put in a shop-floor cabinet twelve years ago, behind the motor starters, often does not. Until that boundary is drawn, the only people who cross it on purpose are attackers.

After vocabulary, this is the second place where programmes get stuck. Nobody refuses the work. Each party assumes someone else is responsible, and the gaps between those assumptions become the attack surface. Anyone from quality on a pharmaceutical or chemical site knows the pattern: a system nobody owns is a system nobody maintains, and it tends to be the one found out of date on inspection day.

Three questions for every perimeter

Defining roles comes down to three questions per perimeter: who decides, who executes, who checks. The answers depend on the size of the site. In a small plant one person may wear all three hats; a large complex may have a team per role. What counts is that the answers are written down and that each perimeter has a named owner, a person, not a department.

The split below is the one EUCALEX uses as a starting point. It does not come from a standard. Adapt it, but write it down.

1. Site management decides

Only one level can weigh a security measure against a production constraint and a budget line, and that is site management. Nobody expects the site director to configure firewalls. What is expected is a formal, written acceptance of the residual risk left once the agreed measures are in place, and the money for the path that reduces it.

For entities covered by the EU NIS2 Directive this has become a legal duty. Article 20(1) requires Member States to ensure that the management bodies of essential and important entities “approve the cybersecurity risk-management measures” taken under Article 21, oversee their implementation and can be held liable for infringements. Article 20(2) requires members of those bodies to follow training. A signed acceptance of residual risk is a simple way to show that approval and oversight really happened; the NIS2 article in this journal covers the rest of the evidence the Directive expects.

2. The OT cyber lead steers

Between decision and execution, someone has to hold the plan together: follow remediation, keep the register of deviations and waivers, and know at any moment which exceptions were granted, by whom and until when. When this role fails, it is rarely for lack of competence. It is for lack of time. A lead with no hours set aside is a name on an organisation chart.

Whatever the arrangement, EUCALEX recommends a mission letter that states the share of time actually allocated, the perimeter covered (and so the one that is not) and the annual training budget. Without those lines the function wears away at the first unplanned shutdown.

3. Engineering and operations execute

Engineering and automation teams apply the measures to the systems they already look after: hardening, backups, changes under MOC. On a GMP site that MOC is simply the change control the quality system already runs. A firewall rule on a validated line is a change like any other, assessed for impact before anyone touches it. Operations see the process every shift; they notice the abnormal first and they are the ones who apply fallback procedures. Both execute. Neither should be left to set priorities alone.

4. HSE, IT and procurement contribute

HSE holds what nobody else has: the reference consequences from the PHA and LOPA studies, and scenarios into which cyber causes can be added. Corporate IT and the CISO secure everything upstream of the plant (enterprise network, industrial DMZ, identities, SOC) and supply detection tooling. They do not, however, decide alone on anything that touches the process. A patch, a scan or an account lockout on a control system is an engineering decision.

Procurement is the contributor most often forgotten, although a large share of OT exposure comes in through vendors, integrators and remote maintenance, and the contract is the only lever the site has over them. Three clauses carry most of the weight.

• A software bill of materials (SBOM) for delivered systems. Under the EU Cyber Resilience Act (Regulation (EU) 2024/2847), manufacturers of products with digital elements must draw up an SBOM covering “at the very least the top-level dependencies” (Annex I, Part II, point 1) once the Regulation applies on 11 December 2027 (Article 71(2)). Nothing in it obliges them to hand that SBOM to customers. If the site wants it, the contract has to ask.
• Access conditions. How, when and through which controlled path a vendor may connect, and who approves each session. The vendor remote access article describes the technical pattern; the contract says who signs.
• Incident notification. The vendor’s duty to tell the site, within a stated time, about a vulnerability or incident affecting what it supplied. The CRA’s reporting obligations (Article 14), which apply since 11 September 2026, cover actively exploited vulnerabilities and severe incidents and include informing impacted users (Article 14(8)). They do not reach every vulnerability or incident, and they set no deadline agreed with your site, so the contract should still ask.

For integration and maintenance contracts, IEC 62443-2-4 is a good anchor. Its second edition (2023) sets security programme requirements for IACS service providers and is written so that asset owners can use it to specify what they expect from those providers. Quoting its requirements in a tender turns “the integrator will follow good practice” into something you can check at acceptance.

5. Audit checks

This last role works only if it is independent. Audit and compliance verify what is actually applied on site, not what the procedure says, and they cannot be the people who did the work. An engineer auditing their own configuration finds what they expect to find. On a regulated site the internal audit programme already exists; adding the OT standard to its scope costs far less than building a parallel one.

6. In an incident, roles become a decision chain

The table proves its worth, or shows its holes, on the day something goes wrong. In incident response the hard part is seldom technical; it is deciding. Who isolates a zone? Who stops production? Who informs the authorities, and by when? If those answers are worked out during the incident, the delay is counted in hours. They belong in an OT-specific response procedure, tied to the site’s safety and crisis-management channels and rehearsed with operations and HSE.

A short tabletop exercise makes the point fast. Take a plausible scenario, say an unknown device showing up on the packaging network at two o’clock on a Sunday morning, and ask each role in turn what it does and whom it calls. The first name nobody can give is the first line to write.

Where to start

List the perimeters, beginning with the ones nobody claims: the integrator’s cabinet, the skid with its own 4G modem, the vendor laptop that comes in twice a year. Those are found by walking the floor, not by reading a drawing. Then:

1. Walk the unit with engineering and operations and put every perimeter on one list, including those that belong to a supplier.
2. Write a name, not a department, against each of the three questions for every perimeter.
3. Write the OT cyber lead’s mission letter: time allocated, perimeter covered, training budget.
4. Have site management sign the result together with the current residual risk.
5. Hand the list to audit and ask for a field check within the next audit cycle.

Five common mistakes

• A department instead of a name. “Engineering” owns nothing. A named engineer with a deputy does.
• An OT lead with no time. The title without the hours gives you a register that stops moving after the first shutdown.
• Letting IT decide alone on the process. A patch or an account lockout on a controller is an engineering decision, taken with operations.
• Assuming the CRA replaces the contract. The Regulation covers some vulnerabilities and incidents and does not put the SBOM in the customer’s hands.
• Auditors checking their own work. People verifying a change they made themselves find what they expect.

A perimeter without a named owner is not shared by everyone. It is covered by no one.

References

• Directive (EU) 2022/2555 (NIS2), Article 20, governance: approval, oversight, liability and training of management bodies. eur-lex.europa.eu
• Regulation (EU) 2024/2847 (Cyber Resilience Act): Article 14 (reporting and informing users), Article 71 (dates of application), Annex I Part II (SBOM). eur-lex.europa.eu
• IEC 62443-2-4:2023, Security program requirements for IACS service providers. webstore.iec.ch