Gather the Inputs

What Documents Cannot Tell You

Discovery is the second gate of the plan project, and it covers the inputs and the interviews. Drawings, inventories and procedures show you the official plant. Interviews show you the working plant: who really gets called at two in the morning, which workarounds exist and who knows them, which systems the plant cannot run without, and where people disagree. Every question you ask should pass one test. Its answer should land in a plan chapter. If it cannot, it was the wrong question. This chapter collects the inputs the rest of the plan stands on. It starts with the interviews, moves through the critical functions and their dependencies, chooses the scenarios the plan must handle, gathers the safe states and the plans the site already has, and ends with a real incident that shows why every one of those inputs matters.

Discovery Interviews

The interview method used here was written for security awareness programs. Cybersecurity All-in-One For Dummies, by Steinberg and co-authors, describes it, and most of it carries over to a plant. Give each person about thirty minutes. Interview the executives early, because their visible support opens doors. Ask everyone a common core of questions, then questions for their role. Keep asking why. Never treat one person's answer as the truth, and keep the window short, about two weeks. One thing does not carry over: that method's list of interviewees has no operations role at all. For a plant, operations is the centre of the list. Start from the planning roster and go wider, because the roster names seats while discovery needs the people who hold the facts, on every shift. Add a lead operator from day shift and one from nights, the roving operator who walks the remote sites at night, maintenance planning, and the instrument and electrical lead. Ask the integrator for the field engineer who would actually come out, not the account manager. Add whoever handles emergency purchases, and the union representative where an agreement covers call-out.

Run discovery in four waves. Wave one is the sponsor and the plant manager. Wave two is operations across every shift. Wave three is engineering, safety and maintenance. Wave four is outside parties and support functions. As this book's planning figure rather than a benchmark, expect twelve to twenty interviews over two to four weeks at a mid-size plant. The awareness method says new information tails off after about ten interviews; in a plant, knowledge is spread across shifts, so you need more. Hold each interview where the work happens. The control room or the workshop beats a meeting room, and walking the panel while asking "show me what you would do" gets answers no meeting room produces. Never interview during startup, shutdown or a turnaround. Go to the night shift at their hours rather than asking them to come in on days. Check the overtime rules and any collective agreement first, and put the overtime cost in the charter budget so nobody is surprised by the bill.

Every interview follows the same thirty-minute shape. The first five minutes set context: what the plan is for, that this is not an audit, and how the answers will be used. Twenty minutes go to questions. The last five ask who else you should talk to and what you did not ask. Then take ten minutes alone to write the log entries while the conversation is still fresh; notes written the next morning lose the detail that mattered. Seven core questions go to every person, whatever their role, and each targets a plan chapter. The two-in-the-morning call shows your real escalation path. What you cannot run without feeds the planning inputs. Losing the screens, or seeing without being able to control, gives you time-to-harm, how long before the loss causes real harm. The shutdown question tests decision rights. Asking whether the vendor's number is on paper is a readiness check. The last question finds the actions people want pre-authorized. After the core questions, add one role module. Operations is asked about going to manual and who gives orders at night, which feeds the inputs, command and procedures chapters. Control engineering is asked which system only one person really understands. Procurement is asked who can buy a replacement switch at three in the morning, and up to what amount. Legal is asked what must never be written in a log. Pick the module before you walk in.

The first answer is rarely the useful one, so ask why, and then ask why again. A typical exchange: I would call the integrator. Why? Only they have the PLC passwords. Why? The contract never handed them over. Three answers in, you have found a recovery dependency and a contract gap that no drawing or procedure would have shown you. Stop digging when the answer names a document, a contract or a decision someone must make.

One Log for Everything You Hear

