The Practitioner's Real Problem Is Not Tools — It's Framing

Industrial security practitioners are not short of frameworks, tools, or threat intelligence. What they are frequently short of is the right framing — a set of foundational questions that force clarity about what the environment actually looks like, what the realistic threats are, and what a successful attack would mean for the organisation.

Without this framing, security investment clusters around compliance checkboxes and tool deployments that look good in board reports but leave core operational risk untouched. Firewalls get installed between IT and OT while the OT network itself remains flat. Asset discovery tools get deployed but nobody acts on what they find. Incident response plans get written for IT environments and fail at the first real OT event.

The five questions that follow are not a methodology or a maturity model. They are the questions that, if asked honestly and answered with operational specificity, will tell a practitioner more about their real security posture than any audit checklist.

Do We Know What Is Connected to Our OT Network Right Now?

Asset visibility is the foundational prerequisite for every other security control. You cannot segment what you have not mapped, cannot patch what you have not inventoried, and cannot detect anomalies without a baseline of normal. Yet complete, current OT asset inventories remain rare. Devices are added during capital projects, vendor engagements, and emergency maintenance without ever being formally registered.

This question must be asked with operational specificity — not 'do we have an asset register' but 'when was it last verified against what is actually on the wire, and who owns keeping it current.' The answer will almost always reveal a gap between what the documentation says and what passive network discovery finds.

Practitioners should push for passive, continuous asset discovery using OT-safe tooling rather than active scanning, which risks disrupting sensitive process communications. The inventory must capture not just IP addresses but firmware versions, open ports, communication protocols, and physical location — because patching and segmentation decisions depend on all of these.

What Is the Worst Consequence a Cyber Event Could Cause Here?

Consequence analysis is the engine of consequence-based security, the approach advocated by Idaho National Laboratory and increasingly adopted by critical infrastructure owners globally. It asks: given the systems we operate and the processes they control, what is the maximum credible harm a cyber-enabled event could produce — and which assets, if compromised, would make that harm possible?

The answer to this question determines where security investment should be concentrated. A facility where a cyber event could cause an uncontrolled chemical release, a high-voltage electrical fault, or a loss of safe shutdown capability has a fundamentally different risk profile than one where the worst outcome is production loss and delayed shipping. Both matter — but they do not warrant identical controls.

Practitioners should facilitate consequence analysis workshops with process engineers, safety officers, and operations leadership. Security teams alone cannot answer this question — they lack the process domain knowledge. The output should be a ranked list of consequence scenarios tied to specific control system assets, which becomes the prioritisation backbone for the entire security programme.

Who Has Remote Access to Our OT Environment, and Can We Prove It?

Remote access is the most consistently underestimated attack surface in OT. The formal answer — a named VPN with named users — rarely matches the operational reality discovered during assessment. Vendor-installed remote support tools, residual TeamViewer or AnyDesk instances, jump connections established during an emergency that were never decommissioned, and shared credentials distributed across dozens of contractors accumulate over years.

The question must be answered with evidence, not policy. Not 'our policy requires all remote access to use the corporate VPN' but 'here is the firewall log showing every outbound and inbound connection made to OT systems in the past 30 days, and here is how each one maps to an authorised user and a valid business purpose.' If that evidence cannot be produced, the remote access surface is unknown.

Remediation starts with a network-level audit of all connections crossing the IT/OT boundary, followed by a vendor access register, a decommissioning process for all unauthorised tools, and a formal access review cycle that runs at least quarterly.

Why These Questions Are Hard to Ask — and Harder to Answer

Each of the five questions touches organisational, contractual, or cultural pressure points that make honest answers uncomfortable. Understanding the barriers is necessary for a practitioner who wants to build the credibility to actually close the gaps.

Can We Detect an Attack in Progress, and Do We Know How to Respond?

Detection and response are the questions most organisations defer until after they have addressed asset visibility, segmentation, and access hardening. That sequencing is defensible. What is not defensible is an indefinite deferral that leaves the organisation flying blind if an incident occurs despite the controls in place.

Question four — can we detect an attack in progress — requires honest assessment of whether OT-specific monitoring is in place, whether alerts are being tuned to reduce noise without eliminating signal, and whether the SOC receiving those alerts has the process domain knowledge to distinguish a malicious command from a valid engineering action. Network-level detection alone is insufficient; practitioners should push for visibility at the protocol level, including industrial protocol command monitoring.

Question five — do we know how to respond — requires a tested incident response plan that covers OT-specific scenarios: loss of HMI visibility, unexpected PLC behaviour, isolation of a compromised engineering workstation without losing process control, and engagement of ICS-specialised incident response support. A plan that has never been exercised is a document, not a capability. Tabletop exercises and regular drills are the only way to convert it into something the organisation can actually execute under pressure.

What Good Looks Like vs. Where Most Programmes Are

Turning Questions Into a Programme

Questions Worth Sitting With

Before your next programme review, leadership briefing, or vendor conversation, consider these.