Topics:
As industries continue to converge their operational technology (OT) and information technology (IT), it’s proving to be a source of significant management strife. Nowhere is this more evident than in sectors reliant on complex industrial systems—where the aging Purdue Model, once the gold standard for OT network architecture, is showing its limitations in the face of cloud infrastructure, software-defined networks, and evolving cyber threats.
For decades, the Purdue Model has provided a clear, hierarchical framework that separates enterprise IT systems from industrial control systems (ICS), that run factories, refineries, and pipelines. At its core, the model relied on physical boundaries—firewalls, air gaps, and distinct network layers—to keep critical OT environments insulated from the risks of the broader IT world.
However, as organizations have adopted cloud computing, remote operations, and the requirement for real-time data, these boundaries have become increasingly blurred. Software-defined infrastructure has replaced hardware-based segmentation, and the once-clear demilitarized zones (DMZs) are now “flatter,” more permeable, and more complex to defend. The result: a new era of risk, where the responsibilities for security and decision-making are no longer neatly divided between plant operators and IT leaders.
This convergence has thrust chief information security officers (CISOs) into the OT security spotlight, often bringing with them a mindset shaped by IT standards focused on data protection and compliance. Yet, as Gretchen Myers, global solutions lead, cyberphysical security, Accenture, noted in her presentation at Hou.Sec.Con last week, “Securing Modern Industrial Infrastructure — Where does the buck actually stop?” these standards rarely account for the operational realities of OT, where the stakes are the potential shutdown of critical infrastructure.
These challenges are not merely technical—they are deeply organizational in nature. One experience Myers shared illustrates both the high stakes and human factors at play.
At a global chemical company, a high-risk vulnerability was discovered in the OT environment. Addressing it required a coordinated shutdown and patching process, but IT and OT leaders could not agree on when—or even how—to proceed. The IT team, guided by a sense of urgency and a commitment to compliance, pushed for immediate action. The OT leaders, responsible for operational continuity and safety, hesitated, wary of disrupting production.
Most CEOs are ill-equipped to make deeply technical decisions about patching industrial systems. Lacking the necessary context, the CEO delayed the decision further, seeking additional information from executives. The result: a critical vulnerability remained unaddressed for weeks, exposing the organization to significant risk.
Myers described what followed as a protracted game of “hot potato.” Responsibility for the decision—and the budget to fund the necessary work—was passed back and forth between departments, and weeks turned into months, with no resolution. The deadlock was finally broken only when the issue was escalated all the way to the CEO.
Yet, as Myers observed, most CEOs are ill-equipped to make deeply technical decisions about patching industrial systems. Lacking the necessary context, the CEO delayed the decision further, seeking additional information from executives.
The result: a critical vulnerability remained unaddressed for weeks, exposing the organization to significant risk.
This case is far from unique. As organizations modernize, the old silos of IT and OT have broken down, yet new processes and governance structures have not always kept pace. So, what can organizations do to avoid similar deadlocks?
Myers outlined several concrete steps:
Organizations must define who has the final say on security decisions that cross IT and OT boundaries. This means moving beyond vague accountability and specifying, in advance, which roles have the authority to make which decisions—and under what circumstances escalation is required.
Unlike the case study Myers shared, not every disagreement needs to go straight to the top. By establishing clear criteria for when and how issues should be escalated—based on risk, operational impact, and stakeholder involvement—organizations can ensure that decisions are made at the appropriate level, with the correct information.
When escalation does occur, technical teams must be able to present their case in terms that business leaders understand: risk exposure, operational impact, and value at stake. Standardizing the format and message of these briefings helps ensure that executives can make informed decisions quickly.
Regular forums that bring together IT, OT, and business leaders—such as architecture review boards or operations councils—can help bridge the language and context gap. These bodies should include not just managers, but also technical subject matter experts who understand the nuances of both environments.
By collecting and maintaining up-to-date documentation on security architectures and protocols, organizations can establish a shared language and context for informed decision-making, thereby reducing misunderstandings and misalignment.
The convergence of IT and OT is inevitable—and, if managed well, can unlock significant value. But Myers’s experience makes clear that the most significant risks may not come from technology itself, but from the organizational inertia and miscommunication that can leave critical vulnerabilities unaddressed.
By establishing clear authority, fostering dialogue, and building shared context, organizations can move from deadlock to decisive action—protecting both their operations and their future.
George V. Hulme is an award-winning journalist and internationally recognized information security and business technology writer. He has covered business, technology, and IT security topics for more than 20 years. His work has appeared in CSOOnline, ComputerWorld, InformationWeek, Security Boulevard, and dozens of other technology publications. He is also a founding editor at DevOps.com.