Every answer goes into one findings log, and every entry gets one of five types: a fact, a decision needed, a gap, a conflict between two people, or an action. The type letter starts the ID, so F-01 is a fact and C-03 is a conflict, and later worksheets cite those IDs as their source. Each entry also gets a plan chapter and an owner. Record the source as a role, not a name, when the finding is sensitive. At Cedar Ridge, the illustrative water treatment plant used throughout this book, one night-shift interview produced a typical spread. The first finding was a fact: radio is the backup to the four remote booster pump stations when cellular telemetry fails, logged as F-01 against the planning inputs chapter. The next was a gap: the only integrator number on paper was the sales line, on an old sticker, with no paper copy of the 24/7 support number. That became G-01, and the fix got its own entry, an action A-01 owned by the operations supervisor. Then came a decision needed. The operator would put dosing on manual himself, but taking chlorine off is a different call, and he did not know whose it is at night. You do not answer that in the log. Entry D-01 is marked for the sponsor, with a decide-by date. The last entry was the conflict from the opening of this chapter: day shift says only the superintendent can stop the plant, night shift says nobody, he would just do it. Both roles go in the source column, the superintendent owns the entry, and the sponsor decides.

Filter the log to the rows that need a sponsor decision and that short list becomes the sponsor's agenda, feeding straight into the decisions box on the charter. This is why conflicts are the best findings. Two people who each believe they hold the shutdown call have handed you a plan decision that is waiting to be made. Resist settling it yourself; you do not hold that authority. Log both answers, mark the entry for the sponsor, and give it a date. Be careful about what you write down at all. Anything you write may later be read by people you did not write it for, so record roles and facts, never opinions about colleagues, and keep your raw notes out of the shared log. Ask legal once, at the very start, how discovery notes should be handled, because written records can be demanded in later legal proceedings. Close each interview with one more question: is there anything you would not want the plan to say? The answer can show you where the politics are. Interviews also do a job that never shows up in the log: they build allies. A night-shift lead operator who was asked, heard, and later shown how the answers were used has a stake in the plan, and defends it when someone calls it paperwork. The Cedar Ridge example log in Appendix A was built from fourteen interviews and holds twenty-seven entries.

Critical Functions and the OT Business Impact Analysis

NIST's public template for a business impact analysis was written for federal IT systems. Copy it for a plant and you get a list of servers, and the plant does not care about servers. Try a different question: if the historian server died tonight, what would actually stop at your site, and when? If your answer names a process and a time, you have started an OT business impact analysis. A critical function is an outcome your site must keep delivering: disinfecting water, holding distribution pressure, protecting a feeder, controlling a reactor's temperature. NIST SP 800-82 revision 3 makes the key point in its incident response guidance: a response plan should be judged against the service being delivered, not only the system that was hit. NIST's contingency planning guide, SP 800-34, already describes a process-focused version of the analysis. So start from functions and map down to systems, never the other way round.

The business impact analysis is not yours. It belongs to the business continuity owner or to operations, and it may already exist for floods, fires and power loss. Your job is narrower: collect the inputs, propose the numbers, and get them set by the people who own them. The response plan then refers to that analysis instead of copying it. If your site has an IT-only version, extend it with process functions, because a rival document splits the truth in two. Sources disagree on who sets these numbers; at least one incident response book has the plan author choose the recovery values. This book takes a different line. The plan writer collects the inputs and proposes; the analysis owner and operations set the numbers; the sponsor approves them. A number you invented alone is a number nobody will defend at three in the morning.

NIST's contingency guide gives the analysis three steps: identify the processes and how badly an outage hurts them; identify the resources each one needs; and set recovery priorities. The plant version keeps the steps and changes the subject, an adaptation of NIST by this book. Step one becomes the function and its consequence over time. Step two becomes resources and dependencies. Step three becomes a proposed recovery order. For step one, pull the list of critical functions from four places: the scope statement tells you which units are in, the findings log holds what people said they could not run without, and the process description and the piping and instrumentation diagrams fill in the rest. Aim for five to twelve functions at a mid-size site, not sixty; that is this book's planning figure, not a published benchmark. Then test each candidate: if it stopped, would someone outside the control room notice within a day?

