Disaster Recovery for Manufacturing in Ontario: Getting the Plant Back After an Outage or Attack

Most disaster recovery advice assumes every system is a server or a cloud app. In a plant, some of the most important data isn’t on a server at all: it’s the program loaded in a machine controller, the recipe on an HMI PC, or the label template on a station by the shipping door. Lose those and production stops, even if the ERP restores perfectly. This article sits alongside our page on business continuity and disaster recovery services and our manufacturing IT page.

I’m Adam Bowles, Partner and CEO at ACT360. Below: what disaster recovery means in a plant, how it differs from an office, why manufacturers get hit, what the plan needs, an example restore order, the old-hardware problem, and how to test without stopping production.

For a manufacturer, disaster recovery is the plan for restoring the systems production depends on after a failure, fire, flood or cyber attack: the business systems in the office and the computers, programs and settings that run the plant floor.

Manufacturing is a major employer in this province: Statistics Canada reported that Ontario manufacturing employed 656,700 people in December 2025. In a 40-person fabricator or food plant without dedicated IT staff, it’s easy for a recovery plan, if there is one, to cover the server and stop there.

Disaster recovery is one half of the picture. The other half is business continuity: how the plant keeps shipping while systems are down. Our explainer on business continuity vs disaster recovery covers how the two plans fit together, and our business continuity plan template gives you the continuity side in fill-in form.

Office recovery is mostly about servers and data. Plant recovery adds machine programs, HMI and SCADA computers, floor stations and outside parties like OEMs and integrators, and production can’t wait for all of it to finish.

Three differences matter most in practice:

• Some data lives outside IT’s backups. A controller program changed on the floor last month may exist only in the controller. If nobody saved a copy, a failed controller means rebuilding the program from memory or old files.
• Outside parties hold keys. Machine builders and integrators often have the original project files, licences or remote access. Their phone numbers belong in the plan, along with what they have and how long they’d take to respond.
• Old operating systems turn up on the floor. HMI PCs that run fine on unsupported Windows are hard to rebuild onto new hardware in a hurry. A disk image taken while they work is far quicker than a fresh install during an outage.

Usually because they’re reachable, not because they were singled out. The Canadian Centre for Cyber Security says ransomware actors are opportunistic, and names manufacturing among the sectors hit by groups such as Akira, ALPHV and Play.

The Cyber Centre’s Ransomware Threat Outlook 2025-2027 says Akira has been used against manufacturing and telecommunications organizations globally and in Canada. Its National Cyber Threat Assessment 2025-2026 also notes that ransomware actors are almost certainly opportunistic and don’t target specific industries. A stopped plant also loses money by the hour, which is exactly the pressure a ransom demand relies on.

The best-documented case is Norsk Hydro, the Norwegian aluminium producer attacked in March 2019. Hydro isolated its plants and switched to manual operations and procedures, kept much of its primary metal production running with a higher degree of manual operation, and rebuilt encrypted PCs and servers from backups. It later estimated the total cost at around NOK 800 million. Two lessons carry over to a 50-person Ontario plant: the manual procedures kept product moving, and the backups made recovery possible at all.

Our article on why ransomware targets manufacturers in Canada covers the attack side in more depth, and our page on cybersecurity for manufacturing in Ontario covers the common ways into a plant and what closes each one.

A plant’s recovery plan needs an inventory that includes floor systems, a restore order based on what stops shipments, recovery targets, backups of machine programs as well as servers, an offline copy, manual-mode procedures, outside contacts and a way to confirm restored systems are clean.

1. An inventory that includes the floor. Every server, application and floor PC, plus each controller, HMI and station, with who owns it and who can restore it.
2. A restore order based on shipments. Rank systems by how quickly their loss stops product leaving the building, not by which server is biggest.
3. Recovery targets per system. How fast each must be back (RTO) and how much data or program history it can lose (RPO).
4. Backups that include machine programs. Current copies of controller, HMI, CNC and label files, with the approved version marked, stored where ransomware on the office network can’t reach them.
5. At least one offline copy. The Cyber Centre’s ransomware playbook recommends an offline backup process, with backups disconnected from all networks.
6. Disk images of hard-to-rebuild PCs. Especially HMI and SCADA computers on older Windows versions.
7. Manual-mode procedures. How each line runs, and how orders, picking and shipping work, while systems are down.
8. Outside contacts. ERP vendor, OEMs, integrators, internet provider and insurer, with account numbers and after-hours lines.
9. A check before reconnecting. How you’ll confirm restored systems are clean before they go back on the network.

