Critical infrastructure security as a leadership agenda, not an admin task
Protection of critical infrastructure is moving to the risk management level. Why this decision can no longer be delegated to system administrators.
There is a persistent assumption that security is a job for technical specialists. Install antivirus, configure the firewall, assign access rights - and the topic can be considered closed. That assumption held when attacks were random and aimed at random targets.
The picture is changing. Targeted attacks on infrastructure - industrial control systems, energy, transport, financial systems - are becoming less rare. And the familiar logic of "that's a job for the IT department" stops working here.
Why this is a management topic
A cyberattack on critical infrastructure is an operational risk, not a technical incident. The distinction matters.
A technical incident is a problem a technical specialist solves. An operational risk is a threat to the company's operations - one that requires a management decision about how acceptable the risk is, what the protected asset is, how much its protection costs, and what happens if the threat materialises.
A system administrator cannot answer those questions alone. They can configure systems in accordance with decisions already made. But deciding what level of risk is acceptable for the company is a management function.
A second point: the consequences of a successful attack on critical infrastructure extend far beyond the IT systems. A halted production process, compromised customer data, breached obligations to partners, regulatory consequences - these are all management problems, not technical ones.
What has changed in the threat landscape
A few trends that are becoming increasingly visible.
Industrial control systems - SCADA, factory automation - were historically designed without network threats in mind: they lived in isolated environments. As these systems gain connectivity to corporate networks and the internet - for remote monitoring, ERP integration, maintenance convenience - the attack surface grows. ICS segmentation is no longer optional once those systems reach the network.
Attacks are becoming more targeted and more patient. An attacker may remain inside a network for months, studying the infrastructure, before taking any active steps. Standard defences oriented toward detecting active threats miss this stage entirely.
The supply chain is becoming an attack vector. Compromising a contractor or software vendor that an organisation trusts opens access to places a direct attack cannot reach.
What leadership should do
I am not calling for paranoia or large-scale security investment without understanding why. But there are a few concrete steps worth taking.
First - conduct an inventory. Which systems are critical - meaning that their disruption or compromise causes direct operational damage? Which of these are currently connected to external networks? Who has access to them, and on what terms?
Second - assess the actual level of protection of those systems. Not "we have antivirus", but specifically: how is unauthorised access detected, who responds to an incident and how, is there a recovery procedure?
Third - consider segregation. Industrial and operational control systems should be isolated as much as technically possible from corporate networks and the internet. The convergence of OT and IT is precisely what makes this segregation harder to maintain and more important to address.
Fourth - make sure critical infrastructure security is on the agenda at the leadership level, not only in the technical department's plans.
A practical benchmark
The question worth asking: if it turned out tomorrow that an attacker has had access to our systems for the past three months - how prepared are we to detect it, assess the damage, and restore normal operations?
If the answer is uncertain, that is a signal that critical infrastructure security still sits only in the technical team's domain. That is a normal starting point. It is not a normal final state.