OT Detection Requirements: Safety, Reliability, and Process State
Write OT detection requirements from physical consequence, process state, engineering authority, and safe decision latency rather than importing assumptions from office IT.
Begin with what could happen to the process
A controller receives a command that changes a motor’s speed. The command may be authorized and still be unsafe in the current process state. It may be unusual and still be required during startup. If you begin only with account privilege or network rarity, you miss the physical context that gives the action meaning.
Operational technology controls or monitors physical processes. An OT detection requirement therefore begins with a consequence such as loss of view, loss of control, unsafe manipulation, degraded product quality, or interruption of a critical service. These are outcomes, not events a sensor directly records.
Work backward. Which equipment and process function could produce the consequence? Which digital and physical actions are required? Which conditions make them safe, expected, or prohibited? This reasoning narrows a broad concern into a path that evidence can support.
Operating mode changes the interpretation
Record whether the process is starting, producing, shutting down, in maintenance, under manual control, or in an emergency state. The vocabulary is site-specific, so detection engineering needs process owners to define it.
A logic download from an engineering workstation may be expected during an approved outage and exceptional during steady production. A remote connection may be normal for a vendor under an active work order and prohibited when safety interlocks are bypassed. The event does not change, but the decision context does.
Use process state as evidence, not as infallible truth. Mode tags can be delayed, incorrectly configured, or manipulated. Preserve their source and time, and identify which independent observations can confirm the state when consequence is high.
Describe engineering authority end to end
Separate the human engineer, remote-access identity, jump host, engineering workstation, application session, controller identity, and target equipment. The device that sends a protocol command may not reveal the person or work order that authorized it.
State which identities and approvals should be available, how long they remain valid, and which zones or assets they cover. A vendor account approved for one line does not become expected everywhere. A controller that accepts a command does not prove the command followed the approved engineering process.
The requirement should identify the evidence needed to relate access, engineering action, controller outcome, and process response. Missing identity or work context may lower confidence without making the protocol action disappear.
Make latency and response safety explicit
Some process changes require attention within seconds; others can be reviewed after a shift. State when a result stops being useful for the consumer. Do not promise real-time response if records arrive through periodic historian exports.
Also state what the result may authorize. An alert can prompt an operator to verify a work order, an engineer to compare controller logic, or security staff to restrict a remote account. It should not silently authorize a network block or device command whose physical consequence has not been assessed.
The requirement should carry the safe first action, responsible process owner, escalation path, and conditions under which automated containment is forbidden. Security urgency does not override process safety.
Claim only the path that has been observed and tested
A bounded statement might say that approved monitoring identifies logic-write operations from named engineering zones to selected controllers during production mode when network parsing, asset identity, and mode data are healthy. It may support operator verification, not automatic blocking.
That statement does not cover proprietary encrypted traffic, portable media, local console access, unmonitored cells, or physical manipulation. Name those gaps. Link network evidence to passive OT network monitoring assumptions and state when controller or engineering records are required.
Validation evidence should identify the equipment model, protocol operation, process mode, observation point, and approved scenario. Passing on one controller and firmware version does not establish universal plant coverage. OT honesty begins with a claim small enough that operators and engineers can trust it.
Frequently asked questions
Why must an OT detection requirement include process state?
Because the same command can be routine during maintenance, necessary during startup, and dangerous during production. Digital evidence gains meaning from the equipment, operating mode, and physical conditions around it.
