Backups and recovery in ICT services: when did you last test it?
The question "do you have a backup" is not the question that matters. The question that matters is: when did someone last attempt to actually restore a system from that backup, and how long did it take? A backup that is created but never restored is in practice an assumption. Supervisors and customers who rely on the care duty measures from the NIS2 Directive therefore look not only at the existence of a backup policy, but at evidence that recovery actually works.
For an ICT service provider, this is not a minor matter. You often manage not just your own environment, but customer systems, remotely, sometimes with the help of a subcontractor. If something goes wrong there, it does not matter who made the error, but whether recovery worked within a timeframe the customer could justify. That makes the recovery test one of the few measures you cannot simply tick off with a document.
Why an untested backup does not count
A backup can be unusable for all sorts of reasons: a corrupted file, a wrong configuration, a password that no one remembers, or a recovery procedure that looks correct on paper but takes three days in practice instead of three hours. None of these problems become visible until someone actually uses the backup. Article 21 of the NIS2 Directive explicitly mentions backup and recovery policy as part of the risk management measures an organisation takes into account with its suppliers. In practice, this means that a customer who is themselves subject to the care duty asks their ICT supplier how recovery is arranged and, increasingly, when that was last tested.
What a supervisor or a customer means by "tested" is not uniformly defined, but the core question comes up every time: has there been a moment when a system or dataset was actually restored, separate from the production environment, and was the outcome documented? A test report with a date and a result is something different from an internal note that "the backups are running".
Remote management: whose backup is it anyway
In remote management, the backup of a customer system is often not physically located at the customer, but at the service provider, or at a cloud service that the service provider has set up on behalf of the customer. That shifts a question that at first sight seems technical into a question about responsibility: who tests, who keeps the test result, and who can demonstrate that recovery works if the customer asks? A security questionnaire from a customer increasingly asks about this in concrete terms, and "our hosting partner does that" is not an answer for a supervisor or an auditor — it is a reference that calls for your own check.
It is therefore wise to record per customer system who has access to the backup, how that access is secured, and who is responsible for the most recent recovery test. the care duty measures organised by subject shows how backup and recovery relate to the other measures from the care duty, such as access control and incident reporting.
Subcontractors: who tests what
Many ICT service providers work with subcontractors for specific parts: a hosting provider, a party that manages the firewall, a freelancer who rolls out patches. If one of them also manages the backup, the recovery test easily gets lost between two parties: the service provider thinks the subcontractor tests, the subcontractor thinks that is not part of his assignment. For the customer it makes no difference — they ask the question to the party with whom they have a contract.
It is therefore worth explicitly stating in agreements with a subcontractor who performs the restoration test, how often, and who retains the evidence. That evidence does not need to be an extensive report; a date, a description of what was restored and the result are usually sufficient to show a client that restoration is not an assumption.
What you record, and what you do not
A restoration test is manual work: someone restores a system, measures how long it takes and checks whether the data is correct. You do this work yourself or have your management partner do it; a platform cannot do this for you, any more than it can replace a penetration test or an audit. What does help is a place where the outcome of each test is stored together with the other risk management measures, so that the next time you receive a questionnaire you do not have to search for when it was last done.
If you do not yet know whether your organization itself falls under the care obligation, or only encounters these questions through a client, find out in five questions where you stand provides an initial indication. If you want to know how we handle the data you record in such a file, how we handle your data explains that. And if you are uncertain whether your situation falls precisely under this, check answers to questions that come up frequently or consult the supervisory authority for your sector.
The free NIS2 check and the knowledge base on secria.eu show where back-up and restoration stand in your situation, without requiring an account.