A cyber incident breaks a function in three different ways, and each gets its own entry. Loss of view means the process runs, but operators cannot see it. Loss of control means they can see it, but cannot change it. Loss of trust means everything looks normal, and nobody can be sure the values or the logic are true. Operators can often run blind for a while; they rarely last long without control; and loss of trust can last a long time, because restored systems must be proven before anyone believes them. For each function, score what happens at one hour, eight hours, a day and three days, using the consequence rows of your site's own risk matrix, for example safety, environment, service, regulatory, and cost and reputation. If your site has no matrix, start from the generic rows on the worksheet's Scale tab. Use a scale from zero to three, written in plant language: "boil-water advisory issued" says far more than "high." The bands come from the same matrix, so zero to three maps onto severity S1 to S4, where S4 is the most severe. Agree the scale with the analysis owner before anyone scores.

Time-to-harm is the single most useful number you will collect: how long after the failure real harm begins. Record it twice, once for loss of view and once for loss of control, because the two are rarely the same. Time-to-harm is this book's working term for an input; the recovery chapter later turns these inputs into formal recovery objectives. At Cedar Ridge, disinfection shows why one downtime figure would hide the truth. Lose control and residual chlorine falls toward a boil-water advisory within hours; go blind, and operators read residual by hand every thirty minutes; lose trust, and residuals may look normal while dosing is wrong, the cell a server list never asks for. Loss of view gets twenty-four hours, because operators can read residuals by hand; loss of control gets four. Manual endurance, how long operators can run it by hand, is seventy-two hours with two call-in operators per shift. Scored over time, public health and service both reach band three, severity S4, within a day.

Step two asks what each function needs to keep running, or to come back: control system components and the drawings that describe them; people with rare skills, like the retired engineer who still understands the old control system; vendor support and the contract behind it; spares, project files and licences; manual-operation equipment such as local panels, radios and handheld meters; and utilities. Extract these from the asset inventory rather than copying it. ISA/IEC 62443-2-1, 2024 edition, already requires that inventory, and its guidance includes third-party assets. A function also depends on far more than its control system. Inside the fence sit the network core, time sync, domain services and the historian. Outside the fence but inside the company sit business systems, the lab system and chemical ordering. Outside the company sit the telemetry carrier, the power supply and key suppliers. Then record the other direction: the hospital, the fire department and the customers downstream all depend on you. A dependency register that only looks one way misses half the picture. Step three proposes a recovery order, set by time-to-harm and by dependency. The services everything else needs come first: network core and time sync before the operator screens, operator screens before the historian. Write one line of reasoning for each position, because someone will challenge it, and remember that the list is a proposal for the analysis owner and operations, not a decision you get to make.

Expect the same kinds of gaps to surface everywhere: a function with no manual workaround, one person holding a critical skill, a vendor with no out-of-hours contract, a dependency nobody owns. At Cedar Ridge the city domain controller had no documented workaround, because the operator screens log on through it, and the integrator's on-site support was best efforts, next business day. Log each gap with an owner. The plan records the gap; fixing it is a project for that owner, not a paragraph in your plan. Now the historian question has an answer in process language: Cedar Ridge keeps treating water, manual log sheets cover the gap for up to three days, and compliance reporting is at risk after twenty-four hours. That answer names a function, a failure mode and a time, and every recovery decision the plan makes later stands on rows like it. In the plan template, this worksheet fills the planning inputs chapter's sections on critical functions and dependencies.

Choosing the Scenarios: Consequence First

How did the scenarios in your current plan get there? Sometimes the answer is that someone read about an attack and wrote a section for it, and the plan ends up ready for last year's headline rather than for the outcome your plant cannot bear. There are two ways to choose scenarios. Threat-first starts with attackers and techniques and asks what they could do to you. Consequence-first starts with the outcomes your site cannot tolerate and asks whether cyber means could produce them. A good plan uses both, with consequence-first going first, because it starts from the worst outcomes instead of hoping they turn up. Threat-first lists are long, and the outcomes that matter most can still be missing.

