When ransomware hits a factory, a refinery, or a power plant, the technology problem usually gets solved within hours, days, or sometimes weeks. The harder problem is deciding who has the authority to act while that technology problem is still unsolved. This is the real gap in most industrial ransomware incident response plans. Not the antivirus. Not the backups. The decision rights.

This article looks at what actually happens in the first hours of an industrial ransomware attack, using two real incidents as evidence, and offers a simple way for any leadership team to close that gap before their own version of this night arrives. Attacks on factories, plants, and pipelines are no longer rare events reserved for the news. They are a routine risk that every operations and security leader now has to plan for, and planning for the technology is only half the job.

The Problem Nobody Rehearses

Picture a control room at two in the morning. Screens go dark across two production lines. A ransom note appears on a workstation. The plant is technically still running, but nobody knows for how long, or how safely.

The people awake at that hour are rarely the people with the standing to make big calls. A shift engineer cannot authorize a full production stop. A duty manager cannot decide whether to talk to criminals. Everyone reaches for the incident response plan and finds that it tells them how to isolate a server, but not who is allowed to say stop.

Most companies spend their security budget on tools that detect and contain an attack. Far fewer spend any time deciding, in advance, who gets to make the human decisions once the attack is already inside. That gap is quiet on a normal day. It becomes very loud on the wrong night. This is not a rare scenario anymore. Ransomware continues to pose a recurring risk to industrial and critical infrastructure organizations worldwide. Industrial cybersecurity firm Dragos tracked 3,300 industrial organizations hit by ransomware in 2025, nearly double the 1,693 hit in 2024, as the number of active ransomware groups with OT reach grew 49 percent to 119. Manufacturing alone accounted for more than two-thirds of those victims. What varies from one company to the next is not whether this will happen, but how many minutes are lost simply working out who is in charge once it does.

Two Real Nights, Two Different Answers

On September 29, 2025, Asahi Group Holdings, the Japanese company behind Asahi Super Dry beer, detected a ransomware attack, later attributed to the Qilin ransomware group, that disrupted the systems it used to manage orders, shipments, and production. Production stopped across its thirty factories in Japan, and staff switched to taking orders by hand, on paper and by fax, just to keep some product moving. Asahi first described the incident publicly only as a system disruption and confirmed days later that it was a ransomware attack. Two months on, the company was still working to fully restore its systems, and it disclosed that the personal data of roughly 1.5 million customers, plus hundreds of thousands of employees, family members, and outside contacts, had been exposed. Asahi has estimated the attack cost it approximately JPY 5 billion (about US$31.4 million) in lost revenue.

A few months earlier, on June 5, 2025, United Natural Foods (UNFI), the primary distributor to Whole Foods and roughly thirty thousand other grocery stores across North America, detected unauthorized activity on its network and took its systems fully offline the next day. Orders that would normally move automatically had to be handled by phone and by hand across its distribution centers, and shelves went empty in some stores within days. UNFI restored its core electronic ordering systems around June 16 and reported a broader return to normal operating capacity by June 26, roughly three weeks after the shutdown, publishing a dated update to customers and suppliers every few days along the way. The company later told investors the incident could cost up to US$400 million in lost sales and would dent that quarter’s earnings.

Both companies made the same first move: stop, then work out the damage. The real difference showed up in what happened next. UNFI’s updates were frequent, specific, and easy to follow, so customers always knew roughly where things stood. Asahi’s early messaging was vaguer, and outsiders had to assemble the full picture from later disclosures and press reporting. Neither outcome was a technology failure. Both were decisions, made by specific people, about how much to say and how soon to say it.

Neither company had a perfect night. What separated them was not the scale of the damage but how clearly, and how quickly, someone with real authority decided what the world outside would be told.

Why the Confusion Happens

Most organizations are not short of incident response documents. They are short of clarity about people. The plan often lives on a shared drive, written by the security team, and reviewed once a year. It rarely says, in plain words, which named person can halt production, which named person can approve contact with an attacker, and which named person must be woken up no matter the hour.

Titles do not solve this. A chief information security officer may have no formal say over a factory floor. A plant manager may have every incentive to keep the line running and no instruction to do otherwise. So at the exact moment speed matters most, people spend precious minutes simply working out who is meant to decide.

Many organizations only discover this gap when they run a proper tabletop exercise: sitting the real people down and walking through the scenario out loud. It is common, in that first rehearsal, for a room full of senior people to realize nobody can actually answer the simple question of who gets to press stop. That discovery is far cheaper in a meeting room than it is at two in the morning.

