Building an OT Incident Response Plan

A generic corporate incident response plan, applied unmodified to an OT event, will make dangerous assumptions -- that systems can be isolated instantly without operational consequence, that forensic imaging is straightforward, and that 'contain and eradicate' can happen on IT timescales. An OT incident response plan has to be built around the reality that physical processes are involved. The plan needs joint ownership between security and operations/engineering from the start -- not a security team that writes a plan and hands it to operations to execute. Isolation decisions in particular must be made jointly: disconnecting a system from the network can be the right call, or it can itself cause an unsafe or uncontrolled process state, and only someone who understands the physical process can make that judgment safely. A good OT IR plan defines, in advance: who has the authority to isolate a system or shut down a process for security reasons, what the safe isolation procedure is for each critical asset class (because 'unplug it' is not always safe), how to preserve evidence without disrupting recovery timelines the business cannot absorb, and who external stakeholders are -- regulators, sector-specific information sharing organizations, law enforcement, insurers -- and when each needs to be notified. Tabletop exercises are the single most valuable preparation activity: walking through a realistic scenario (a suspicious command detected on a safety-critical controller, for example) with the actual people who would respond reveals gaps -- unclear authority, missing contact information, untested assumptions about backup integrity -- far more cheaply than discovering them during a real incident.