Over two days in July, more than 30 Minnesota water systems fell back on manual controls after a coordinated attack disrupted their operational technology. The state activated its whole-of-state incident response program. Four cities went public. Federal agencies updated their advisories.
Your board wants to know: are we ready?
The decision you're facing isn't whether to prepare for an OT incident. It's whether your existing IT-focused Computer Security Incident Response Team can handle industrial control systems, or whether you need a dedicated OT response framework. The wrong choice leaves you coordinating containment across environments that speak different languages, operate on different timelines, and fail in different ways.
Key Factors That Affect Your Choice
Your OT footprint determines your exposure profile. If you operate water treatment plants, electric substations, manufacturing lines, or building automation systems with internet-connected programmable logic controllers, you're managing devices that attackers can reach directly. CISA's joint advisory describes threat actors modifying project logic, disabling alarm functions, and manipulating human-machine interface displays while operators see normal readings. Your incident response plan either accounts for these attack vectors or it doesn't.
Your IT-OT convergence maturity shapes your response requirements. Organizations with fully air-gapped OT environments face different incident scenarios than those running remote engineering access through VPNs. The Minnesota attacks targeted internet-connected controllers. If your SCADA systems route through authenticated channels with tightly restricted access, your containment procedures differ from organizations still running direct internet exposure.
Your regulatory obligations define your notification timelines. Water utilities answer to EPA and state health agencies. Electric utilities operate under North American Electric Reliability Corporation Critical Infrastructure Protection requirements. Your incident response framework must map Containment, Eradication, and Recovery steps to sector-specific reporting obligations, not just general breach notification rules.
Your operational continuity tolerance sets your recovery priorities. Plymouth reported affected communications to two water towers and multiple wastewater lift stations overnight. Braham's public works crews restored their water treatment plant in under two hours. Your plan either prioritizes safe degradation to manual controls or it attempts automated recovery. That choice depends on whether you can tolerate the safety risks of bringing compromised logic back online.
Path A: Retrofit Your IT Incident Response Plan
Choose this path when your OT environment is small, air-gapped, or managed entirely by third-party operators who maintain their own response capabilities.
Add OT-specific containment procedures. Your standard "isolate the affected system" directive doesn't work when isolating a controller means shutting down a water treatment process. Document the safe shutdown sequences for each critical system. Identify which manual overrides your operations team can activate without creating secondary safety hazards.
Include operations staff in your incident response structure. Your Computer Security Incident Response Team can't make containment decisions alone. The people who understand process safety, equipment tolerances, and regulatory reporting obligations must participate in real-time response coordination. Update your CSIRT charter to include OT operations representatives with decision authority.
Gather threat intelligence relevant to industrial control systems. The federal advisory describes attackers stealing controller project files and modifying add-on instructions. Your IT-focused threat feeds won't flag these indicators. Connect to sector-specific information sharing programs. Minnesota coordinates through its Whole-of-State Cybersecurity Program, though federal liability protections for such sharing lapsed last fall and remain unsettled in Congress.
This path works when you can absorb the coordination overhead. Your IT incident manager will need to translate between security analysis and operational impact. Your forensics team will need to understand both network packet captures and controller logic files. If your OT footprint is small enough that this translation layer doesn't slow your response below acceptable recovery time objectives, retrofitting avoids the cost of maintaining separate frameworks.
Path B: Build a Dedicated OT Incident Response Framework
Choose this path when you operate significant internet-connected OT infrastructure, when your IT and OT environments share network segments, or when regulatory obligations demand sector-specific response procedures.
Develop separate detection and analysis capabilities. Attackers modified SCADA display data to show normal readings while systems drifted into unsafe states. Your IT security information and event management platform won't catch logic manipulation in programmable logic controllers. Deploy OT-specific monitoring that validates controller behavior against expected process parameters, not just network traffic patterns.
Create containment procedures that prioritize safe states over rapid isolation. When Braham's water treatment plant went offline, public works crews restored it in under two hours with no physical damage or water quality impact. That outcome required pre-planned manual operating procedures. Your OT incident response framework must document the safe degradation path for each critical process, including which valves to close, which pumps to stop, and which backup systems to activate before you attempt any digital containment.
Establish recovery procedures that validate logic integrity before restoration. The federal advisory describes attackers deleting shutdown and alarm logic. Your standard "restore from backup" procedure creates risk if you don't verify that controller project files match your known-good baseline. Build verification steps that compare running logic against offline copies, test alarm functions in isolated environments, and validate human-machine interface displays against actual sensor readings before you return systems to automated control.
Coordinate protocols that connect federal, state, local, and sector partners. Minnesota activated response capabilities spanning MNIT, the Department of Public Safety, the Bureau of Criminal Apprehension's fusion center, state health and pollution control agencies, CISA, EPA, and FBI. Your framework must define who coordinates multi-agency response, who authorizes information sharing with sector partners, and who manages public communications when multiple jurisdictions are affected.
This path works when your OT risks justify dedicated resources. If you operate critical infrastructure that serves public health, safety, or economic functions, the cost of maintaining separate OT incident response capabilities is lower than the cost of coordinating IT-OT response through a single team during an active incident.
Path C: Hybrid Response With Separate Playbooks
Choose this path when you maintain a single Computer Security Incident Response Team structure but need OT-specific procedures for detection, containment, and recovery.
Use your existing CSIRT governance and escalation structure. One incident manager coordinates response across IT and OT environments. One decision authority approves containment actions. One communications lead manages stakeholder notifications.
Maintain separate technical playbooks for IT and OT incidents. Your IT ransomware playbook focuses on data encryption and backup restoration. Your OT disruption playbook focuses on safe shutdown sequences and logic validation. Your incident manager selects the appropriate playbook based on which environment is affected.
Train your CSIRT on OT-specific decision criteria. Your team learns to recognize when network isolation creates safety risks, when automated recovery threatens process integrity, and when federal advisories describe attack patterns relevant to your industrial controllers.
This path works when you need OT-specific expertise without duplicating your entire incident response organization. You avoid the coordination overhead of Path A and the resource requirements of Path B.
Summary Matrix
| Decision Factor | Retrofit IT Plan (Path A) | Build OT Framework (Path B) | Hybrid Playbooks (Path C) |
|---|---|---|---|
| OT environment size | Small, air-gapped | Large, internet-connected | Medium, segmented |
| IT-OT convergence | Minimal network overlap | Shared infrastructure | Partial integration |
| Regulatory complexity | General breach notification | Sector-specific requirements | Mixed obligations |
| Operations team capacity | Limited availability | Dedicated OT staff | Shared resources |
| Incident coordination tolerance | Can absorb translation overhead | Requires specialized response | Accepts playbook switching |
| Resource commitment | Lowest | Highest | Moderate |
The Minnesota attacks disrupted more than 30 water systems because internet-connected controllers gave attackers direct access to operational technology. Your incident response framework either accounts for that attack surface or it leaves you coordinating manual fallback procedures during an active incident.
Choose your path based on your OT footprint, your convergence maturity, and your operational continuity requirements. Then test it before you need it.