Build the Authority Card Before You Need It

The fix is not complicated, and it does not require new technology. It requires one page, agreed in daylight, long before any attack. The table below turns that page into five concrete decision rules.

Decision	Primary Authority	Backup Authority	Trigger	Time Limit
Halt full production	Named plant/operations leader (e.g., VP of Operations)	Named deputy, then site general manager	Ransomware confirmed on a system touching safety or production control	Decision made within 15 minutes of confirmation
Open contact with the attacker	General Counsel	Deputy General Counsel or retained breach counsel	A ransom note or demand is received	Within 1 hour; CEO notified immediately
Approve any ransom payment	Joint sign-off: CEO, CFO, and Legal/Compliance, never one person alone	COO stands in only if the CEO is unreachable	Legal/Compliance and Finance have both reviewed the demand and any sanctions exposure	No payment authorized without all three sign-offs
Notify regulators and customers	Chief Communications Officer with General Counsel	Deputy in either role	Statutory deadline (e.g., a six-hour reporting window) or material business impact	Set by the regulatory clock, not internal readiness
Escalate automatically to the CEO	—	—	Production down beyond an agreed number of hours, confirmed data theft, or a ransom demand above an agreed amount	Immediate, no one on the call decides whether to escalate

Separate the authority to open a conversation with attackers from the authority to approve any payment. These are different decisions with different risks, and they should never default to the same person by accident. The payment decision in particular should never rest with one person: it needs sign-off from Legal and Compliance, Finance, and a named executive together, precisely because it carries legal, financial, and reputational risk that no single function can assess alone.

The Clock Doesn’t Wait for You to Be Sure

While all this is being worked out, regulatory clocks are already running. In India, CERT-In’s Direction No. 20(3)/2022-CERT-In, issued on April 28, 2022 under Section 70B of the Information Technology Act, requires certain organizations to report specified categories of cyber incidents, a list of about twenty that includes ransomware attacks, within six hours of noticing them. It is one of the shortest reporting windows anywhere in the world. The obligation turns on the type of incident and the entity involved, not automatically on every disruption a company experiences, so working out whether and how a given event triggers this window is itself a judgment call that needs to be made in advance, not during the incident. Sector regulators, insurers, and major customers often add further deadlines on top of that, and organizations with European operations face a separate 72-hour notification window to supervisory authorities under GDPR.

None of these clocks pause while a team is still confirming exactly what happened. Waiting for full certainty before reporting anything is, in itself, a decision, and often the wrong one.

Evidence or Speed, Rarely Both

There is one more quiet trade-off that catches leaders off guard. Restoring systems quickly can mean rebooting machines before anyone has properly recorded their state, which can destroy the very evidence investigators need later. Waiting to preserve that evidence properly can mean longer downtime and larger losses.

In practice, this trade-off can be softened rather than avoided outright. Where it is safe to do so, a short, predefined step, imaging the disks and capturing the memory of the first few affected machines, and preserving relevant log files before anything is wiped or reimaged, lets a company begin recovery elsewhere in the network without giving up the evidence investigators, insurers, and regulators will later ask for. Deciding in advance which handful of systems get this treatment, and who is authorized to skip it under time pressure, is exactly the kind of decision this article is about.

There is no universally correct answer to this trade-off. A hospital may lean toward speed to protect patients. A listed company facing a regulator may lean toward evidence to protect itself later. There is no single right choice for every industry, but there is a wrong time to think about it for the first time, and that time is in the middle of the actual incident, with a production line standing still and everyone watching for a decision.

The Next Step

Most boards discuss ransomware as a technology risk and leave it to the technology team. The more useful question for any leadership team to ask this week is far simpler: if this happened tonight, who is actually allowed to stop production, and how quickly could that person be reached?

If the honest answer takes more than a few seconds, that hesitation is the real finding, more telling than any penetration test. The next step is not another audit. It comes down to three things, done in this order.

1. Name the deciders. Three real people, in order, who can authorize a full production stop, plus separate named people for opening contact with attackers and for approving any payment. Names and current phone numbers, not job titles.

2. Set the automatic triggers. The specific number or condition that pulls in the CEO without anyone having to argue for it, and the regulatory clocks, like CERT-In’s six-hour window, that start ticking regardless of how ready the company feels.

3. Rehearse it once. Sit the actual named people down for a single tabletop exercise this year. Bring more than the security team: operations, legal, communications, and finance all need a seat at the table, because the decisions above cut across all four. Walk through the scenario out loud, and fix whatever it exposes while it is still cheap to fix.