Govern & Identify to Recover & Improve: the functions of an OT programme, with people at the centre

This is part 8 of 12 of the “Common language” series on industrial cybersecurity; it continues with part 9, the remediation cycle.

A new detection probe is switched on in a plant. Within a week it has reported several hundred flows, and nobody can say which are legitimate, because nobody knows which assets are supposed to be there or who owns them. The probe works fine. It was simply bought for the third function of a programme whose first one had never been done.

Rather than invent a house structure for an OT security programme, it pays to borrow one that everyone already understands. The function-based logic popularised by the NIST Cybersecurity Framework is read the same way by corporate IT, site management, insurers and regulators, and it translates without much effort into the reality of a plant.

A word on the framework

The original framework had five functions: Identify, Protect, Detect, Respond and Recover. Version 2.0 of the NIST Cybersecurity Framework, published on 26 February 2024, added a sixth, Govern, and placed it at the centre of the others because it “informs how an organization will implement the other five Functions”. NIST also stresses that “the Functions should be addressed concurrently”, not one after the other.

For OT sites, EUCALEX uses a deliberately simplified grouping of five. It is our own method, not NIST’s model. Govern is paired with Identify, because without a written strategy and assigned responsibilities an inventory leads nowhere. Improvement is attached to Recover, because recovery after an incident or an exercise is what produces the most useful lessons. (In CSF 2.0 itself, the Improvement category sits under Identify.) For OT-specific controls, NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security (September 2023), provides an OT overlay of the SP 800-53 Rev. 5 controls. The same five-step reading is set out in Securing OT/ICS: a cycle, not a project.

The order matters

Each function assumes the one before it. You cannot protect what you have not identified, you cannot usefully detect on a network you have not segregated, and you cannot respond well to an alert nobody knows how to read. NIST is right that all functions end up running in parallel. On a plant, though, they mature in sequence.

The programmes that struggle nearly always start in the middle of the chain, very often with the purchase of a detection tool, as in the opening scene.

01 · Govern & Identify: know what you want, then what you have

This is the function most often rushed, and every other one depends on it. Governing means an OT security policy and standard, graded requirement levels, rules for exceptions, and a named sponsor in site management. It means deciding, for every perimeter, who decides, who executes and who checks, including the areas nobody claims. It also covers external requirements: applicable regulation, and supplier contract clauses on software bills of materials (SBOMs), access conditions and incident notification.

Identifying means an inventory of PLCs, HMIs, engineering workstations, drives, smart sensors and vendor-supplied skids, each with version, location and owner. It means mapping flows and dependencies: who talks to whom, by which path, and what each critical asset relies on. The links nobody claims are found by walking the cabinets, not by reading the drawings. Finally, assess risk by consequence, reusing the site’s existing PHA and LOPA studies (and, on a GMP site, the risk assessments already written for validation), and keep a prioritised register of vulnerabilities and gaps.

02 · Protect: reduce the surface, make access hard

Protect consumes the most resources, and it is where IT and OT practice differ most.

• Segregate. Zones and conduits, an industrial DMZ, separation of the safety instrumented system from basic control, isolation of wireless equipment.
• Control access. Named accounts, least privilege, stronger authentication, no shared or dormant accounts. Remote access always goes through the DMZ, opened on demand, supervised and recorded, vendors included.
• Harden. Unused services and ports disabled, application allow-listing, controlled removable media, a reference configuration per device type.
• Treat vulnerabilities. Patches decided through management of change (MOC); for legacy equipment that cannot be patched, a compensating measure that is documented, dated and reviewed.
• Back up. PLC programs, recipes, configurations and supervision images, offline or genuinely protected.

Awareness and training also belong in Protect, not in an annex at the back of the programme.

03 · Detect: see what happens on the control network

In OT the constraint is simple: observe without disturbing. Passive collection is the default in production. NIST SP 800-82 Rev. 3 (Appendix E.2.3) warns that “active scans may cause device instability or interfere with the device process state” and that they “should be scheduled to occur during planned OT outages whenever possible”. Any active query is therefore deliberate, made with a tool suited to the devices, and agreed with operations. Devices that can log should do so; for the rest, network monitoring takes over.

Use cases should fit the plant: an unknown device appearing, a PLC program change, a vendor connection outside its authorised window, an unexpected write command to a safety device. Recipients and thresholds must be defined. Who gets the alert at three in the morning, and what do they do with it? If nobody is named, the alert goes nowhere. Human detection counts too: the operator who notices that a valve is behaving strangely is a sensor, provided they know whom to call.

04 · Respond: decide fast, without improvising

The hard part of response is deciding, far more than the technology. The site needs an OT response procedure linked to its safety circuits and crisis management, rather than a copy of the IT one. It needs a clear decision chain: who decides to isolate a zone, who decides to stop production, who notifies the authority and within what deadline. Degraded modes must be documented and known; being able to run the plant without supervision for a few hours is a cybersecurity measure in its own right. Exercises should be regular and involve operations and HSE. Slipping a cyber scenario into a safety drill costs little and shows a lot. The contact list (vendors, integrators, external support, insurer, authorities) is prepared in calm times.

05 · Recover & Improve: come back, and learn

Restore in an order set by process criticality, from verified backups, and decide that order in advance rather than during the crisis. Test recovery regularly, and agree with operations what is acceptable in downtime and lost production data; on a GMP site, add what the batch record needs to stay complete. Plan continuity: what is produced, how, and with what means while systems come back. Then learn from it. Every incident and every exercise feeds the standard, the remediation plan and the awareness content, which closes the loop back to function 01. Priorities are reassessed periodically, because the installation changes and so does the threat.

How the functions map to the baseline domains

People run underneath every function

None of the five functions happens without people. That is why EUCALEX does not draw them as a sixth box but as the band that runs underneath all of them, and why the people-centred approach to digitalisation applies here unchanged.

It starts with leaders. Executives and managers commit when cyber risk is translated into risks they already manage: a production stoppage, the safety of people, revenue, reputation, compliance. Then come skills. OT security expertise is either hired or brought in by a specialist firm, and the firm’s job is to raise the level of the teams already on site, not to replace them.

Training has to be specific to each trade. The automation engineer, the instrument technician and the maintenance lead each need to learn the cybersecurity of their own discipline; a generic e-learning module does little for any of them. And everyone else needs plain awareness: that the risk is growing, what it can do to the business and to people, and the few reflexes that actually protect.

Where to start

Start where the chain starts, and resist the purchase that skips it:

1. Name the sponsor in site management and write the one-page OT security policy.
2. Build the first inventory of the most critical zone, with version, location and owner for every asset.
3. Map the flows of that zone, and list the links nobody can justify.
4. Write the decision chain for an incident: isolate, stop, notify, with names.
5. Only then scope detection, with use cases, recipients and thresholds agreed with operations.

Five common mistakes

• Starting with the probe. Detection bought before identification reports flows nobody can qualify.
• Treating Govern as paperwork. Without a sponsor and written responsibilities, every other function stalls waiting for a decision.
• Active scanning in production. NIST’s advice is to schedule it during planned outages whenever possible.
• Copying the IT response procedure. An OT procedure is tied to the safety circuits and to degraded modes.
• Listing people as a sixth box. Training then becomes an annex, and the annex is the first thing cut when budgets tighten.

Govern & Identify, Protect, Detect, Respond, Recover & Improve, with people running underneath from end to end. The structure is not new, which is exactly why everyone on site can follow it.

References

• NIST, The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29, 26 February 2024. nvlpubs.nist.gov
• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, September 2023, Appendix E.2.3. nvlpubs.nist.gov