A ransomware attack on a manufacturer is not simply an IT problem. It can stop production lines, block access to ERP or MRP data, prevent warehouse dispatches and expose valuable CAD drawings, specifications and customer information. Effective ransomware recovery is the planned process of containing the attack, restoring trusted systems and getting the business operating safely again.
The clear answer is this: recovery depends far more on preparation than on the actions taken after the ransom note appears. A current, tested backup is essential, but it is only one part of the plan. You also need to know what to restore first, whether the attacker still has access, and how older machinery-connected computers will be handled.
Ransomware recovery starts with keeping production safe
When ransomware is suspected, the first priority is containment. Disconnect affected computers from the network and isolate any shared storage, servers or virtual machines showing signs of encryption. Do not switch off systems blindly if doing so could create a safety or production risk. In a factory, the right response may differ between an office laptop and a PC connected to a CNC machine, test rig or packing line.
This is why a written incident plan needs named decision-makers from operations and IT. Someone must be able to decide whether a line can be paused, which supplier should be called, and how staff communicate if email or Teams is unavailable. Waiting for a director to return a call while orders pile up is a poor recovery strategy.
Avoid the temptation to begin restoring immediately. If the attacker still has administrator access, a restored server can be encrypted again. The recovery team must first establish the likely entry point, remove malicious tools and reset compromised credentials. That includes privileged IT accounts, remote access accounts and any shared passwords used for supplier support.
Identify what must return first
Most manufacturers cannot restore every system at once. Recovery should follow business priorities, not the order in which servers happen to appear in a backup console.
For one business, the first requirement may be the MRP system that drives work orders and material availability. For another, it may be the file server holding released production drawings, the warehouse scanning platform or the machine programming workstation. Email matters, but it may not be the system that gets goods out of the door.
A useful recovery plan records each critical system, its dependencies, its owner and the maximum time it can be unavailable before it causes unacceptable disruption. Dependencies are often where plans fail. Restoring an ERP application is of limited use if its database, licence server, Active Directory service or network connection has not been restored first.
Include the shop floor, not just office IT
A common mistake is to document Microsoft 365, finance and servers while overlooking operational technology. Machinery-connected PCs may run unsupported Windows versions, use specialist software or rely on serial connections and fixed IP addresses. They can be difficult to replace at short notice and may need input from the machine supplier before being rebuilt.
That does not mean such devices should be left exposed. Separate them from office networks where possible, tightly control remote access, remove unnecessary internet access and keep a documented image or backup of their configuration. Network segregation will not make an old computer modern, but it can limit how far an incident spreads.
Backups must be recoverable, not merely present
Many businesses believe they have backups because a job reports as successful each night. That is not proof that their data can be restored within a useful timeframe. Backups can be incomplete, corrupted, encrypted by attackers or too slow to rebuild a critical environment.
A sensible approach uses separate backup copies, with at least one protected from normal administrator access. This may include immutable backup storage, where saved data cannot be altered for a defined period, and an offline or separately managed copy. The exact design depends on the systems involved, available recovery time and the volume of engineering data, but the principle is straightforward: an attacker should not be able to delete both production data and the means to restore it.
Testing matters just as much. Test a full restore of a representative system, not only an individual file. Confirm that the restored application opens, users can sign in and the required data is current enough to work from. For CAD, CAM, ERP and MRP platforms, involve the people who use them. A technically successful restore that cannot produce a job pack is not a successful business recovery.
Keep backup records clear. You should be able to answer three questions quickly: where is the latest clean copy, who can authorise its use, and how long will restoration take? If the answer requires searching old emails or calling a former provider, improve the arrangement before an incident tests it for real.
Rebuild cleanly before reconnecting
Recovery is usually safer when affected devices are rebuilt from known-good images or clean operating system installations, rather than simply decrypted or patched in place. This takes longer, particularly where specialist applications are involved, but it reduces the chance of leaving hidden attacker access behind.
Before reconnecting systems, apply available security updates, install endpoint protection, reset passwords and review administrator rights. Check remote access tools, firewall rules, scheduled tasks and newly created accounts. Attackers commonly create more than one route back into an environment.
For a smaller manufacturer, this may mean restoring core identity services, then file storage and ERP, followed by office devices in stages. For a site with production equipment, the sequence should be agreed with operations and relevant machine suppliers. A rushed restart can create quality, safety or traceability issues. Production continuity is the aim, but controlled recovery is safer than switching everything back on and hoping for the best.
Decide how to handle the ransom demand
A ransom demand creates pressure, especially when delivery dates are close. Paying does not guarantee that data will be returned, that stolen information will be deleted or that attackers will not strike again. It can also complicate insurance, legal and contractual decisions.
Treat payment as a business decision requiring specialist advice, not as an IT fix. Preserve evidence, record key timings and involve your cyber insurance provider and appropriate incident-response advisers promptly where applicable. Your IT team or support partner should focus on containment, technical investigation and a safe restoration path.
If data may have been copied as well as encrypted, the incident may affect customers, suppliers and contractual confidentiality obligations. Do not make assumptions about notification requirements. Obtain appropriate legal and data protection advice based on the facts of the incident.
Improve the plan after recovery
The weeks after an incident are uncomfortable, but they reveal the gaps that ordinary risk reviews miss. Record what happened, how access was gained, which controls worked and where delays occurred. Then turn those findings into practical changes.
Priorities will often include stronger multi-factor authentication, better control of remote supplier access, patching routines, separate administrator accounts, network segregation and staff awareness training. These measures work together. Multi-factor authentication may stop an attacker using a stolen password, while segregated networks can prevent one compromised office device from reaching a production system.
Run a short tabletop exercise at least annually. Ask operations, finance and IT what they would do if the ERP system, engineering files or warehouse scanners were unavailable at 7am on a Monday. It is not glamorous, but neither is explaining a missed shipment caused by an untested backup.
What a practical recovery plan should contain
A useful plan is short enough to use under pressure and detailed enough to avoid guesswork. It should include:
- named internal contacts, IT support contacts and key machine or software suppliers;
- an isolation procedure for office, server and shop-floor systems;
- a prioritised list of applications, data and dependencies to restore;
- backup locations, recovery credentials and tested recovery time expectations;
- an out-of-band communication method if email is unavailable; and
- a clear process for recording decisions, evidence and customer communications.
Keep a printed or securely offline copy. A recovery plan stored only on the file server is a fine example of optimism, not resilience.
For manufacturers across Hampshire, Surrey and West Sussex, the most valuable next step is to review whether your current backups, network design and recovery priorities reflect how work actually moves through the business. Syn-Star can help you assess those arrangements before ransomware turns an IT weakness into a production stoppage.
