Introduction

The Control Room at 2 A.M.

Picture your control room at 2 a.m. Every HMI screen is dark. The phones on the operator desk are ringing faster than anyone can answer them, and the shift supervisor is holding a binder with "Incident Response Plan" printed on the spine. Now answer two questions, honestly, for your own site. Who gets in a truck and drives to the first substation, pump station, or remote unit? And when they get there, which page of the plan do they open? If your answer starts with "it depends who's on shift," you are in the same position as most industrial organizations. The plan exists. It was probably written with care, reviewed by someone senior, and filed where an auditor can find it. What it has almost never had is a run under pressure, with real operators, real phones, and a real clock. That gap is invisible on an ordinary day. It becomes the whole story on the night something goes wrong, because every question the plan did not answer gets answered by improvisation, and improvisation in a running plant has physical consequences. This book exists to close that gap before the night arrives. It shows you how to find the answers to those two questions, and dozens like them, in a drill or an exercise you control, instead of in a real incident that controls you.

Who This Book Is For

This book is written for the people who will actually be in the room when an OT incident happens, or who are responsible for making sure that room works. That includes control systems and automation engineers who know their PLCs, HMIs, SCADA, and DCS better than anyone and have now been asked to own part of the response. It includes automation technicians and senior operators, who are usually the first people to notice that something on the process is wrong. It includes OT security leads who have to design exercises, run them, evaluate them, and then prove to management and auditors that the results mean something. And it includes IT security professionals whose incident response responsibilities have recently been extended across the boundary into industrial systems, and who are discovering that several of their reliable IT instincts are dangerous on the plant floor. The regulatory examples come from electric power and pipelines, because those sectors have the most specific testing and reporting rules, but the habits the book teaches carry straight over to water and wastewater, chemicals, oil and gas, and manufacturing. If your site has an incident response plan that nobody has really tested, or a plan that was tested once, found wanting, and then quietly shelved, you are the reader this book had in mind.

What You Will Be Able to Do

By the time you finish, you will be able to take the plan you already have and turn it into a capability you can demonstrate. You will know how to shape that plan around the things an IT template leaves out: a defined safe state for each process area, manual fallback procedures operators can follow under stress, and clear limits on what the first person on the scene is authorized to do. You will be able to design two very different kinds of tabletop exercise, one that tests how leadership makes decisions when there is no clean answer, and one that tests whether the technical playbook steps actually work and how long they really take. You will be able to build scenarios that escalate realistically, adapt the free exercise packages CISA publishes instead of starting from a blank page, and choose which incident types your team most needs to rehearse. You will understand what NERC CIP-008-6 and the TSA pipeline directives expect as testing and reporting evidence, so that a well-run exercise does double duty as compliance proof. You will know how to write an after-action report and an improvement plan whose items actually get closed, how to prove a backup can rebuild a working control system rather than just a file share, and how to schedule a full year of drills around outages, audit dates, and the people who have to attend them.

How the Five Parts Fit Together

The book is arranged in the order you would build a real program, and each part hands the next one something it needs. A drill tests nothing if there is no plan to test, and a finding means nothing if no one is accountable for fixing it, so the sequence is deliberate. Part 1 starts with the plan itself: why an untested plan is a theory, how the standard incident response lifecycle bends when a physical process is involved, what an OT plan must contain, and how operators and monitoring turn an odd reading into a declared incident. Part 2 moves into the exercises themselves, covering the two kinds of tabletop and the craft of building scenarios that put real pressure on the plan. Part 3 deals with everyone outside the control room, from the shift supervisor's first phone call to the regulators who expect a filing within hours, and it reads the power and pipeline testing rules closely. Part 4 is about what happens after the exercise ends: turning observations into an improvement plan, measuring progress in a way that means more than a count of drills, proving recovery is possible, and setting a twelve-month rhythm so testing becomes habit. Part 5 closes with two real incidents told from the responder's side, the 2015 attack on Ukraine's power grid and the 2019 ransomware attack on Norsk Hydro, followed by a complete worked exercise that pulls every earlier chapter into one session.

How to Read It

Read it in order the first time. Later chapters build on earlier ones and refer back to them rather than explaining the same idea twice, so the chapter on scenario design assumes you already know what safe state means, and the chapter on regulatory testing assumes you know the difference between a drill and an exercise. The two incident chapters are placed near the end on purpose. Reading about Ukraine after you have thought hard about manual fallback and out-of-band communication is a different experience from reading it cold, because you will recognize each decision the responders faced and ask whether your own team could make it. After the first pass, the book works as a reference you return to with a specific job in hand: the scenario chapter before you design next quarter's exercise, the regulatory chapter before an audit, the after-action chapter the week after a session when the notes are still fresh. Keep a page or a file open for your own site as you go. Almost every chapter will raise a question about your plan, your people, or your process that you cannot answer from memory, and writing those questions down as you meet them is the beginning of your first improvement plan.

What's Next

Go back to that dark control room for a moment. Somebody is about to drive to a site and open a page of a plan, and the only thing you can still influence is whether they have rehearsed it. Chapter 1 begins with an uncomfortable truth about the plan you already have: having one and having tested one are different things, and the difference shows up in the same three ways at almost every site that has been caught by it. Once you can see those gaps, you will also see why drills and exercises are separate tools, and why choosing the wrong one wastes the session.

Reflect

• At 2 a.m. tonight, who at your site would drive to the first affected location, and how confident are you that they would know which part of the plan to follow when they arrived?
• When was the last time your incident response plan was opened for any reason other than an audit or an annual review?
• Which of the five parts of this book describes the weakest area of your current program, and what makes you think so?
• If your plan were run for real next week, which answers would depend on who happened to be on shift?