IT vs. Process Automation (OT) — Different Objectives, Different Metrics
Sinclair Koelemij | Cyber Physical Risk Academy | June 2026
IT vs. Process Automation (OT) — Different Objectives, Different Metrics
Sinclair Koelemij | Cyber Physical Risk Academy | June 2026
Why performance metrics matter in process automation incident response
Every organisation that handles cyber incidents measures something. Response time, containment speed, number of incidents per period, compliance with recovery objectives. These metrics shape behaviour: they define what the response team focuses on, what gets escalated, and what counts as success.
In Information Technology environments, those metrics are well established. NIST SP 800-61, ISO/IEC 27035, and ITIL 4 provide a consistent framework. The objective is to restore digital systems and services as quickly as possible, and performance is measured accordingly.
In process automation, those same metrics are necessary but not sufficient. A process automation environment is not an information system. It is a digital layer directly connected to a live physical process — one that continues to react, heat, cool, pressurise, and move regardless of whether a cyber incident is under investigation. The consequences of getting incident handling wrong are not limited to data loss or service disruption. They extend to loss of process control, loss of operator visibility, failure of safety functions, and physical harm to people, equipment, and the environment.
That changes what must be measured. And it introduces a set of performance parameters that do not exist in any current IT incident handling framework.
This article explains the performance parameter chart, category by category, and describes what each parameter means in practice.
Two domains, two objectives
The chart makes the fundamental difference explicit at the outset.
The objective of IT incident handling is to restore digital systems and services. The response team contains the attacker, removes persistence, cleans affected systems, and brings services back online. Performance is measured by how quickly and completely that restoration is achieved.
The objective of process automation incident handling is to maintain or restore a safe, controllable, and observable process state. That is not a variation of the IT objective. It is a different objective, governed by a different logic, requiring different decisions and different measurements.
The difference becomes clear when a response action is considered. Rebooting a controller, isolating a network segment, disabling an alarm, or restoring a system from backup are all standard IT containment or recovery actions. In a process automation environment, each of those actions may simultaneously change control capability, remove operator visibility, degrade safeguard availability, or introduce an automation state that no longer matches the actual physical condition of the plant. An action that is correct from a cybersecurity perspective may be dangerous from a process safety perspective.
A cyber incident can be initiated by malicious activity, but process harm may also result from an inappropriate response action.
This is the starting point for process automation-specific performance measurement: every response action must be judged not only by its cybersecurity effect, but by its effect on the live process.
The operational performance lens: Operability, Observability, Controllability
The chart introduces a framework that has no equivalent in IT incident handling: an operational performance lens consisting of three dimensions. Every process automation performance parameter in the chart is tagged to one or more of these dimensions. Together they define the conditions that must be maintained throughout the incident and throughout the response.
Operability is the ability of the process to be operated safely. It covers the availability of the operating organisation, procedures, and automation functions needed to keep the process within its safe operating envelope — to start it, stabilise it, adjust it, and shut it down in a controlled and predictable way.
Observability is the ability of operators to see what the process is doing. It requires that operators receive accurate, timely, and trustworthy information about process conditions, equipment states, alarm status, and control responses. Without observability, operators cannot make safe decisions regardless of whether control capability exists.
Controllability is the ability to direct the physical process — to issue commands that produce the expected process response. It requires that control functions, field devices, and the communication paths between them remain available and trustworthy.
Loss of any one of these three dimensions during incident handling is itself a performance failure, independent of whether the cybersecurity objective was achieved. A response that contains the attacker but blinds the operator has not succeeded. A response that restores digital systems but leaves the automation state misaligned with the physical process has not succeeded. Measurement must reflect that.
Category 1 — Joint Triage and Early Response
Dimensions: Observability, Operability
The IT equivalent of this category focuses on speed of detection and response measured against administrative targets: Mean Time to Detect, Mean Time to Respond, Mean Time to Resolve, Mean Time to Contain. These are workflow measurements. They tell you how fast the response organisation moved through its process.
In process automation, the relevant time measurements are different. They are not measured against service level agreements. They are measured against process dynamics — the physical behaviour of the live plant.
Time to Joint Triage measures how quickly security, process operations, process safety, and automation engineering are simultaneously engaged in a structured assessment. This is not a sequential hand-off where security investigates first and then passes findings to operations. It is a concurrent, multi-disciplinary assessment that must begin as soon as a condition arises that may affect the safety or controllability of the process. The clock starts when the anomaly is first recognised — not when the cybersecurity team confirms a compromise.
Time to Escalate on Process Uncertainty measures how quickly the organisation moved into joint triage when process behaviour, operator visibility, automation behaviour, or safeguard status became questionable — even in the absence of a confirmed cybersecurity alert. This is a fundamental departure from IT practice. IT frameworks escalate on confirmed indications of compromise. Process automation cannot wait for that confirmation. An unexplained process deviation, an inconsistent alarm, or an actuator that does not respond as expected may be the first visible symptom of an attack — and the process will continue to evolve while the investigation is still determining whether a compromise has occurred.
Pre-demand Detection Window is the period between the start of a process deviation and the point at which the process reaches a condition that demands protective action — a protective trip or Safety Instrumented System demand. Detection must occur within this window to preserve a meaningful operator intervention opportunity. A security alert or anomaly signal that arrives after the process has already passed that demand point is still valuable for investigation, but it cannot prevent the operational impact that has already begun. This parameter therefore measures not only whether detection occurred, but whether it occurred early enough to make a difference to the process outcome.
Operator Intervention Window Preserved is a binary parameter: yes or no. At the moment the response team acts, was there still a period in which operators could influence the process before it required automated protective action? If the answer is no, the character of the incident has already changed. The objective is no longer prevention. It is limitation of consequences.
Category 2 — Observability Maintained
Dimension: Observability
This category has no equivalent in IT incident handling. The concept of operator visibility as a safety-critical performance parameter simply does not arise in a digital environment where the consequences of information loss are limited to data and services.
In process automation, operator visibility is an active safety requirement. Operators make decisions about control actions, alarm responses, intervention timing, and safe-state transitions based on what they can see. Remove that visibility — through a cyber attack, through a containment action, or through a combination of both — and the operator can no longer make safe decisions about a live physical process that is still reacting, heating, pressurising, or moving.
Process Observability Maintained measures whether the operator’s ability to see the process was preserved throughout the incident and the response. If a containment action removed process visibility, that is a response failure. It may also be a necessary and authorised decision — but it must be measured and documented as a failure of the observability dimension, not treated as a neutral side effect of a successful containment action.
Alarm and Status Visibility Maintained measures whether alarm functions and equipment status information remained available and trustworthy. A silent alarm system during a process deviation is not a neutral condition. Alarms that are suppressed, frozen, or manipulated do not only reduce situational awareness — they remove the warning layer that operators depend on to recognise when the process is moving toward an unsafe condition. This parameter specifically covers the integrity of alarm information, not only its availability.
Open Anomaly Closure Rate measures the percentage of anomalies closed with a confirmed, credible root cause. In normal operations, most anomalies have operational or technical explanations. But in a process automation environment that may be under cyber attack, malicious interference can present itself through exactly the same symptoms as an equipment fault, a process disturbance, or an operator error. An anomaly must not be closed until the explanation is consistent with the physical process, the automation state, recent changes, and the observed operator information. Malicious interference must remain in the active cause set until a credible non-malicious explanation is confirmed. An anomaly closed without that confirmation is a gap in the observability record — and potentially the first symptom of an attack that has been classified away.
Category 3 — Controllability Maintained
Dimension: Controllability
Control Capability Maintained measures whether the ability to direct the physical process was preserved throughout the incident. Control capability can be lost in two ways. The attack itself may manipulate setpoints, block commands, modify control logic, or degrade the communication paths between the automation system and the field. Alternatively, a response action — isolating a network segment, rebooting a controller, removing engineering access — may interrupt control functions that were still operating correctly. Both are performance failures. Both must be counted.
Safeguard Availability measures whether alarms, interlocks, Emergency Shutdown systems, and Safety Instrumented Functions remained available and trustworthy throughout the incident and throughout the response. These functions are the last lines of defence before a process deviation becomes a hazardous event. Their availability cannot be assumed during a cyber incident. An attack may have sabotaged a safety function that appears operational on the display but will fail when demanded. A containment action may have isolated a system that carries safeguard logic or communication without that dependency being recognised.
The chart states the containment authority boundary as a performance requirement within this category: security may not execute containment actions affecting control, visibility, or safeguards without operational authorisation. This is not a procedural guideline. It is a structural condition of safe incident response in a live process environment. The performance metric counts containment actions that affected control capability, operator visibility, or safeguard functions and were executed without prior operational authorisation. The acceptable count is zero. Any deviation requires documented investigation and root cause analysis.
Category 4 — Operability and Safe Process State
Dimensions: Operability, Controllability
Time to Safe State measures how quickly the process reached a stable, safe condition — not how quickly digital systems were restored. These two timescales can differ significantly. The process may reach a safe state before digital recovery is complete. Digital systems may be restored while the process remains unstable. Tracking only digital restoration time misses the operability objective entirely.
Process RTO reinterprets Recovery Time Objective for process automation. In IT, RTO asks how quickly systems must be technically operational. In process automation, Process RTO asks how quickly the minimum trusted automation capability must be available to support safe stabilisation and process reconstitution. The emphasis falls on two words: minimum and trusted. Not all automation functions need to be restored immediately. The functions that operations requires to keep the live process safe must be restored first, in a defined sequence, before additional capability is reintroduced. Restoring non-essential functions too early can overload the response team, reintroduce compromise paths, or distract attention from the stabilisation task.
Process RPO reinterprets Recovery Point Objective for process automation. In IT, RPO asks how much data loss is acceptable, expressed as time. In process automation, Process RPO asks how much operational state history can be lost before confidence in the actual process state is lost. This is not a data question. It is a process knowledge question. The restored system must have enough context to understand what the process is doing: its sequence state, batch phase, permissive conditions, recent operator actions, control mode changes, and equipment status. Lose too much of that history, and the automation system is operating on assumptions that no longer correspond to the physical plant.
Response-Induced Process Events counts the number of additional process disturbances caused by response actions that were not caused by the attack itself. Every reboot, isolation, configuration change, or alarm modification that creates an unintended process disturbance is counted here. A high number indicates that the response was not sufficiently process-aware. The objective is not only to contain the attacker. It is to contain the attacker without creating a second incident.
Evidence Sacrificed for Process Safety: if immediate process stabilisation requires it, forensic evidence may be lost. This must be documented as a deliberate decision.
Forensic evidence preservation supports root cause analysis, regulatory reporting, and legal proceedings, and should be pursued wherever it is safe to do so. However, in a live process environment, evidence preservation cannot override process stabilisation. When the two objectives conflict — when maintaining the integrity of a system for forensic purposes would delay or prevent a stabilisation action — process safety takes priority without exception. The requirement is not to avoid this situation. The requirement is to recognise it, authorise it explicitly, document it with a timestamp and stated reason, and treat it as a pre-planned decision rather than an improvised one. Pre-defined evidence preservation plans, agreed between security, operations, process safety, and legal before any incident occurs, are the mechanism that makes this manageable.
Category 5 — Recovery Validation and Reconstitution
Dimensions: Operability, Observability, Controllability
Category 5 carries all three operational performance dimensions simultaneously. This reflects its position as the final gate before normal operation resumes — the point at which operability, observability, and controllability must all be confirmed together before the process is returned to automated control.
Time to Process Reconstitution measures the time from digital system restoration to confirmed alignment between the automation state and the actual physical process state. It is the process automation equivalent of the moment a system is declared fully recovered — but the declaration requires a different confirmation. In IT, the system is recovered when it is clean and operational. In process automation, the system is recovered when it is clean, operational, and correctly aligned with the physical plant.
The chart identifies Automation-to-Process Alignment at Recovery as the critical differentiator of the entire framework. It deserves full explanation.
When digital systems are restored after a cyber incident — controllers reloaded, configurations recovered from backup, networks reconnected — the system may be technically clean and operationally functional. From an IT perspective, recovery is complete. From a process automation perspective, recovery has not yet been confirmed.
The question that must be answered before returning the process to automated control is not: is the system clean? It is: is the restored automation state still valid for the actual physical process state?
During the incident, the physical process did not pause. Temperatures changed. Pressures shifted. Material states advanced or deviated. Operators intervened manually. Batch sequences progressed or were interrupted. Equipment was started or stopped outside normal automated sequences. A backup or checkpoint taken before these events captures a digital state that reflects a moment that no longer exists in the plant.
If that restored digital state is used to control the physical process without validation, the automation system may issue commands based on assumptions that are no longer true: a batch phase that has already passed, a vessel that has already been emptied or filled, a thermal condition that has changed, a permissive state that no longer reflects the actual equipment status. The result is not a data error. It is a process safety event — potentially a serious one.
Automation-to-Process Alignment at Recovery therefore requires that two conditions are confirmed before the process is returned to automated control:
- The restored automation state has been validated against the actual physical process state by process operations and automation engineering jointly.
- Confirmed alignment has been established and documented before return to normal operation begins.
Until both conditions are met, recovery is incomplete — regardless of what the digital systems show.
Our goals in process automation incident handling
The right column of the chart lists seven goals. These are not performance targets in the conventional sense. They are the conditions that must be maintained throughout every phase of the response — from the first anomaly signal to the confirmation of process reconstitution. They define what success looks like in process automation incident handling.
- Ensure people safety. Non-negotiable. Takes precedence over attacker containment, evidence preservation, system recovery, and every other consideration without exception.
- Maintain a safe process state. The process must not be allowed to move toward an unsafe condition as a result of the incident or the response. If it is already moving, arresting that movement takes priority over digital objectives.
- Maintain control capability. The ability to direct the physical process must be preserved throughout the incident. Any containment action that removes control capability requires explicit operational authorisation and a defined compensating measure.
- Maintain process observability. Operators must be able to see what the process is doing at all times. This is a safety requirement, not a comfort requirement.
- Maintain safeguard availability. Alarms, interlocks, Emergency Shutdown systems, and Safety Instrumented Functions must remain available and trustworthy. Degraded or unavailable safety functions require explicit operational management, not silent acceptance.
- Ensure alignment between automation and the physical process. At every stage — during the incident, during digital recovery, and before returning to normal operation — the automation state must correspond to the actual physical state of the plant. Misalignment is not an abstraction. It is a direct source of unsafe control actions.
- Maintain or restore a safe and controllable process state. The governing objective that connects all others. Every response action is evaluated against it. It defines what a successful outcome requires.
The core difference
IT metrics measure how fast the digital environment is restored. That is their purpose, and within their domain it is the right measure.
Process automation metrics measure whether the installation remains safe, controllable, observable, and able to maintain or restore a safe and controllable process state throughout the incident response. That is a fundamentally different measurement, for a fundamentally different kind of system, with fundamentally different consequences when it fails.
IT recovery does not guarantee process safety or control. Validated alignment does.
The frameworks referenced in the chart — NIST SP 800-61 rev.2, ISO/IEC 27035, ITIL 4, and ISA-TR84.00.09 — define strong and well-established practices for IT incident handling. This chart does not replace them. It extends the conversation to what matters when a digital incident occurs in a system that is directly connected to a live physical process. The process automation parameters described here do not yet exist as a standardised set in any published framework. Establishing them is the work that remains to be done.
About the author: Sinclair Koelemij is a Cyber-Physical Risk Consultant and Trainer at Cyber Physical Risk Academy (since April 2023). He spent 43 years in process control and process safety (1980–2023) and 21 years specialising in industrial networks and cybersecurity (2002–2023), retiring from Honeywell Process Solutions / Honeywell Connected Enterprise as EMEA Regional expert. He has conducted semi-quantitative cyber-physical risk assessments on 25 brownfield and 6 greenfield installations across petrochemical, refining, offshore, and pipeline sectors. He has actively contributed to ISA 99 and ISA 84 standards, published technical papers, and holds 3 US patents in cyber-physical risk.
© 2026 Sinclair Koelemij / Cyber Physical Risk Academy. Based on: Cyber Incident Strategy for the Process Industry (2026).