A ransomware note lands on an engineering workstation at a packaging plant at 02:40. By 06:00 the malware is contained, the screens are back, and the morning shift is at the gate. The site director wants one answer. Can we run?
The answer is awkward: who decides when to restart production after a cyber incident is never one person's judgement call, because it is four separate checks with four different owners, and the line should not move until each owner has answered and the answer sits on the record.
Who decides when to restart production after a cyber incident is not a matter of one opinion. A safe restart depends on four separate answers: containment, control integrity, process safety and product release. Each needs a named owner, and the line should not move until all four are closed.
What Does A Safe Restart After A Cyber Incident Actually Mean?
A safe restart means production resumes on equipment, settings and materials that someone has verified since the incident. Coming back online is not the same thing. A cyber incident can leave a recovered system running unverified logic, altered setpoints or a corrupted recipe while every screen in the control room looks entirely normal.
That gap between available and verified is where most restart arguments start. The IT team reports that systems are restored. True, and a different claim from the one the plant manager needs. Restoration is about services. A restart is about whether this process, on this equipment, with this material, is safe to run and safe to sell. Which is why who decides when to restart production after a cyber incident cannot be answered by the team that restored the systems. Reaching the people who can answer it is a problem of its own, and one we covered in a piece on alerting the plant floor when the network is down.
Why Does The Restart Decision Go Wrong On The Shop Floor?
The restart decision goes wrong because the pressure to run arrives long before the evidence does. Every hour of stoppage carries a number. Customers and hauliers are waiting. The systems look normal again. All three pressures are legitimate. None of them tells you whether the line is safe to start.
Who decides when to restart production after a cyber incident is rarely written down anywhere, and that absence is how three patterns take hold. They show up again and again when a restart is reviewed afterwards:
- A single voice decides. Whoever is most senior in the room says go, and no record exists of what that was based on
- The checks happen but nobody owns them. Four people each assume somebody else confirmed containment
- The decision is verbal. Six weeks later an insurer or a regulator asks what the restart was based on, and there is nothing to show them
None of those three is a technical failure. They are coordination failures. The plant usually has the expertise it needs already on site. What it lacks is an agreed way of turning that expertise into one decision with a name against it.
Who Decides When To Restart Production After A Cyber Incident?
Who decides when to restart production after a cyber incident should be settled by four named owners, each answering one question: the security lead on containment, the operational technology and engineering lead on control integrity, the HSE lead with the plant manager on process safety, and the quality lead on product release. One person, usually the plant manager or site director, then makes the call on those four answers.
Splitting the decision this way does two things. No single function gets asked a question it cannot answer. And the restart becomes auditable, because every answer carries an owner and a time.
The table below sets out who decides when to restart production after a cyber incident, check by check, together with what counts as an answer rather than an assurance.
| The check | Who owns the answer | What counts as an answer |
|---|---|---|
| Containment | Security lead | A clean scan of the affected segment since the incident started, plus evidence the access route is closed |
| Control integrity | Operational technology and engineering lead | Running logic and setpoints compared against a known-good copy, with the differences explained |
| Process safety | HSE lead with the plant manager | Interlocks and instruments confirmed, and a start-up sequence agreed for a process that has been down |
| Product release | Quality lead | Material made inside the incident window quarantined or tested, with a documented result |
The four checks do not have to run in sequence. On a well-rehearsed site they overlap. What matters is that all four are closed before the line moves, and that whoever makes the final call knows which of the four is still open.
What Is The Restart Decision After An OT Cyber Incident Based On?
The restart decision after an OT cyber incident is based on verification. Reassurance is not enough. For each of the four checks, the owner needs a positive result from something they looked at after the incident started: a clean scan of the affected segment, a comparison of running logic against a known-good copy, a confirmed instrument calibration, a sample result. "We have seen nothing unusual" is an absence of evidence. It should never close a check.
Operational technology is why the restart question is harder in a plant than in an office. The NIST Guide to Operational Technology (OT) Security, published as Special Publication 800-82 Revision 3 in September 2023, sets out recommended security countermeasures for these environments because OT carries risks general IT guidance does not address: equipment you cannot simply reboot, physical processes with safety consequences, and long-lived controllers that hold state.
NIST revised its incident handling guidance in April 2025. Special Publication 800-61 Revision 3 treats incident response as part of continuous cybersecurity risk management instead of a standalone activity, and organises its recommendations around the Cybersecurity Framework 2.0 functions, recovery among them. For a plant the reading is simple. Recovery decisions belong inside the same governance as everything else, with owners, evidence and review, not improvised at 06:00.
What Does Not Count As Evidence
- The screens being back, which tells you the HMI is running and nothing about what it is running
- A vendor's verbal assurance with no test behind it
- A clean result from before the incident window
- Silence from a team nobody asked
Which Plant Incident Command Roles Need Naming Before The Shutdown?
The plant incident command roles that need naming in advance are the four check owners, the single decision maker, a deputy for each, and one person responsible for the record. Naming them during an incident costs time nobody has. A night shift also rarely holds the same people the plan assumes, which is why the deputies matter more than the primary names.
Notification sits alongside the restart decision rather than inside it, and it needs its own owner. Duties vary by sector and by country, so confirm yours on a quiet day. In the United Kingdom, for example, Regulation 11 of the Network and Information Systems Regulations 2018 places a duty on operators of essential services to notify their competent authority in writing of an incident that significantly affects service continuity "without undue delay and in any event no later than 72 hours after the operator is aware that a NIS incident has occurred". Whether your site sits inside that regime, an equivalent one elsewhere, or neither, is worth settling before you need the answer. Treat this as orientation and not legal advice: check your own obligations with your regulator and your advisers.
Before the line moves, the list of people who need telling is usually wider than anyone expects. Everyone on shift, contractors included. Customers waiting on affected orders. The regulators and insurers your own obligations cover. Leadership. That list belongs in the plan too, with a named owner.
How Does Crises Control Support The Restart Decision?
Crises Control holds the structure around the restart decision, so the four checks, the people who own them and the record of what was answered all sit in one place instead of in a phone tree and someone's notebook. Crises Control is an Operational Incident Coordination Platform. A restart is a coordination problem before it is a technical one.
For a restart the relevant module is Incident Manager, described on the Incident Management Software page. It gives a live incident workspace for monitoring incident status, response activities and operational progress in real time. An authorised user can launch a predefined response plan, structured communications go out to predefined recipient groups from approved templates, and an operational timeline keeps a chronological record of communications, updates and decisions. The manufacturing incident management pages describe the same platform recording every alert, acknowledgement, task and decision automatically.
The actions each check generates are tracked separately, through Incident Task Management Software, so "verify the logic against the known-good copy" becomes an assigned task with a completion state instead of a verbal commitment. Where a cyber event spans plant and corporate systems, this is the point it joins up with Incident Response Software handling the IT side of the same incident.
What the platform does not do is make the four judgements. It cannot decide that a segment is contained, that a controller can be trusted, that a process is safe, or that a batch can be released. Those stay with the named people, who need the technical evidence in front of them. The software reaches them, routes the questions, records the answers with a time against them, and produces the account afterwards. Who decides when to restart production after a cyber incident is still a human decision. What changes is that it becomes structured and visible, with evidence behind it.
Safe Restart Checklist
Use this as the test of whether your site could answer who decides when to restart production after a cyber incident tomorrow morning, without calling a meeting.
- Four checks written down: containment, control integrity, process safety, product release
- An owner and a deputy named against each check, tested against a night shift
- One named final decision maker, agreed before any shutdown
- A definition of acceptable evidence for each check, so "nothing unusual" cannot close one
- A notification owner, with your own sector and country duties confirmed in advance
- A communication list covering contractors, affected customers, the regulators and insurers your obligations require, and leadership
- A record of each answer, who gave it and when, captured while the incident runs instead of reconstructed later
- The restart rehearsed at least once, so the first time is not during a live event
Agree The Restart Rules While The Line Is Still Running
The restart after a cyber incident is where operational pressure, safety duties and commercial reality all meet at once, and it is a poor moment to be working out who is allowed to say yes. Sites that handle it well have not found a faster way to verify a control system. They have agreed, on an ordinary Tuesday, who decides when to restart production after a cyber incident: which four questions must be answered, who answers each one, who makes the final call, and where the answers are written down.
That agreement costs an afternoon. Skip it, and the decision falls to whoever is most senior in the room, the evidence behind it goes unrecorded, and the account you give an insurer or a regulator months later is assembled from memory. To see what structured coordination and a defensible record look like against your own restart plan, request a demo and bring the plan with you.
Frequently Asked Questions
Who decides when to restart production after a cyber incident?
One named decision maker, usually the plant manager or site director, makes the final call, but only on the back of four separate confirmations. The security lead confirms containment, the operational technology and engineering lead confirms control integrity, the HSE lead and plant manager confirm process safety, and the quality lead confirms product release. Naming all five people before a shutdown is what makes the decision workable.
What is the difference between systems being restored and production being safe to restart?
Restoration means the services and screens are available again. A safe restart means the process, equipment and materials have been verified since the incident. A recovered system can run unverified logic or altered setpoints while every display looks normal. Restoration is an information technology milestone, and the restart is an operational and safety decision that sits on top of it.
How long should a restart decision take after an OT cyber incident?
There is no single answer, because it depends on how much of the operational technology estate was affected and what evidence each check requires. The decision takes as long as the slowest of the four checks, which is why running them in parallel with named owners beats running them in sequence through one person. Rehearsing the sequence is the only reliable way to learn your own realistic timeframe.
What record should we keep of the restart decision?
Keep each of the four answers, the name of the person who gave it, the evidence it rested on and the time it was given, plus the final decision and who made it. A record captured while the incident runs is defensible in a way that one reconstructed from memory weeks later is not. Incident Reporting Software produces that record as a by-product of the response instead of as a separate write-up afterwards.
Do we have to tell a regulator before restarting production?
Notification duties and restart decisions are separate obligations, and which regulators you must tell depends on your sector and the countries you operate in. Notification deadlines run from the point you become aware of the incident, not from the point you restart, so waiting for a restart decision can put a reporting duty at risk. Confirm your own duties with your competent authority in advance and give the notification its own named owner.
This article was drafted with AI assistance and reviewed by the Crises Control team. Featured image: AI-generated.
