LEARN. PRACTICE. GROW.Start with the physical process
In a fictional financial institution’s data centre, a building management platform collects temperatures and coordinates cooling. Application servers may be protected while the process remains exposed through an old controller or permanent supplier access. Start by identifying what the system controls, who operates the process and the consequences of incorrect commands, delays or communication loss. Priority cannot be inferred solely from vulnerability counts. A controller holding no personal data may support availability and physical safety. Record technical and operational owners, power and network dependencies, manufacturer constraints and the agreed escalation procedure for a dangerous condition. This is a possible workplace context, not a description of any bank’s internal procedures.
Build an inventory with explicit confidence
An IT inventory export lists twenty devices while maintenance diagrams show twenty-four. Do not declare the other four retired merely because the tool omits them. Compare maintenance records, authorized configurations, network ports and passive observations from relevant segments. For each discrepancy, identify the latest evidence, its resolution owner and the uncertainty still open. A passive sensor may miss a device that remains silent during observation. It also does not necessarily interpret encrypted payloads or segments outside its collection point. Qualify information by origin and freshness. A useful inventory connects function, version, logical and physical location, support, criticality and dependencies; an address list without context is insufficient for deciding an interruption.
Distinguish discovery from permission to test
An incomplete report does not authorize running the usual server scanner against production controllers. First define the question and seek existing evidence. Where active interaction is needed, involve the process owner and equipment specialists, assess compatibility, limits and timing, and prepare observation and stop criteria. A representative exercise reduces uncertainty but does not guarantee risk-free behavior under every condition. Apply the same care to patches, monitoring agents and polling-frequency changes. In a project, turn these concerns into acceptance criteria and owned tasks. Authorization should bound targets and actions; a general request to improve security does not grant permission to test every device in the building.
Prepare containment and recovery with the operator
The security team detects suspicious activity on a maintenance workstation. Disconnecting the entire network may remove supervision or change process behavior. The procedure should identify what can be isolated, which flows are essential, how the operator observes physical state and who decides emergency measures. A safe state does not universally mean powered off: the choice depends on the process and safety analysis. Define time limits and conditions requiring local intervention. Recovery needs known configurations and versions, available skills, process validation and authorization to resume. Restored connectivity establishes only one technical aspect. This unit’s Docker exercise contains no controllers, interlocks or physical equipment and does not establish that a real installation can lose communication without consequences.
Manage obsolescence as an owned decision
A controller stops receiving fixes but can only be replaced during a future outage. Record exposure, constrain access paths and reduce unnecessary services where compatibility allows. Add observation, change control and a replacement plan with funding, an owner and a review date. These controls reduce parts of the risk; they neither restore software support nor remove the vulnerability. Present residual risk to the organization’s designated authority. At handover, deliver reconciled inventory, a flow matrix, temporary access records, recovery evidence and known gaps. For study, CAS-005 places specialized and legacy systems in objective 3.5. The consulted final reference is NIST SP 800-82 Rev. 3; Rev. 4 is an initial draft to track without presenting it as final guidance.
# Planning artifact, not a command to run against OT
# asset | physical function | owner | allowed flows | support | evidence date
# Record discrepancies and stop criteria before scheduling interaction.Four devices absent from the tool remain discrepancies until reconciled with maintenance and segment evidence.
Common pitfalls
Silent inventory as retirement; IT scanning authorization as OT permission; shutdown as a universal safe state.
Related topics: OT inventory and dependencies · Segmentation and remote access · Physical safety and operations
Select controls from process functions and consequences, keeping uncertainty, owners and recovery criteria explicit.
Reference: Guide to Operational Technology Security, SP 800-82 Rev. 3 · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17