OT incident response for electricity and water: your own playbook step, drawing, contact and reporting clock behind one plain question
The right playbook step at 3 a.m.
See one case, screen by screen ↓OT Incident Response is software that answers OT responders from their own incident response plan. The night SOC analyst types what is happening in plain words, and the plan's playbook opens as a decision tree at the step they are on, each instruction quoted from its page, with the zone drawing, the vendor's security line and the reporting clock beside it. Today those answers sit in a 64-page plan, nine playbooks, 14 zone and network drawings, 23 vendor contracts and five sets of reporting rules, in binders and on SharePoint, written for the auditor. In the demo utility's July 2026 tabletop the night team took 22 minutes to reach the right playbook step and 31 minutes to find the vendor's security hotline.
Meanwhile the clocks run. Under CIP-008-6 the initial notification to the sector ISAC and the national cyber agency is due one hour after the determination of a Reportable Cyber Security Incident, not after detection, so a team that does not record when it determined cannot prove it met the hour. The drawing that shows which RTUs sit behind which firewall is in a different folder from the playbook, so pulling the wrong conduit can take the control room's view of the grid away. And the timeline is rebuilt afterwards from memory, so the notification, the 7-day update and the 90-day lessons learned are written late.
Estimated split, in minutes, by hand and with the solution. The first two “before” figures are the demo utility's own July 2026 tabletop (22 and 31 minutes); the rest are our estimate.
Six agents find the step, the drawing, the contact and the clock; the incident commander decides every branch and signs.
Lumina Utilities runs electricity and water: 41 substations, two control centres and six water works. On Tuesday 13 October 2026 at 02:51 a remote session opens on jump host JH-02 with corv-svc2, a vendor account of Corvane Automation, from an address not on Corvane's approved list. Here is what happens next, screen by screen, in the working solution.
Alert OTS-88213: unusual DNP3 function codes from engineering workstation EWS-14 at Northgate, severity high. The running timeline already holds what the sensor saw: the JH-02 session at 02:51 with no booked window, EWS-14 reading 7 RTUs where its normal set is 2, and two DNP3 select commands to breaker CB-212 at Marlow Cross 33 kV, with no operate. The nine playbooks of plan IRP-OT-01 v6.1 sit above it.
“No clock running yet. Five rule sets are read for every incident: CIP-008-6, the water licence, the cyber policy, CIRCIA and the plan's own targets.”
Sam types “Suspicious traffic on the SCADA network?”. The incident classifier names playbook PB-OT-04, “Suspicious activity on the control network”, and the navigator opens it as its nine-step decision tree at step 1, quoted from §3.1, page 6. The plan's 60-minute determination target starts from detection: 03:07 to 04:07. Beside the step, the agents have found the session on JH-02, that EWS-14 is approved for 2 RTUs read only, and Corvane's 24/7 security line.
PB-OT-04 §3.1: “Check the source against the approved connections list (ACL-SCADA). Call the vendor's security line to confirm any vendor session. Do not disconnect the source yet.”
Sam calls Corvane's security line under contract CV-2291 §9.2: no work is booked tonight and corv-svc2 was not issued. Step 1 is answered “Not approved”, and the contact finder pages Elena at 03:15; she joins the bridge from home at 03:19. Joel Brandt, the Northgate shift supervisor, confirms no uncommanded operations, CB-212 closed and full view of all 41 substations. Branch: contain at the conduit, keep control.
PB-OT-04 §3.3: “Contain at the conduit, not at the device. … Keep the workstation powered: do not reboot or log off.”
On zone drawing NET-DWG-0142 rev F, tonight's path is traced from 203.0.113.47 through JH-02 to EWS-14 and the seven RTUs. Two ways to contain sit side by side. Block EWS-14 at firewall FW-L3-02 with pre-staged rule 41: the front-ends keep polling all 41 substations and 0 customers are affected. Pull FW-L3-02 itself: the control room loses its view and 58,400 customers behind the 7 RTUs are out of sight.
The resolver reads the drawing and never sends a command to a control system or a firewall. Sam enables rule 41 himself.
Sam disables the vendor path for corv-svc2 on JH-02 at 03:29 and enables FW-L3-02 rule 41 at 03:31; the resolver checks that FE-01 and FE-02 still poll 41 substations. Elena records the containment, with EWS-14 kept powered for memory capture. Step 4 sets out the facts: JH-02 is an EACMS of the Medium Impact Northgate EMS, EWS-14 is a BES Cyber Asset inside the perimeter, and what each possible answer starts.
“Reportable: notify within 1 hour. Attempt to compromise: by the end of tomorrow, 14 Oct. Neither: no external notice.”
Elena determines a Reportable Cyber Security Incident. The clock keeper stamps the time and replaces the plan's determination target, met with 26 minutes to spare, with CIP-008-6 R4.2: notify the sector ISAC and the national cyber agency within one hour, due 04:41. The 7-day update and the cyber insurer's 72-hour notice under policy NMS-CY-22871 clause 6.1 arm with it. The water licence clock stays n/a, and CIRCIA is shown but not counted, because it is not yet in force.
The clock keeper never moves a start time a person recorded, and never sends a notification.
The scribe drafts the initial notification from 14 timeline entries, with the functional impact, attack vector and level of intrusion CIP-008-6 Part 4.1 asks for, each cited to its entry: “Reached a BES Cyber Asset (EWS-14) inside the Electronic Security Perimeter through an EACMS (JH-02). Operation of CB-212 was attempted, not achieved.” Elena reads it, edits it and signs as OT incident commander.
“The signature, the time and the text are kept on the record for three calendar years.”
The notice goes to the sector ISAC portal and the national cyber agency, with a copy to Farida Nasser, the CIP Senior Manager, who was informed of the determination at 03:42. The clock stops and records the minutes to spare. The 7-day update clock under Part 4.3 is armed and runs from the first new or changed fact.
“Sent at 04:02:00 by Elena Varga … 39 minutes inside the hour.”
Every sensor event, branch answered, call and signature is on the running timeline of INC-2026-0417 with its source. The key times sit beside it: detected 03:07:00, playbook opened 03:09:09, contained 03:33, determined 03:41:00 Reportable, notified 04:02:00, 39 of 60 minutes to spare. The same record feeds the 7-day update and the lessons-learned review, due 11 January 2027, 90 days on.
The scribe never edits a signed entry, and every line keeps its source.
Halden Ridge is one of four incidents on the clock line. At Westbrook water works, 41 failed logins on HMI-WB-03 run on the water licence's clock instead: WL-7, 24 hours from detection, due 14 Oct 01:58. Fenby wind farm's 7-day update is due 18 Oct 16:40, and the Ridgeway substation's lessons-learned review is due 31 Dec. Each clock was chosen by the incident's own facts.
“My clock is not NERC's clock. Show me mine.”
The same incident, seen by the five people who carry it — what that night looked like, and what it looks like now.
Six agents find the step, the drawing, the contact and the clock; the incident commander decides every branch and signs.
Reads the responder's question and the open OT sensor alerts, names the incident type in the plan and the playbook to open, and says why.
Opens the approved playbook as its own decision tree, highlights the current step and quotes it word for word with its section and page.
Finds every asset in the incident on the current zone drawings and, for each way to contain, shows the conduit, the firewall rule and how many customers sit behind each RTU.
Re-reads the reporting rules at every answer, starts each clock at the event its rule names — detection, determination or new information — swaps and stops clocks, and reminds the incident commander before each deadline.
Matches the incident to the vendor contracts, the forensic retainer, the notice clauses and tonight's on-call rota, and names who to call with the clause that says so.
Writes every event, answer, call and signature on the running timeline with its source, and drafts the initial notification, the 7-day update and the lessons-learned report from it.
Decides every branch and signs the notice. The agents propose; a named person decides.
Ask about the plan, the drawings, the contracts or the clocks. Every answer is quoted from an approved document.
Is this reportable under CIP-008?
That is your determination, at step 4. The facts the agents found: JH-02 is an EACMS of the Medium Impact Northgate EMS, and it was used to reach EWS-14, which armed CB-212 without operating it. A compromised EACMS meets the plan's definition of Reportable. If you determine it Reportable, the notice to the sector ISAC and cyber agency is due one hour after the time you record.
Who do I call at Corvane at this hour?
Corvane's security line runs 24 hours a day on +1 (555) 014-2290; for a Severity 1 security incident they call back within 30 minutes (CV-2291 §9.2). Their only booked session this week was CHG-26-1184 on 12 Oct, so corv-svc2 at 02:51 was not theirs to book.
What happens to customers if we block EWS-14 at FW-L3-02?
Nothing. Rule 41 on FW-L3-02 is pre-staged to deny EWS-14 only; front-ends FE-01 and FE-02 keep polling all 41 substations, so the control room keeps its view. Pulling FW-L3-02 itself would take that view away and put you on PB-OT-07.
Draft the notice for the sector ISAC and cyber agency
The draft is open with the three attributes CIP-008-6 Part 4.1 asks for: functional impact, attack vector and level of intrusion, each from a timeline entry. It needs your determination at step 4 first; then you read it, edit it and sign. I do not send it.
13 screens from the working solution, on its sample data. Pick one to see it large.
Which clock, from which event, to whom — and who decides — are settings, approved by the CIP Senior Manager.
| Setting | Default | Choose from |
|---|---|---|
| CIP-008-6 R4.2 · Reportable | 1 hour from determination | Counted on or off · to the sector ISAC and the national cyber agency |
| Water licence WL-7 | 24 hours from detection | Counted on or off · to the Calder Valley Water Commission, for water incidents |
| CIRCIA · covered incident | Off | 72 hours from reasonable belief, counted once the final rule is in force |
| Determination target | 60 min | Set in minutes from detection, per IRP-OT-01 §2.3 |
| Page the incident commander if not escalated | 10 min | Set in minutes, per IRP-OT-01 §4.1 |
| Reminders before a deadline | 20 min, then 10 min | Set in minutes · first to the incident commander and deputy, second also to the CIP Senior Manager |
| Offline copy on the control-room terminal | On | On · Off — plan, playbooks and drawings, refreshed at every approval |
| Agents may send commands to OT systems | Never | Read-only by design; containment is done by a person |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
“demo” = seen in the working solution, on its sample data · “target” = the design goal, measured in the live solution · “estimated” = our estimate, except the 22 and 31 minutes, which are the demo utility's own tabletop figures · “typical” = published figures (SANS OT response planning guidance — about 50 % without an ICS/OT-dedicated plan; Dragos 2026 OT Cybersecurity Year in Review — 82 % and 73 %). Regulatory context: NERC CIP-008-6, Table R4; CIRCIA is not yet in force. Lumina Utilities and the people, sites, vendors, systems and incidents named on this page are fictional — characters and sample data in the working solution.
Software that puts a utility's OT incident response plan, playbooks, zone drawings, vendor contracts and reporting rules behind one question at the moment of an incident. In OT Incident Response a responder types what is happening, the right playbook opens at the right step with every instruction quoted, and the reporting clock the rules choose runs beside it. The incident commander decides every branch and signs.
The playbook navigator shows your approved playbook as its own decision tree, with the current step lit and quoted word for word from its page. A branch moves only when a person answers it, and each answer writes the timeline. In the sample case PB-OT-04 has nine steps, from confirming the source to lessons learned.
CIP-008-6 sets the initial notification at one hour after the determination of a Reportable Cyber Security Incident, by the end of the next calendar day for an attempt to compromise, and an update within 7 calendar days of new information. The clock keeper starts each clock at the event its rule names, from the time the incident commander records, and the notice is drafted from the timeline with the three attributes Part 4.1 asks for.
No. The agents are read-only towards OT: none can send a command to a control system, a firewall or an account. The zone and asset resolver shows the conduit, the rule and the customers behind each RTU, and a person carries out the containment and records it.
Yes. Each incident's facts choose its clocks. In the sample, failed logins on a Westbrook water works HMI run on the water licence's 24-hour clock from detection under playbook PB-OT-08, while the Northgate incident runs on CIP-008-6.
Yes. The incident commander answers every branch, makes the determination and signs every notification; the settings mark these “person only”. Agents never send a notice, never page anyone outside the plan's on-call list, and never edit a signed timeline entry.
Yes — the answers come only from your approved documents. Which rules apply, when each clock starts, the determination target, escalation and reminder times, the offline copy and who decides and signs are all settings, and every change is a new version approved by your CIP Senior Manager.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your OT incident response plan, playbooks, zone drawings, vendor contracts and reporting rules — and it goes live once every quality gate has passed. We will walk you through it first on a tabletop scenario of your own.
Audit binders built continuously, not in a 30-day scramble.
1-min demoThird-Party Cyber Risk ManagementEvery supplier answer checked against its evidence before you sign.
1-min demoOT Patch ManagementEvery OT patch evaluated inside the 35-day window, with a dated plan if it must wait.
1-min demoWe'll run OT Incident Response on your own response plan, playbooks and drawings, against a tabletop scenario you choose.