The consequence-first idea comes from Idaho National Laboratory's Consequence-driven Cyber-informed Engineering, or CCE, which has four phases: consequence prioritization, system-of-systems analysis, consequence-based targeting, and mitigations and protections. CCE assumes the adversary already has access, knows the process and is well resourced. It is a design and mitigation method, not an incident response method, but its first phase produces a ranked list of high-consequence events, and that is the strongest scenario list an OT plan can start from. Paraphrasing the laboratory's definition, a high-consequence event is a physical event, achievable through cyber means, that would seriously hamper delivery of your critical functions. Every candidate faces two tests: does it hit a critical function from your impact analysis, and could cyber means actually cause it? If either answer is no, it does not belong on this list. The function list you already built is the yardstick; without it, "high consequence" has nothing to be measured against.

A full CCE engagement is large and facilitated. For a response plan, run a lighter version, inspired by CCE but not CCE itself, in five steps: agree the boundary, reusing the boundary sentence from your scope statement; brainstorm disruptive events; screen out events that cyber means cannot cause; describe in outline how each remaining event could happen; then score severity on criteria your site defines. Many candidate events go in; three to seven high-consequence events come out, which is this book's planning figure rather than a benchmark. Book two to three hours with operations, process safety and control engineering, plus whoever knows your OT network. The laboratory is clear that recognizing these events takes engineering knowledge and cyber knowledge together. A security team alone can invent attacks the process cannot suffer; engineers alone can dismiss attacks they have never seen. Hold the session after the function list is agreed, so nobody argues about what matters.

The brainstorm step hides the cleverest idea in the method. The laboratory tells teams to include events caused by human error, engineering failures and natural disasters, which makes your plant's own history the richest source. At Cedar Ridge, three past events seeded the list: a stuck chemical valve, a storm that cut telemetry, and a high-lift pump trip. For each one, ask a single question: if this happened by accident, could someone cause it on purpose? The findings log may already hold these stories; at Cedar Ridge it held all three. The cyber screen removes events, and the removals teach you something too. A chlorine gas leak from storage scored the highest severity and was still screened out, because the cylinder valves are manual, so no cyber path exists, and the emergency response plan already covers it. A storm power outage went the same way and became a row on the dependencies list instead. Screened-out events are not wasted; they show the other plans what they own and keep yours focused on what only it can handle. For scoring, the laboratory's electric-sector example rates criteria such as area affected, duration, safety, system integrity confidence and cost, with weights. Do not copy those weights. Let your site define its criteria, reuse the zero-to-three scale from your impact analysis so both worksheets speak one language, and keep system integrity confidence, which flags where the plant cannot simply restore and trust the result. When scores differ, record the disagreement and how the room settled it.

Cedar Ridge screened twelve candidate events and kept four: chemical overfeed into the treated water; disinfection silently lost while the operator screens show normal values; a pressure transient in distribution from pump manipulation; and loss of all telemetry to the booster pump stations during high demand. Each scored three, the top of the scale. The silent disinfection loss started at two; operations raised it after the room discussed its four-hour time-to-harm, and that note in the disagreement column is worth more than the score itself.

Consequence-first ignores likelihood, which is its strength and its blind spot. ISA/IEC 62443-2-1, 2024 edition, takes the risk-based route: its guidance talks about developing attack scenarios and ranking their consequences, and points to ISA/IEC 62443-3-2 for the assessment. So a second pass adds the likely, everyday events: office ransomware that prompts a precautionary OT shutdown, a vendor's remote access account used by someone else, infected media plugged into an engineering workstation, a shared company service going dark. Do not run a new risk assessment for the plan; your site may already hold several, and each is a source of scenarios. An ISA/IEC 62443-3-2 zone and conduit assessment is one. In the United States, a community water system serving more than 3,300 people must complete a risk and resilience assessment. In the EU, NIS2 Article 21 requires policies on risk analysis. Australia's critical infrastructure risk management program identifies material hazards, and Canadian pipelines may follow the CSA Z246.1 security management standard. Read these first and copy the scenarios they already name into your list, with "risk assessment" as the source.

