Trusting What You Operate: Asset Trust in OT Environments and the Shift to Continuous Control Assurance

Two kinds of trust

Operators of essential services have always trusted their technology. They trust a protection relay to operate within defined parameters. They trust a SCADA system to reflect the state of the service it monitors. They trust a safety instrumented system to intervene when a process exceeds its limits. That trust is engineered. It is tested, maintained, and periodically validated by operational teams who understand the systems they run.

This is operational trust. It is earned through design, commissioning, and maintenance. It underpins every essential function an operator delivers.

The regulatory inspection regime is now asking for something different. It is asking whether operators have security trust in those same assets: whether they know what each asset is, what it is currently doing, whether its configuration remains as intended, and whether its communications are expected and any change to it would be detected before it has operational consequence. That question is not answered by knowing the asset works. It is answered by being able to demonstrate, continuously and evidentially, that the asset remains in a known, verified and monitored state.

These two forms of trust should not conflict. But in a great many operational technology environments, only one of them is a culturally established process.

The Operational Gap

The shift in the regulatory inspection model is real, and it is accelerating. Competent authorities assessing organisations against the Cyber Assessment Framework are moving beyond point-in-time assessments. The expectation is no longer that an operator can describe their controls. It is that an operator can demonstrate their controls are working, knows when a control degrades or fails, and can produce evidence of that capability on demand.

That requires knowing, with precision, what is actually in the environment, what it is communicating with, and whether those communications are authorised. Not what was commissioned five years ago. Not what the original design documentation shows.

In operational technology environments, that gap between documented intent and operational reality is frequently much wider than in IT, and the reasons for it are legitimate, not negligent. OT assets have long lifecycles. A protection relay or a remote terminal unit installed fifteen years ago was not designed to be inventoried by a network scanning tool, and scanning it may impact the essential service. Firmware versions are not always visible remotely, so require physical access during a maintenance window.

In environments with safety-critical systems, there is an additional and non-negotiable constraint. Operational safety is the top priority. No cybersecurity control should be deployed that degrades the integrity of safety instrumented systems or safety-critical operational processes, and some forms of security monitoring are genuinely incompatible with their operational requirements. This is not a compliance workaround. It is an engineering reality that competent authorities must account for in their assessment approaches, and one that honest OES organisations need to state directly rather than work around quietly.

The gap is not about neglect. It is about a security model that was not built in at the point of design and now has to be established around systems that pre-date current expectations.

There are specific areas where it surfaces most sharply:

• Asset identification at the boundary of IT and OT. The assets most likely to be accurately inventoried are those closest to the IT/OT boundary: the historian, the engineering workstations, the firewalls. Those furthest into the process network are least likely to be. Competent authority assessments cover the full scope of systems supporting the essential function. The boundary is not a safe place to stop.
• Configuration as a point-in-time artefact. Documented baseline configurations are accurate at commissioning. Whether they reflect the current device state is a different question. Firmware updates, parameter changes made during maintenance, and vendor enhancements all create drift between the documented baseline and operational reality. Security trust requires that drift to be detectable.
• Authorised versus actual communications. Zone and conduit documentation describes what communications should occur. Whether communications outside those definitions are actively detected is a separate capability. An organisation that has documented its architecture but has no mechanism to alert on unexpected lateral communication cannot demonstrate that its segmentation controls are working. It can only assert that they were designed correctly.
• Legacy assets where patching cannot occur. Many OT assets remain within defined operational risk tolerances and will not be patched, for valid reasons of safety, vendor support, or operational continuity. The obligation does not disappear; it shifts. Where patching cannot occur, the CAF expectation moves to compensating controls: network visibility, anomaly detection, formal residual risk acceptance signed at an appropriate level, and documented review cycles. Treating legacy risk as accepted without that evidential infrastructure will not hold up under assessment.

How do you respond

An organisation can be fully compliant on paper, with its self-assessment scored and documentation complete, and still be operationally exposed. The CAF describes the standard. Continuous security trust is what closes the gap between the standard and what is actually running in the environment. The inspection regime is increasingly designed to test that gap directly.

The organisations best positioned to demonstrate continuous control effectiveness are those that have built a coherent picture of what they are responsible for, established a formal position on what they can and cannot verify, and created an evidence-producing process to close the remaining gaps progressively. Four starting points:

• Build an asset register that reflects operational reality, not design intent. An asset register built from original design documentation is a project record. Verifying what is present, capturing the attributes that matter for security management, and maintaining that accuracy through engineering change is where the register becomes useful. It does not have to be perfect on day one, but it has to be honest and improving.
• Document what you cannot currently verify, and hold the risk formally. Not every OT asset can be passively monitored. Not every communications path can be baselined in a live environment. Where the organisation has accepted a limitation on its security visibility, that position should be formally documented, risk-accepted at an appropriate level of seniority, and reviewed on a defined cycle. A documented risk position is manageable under scrutiny. An undocumented assumption is not.
• Map your controls to your assets, not to your framework. The inspection question is not whether a control exists. It is whether the control is operating effectively for the assets and functions it is supposed to cover. That requires the mapping to run from control to asset, not from control to principle.
• Treat control effectiveness as an ongoing operational output, not an audit output. The evidence a competent authority expects to see should be a by-product of how the organisation manages security day to day, not something assembled in the weeks before a review. If producing it requires significant effort to reconstruct, the underlying capability is not functioning at the level the inspection regime expects.

Building that continuous evidence picture across an OT estate is not a spreadsheet exercise. Evidence must be weighted by quality and age, mapped from the asset through its associated risk to the specific controls intended to address it, and updated as the environment changes. This is one of the problems IISZON's Innovation practice is actively working on. We are supporting Provn, a UK startup building an industrial trust platform for OES and critical infrastructure environments, whose evidence-weighted scoring and time-decay model produces exactly the kind of structured, traceable evidence lineage that a continuous inspection regime requires.

The right sequence is rarely to start with a platform. It is to understand the gap, document what can and cannot be verified, and establish the asset and control baseline, then build the automation around a picture that is already honest. The time to start is not when an assessment is imminent.

I work with boards and security teams at different points in that journey. The distance between where most organisations are and where the inspection regime is heading is real, but it is not insurmountable for those who treat it as a progressive programme rather than a compliance event.

IISZON supports Operators of Essential Services across advisory, assurance and innovation. If you would like to understand where your asset trust gaps are before a competent authority finds them, we are available to discuss it.