January 29, 2026
January 29, 2026
The article argues that ISA/IEC 62443 “Security Levels” are useful because they turn messy industrial environments into something engineers can actually design and improve: you pick a target Security Level and implement a defined set of controls to make compromise harder for a given class of attacker. The problem starts when organizations treat “we achieved the Security Level” as an unspoken conclusion that risk is therefore acceptable. Security Levels, the author stresses, do not make residual risk explicit: they do not tell you how likely an attack is to succeed anyway, how a compromise might propagate, or what the physical consequences would be if it does. In other words, they shape risk, but they do not answer the governance question of whether the remaining risk is acceptable.
The second message is about accountability in high-hazard industries (refining, petrochemicals, pipelines, etc.), where cyber incidents can become process safety initiators—for example, by altering control logic, corrupting sensor data, suppressing alarms, or manipulating operator decision-making. In those contexts, “Security Level achieved” cannot be the stopping point; the author says you need scenario-based analysis consistent with process safety practice (framed as IEC 61511-style causal analysis) and risk acceptance under the same ALARP-style governance used for other safety decisions. OT security engineers design zones and baseline resistance, and process safety specialists analyze escalation paths and safeguards, but the authority to accept residual risk ultimately sits with plant management acting for the asset owner—because they are the ones who must defend that decision to regulators, courts, and society if something goes wrong.
Source: https://industrialcyber.co/expert/who-decides-when-security-levels-are-enough/