Backups and recovery in the metal and manufacturing industry: when did you last test it?
The question that matters is not whether a backup exists, but when someone last attempted to restore it. A backup that is created but never restored may be incomplete, corrupted, or simply incompatible with the machine on which it must eventually run. You will not discover this by looking at a log file, but by actually trying it.
For the metal and manufacturing industries, this is not a theoretical matter. CNC controls, MES software, PLCs and the planning systems around them are increasingly connected to the same network as office systems. If that network fails due to technical defect or an incident, the question is not only whether data comes back, but whether the production line can run with it again within a workable timeframe. That is what the duty of care under the NIS2 Directive is about: not the possession of a backup, but the demonstrable ability to restore.
Why a recovery test carries more weight than the backup itself
A backup strategy usually consists of three components: what is copied, how often, and where it is stored. These are the components that companies typically have in order, often for years through their IT provider. The fourth component is missing in many SMEs: a planned, repeated test in which someone actually restores the backup to a test environment and verifies that the result works.
That test shows whether backup and recovery actually align with each other. A backup of a database server without the associated configuration files of the connected machine is often unusable in practice. The same applies to a backup that contains the file but not the license key or the connection to the control system that operates the production line. You only find those gaps by restoring, not by reading the settings.
What this means for systems connected to the network
Production systems that once stood alone from the office network are now connected to it in many companies: for remote maintenance, for planning data, or because a supplier needs access for updates. That connection makes the business more efficient, but also means that a failure or incident on the office network can ripple through to the production floor.
When testing recovery, it therefore makes sense to distinguish between the backup of administrative systems and the backup of production systems. Both have their own recovery time, their own owner, and their own risk if something goes wrong. A test that only covers the office server says nothing about how quickly a CNC machine can read a drawing again after a failure.
What you record, and why that is just as important as the test itself
A recovery test that no one has documented is indistinguishable to a regulator or a client from a test that never took place. Recording does not have to be complicated: the date of the test, which system was restored, who performed it, and what the result was. That is exactly the kind of evidence that comes up in a security questionnaire from a client, and the kind of support that becomes relevant when reporting an incident.
For anyone who wants to organize this per measure, you will find in the overview of all topics by situation how backup and recovery relate to the other nine measures from the duty of care, such as access control and incident logging. That prevents recovery from standing alone, isolated from the rest of the dossier.
How often testing is enough
There is no fixed timeframe that applies to every organization; it depends on how critical the system is and how quickly it must resume operations after a failure. An annual test is insufficient for some systems and more than adequate for others. Regulators and the directive itself do not prescribe an interval; they expect an organization to be able to explain why the chosen frequency is appropriate given the importance of the system.
If you are uncertain whether your organization qualifies as an essential or important entity subject to the due care obligation, or whether you only encounter questions about backups through a contracting party, then the NIS2 check provides a first indication in just a few questions. Frequently asked questions about what is and is not required are collected at the frequently asked questions page.
A recovery test takes time, but less than rebuilding a production system without knowing whether the backup works. Would you like to see how this fits together with the other obligations in a single file, with a status, evidence, and an owner for each measure? First do the free NIS2 check, or read further at your leisure in the knowledge base.