A ransomware plan for manufacturing should define in advance how to bring the plant to a safe state, what to isolate, which verified copies will restore systems, and who approves the return to operation. Recovery of manufacturing systems does not start by restoring the first available server. It starts by protecting people, equipment, and processes, then restoring functions in an agreed order based on business dependencies.
Ransomware in manufacturing is not only a problem of unavailable files. An incident can disrupt planning, data exchange with the shop floor, product labeling, quality control, access to recipes, and equipment configurations. Incident response in manufacturing must therefore connect IT systems, operational technology - OT, production teams, and management.
Before an incident, determine which plant components can continue operating autonomously, which can be isolated from the network, and which require a coordinated shutdown. The decision is not the same for an office server, MES, HMI, PLC, industrial network equipment, or a labeling system.
Disconnecting the wrong component can create an additional safety or production issue. The plan should therefore contain real technical and operational decisions, not just a general instruction to disconnect the affected system from the network.
For every critical zone, record:
Contacts, authorities, and plans must be available outside the affected environment. A document stored only on a network drive is not operational if that drive is unavailable. Printed key procedures, a protected offline copy, and a pre-agreed alternative communication channel can reduce improvisation during the first decisions.
A backup has value only when the organization can demonstrate that it can restore the required component in the required sequence. In manufacturing, this usually includes more than virtual servers and business databases.
Depending on the actual plant architecture, the OT backup inventory should cover:
For each copy, assign an owner, creation frequency, storage location, protection against unauthorized modification, and evidence of restoration. Protection against modification matters because ransomware can affect accessible network locations and administrative accounts. However, a separate location alone does not solve the problem if no one knows which configuration version matches the actual equipment and process.
Periodically restore a selected component in an isolated and safe environment. Verify file integrity, version, required permissions, links to other systems, and the function that a user needs to confirm. For example, restoring a PLC program is not complete simply because the file is available. It is necessary to verify that it matches the approved version, can be applied according to the internal procedure, and remains aligned with the related HMI project, recipe, and documentation.
NIST operational technology security publications provide guidance on security controls in OT environments, including backups and remote access. NIST SP 800-82 Rev. 3 explains the broader context of differences between IT and OT.
Recovery must not bring the same problem back into the restored environment. Before systems return, determine which administrative credentials, remote access paths, integrations, and configurations may have been affected or misused.
The plan should therefore define what a clean configuration means for each system. This can include restoration from a known source, review of configuration changes, replacement of credentials where needed, review of remote access, and confirmation that segmentation and communication rules have returned to an approved state.
This is not a universal technical checklist. Some equipment may have limited upgrade options, supplier-specific procedures, or a need for planned downtime. Record these constraints before an incident, together with the person who can assess the risk and approve the procedure.
ERP may not function without identity services and a database. MES may not exchange work orders without network connectivity and ERP integration. Labeling may depend on master data, while quality control may depend on available recipes or specifications. The recovery order for manufacturing systems must therefore follow actual dependencies, not simply the order in which servers were purchased or virtualized.
Create a simple map showing which functions need identity, network access, a database, an integration, and data. Then define the minimum acceptable function required for a controlled continuation of work. This may mean limited production supported by pre-approved manual records, rather than restoring every application at once.
For each critical system, document:
In manufacturing organizations, work orders often connect planning, materials, execution, and records. It is therefore useful to verify in advance which data and confirmations must return for work to continue in a controlled way. Related considerations are covered in Manufacturing work orders .
A technically restored system is not automatically ready for production. Returning to operation should be a joint decision with clear criteria. IT confirms the state of infrastructure and identities. OT and production confirm safe operation of the process and equipment. Finance or accounting verifies the integrity of key documents and transactions. Management accepts the remaining business risk if operations continue with limitations.
A short decision form can include these questions:
The CISA StopRansomware Guide provides a framework for preparation, response, and recovery. Its application should be adapted to your own machines, shifts, suppliers, critical deadlines, and plant architecture.
A tabletop exercise can begin with a simple scenario: the office domain and part of the server estate are unavailable while the plant is still operating. The team then walks through contacts, authorities, isolation, safe shutdown, and the recovery sequence. The purpose is not to simulate every technical detail, but to find decisions that currently lack an owner, a procedure, or accessible information.
A technical exercise can include restoring one configuration and one database in an isolated environment. Record the duration, missing permissions, unknown dependencies, and steps that are unclear to someone who is not the daily administrator of that system. The exercise also demonstrates the difference between a copy that exists and a copy that genuinely supports recovery.
A plan has limitations. It cannot remove every operational risk, resolve every failed component in advance, or replace the judgment of specialists responsible for a specific process. It can, however, define safe boundaries, responsibilities, clean recovery sources, and priorities before decisions need to be made under pressure.
As a next step, bring IT, OT, production, and management together around one critical production line. Map its dependencies, verify one OT backup copy, and run a tabletop exercise for returning to operation. The Operational management guide can help structure ownership of decisions, while the recovery plan should remain tied to the specific plant architecture and operating model of your manufacturing environment.