The last point is easy to skip. The joint guidance on principles of operational technology cyber security, co-sealed by the Cyber Centre, asks plant operators to think through whether backups can be trusted if an attacker has been on the network for a while, and how to validate that a critical system is safe after recovery. Restoring last night’s backup doesn’t help if the attacker was already inside last week.

Restore the foundations first (network, accounts, internet), then whatever gets product out the door (ERP, shipping and label stations), then each production line, then engineering files, and reporting last.

The table below is an illustrative example for a mid-sized plant, not a standard. Your own order should come from asking each department what stops shipments and how fast.

Notice that the ERP isn’t automatically first. If the network and admin accounts aren’t trusted yet, restoring the ERP just puts it back somewhere unsafe. And if the label stations depend on the ERP, they come back together or the shipping dock stays stuck.

They make recovery slower and riskier. Windows 10 reached end of support on October 14, 2025, and Windows Server 2016 extended support ends January 12, 2027, so floor PCs and plant servers on those versions need a recovery plan of their own.

Microsoft’s lifecycle pages confirm both dates: Windows 10 and Windows Server 2016. Some HMI and machine PCs run on versions older still, because the machine software was certified on them and nobody wants to touch a working line.

That’s a reasonable choice for production, but it changes the recovery plan. For each old PC or server, record what it runs, keep a working disk image, keep the install media and licence keys, and know whether you have spare hardware it will actually run on. Where the machine vendor supports an upgrade, plan it during a shutdown instead of during an outage.

If the ERP server is the one on borrowed time, our page on ERP support for manufacturing in Ontario covers who owns which layer, and our article on cloud migration for manufacturing covers what should move off site and what should stay.

Test in layers: restore backups to a test machine on a schedule, practise manual mode on one line during a planned slow period, and run a tabletop with the plant manager, maintenance and IT once a year.

• Restore tests. The Cyber Centre’s ransomware playbook suggests a regular schedule to test backups, for example monthly. Include a controller program and an HMI image, not just the ERP database.
• Manual mode. The Cyber Centre’s guidance to protect your operational technology (ITSAP.00.051) advises testing systems and processes in manual mode. Doing it on one line during a slow shift shows what the procedure forgot.
• Tabletop. Walk through a scenario, such as ransomware on the office network at 6 a.m. on a Monday, and time each decision. Who isolates the floor network? Who calls the integrator?
• Bigger tests around shutdowns. Summer and holiday shutdowns are the natural window for a fuller recovery test of a production system.

Our articles on disaster recovery testing and how often to test your backups cover the testing levels and cadence in more detail.

We start on the floor, not with a backup product. Through the Assess and Comprehend steps of our ACTION approach, we walk the plant, inventory what runs where, and ask each shift what can’t stop and for how long. The restore order comes from those answers.

From there, our business continuity and disaster recovery service covers backup design around your critical systems, scheduled test restores, a documented recovery time for your environment, ransomware-specific planning alongside our cybersecurity work, audit-ready documentation for insurer and customer questionnaires, and quarterly recovery reviews so the plan keeps up with the plant. For machine programs and controllers, the plan names your OEMs and integrators and what each is responsible for, so nobody is guessing during an outage.

A plant’s recovery plan is only as good as its weakest copy. If the ERP is backed up nightly but the controller programs live only in the controllers, the plan has a hole exactly where production is most exposed. Inventory the floor, copy what matters, keep one copy offline, decide the restore order by what ships, and practise manual mode before you need it.

If you’d like a second opinion on your plant’s recovery setup, our free IT Readiness Assessment is a 30-minute review of your backups, security and recovery plans, with a short list of what to fix first. You can also call 705-739-2281 or email [email protected].