Short, medium, long term: an OT security roadmap that survives shutdowns and budgets

This is part 7 of 12 of the “Common language” series on industrial cybersecurity; it continues with part 8, five functions, people first.

Once a site has agreed on its vocabulary and on who decides, who executes and who checks, the next question is practical: where do we start, and how far do we go? The usual mistake at this point is to run industrial cybersecurity as a project, with a kick-off, a go-live and a closing report. Projects end. The exposure of a plant does not, so the work is better thought of as a trajectory over three horizons, the first two overlapping on purpose.

Three horizons, one movement

The short term buys time. The medium term puts the structure in place. The long term makes that structure independent of the people who built it. The windows below are EUCALEX’s working recommendation, not figures from a standard, and they overlap: awareness starts on day one and never stops.

1. Short term: lower the risk quickly, with what is simple and proven

The urgent horizon is not about securing everything. The aim is to bring the risk down fast with measures that are known to work and that wait neither for a capital budget, nor for a production shutdown, nor for a hire who has not yet arrived. Six actions, taken in a deliberate order, cover most of the first six months: a high-level assessment, a starting inventory, on-site awareness, tested offline backups, offline malware scanning, and cutting the links nobody can justify. The previous part of this series covers them in detail.

So no full audit yet, no tool purchase, no steering committee. Just a run of simple moves, decided quickly, that reduce exposure while the real project is being prepared. One test keeps the horizon honest: if an action needs capital expenditure or a shutdown, it belongs to the medium term.

2. Medium term: a real project, built to stretch

The medium term picks up where the short term stops, on the same three fronts, each taken one level deeper. The assessment becomes detailed, domain by domain across the seven domains of the site’s baseline (asset inventory, network architecture and segregation, access control and remote access, vulnerability management, incident response, backup and restore, monitoring and detection), and ends in a formal gap analysis. Training becomes technical and fitted to each person’s trade, whether automation, instrumentation, operations or IT. And the skills question gets settled: either the site recruits an OT security profile, or it brings in a specialist firm whose job is to raise the level of its own team.

Beyond that, this is a project in the proper sense, with a scope, a budget, milestones, a project manager and deliverables. What makes it different on an industrial site is that it has to stretch to fit the site as it actually is: its planned shutdowns, its production constraints and the people it really has.

I have seen plans that assumed two shutdowns a year on a site that stops every eighteen months. They looked ambitious in the steering committee and were never executed. The shutdown calendar is the backbone of the medium-term schedule. Work that can be done with the plant running, such as moving vendor remote access into an industrial DMZ or writing the standard, goes first. Work that needs the process down, such as re-cabling to separate the safety instrumented system (SIS) from the basic control network, is booked into the turnaround that actually exists. On a GMP site the same goes for the validation effort: a change that touches a qualified system needs its impact assessment and its tests planned into the same window, as the article on change control and requalification explains.

The good practice is to cut the trajectory into self-supporting stages, each of which delivers a measurable security gain even if the next one slips by six months. That is what lets a programme survive a budget freeze or a postponed shutdown without starting again from zero. A stage that only pays off once the following one is finished is really half of a larger bet, and bets of that kind are the first casualties of a bad quarter.

3. Long term: leaving the project mindset behind

In the long term the aim changes. There is no target state left to reach; what matters is that the arrangement keeps working without the people who set it up. Three things carry it: a maintained standard, a periodic awareness plan and durable in-house skills. A programme that rests on one motivated engineer tends to fade within a year of that engineer’s transfer.

4. From horizons to a working roadmap

The horizons say when. A roadmap also has to say what, phase by phase, and what is particular to a process plant.

5. Measure, and borrow the rhythm of process safety

The last phase is where programmes either quietly die or become routine. Track indicators that mean something: mean time to detect and respond, zone coverage, the state of patches and compensating measures, how many MOC reviews actually had a cyber check. Reassess whenever the installation changes or the threat moves.

A maturity model helps if it is used as a ladder, and does harm if it is used as a stick. ISA/IEC 62443 offers one. The 2024 edition of IEC 62443-2-1, which sets security programme requirements for asset owners, introduced a maturity model for evaluating its requirements, and IEC 62443-2-4 (service providers) and IEC 62443-4-1 (product development) use four process maturity levels, from ML1 “Initial” to ML4 “Improving”. A scale like that sits naturally alongside self-supporting stages.

For cadence, the simplest move is to ride on audit cycles the site already runs, because cybersecurity is now part of safety and deserves the same calendar. In the United States, OSHA’s Process Safety Management standard requires employers to certify that they have evaluated compliance “at least every three years” (29 CFR 1910.119(o)(1)); EPA’s Risk Management Program (40 CFR Part 68) asks the same of Program 2 and Program 3 processes (§68.58 and §68.79). In the European Union, the Seveso III Directive (2012/18/EU) sets, in Article 20(4), a period between two site visits that shall not exceed one year for upper-tier establishments and three years for lower-tier ones, unless the competent authority has drawn up an inspection programme based on a systematic appraisal of hazards. Article 8(4) has the major-accident prevention policy reviewed at least every five years.

Attached to that calendar, the cyber review is prepared by the same people, with the same seriousness, and is much harder to postpone. Between audits, EUCALEX recommends a quarterly review of the programme, run with the same discipline as the site’s safety indicators.

Where to start

A roadmap starts from the site’s calendar, not from a template. Five steps turn the horizons into a plan:

1. Get the real shutdown calendar for the next three years from production planning, and mark the windows that are firm.
2. Sort every candidate action with the short-term test: no capex and no shutdown, or it goes on the roadmap.
3. Tie each medium-term milestone to a named shutdown, and on a GMP site to the validation effort it will need.
4. Cut the plan into stages that each deliver a gain on their own, and write that gain down.
5. Attach the programme review to the audit cycle the site already runs, with a quarterly check in between.

Five common mistakes

• A project with an end date. The closing report is the moment the arrangement starts to decay.
• A schedule that ignores turnarounds: two shutdowns a year on paper, one every eighteen months in reality.
• Stages that depend on the next one, so that a freeze or a slipped shutdown leaves nothing standing.
• A maturity model used as a stick. Teams learn to report the score instead of climbing the ladder.
• A separate cyber calendar. A review nobody has attached to an existing audit cycle is the first one to be postponed.

Three checks before you sign the roadmap: every short-term action runs without capex or a shutdown, every medium-term milestone sits on a shutdown that is really in the calendar, and the current stage still stands if the next one slips by six months.

References

• IEC, IEC 62443-2-1:2024, Security program requirements for IACS asset owners.
• ISA Global Cybersecurity Alliance, Quick Start Guide to the ISA/IEC 62443 series, Table 4 (maturity levels).
• OSHA, 29 CFR 1910.119, Process safety management of highly hazardous chemicals, (o) compliance audits.
• Directive 2012/18/EU (Seveso III), Articles 8 and 20.