OT Ransomware Response: What to Do in the First 60 Minutes

Ransomware notes appearing on screens, file extensions changing in real time, a historian that suddenly stops logging — the first indications of a ransomware event rarely arrive with context. What happens in the first sixty minutes shapes everything that follows: how much is contained, how much evidence survives, and how much operational risk gets introduced by the response itself rather than the attack.

This isn't a generic incident response checklist with "OT" appended to the title. The sequence below reflects how ransomware actually plays out differently when industrial control systems are anywhere near the blast radius.

Minute Zero: Confirm What You're Actually Dealing With

Before anything else, separate confirmed fact from assumption. Is this ransomware, or does it look like ransomware — a corrupted backup job, a failed patch, a legitimate encryption process gone wrong? Pull whoever first noticed the issue into a short call and get specifics: what they saw, when, and on which system. Panic compresses timelines and inflates scope in people's memory, so get the raw observation before it gets retold a few times.

Step 1: Check Safety and Operational Status First

Before touching a keyboard to contain anything, establish what the physical process is doing right now. Is the plant, line, or facility running normally? Are safety systems reporting normal status? This isn't a formality — it determines everything else. If the process is currently stable and safety systems are unaffected, you have room to make deliberate decisions. If something is already behaving abnormally, that changes the entire calculus of what happens next, and safety takes priority over containment speed.

Step 2: Establish Incident Command

One person needs to be making decisions, and that person needs authority over both IT and OT actions — or a clear, fast path to someone who does. A common failure mode in the first hour is IT and OT teams independently taking containment actions without coordinating, each unaware of what the other just changed. Name an incident commander explicitly, even if it's informal and temporary. Get engineering and operations leadership on the call within the first few minutes, not after IT has already made containment decisions unilaterally.

Step 3: Determine IT/OT Impact

Most industrial ransomware events start in IT — a phishing email, a compromised VPN account, an exposed RDP service — and the immediate question is whether it has reached, or could reach, the OT environment. Check the systems that sit at the IT/OT boundary specifically: jump servers, historians with two-way data flows, engineering workstations with dual network connectivity, and any system where IT and OT credentials or trust relationships overlap. Don't assume containment based on a network diagram that hasn't been validated recently — verify what's actually reachable, not what's supposed to be reachable.

Step 4: Contain Without Creating Unsafe Operational Consequences

Containment in OT has to be a coordinated decision between security and the people who understand what each system is currently doing in the process. Before isolating anything, ask: what does this system currently control or monitor, and what happens to the process if it goes offline right now? Sometimes the right containment action is immediate isolation. Sometimes it's a controlled, monitored shutdown sequence coordinated with operations. Sometimes it's leaving a system running under close observation while other actions are taken first. The point is that this is a decision, not a reflex.

Step 5: Review Remote Access

Ransomware operators frequently arrive through remote access — VPNs, vendor jump hosts, remote engineering tools. In the first hour, identify every active and recently-used remote access path into the OT environment and be prepared to disable it, particularly vendor and third-party connections that may not be actively monitored by your own team.

Step 6: Assume Credentials Are Compromised

If ransomware has executed, assume that whatever credentials were used to get there are burned, and start scoping what those credentials had access to — including any shared or service accounts used by OT systems, which are often broader in scope and less frequently rotated than typical IT accounts. Don't reset every credential in the environment reflexively; scope it to what's actually implicated, informed by what you learn in the hours that follow.

Step 7: Preserve Evidence Before It's Gone

Volatile evidence disappears fast — memory contents, active network connections, running processes. Before remediation activity starts (patching, rebooting, reimaging), capture what you can from systems that are believed to be involved: memory images where feasible, relevant logs, and a simple written timeline of what was observed and when. This matters even if you don't yet know whether you'll need it for a formal investigation — you can't go back and capture it later.

Step 8: Communicate Deliberately

Decide early who needs to know what, and on what cadence — executive leadership, operations teams at affected sites, and any regulatory or insurance obligations that may apply. Avoid speculating about scope or cause in early communications; state what's confirmed, what's being investigated, and when the next update will come. Uncontrolled internal speculation early in an incident tends to outlive the facts that eventually correct it.

Making the First Recovery Decisions

By the end of the first hour, you're unlikely to have full scope, but you should have: a safety and operational status check, an incident commander, a working theory of IT/OT impact, deliberate (not reflexive) containment actions, remote access reviewed, and evidence preservation underway. Recovery decisions — what to restore, in what order, from what source — come after scope is better understood, not during the first hour under incomplete information.

Mistakes to Avoid

• Isolating operational systems without checking what they currently control in the process
• Letting IT and OT teams take independent containment actions without coordinating
• Rebooting or reimaging systems before any evidence is preserved
• Resetting all credentials environment-wide instead of scoping to what's implicated
• Assuming a network diagram reflects actual current connectivity without verifying it
• Speculating about root cause or scope in communications before it's confirmed

The first sixty minutes of an OT ransomware event rarely feel calm, but the decisions made in that window — particularly around containment — have consequences that last well past the first day. Organizations that have already thought through these decisions, ideally through a tabletop exercise or an existing incident response retainer, tend to make them faster and with less second-guessing than organizations encountering them for the first time. If you're dealing with a suspected or active OT ransomware event now, our OT Ransomware Response & Recovery team can help scope and contain it; if you're preparing for the possibility, our OT Incident Response Retainers and Industrial Cyber Recovery services are built for exactly this scenario.