Critical infrastructure companies face a workforce challenge that no software tool can solve alone: the people who run industrial systems rarely have cybersecurity skills, and the people who have cybersecurity skills rarely understand industrial systems. As cyber threats against operational technology (OT) environments escalate — and as the EU's NIS2 Directive, US NERC CIP, and equivalent frameworks worldwide tighten compliance requirements — this gap is becoming a board-level risk.
The Reality on the Ground
OT teams are lean by design. Process automation engineers spend their days improving control logic, calibrating instruments, fine-tuning control loops, and keeping plant operations running. They are skilled, experienced, and stretched. Cybersecurity was never part of their role — until now.
When OT security programmes are launched, the most common approach is to bring in IT security professionals to implement controls. This makes sense on paper. In practice, IT professionals face a steep learning curve: OT systems run on different protocols (Modbus, PROFINET, DNP3), operate under different constraints (a PLC cannot simply be patched during a maintenance window), and carry safety implications that enterprise IT does not. Recommending a control that makes sense in an IT context can cause a production outage — or, in the worst case, a safety incident.
The result is friction, slow progress, and security measures that are either poorly implemented or quietly bypassed by operations teams who cannot afford the disruption.
Why the Board Is Right to Pay Attention
Three forces are making OT security a board-level issue, not just an operational one.
Rising attack volume targeting OT globally. Attacks on industrial systems are no longer rare events — they are a regular occurrence across every region and sector. The Ukraine power grid attacks of 2015 and 2016 were the first confirmed cyberattacks to cause civilian power outages. TRITON/TRISIS (2017) targeted Safety Instrumented Systems at a petrochemical facility in Saudi Arabia — the first malware explicitly designed to cause physical harm. Norsk Hydro (Norway, 2019) was forced to switch aluminium smelters to manual operation after LockerGoga ransomware spread across its global network. Colonial Pipeline (US, 2021) triggered a regional fuel emergency. In each case, the gap between IT and OT teams was a factor in how far the attack spread and how long recovery took.
| Incident | Location | Year | Impact |
|---|---|---|---|
| Ukraine Power Grid Attack | Ukraine | 2015–16 | 225,000 homes lost power; first confirmed OT cyberattack |
| TRITON / TRISIS | Saudi Arabia | 2017 | Safety systems targeted; designed to cause physical failure |
| Norsk Hydro / LockerGoga | Norway (global) | 2019 | Aluminium production halted; ~$71M recovery cost |
| Colonial Pipeline | United States | 2021 | 6-day fuel supply disruption across US East Coast |
| Oldsmar Water Treatment | United States | 2021 | Attacker raised sodium hydroxide levels 111× |
| German Wind Energy (ENERCON) | Germany | 2022 | 5,800 turbines lost remote monitoring during Ukraine conflict |
Tightening regulation across Europe and beyond. The EU's NIS2 Directive covers operators in energy, water, transport, health, and digital infrastructure across all member states. It places explicit obligations on management bodies, not just IT teams: leadership must approve cybersecurity risk measures, receive security training, and can be held personally accountable for systematic failures. Fines reach €10 million or 2% of global turnover. Beyond Europe, the US has sector-specific mandates (NERC CIP for energy, TSA Security Directives for pipelines and rail), Australia has the SOCI Act, and the UK operates its own NIS Regulations. The direction is consistent globally: OT security is now a regulatory obligation, not just good practice.
The disappearing air gap. Remote monitoring, cloud connectivity, and digital transformation initiatives are eliminating the physical separation that used to protect OT networks. Every efficiency gain through connectivity creates a potential attack path. The traditional assumption that OT systems are isolated is no longer valid — and in many industries, it has not been true for years.
The Upskilling Dilemma
The ideal scenario is well understood: process automation engineers who are capable of both running the plant and implementing security. One team, one view, no translation layer between operations and security.
Getting there requires significant investment. Training takes 12 to 18 months to bring an experienced OT engineer to a functional OT security capability. During that window, the risk is not just the cost of training — it is attrition. Upskilled engineers command higher market salaries, and competitors will recruit them.
Upskilling is not the wrong strategy. It means it must be managed deliberately, with retention considered as part of the programme design — not as an afterthought once training is complete.
Who Should Own OT Security?
The most common governance failure is ambiguity. IT security assumes OT is the plant manager's responsibility. The plant manager assumes IT handles cybersecurity. Neither team is accountable, and incidents fall through the gap.
Effective OT security requires a single named owner — a person with accountability that crosses both the operations and security functions.
For smaller operators (under 200 employees), a designated OT Security Coordinator — even as a part-time role — is better than no clear ownership. What matters is that one person can be asked "who is responsible for OT security?" and give a clear answer.
For larger operators, a dedicated OT Security Manager with a reporting line to both the CISO and the Head of Operations. This person translates between OT risk language and IT security language, and is empowered to make decisions that affect production schedules.
Key Roles to Build or Source
| Role | What They Do | Build or Source? |
|---|---|---|
| OT Security Manager | Owns the programme, bridges IT and OT, reports to leadership | Build internally — needs plant context |
| OT Security Analyst | Monitors OT networks, triages alerts, investigates anomalies | Can be outsourced to MSSP initially |
| OT Security Architect | Designs network segmentation, remote access controls, secure design standards | Project-based consultant works well |
| OT Incident Responder | Responds to OT events without disrupting operations | Retain a specialist firm on retainer |
| Compliance Lead | Maps NIS2 and sector requirements, manages audits | Can be shared with IT compliance function |
Managing Vendor and Third-Party Access
Most OT security incidents involve remote access. A vendor connecting to commission, maintain, or troubleshoot a system — with credentials that are too broad, poorly managed, or never revoked — is one of the most common entry points for attackers. Business owners often treat vendor access as a controlled, trusted activity. Credentials shared over email, never changed, and never reviewed are a systematic vulnerability that no monitoring tool can fully compensate for.
Minimum controls every operator should have:
- No standing vendor credentials — access granted per session, not permanently
- All vendor sessions routed through a jump server or PAM solution
- Session recording — a full audit trail of every action taken
- Least privilege — vendors access only the specific system they are there to work on
- Quarterly access review — remove access that is no longer needed
Measuring Progress
Workforce management without measurement drifts. These are practical metrics business owners can ask for to track the maturity of their OT security programme.
| Metric | What It Shows | Target |
|---|---|---|
| % of OT engineers with security awareness training | Breadth of basic capability | 100% within 12 months |
| Staff with OT security certifications | Depth of specialist capability | At least 1 per site |
| Vendor access review cadence | Third-party risk governance | Quarterly minimum |
| Mean time to detect OT anomalies | Detection effectiveness | Improving trend quarter on quarter |
| Tabletop exercises per year | Incident response readiness | Minimum 1 per year |
| NIS2 gap assessment completion | Compliance posture | Completed and documented |
A 90-Day Starting Plan
Week 1–2: Name the person accountable for OT security. This single step, more than any tool or policy, changes the conversation across the organisation.
Week 3–7: Build the asset inventory. You cannot protect what you cannot see. Many operators discover equipment during this exercise that nobody knew was connected.
Week 3–6: Audit vendor access. List every third party with access to OT systems. When was that access last reviewed? Are those credentials still active?
Week 3–10: Start training. A single engineer completing ISA/IEC 62443 Fundamentals gives you someone who can speak the language of both operations and cybersecurity. That person becomes a multiplier.
Week 6–12: NIS2 gap assessment. Understand where you stand before regulators or auditors ask first.
What Good Looks Like
Most operators are in the early stages of this journey. That is not a failure — OT security as a formal discipline is less than fifteen years old, and the threat environment has changed faster than most organisations can adapt.
The goal is not perfection. It is deliberate, documented progress: a named owner, a running training programme, a controlled vendor access process, a tested incident response plan, and metrics that tell leadership whether the programme is improving.
The operators who handle incidents best are not the ones with the most technology. They are the ones with people who know the systems, know the risks, and have practised responding together.