A supplier access ticket, a PLC change investigation and a VEX statement all ask someone to accept a residual risk.
In each of these hypothetical scenarios, the decision depends on evidence from the system where the consequence can still occur: the downstream session, the running controller or the delivered ECU build.
The pattern this week
Closure needs evidence from the system that can still act.
Remote accessBroker disconnectedCheck the downstream session and reconcile writes already accepted.
→
PLCProcess readings normalEstablish whether the changed logic permits continued operation within explicit limits.
→
ECUVEX marked not affectedTie the justification to the delivered build and the relevant vulnerability.
Common gap: Name the component that can still act, the evidence that closes the claim and the condition that would reopen it.
01
OT · Remote Maintenance
The broker is disconnected. Is the engineering session closed?
A supplier connects to a legacy controller through a remote access broker. Disconnecting the broker or disabling the account can block further access without establishing what happened to a session on the engineering workstation. Even a confirmed session termination leaves a separate question: did any change already reach the controller?
DecisionVerify that the old session cannot issue another write. Reconcile any writes already accepted against the approved baseline before closing the ticket.
The process looks normal. Can the line keep running?
A PLC program changes outside the approved window, but the operator sees no alarms or unexpected readings. The current readings describe the process under current conditions. They say little about the behavior of changed logic when an interlock, permissive or recovery path is needed.
DecisionRestrict further engineering changes. If operations and safety owners accept temporary operation, record the limits, the stop triggers and who can authorize restoration.
The ECU is closed. Is this build actually unaffected?
A supplier says a vulnerability is not applicable because the ECU is closed. The claim needs to identify the vulnerability and delivered build, then show whether the relevant code is absent, unreachable in the delivered configuration or only shielded by an external control. Those are different claims with different failure conditions.
DecisionRequire a build-specific justification and reopen it when the build, configuration or assumptions behind the conclusion change.
Take one recently closed decision. Record what changed at the point of consequence, what evidence you have for it, and what would reopen the decision. Give that last condition an owner. A closed ticket is much easier to defend when the team knows what would invalidate it.
