The Challenge
A UK power facility went offline for several days following a suspected state-linked cyberattack. This incident was part of a coordinated wave of attacks targeting vulnerable industrial devices in the water and energy sectors. It exposed a fundamental problem: the control systems that keep critical infrastructure running weren't designed with modern cyber threats in mind.
For auditors and assessors evaluating compliance frameworks, this raises an uncomfortable question: Are we auditing the right things? Traditional SOC 2 and ISO/IEC 27001 assessments focus heavily on IT security controls, network segmentation, access management, and data protection. However, industrial control systems (ICS) and operational technology (OT) environments operate under different constraints, different risks, and often different teams.
Unique Challenges in ICS Environments
Industrial control systems present unique audit challenges that standard compliance frameworks struggle to address:
Physical consequences replace data breaches. When an ICS system fails, you're not dealing with compromised customer records. You're dealing with power outages, water treatment disruptions, or manufacturing shutdowns. The risk models in ISO/IEC 27001 Clause 6.1.2 (information security risk assessment) typically focus on confidentiality, integrity, and availability of information assets. But OT environments prioritize safety and operational continuity above information protection.
Legacy systems can't be patched on IT timelines. A water treatment facility might run on programmable logic controllers (PLCs) that are 15 years old, running firmware that hasn't been updated because the vendor no longer supports it, or because updates require operational downtime measured in days, not hours. Your SOC 2 CC6.1 control about logical and physical access controls assumes you can implement multi-factor authentication and regular password rotations. Try implementing that on a SCADA system that authenticates via hardcoded credentials.
Air gaps are myths. Auditors often encounter organizations claiming their OT networks are "air-gapped" from corporate IT. In practice, these environments connect to the internet for remote monitoring, maintenance access, or data integration with enterprise systems. The wave of attacks targeting industrial devices exploited exactly these connection points.
Rethinking Compliance Approaches
Organizations responding to these threats are discovering that checkbox compliance doesn't translate to actual security in OT environments. The effective approach requires reinterpreting framework controls through an operational lens:
Asset inventory takes on new meaning. ISO/IEC 27001 Annex A 5.9 (inventory of information and other associated assets) and SOC 2 CC6.1 both require asset inventories. In OT environments, this means cataloging not just servers and workstations, but every PLC, remote terminal unit, human-machine interface, and industrial protocol in use. You're documenting Modbus, DNP3, and OPC connections alongside your typical TCP/IP infrastructure.
Network segmentation becomes non-negotiable. Annex A 8.22 (segregation of networks) isn't optional guidance in critical infrastructure. Organizations are implementing defense-in-depth architectures with multiple security zones: a demilitarized zone between corporate IT and OT networks, separate VLANs for different operational functions, and unidirectional gateways that allow monitoring data out but prevent commands from flowing back in without explicit validation.
Monitoring shifts from log analysis to anomaly detection. Traditional SIEM tools built for IT environments don't understand industrial protocols. Effective OT security monitoring (relevant to Annex A 8.16, monitoring activities) requires protocol-aware detection that can identify when a PLC receives an unexpected command sequence or when communication patterns deviate from operational baselines.
Lessons Learned
The UK power facility incident demonstrated multi-day operational impact. Organizations in the water and energy sectors faced a coordinated campaign targeting industrial device vulnerabilities across multiple sites.
These aren't theoretical exercises. When auditors assess control effectiveness in critical infrastructure environments, they're evaluating whether controls can withstand sophisticated, persistent threats with geopolitical motivation and significant resources.
Evolving Compliance Practices
The compliance community is recognizing that standard audit procedures miss critical OT security gaps:
Risk assessment methodology needs OT-specific scenarios. ISO/IEC 27001 Clause 6.1.2 requires organizations to identify risks to information security. But the scenario-based risk assessment for critical infrastructure should include: What happens if an attacker gains write access to our PLCs? Can we detect unauthorized firmware changes? How quickly can we restore operations if control systems are compromised?
Third-party risk extends to industrial vendors. Annex A 5.19 through 5.23 cover supplier relationships, but OT environments add complexity. Your SCADA vendor might require remote access for support. Your equipment manufacturer might push firmware updates without your explicit approval. The compliance assessment needs to verify that Complementary Subservice Organization Controls exist for these relationships, or that compensating controls adequately address the risk.
Incident response plans must account for operational reality. SOC 2 CC7.3 and Annex A 5.24 through 5.28 require incident management capabilities. But you can't just "disconnect from the network" when the network controls physical processes. Incident response plans for critical infrastructure need procedures for maintaining safe operations during an active compromise, not just IT containment strategies.
Takeaways for Your Team
When you're auditing organizations with OT environments, or when you're designing compliance programs for critical infrastructure:
Verify that asset inventories include industrial systems. If the inventory only lists IT assets, the organization hasn't scoped its ISMS or SOC 2 system description correctly. Industrial control systems that connect to networks, even indirectly, are in scope.
Test whether network segmentation actually works. Don't accept network diagrams at face value. Verify through technical testing that the corporate IT network can't directly communicate with operational technology systems, and that any necessary connections pass through monitored security controls.
Confirm that monitoring covers industrial protocols. Ask what happens when someone sends an unexpected command to a PLC. If the answer is "we'd see it in firewall logs," that's insufficient. Industrial protocol monitoring should detect anomalous commands before they execute.
Assess incident response procedures for operational continuity. During your walkthrough of incident response plans (ISO/IEC 27001 Clause 5.3 requires top management to ensure incident management policy is established), ask: Can you maintain safe operations if your control network is compromised? What's your procedure for manual operations? How do you verify system integrity before restoration?
The wave of attacks on industrial devices in the water and energy sectors isn't going away. State-linked threat actors have demonstrated both capability and intent to target critical infrastructure. Your compliance assessments need to evolve accordingly.