Both passes land on one merged list. Every row records where the scenario came from, so nobody later asks why it is there; the failure mode, reusing lost, blind or untrustworthy; severity from S1 to S4; and three fields that turn the list into work: does the scenario need a playbook, how urgent is it, and who owns it, by role. Every high-consequence event must be covered by a playbook. Everyday scenarios get one when they are likely, or when the response differs from the generic procedure. Covered does not mean one each. At Cedar Ridge, three of the four events share one playbook, for an unexplained setpoint, mode or logic change, because operators see the symptom, not the attacker's goal. Write playbooks around what the control room will notice. A plan that tries to cover forty scenarios covers none of them: nobody maintains forty playbooks, and nobody finds the right one at two in the morning. Aim for six to ten scenarios with perhaps four to six playbooks, again this book's planning estimate. Cedar Ridge ended with eight scenarios and five playbooks, and three scenarios stayed on the list without a playbook: infected removable media, a lost city service and a supplier outage, all covered by the generic procedure. Choosing scenarios for the plan is not the same as writing scenarios for an exercise, which add storylines, timed injects and escalation; keep this list short and factual, one line per scenario. It becomes the plan's section on scenarios to plan for, the ranked playbook backlog, and the scenarios for the walk-through that validates the draft.

Safe States and Manual Operation

Most plants already have written procedures for losing control. They were written for failures that were not cyber, and an incident response plan should point to them rather than rewrite them. Your job here is not to invent safe states; it is to find them, check them and point to them. The safe state comes from the process engineers and operations, not from the security team, and the plan writer collects it. ISA/IEC 62443-2-1, 2024 edition, requires one: the asset owner needs procedures for bringing the control system to "a predetermined state if normal operation cannot be maintained as a result of a detected security compromise." For a writer, the key word is predetermined. Either it already exists, or it gets agreed before the plan is approved. Read before you interview anyone, so the conversation confirms rather than starts from zero: the emergency shutdown procedures, the loss-of-SCADA or loss-of-DCS procedures, the power-failure procedures, the cause-and-effect charts, the HAZOP or process hazard analysis, and the alarm response procedures. Then ask the same six questions of each process unit, unit by unit rather than plant-wide:

1. What is the safe state for this unit?
2. Who may command it, and who is the backup on nights?
3. Can it be reached without the HMI or DCS? How, exactly?
4. How long can it run in manual, and with how many extra people per shift?
5. What forces a shutdown, such as a lost safety system or analyser?
6. Which existing procedure already covers this, by number?

The questions go to the process engineers and to operations, in one room where you can; if their answers differ, the difference is a finding for your log. "Just go to manual" is not an answer. Ask which local panel, which radios and which handheld meters, then go and look with the operator beside you. At Cedar Ridge, chlorine dosing goes to manual at local panel LP-CHEM in the chemical building. A safe state that can only be reached from the HMI is a finding, not a fact. Manual endurance has two parts, hours and people; record both and check the people against the call-out roster. Dosing holds for seventy-two hours with two call-in operators per shift, a figure that must match the manual endurance column on the critical function worksheet. Sometimes the honest answer to how long it can run in manual is that nobody knows, because no current crew has done it. Record that exactly as given and log it as a gap, with an owner, for the exercises that test the finished plan. At Cedar Ridge, Crew D, one of four crews, had not run dosing by hand in the last year, and that became finding G-08. Throughout, the plan points to procedure numbers and never copies procedure steps, which go out of date when the procedure is revised. It adds only what the procedure lacks: the cyber trigger that should start it, and who may invoke it for a cyber reason. Cedar Ridge has no process engineer, so the superintendent signs each safe-state row, as the holder of change approval under the site's management-of-change process.

The Plans You Already Have

