Frame the risk in operating terms
Operational technology and connected devices often combine long service lives, specialist protocols, supplier access and strict availability constraints. A security change that is routine in an office environment may interrupt a physical process or invalidate support. Begin with process consequence and safety, then map controllers, sensors, gateways, engineering workstations, remote access and dependencies.
Treat the subject as an operating system rather than a product setting. The accountable owner is the operational process owner working with engineering, safety and cybersecurity specialists. Important decisions include which process consequences are unacceptable, which connections are genuinely required, how maintenance access is authorised, how degraded manual operation works. Record assumptions, dependencies and accepted exceptions so a future reviewer can distinguish deliberate design from accidental exposure.
Engineer a controlled path
Separate operational zones according to required flows, protect engineering and vendor access, and avoid direct public management interfaces. Use allow-listed communications where practical, strong individual identities and controlled maintenance windows. Compensate for unpatchable devices with isolation, monitoring and replacement planning rather than treating age as a permanent exception.
Build the control path in layers: process-based asset inventory, zoned connectivity, controlled remote maintenance, configuration protection, safe recovery procedures. Apply stronger safeguards where a failure could change production, expose sensitive information or block recovery. Pilot changes with representative users and services, define rollback criteria and make emergency access narrower and more observable than ordinary administration.
Operate from evidence, not reassurance
Baseline expected communication and configuration so unusual changes can be investigated without overwhelming operators. Preserve secure backups of logic, configuration and keys, and test restoration with engineering approval. Monitor new remote tools, unauthorised wireless links, disabled safeguards and devices that disappear from management.
Useful evidence includes network flow baselines, engineering change records, remote session logs, configuration hashes, restore test results. Keep collection protected from the systems being observed, test that records arrive when expected and assign a person who can act on a meaningful signal. Measures such as known device coverage, unapproved connection age, remote access review completion, validated recovery time should lead to a decision, not merely decorate a dashboard.
Exercise failure and improve the design
Simulate loss of one control component or compromise of a supplier account without endangering production. Practise isolation, alternate operation, evidence capture and restoration from approved configuration. The outcome should clarify which cyber action requires safety authority and which dependency prevents timely recovery.
Run a bounded exercise that forces the team to use real contacts, authority, evidence and recovery paths. Capture what was known, what was assumed and which action changed the outcome. Give every improvement an owner and validation method, then repeat the difficult part after the change instead of closing the work on written assurance.
What to do next.
- ✓Start from process and safety consequences.
- ✓Inventory devices, software and remote paths.
- ✓Segment operational zones by required flow.
- ✓Control supplier identities and maintenance windows.
- ✓Protect logic and configuration backups.
- ✓Exercise isolation and safe restoration.
Use guidance responsibly
Technology, provider behaviour and legal requirements change. Validate implementation details against current official documentation, test changes safely and obtain qualified legal advice where required.