Not every control system event involving computers, controllers, or digital instruments is a network cybersecurity incident. Many serious events are better understood as automation incidents, where the root cause lies in sensors, actuators, control logic, calibration, setpoints, timing, maintenance, or engineering decisions that affect the physical process.
Understanding the difference helps organizations investigate the right causes, involve the right teams, and avoid treating every automation failure as a cyberattack.
Automation incidents occur when automation, instrumentation, control logic, field devices, controllers, or engineering decisions cause, contribute to, mask, or fail to prevent an unsafe, damaging, or disruptive physical outcome. These events usually require engineering, operations, maintenance, instrumentation, reliability, or process safety expertise — not just cybersecurity analysis.
Network cybersecurity incidents involve unauthorized or malicious activity through networks, systems, credentials, malware, ransomware, remote access, or communications pathways. These incidents are typically investigated through cyber incident response methods such as containment, forensic review, log analysis, credential protection, and malware investigation.
Blended automation/cyber incidents involve both a cyber pathway and automation behavior. For example, a compromised engineering workstation may be used to change controller logic, remote access may be abused to alter setpoints, or malware may disrupt operator visibility while the physical process continues in an unsafe state.
The practical question is this: did the event primarily come from automation behavior affecting the physical process, or from unauthorized digital activity through a network or system? If automation behavior drove the outcome, the incident should not be labeled as cyber simply because computers or programmable devices were involved. If malicious digital activity drove the event, it belongs in the cybersecurity category. If both mattered, it should be treated as a blended incident.
Questions to ask before forcing an event into a category
- Did the event involve physical process behavior, equipment movement, unsafe state, product quality, environmental release, injury, death, or equipment damage?
- Did a sensor, transmitter, actuator, valve, motor, relay, drive, controller, logic solver, safety function, alarm, trip, interlock, or calibration issue contribute to the event?
- Was there evidence of unauthorized access, malicious activity, malware, ransomware, credential abuse, remote access compromise, or network exploitation?
- Did communications loss or network behavior merely limit visibility, or did it directly change the physical process outcome?
- Would the event still have occurred if no attacker, malware, or network compromise were present?
- Did the incident require engineering reconstruction of what the automation was supposed to do versus what it actually did?
Calling every control system event a “cyber incident” can send investigators in the wrong direction. Accurate terminology helps preserve the right evidence, assign the right experts, and identify the true root cause. Automation incidents call for engineering-led investigation; network cybersecurity incidents call for cyber incident response; blended incidents require both.