The second half of the job is the plans your site already holds. List every plan a disruption can activate: the emergency response or emergency action plan; business continuity and disaster recovery; crisis management and crisis communications; the site security plan; process safety elements such as management of change, pre-startup safety review and incident investigation; the enterprise IT incident response plan; vendor contracts; and the insurance policy. NIST guidance points the same way: SP 800-82 tells organizations to consider leveraging existing plans, and SP 800-34 asks for coordination with related plans. Each plan gets one row, and the columns are what you need at the moment of hand-off. The activation trigger is the observable condition that starts the plan, not a vague category. The hand-off contact is who you call to activate it, at any hour; then dial it. At Cedar Ridge the integrator contract's contact is its 24/7 support line, and the insurance policy's trigger is its notice condition. A US water system under AWIA has a row for its emergency response plan, which the Act requires to cover cybersecurity; check that element too.

The OT incident response plan is one member of a plan family, not the umbrella over it, and each seam has a condition that crosses it. People at risk sends the incident to the emergency response plan. An outage beyond the impact analysis tolerance brings in business continuity. Relocation or a mass rebuild calls the disaster recovery plan. Public, legal or multi-site impact goes to crisis management. A physical element goes to site security. Emergency configuration changes go to management of change. The inventory will surface gaps in plans you do not own. The availability guidance in ISA/IEC 62443-2-1 says business continuity and disaster recovery plans should address cyber attacks, and plan projects often find a continuity plan with no cyber scenario. Log each gap for that plan's owner, with a date, and do not rewrite another owner's plan inside yours. At Cedar Ridge the city continuity plan had no cyber scenario, and the finding went to the city emergency manager. The inventory also closes the loop with your scope statement, whose exclusions all pointed to other plans and owners; it now tests whether each pointer leads somewhere real. An exclusion that points to a plan nobody can find is a scope gap, and it goes back to the sponsor.

Your worksheets now assemble into the second chapter of the plan, Planning Inputs: the findings and decisions log first; then critical functions, consequences and dependencies; then the scenarios to plan for; then safe states, manual operation, and related plans with their hand-off contacts. Later chapters draw on these. Classification uses the impact scale and the seams; command uses the contacts; response and recovery use the safe states and manual windows; playbooks use the scenario list. The plan does not repeat what the plant already knows. It points to it precisely, and it flags what the plant does not know yet.

Case Study: Jaguar Land Rover, 2025

On Monday 1 September 2025, Jaguar Land Rover sent plant workers home and dealers found they could not register new cars. There is no public evidence that a single robot or controller was touched, and nothing could be built anyway. Before the story, separate what is known from what is only said. The company confirmed three things: it shut down its systems as its first response; production and retail were severely disrupted; and some data was affected, with regulators informed. A group calling itself Scattered Lapsus$ Hunters claimed the attack, but the company never named an attacker. Two stories about how the attackers got in circulated without verified sources. And there is no public evidence that control systems were compromised. The plants stopped because production depends on IT.

On 2 September the company described its first move in one sentence: "We took immediate action to mitigate its impact by proactively shutting down our systems." The UK plants at Solihull, Halewood, Wolverhampton and Castle Bromwich stopped. Dealers reportedly could not register cars or order parts, and workshops reported trouble with diagnostics and the electronic parts catalogue. Nothing public says the production lines themselves were damaged; the systems around them were switched off, and the lines waited. An impact analysis that listed only control systems would have missed what stopped these plants. A modern plant also depends on business services: enterprise resource planning, production scheduling, parts logistics, supplier ordering, quality systems and build data. Nothing public says whether this company had such an analysis, so do not judge it. Ask what a plan would need to know on day one: for each business service, can the plant run without it, and for how long?

Outside the company, a second clock was running. On 11 September the chair of a parliamentary committee wrote to the Chancellor warning that the disruption "may imminently pose very significant risks to cashflow" for suppliers. The production pause was extended to 24 September and then again to at least 1 October, and by 23 September the industry body SMMT was reported as estimating that about a quarter of parts suppliers had paused work or cut staff. The company's harm was lost revenue and cash; its suppliers felt harm while the plants were still dark. That pattern holds well beyond car making. Your site's time-to-harm is not the only clock that matters. A key supplier or contractor may hit its limit before you hit yours, and if it fails, your restart waits for it. That is why the dependency register has a direction column: record who you need, and also who needs you.

