DNV's OT playbooks need physical-action authority
DNV says industrial incident plans can require manual plant actions and must include domain experts and decision authority. A usable playbook therefore has to bind each cyber scenario to the physical action, operating constraints, authorized decision maker, execution evidence, and return-to-service proof.
Editorial figure by OT Defense Review. Source context: DNV Cyber OT risk-reduction and incident-response guidance.
Bind the playbook to physical action and accountable authority
| Playbook object | Minimum retained evidence | What it does not establish |
|---|---|---|
| Scenario and equipment under control | Scenario version, affected service, assets, process function, topology, initiating evidence, consequence hypothesis | That the scenario occurred, that every asset is known, or that the worst consequence is probable |
| Physical action | Named valve, breaker, bypass, isolation, manual mode, shutdown, repair, or other action; prerequisites and prohibited states | That the action is safe, feasible, authorized, or sufficient in the current plant state |
| Decision authority | Accountable role, consultation path, escalation threshold, shift coverage, delegation and unavailable-person fallback | That a cyber alert, severity score, or playbook step grants operating authority |
| Execution and observation | Actor, timestamp, command or field action, permit or work record, plant state, alarms, measurements, exceptions | That the expected physical effect occurred or that independent barriers remained effective |
| Recovery and closure | Return-to-service criteria, verification owner, restored configuration and process state, unresolved restrictions, approval | That ticket closure proves safe recovery, security containment, compliance, or absence of latent damage |
Source basis: [1]
Start with the equipment and consequence, not the alert label
DNV's three-step guidance begins with topology and inventory, then asks what the equipment under control actually does. That distinction matters because a server, controller, transmitter, switch, or workstation is not the operating consequence. The same technical observation can mean something different when it affects cooling, pressure control, power transfer, material handling, transportation, or a safety-supporting function. [1]
Create a scenario record that links the cyber observation to asset identity, software and configuration, network path, controlled equipment, process function, operating mode, independent safety barriers, dependencies, credible physical consequences, and uncertainty. Preserve the IT and process evidence separately but connect them through governed identifiers. A topology diagram or current inventory does not prove completeness, consequence, or exploitability.
Name physical-action authority before an incident
DNV notes that industrial response may include manual actions such as operating valves and that coordination with industrial operations belongs in the playbook. Translate that principle into explicit authority. For each action, name who can propose it, who evaluates process and safety constraints, who authorizes it, who performs it, who observes its effect, and who can stop or reverse it. Include shift, site, contractor, and unavailable-person contingencies. [1]
Keep cyber severity, engineering consequence, operating urgency, and action authority as different fields. A security analyst may establish a credible event without having authority to isolate equipment. An operator may have authority to place a unit in a safer mode without concluding that a cyber incident caused the condition. A playbook should route those judgments together without collapsing them into one status.
Exercise execution, degraded operation, and return to service
A tabletop that ends when the team chooses an action does not test the hard boundary. Use an authorized representative scenario to trace detection, domain-expert review, decision, permit or work control, field communication, physical action, process observation, cyber containment, degraded operation, restoration, independent verification, and closure. Record timing, failed contacts, missing evidence, rejected options, unsafe prerequisites, manual workarounds, and unresolved restrictions.
Test cases should include a stale inventory identity, unavailable historian data, an action that cannot be performed in the current mode, a safety barrier already impaired, a contractor needed after hours, loss of ordinary communications, an action that succeeds technically but changes production quality, and a cyber system restored before the physical process is ready. The retained record should show why the team moved—or refused to move—to each next state.
Keep official guidance and site proof separate
DNV's article supports the attributed three-step method: know the OT and the equipment it controls, collaborate with physical-domain experts, and plan responses with industrial context, including physical actions and decision authority. It does not establish any reader's inventory, topology, hazard analysis, barrier health, incident, response capability, exercise result, authority model, recovery, safety outcome, or security outcome. [1]
OT Defense Review reviewed the exact registered DNV page on October 2, 2026. The full source gate passed 71 of 73 normalized URLs and all 14 critical URLs; two unrelated ordinary sources remained unavailable. Because the gate preserves reachability rather than a complete comparable semantic snapshot from the October 1 cutoff, no material post-cutoff change is claimed. This is durable operating analysis, and current-intelligence coverage remains limited. [1]
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
OT Defense Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.