If you're responsible for IT governance and your organization operates critical infrastructure, you're now managing two fundamentally different security models. The recent targeting of over 100 internet-exposed water systems in July highlights the risks when IT security practices don't translate to operational technology (OT) environments.
This checklist helps governance teams build a practical bridge between IT and OT security. It's designed for organizations where OT was historically "someone else's problem" but now sits squarely in your risk register.
Prerequisites
Before you start this checklist, confirm you have:
- Asset inventory that includes OT systems: Document controllers, HMIs, SCADA systems, and industrial control systems with network locations and internet exposure status.
- Stakeholder access: Establish working relationships with operations teams, facility managers, and anyone who interacts with OT systems daily.
- Authority to implement network changes: Some items require segmentation or access restrictions affecting operational workflows.
- Incident response plan skeleton: Even a basic IT incident response plan that you can adapt for OT scenarios.
Checklist Items
1. Identify all internet-facing OT assets
What to do: Run network scans to find every OT device, controller, or interface directly accessible from the internet. Document each with IP address, purpose, and business justification for internet exposure.
Done looks like: A spreadsheet listing every internet-exposed OT asset, with a clear yes/no decision on whether that exposure is necessary.
2. Remove unnecessary internet exposure
What to do: For every asset without a documented business need for direct internet access, remove that exposure. If remote access is required, route it through VPN or jump boxes with multi-factor authentication.
Done looks like: Zero OT devices directly accessible from the internet without passing through an authentication layer. Operations teams confirm they can still perform required remote tasks.
3. Change all default credentials on OT systems
What to do: Audit every controller, HMI, and industrial device for default usernames and passwords. Change them. Document the new credentials in your privileged access management system.
Done looks like: A completed audit log showing every OT device with credentials changed from manufacturer defaults. Your PAM system stores and rotates these credentials on a defined schedule.
4. Implement network segmentation between IT and OT
What to do: Create network boundaries that prevent lateral movement from IT systems into OT environments. Use firewalls, VLANs, or microsegmentation to enforce communication rules based on least privilege.
Done looks like: A network diagram showing clear boundaries between IT and OT zones. Firewall rules that explicitly allow only necessary traffic between zones. Test results confirming that a compromised IT workstation cannot directly reach OT controllers.
5. Establish zero trust controls for OT access
What to do: Require identity verification, device health checks, and explicit authorization for every connection to OT systems. This applies to internal users, not just external access.
Done looks like: Access logs showing that every OT connection requires authentication and authorization. No "trusted network" assumptions where being on the internal network grants automatic access to controllers.
6. Patch supported OT systems on a documented schedule
What to do: Identify which OT systems can be patched without operational disruption. Create a maintenance window schedule. Patch those systems. For legacy systems that can't be patched, document compensating controls.
Done looks like: A patch management schedule for OT systems with evidence of completed patches. For unpatchable legacy systems, documented compensating controls like network isolation or enhanced monitoring.
7. Monitor OT systems for anomalous activity
What to do: Deploy logging and monitoring that captures configuration changes, unauthorized access attempts, and unusual communication patterns in OT environments. Set up alerts for deviations from normal operational baselines.
Done looks like: Monitoring dashboards showing OT system activity. Alert rules configured for suspicious patterns like configuration changes outside maintenance windows or communication with unexpected IP addresses. Evidence that alerts trigger incident response procedures.
8. Create offline configuration backups of OT systems
What to do: Back up controller logic, HMI configurations, and system settings to offline storage. Test restoration procedures to confirm you can rebuild systems without network access.
Done looks like: Documented backup procedures with timestamps of last successful backups. Test results showing you can restore a controller configuration from offline media within your recovery time objective.
9. Build OT-specific incident response procedures
What to do: Adapt your IT incident response plan to address OT scenarios. Include procedures for switching to manual operations, isolating compromised controllers, and coordinating with operations teams during security incidents.
Done looks like: Incident response playbooks that explicitly cover OT scenarios. Tabletop exercise results showing IT and operations teams can coordinate during a simulated OT security incident.
10. Map third-party access to OT systems
What to do: Document every vendor, contractor, or service provider with access to OT systems. Review their security practices. Require MFA and time-limited access for all third-party connections.
Done looks like: A vendor access matrix showing who has OT access, why, and through what method. Contracts requiring vendors to follow your security standards. Logs confirming third-party access is time-limited and monitored.
Common Mistakes
Treating OT like IT: You can't just apply your IT security playbook to operational technology. OT systems prioritize availability over confidentiality, can't tolerate downtime for patches, and often run on decades-old protocols. Your controls need to account for these constraints.
Assuming air gaps still exist: If operations teams can access OT systems remotely, attackers can too. The concept of isolated OT networks is mostly historical. Treat OT as internet-connected until you prove otherwise.
Skipping operations team input: IT governance teams sometimes design security controls without understanding operational workflows. The result is security measures that get disabled because they break critical processes. Involve operations staff from the start.
Focusing only on prevention: You won't patch every vulnerability or block every attack. Build controls that assume compromise and limit what attackers can do once inside. Microsegmentation and zero trust principles contain breaches even when prevention fails.
Ignoring small or rural facilities: 81% of all U.S. public water systems are small utilities, which account for 93% of violations for Nonconformity with federal drinking water standards. Your smallest sites are often your most vulnerable. They need the same attention as your flagship facilities.
Next Steps
Once you've completed this checklist:
Schedule quarterly reviews: OT environments change slowly, but your risk profile doesn't. Review this checklist every quarter to catch new internet-exposed assets or third-party access.
Map to compliance requirements: If you're subject to sector-specific regulations or pursuing ISO/IEC 27001 certification, map these controls to Annex A requirements for operational security (Clause 8) and supplier relationships (Clause 5.19-5.23).
Build competency internally: Train your IT governance team on OT-specific risks. Consider ISO/IEC 27021 competency requirements for ISMS professionals working with critical infrastructure.
Test your incident response: Run tabletop exercises that simulate OT compromises. The goal is finding gaps in your procedures before you need them in a real incident.
The convergence of IT and OT security isn't optional anymore. Attackers already understand that critical infrastructure combines IT-style attack vectors with OT-style consequences. Your governance model needs to reflect that reality.