The company started building answers while systems were still down. On 22 September it signed a new two billion pound bridge facility; six days later the UK government announced a loan guarantee of up to one and a half billion pounds. As IT returned, the company significantly increased processing capacity for invoicing, and on 7 October it confirmed it had been "establishing a dedicated supplier help desk and implementing a manual payment system to settle outstanding invoices": a manual payment system, built during the incident. Two inputs come out of those weeks. The first is the manual workaround for each critical function: what it is, how much it can handle, how long it holds and who runs it. A workaround with no capacity figure is a hope. The second is one line of financial resilience: what your insurance covers and excludes, and how long the business can pay its bills at zero output. You are not doing finance here; log it as a finding for the finance owner, so somebody knows the answer before the incident.

The restart followed a clear order. IT came back from 25 September. Wholesale finance and invoicing came first, which the company said was to support cash generation, then the Global Parts Logistics Centre. From 8 October the engine plant and the Battery Assembly Centre restarted, then stamping, body and paint, then final assembly, and Halewood, the last plant, restarted vehicle production on 16 October. Read it as a dependency chain: the steps others depend on came back before the steps that depend on them. Someone had to decide that cash systems came before engines, and engines before final assembly, and the same thinking shaped the money: the supplier financing scheme began with suppliers "critical to the restart of production." That is a list you want before an incident, not one you build during it. Your worksheet already asks for half of it in the proposed recovery priority, with a reason for each position; mark the suppliers your restart cannot happen without as well. Shutting everything down was also a decision with a price tag: the company said it acted to mitigate the attack's impact, and the same decision started weeks of lost production. Whoever makes that call at your site needs numbers to weigh it, and the consequence-over-time scores supply them. Finally, when was the company back? Manufacturing restarted on 8 October, the last plant on 16 October, and production returned to normal levels only in mid-November. Three answers to one question, each true. A plan that says "recovered" without defining it invites an argument at the worst moment, so log your ramp-up assumptions and the minimum service level that counts as recovered; the recovery chapter owns the formal criteria.

Here is the bill, with every figure labelled by who said it. The company's own cyber costs came to about 260 million pounds over two quarters, excluding lost sales. The chief financial officer reportedly put lost output at about 50,000 vehicles. The Cyber Monitoring Centre, an independent body that rates cyber events, modelled the wider UK loss at about 1.9 billion pounds across more than 5,000 organisations, an estimate rather than an accounting figure. For your plan, the useful number is not the total; it is the cost of each day the plant cannot run. Even the Cyber Monitoring Centre could not say whether the control systems were hit, noting its estimate could be higher "if operational technology has been significantly impacted." For a plan writer, that uncertainty is the point. A plan that only imagines a compromised controller misses this incident. The control systems may be clean and the plant still cannot run, because production depends on IT. Use the story as a test of your own dependency list: list every system and service the plants were waiting for, add every outside party the wait was hurting, and check each one has a row, with needed-by entries where others depend on you. The team in this story had to build those answers in a crisis. Your worksheets ask for them on a calm Tuesday.

Standards for This Chapter

The standards, laws and guidance this chapter relies on, with what each asks of the planning inputs, as checked in October 2026.

What's Next

The plan now knows what the plant needs, what it cannot bear, how it can be run by hand and which other plans it must hand off to. What it does not yet have is a shared language for the moment something goes wrong: when an odd reading is just an event, when it becomes an incident, how serious it is, and what level of response it calls for. Chapter 3 builds those definitions and the classification scheme that turns the impact scale from this chapter into activation levels.

Reflect

• If you asked your day and night shifts who can stop the plant for a cyber reason, would you get the same answer, and where would the difference be written down?
• For your most critical function, what are the time-to-harm values for loss of view and loss of control, and who gave you those numbers?
• Which of your safe states can only be reached from the HMI, and when did a current crew last reach one by hand?
• Which outside parties depend on your site, and how long could they last if your plant stopped tonight?
• How did the scenarios in your current plan get there, and which outcome your plant cannot bear is missing from them?