A backup only counts if you have also tested that you can recover with it — not just whether the file is there, but whether the source code, the development pipeline and the associated secrets come back working after an incident. In software development it is not just about a repository you can restore, but about an entire chain: version control, build servers, pipelines, test environments and the keys and tokens that go with them. Without a tested recovery procedure, you only find out during an incident whether it works, and that is the worst time to discover it.
The NIS2 duty of care explicitly names continuity and recovery as part of the ten measures from Article 21. The directive prescribes no fixed test frequency and no concrete form — that is filled in per organisation, and the country-specific transposition can add its own emphasis there. What does consistently come back, in questionnaires from customers and in what supervisors consider reasonable, is the distinction between having a backup and having restored a backup and knowing the result works.
What 'tested' exactly means
A test is not the same as a green tick in the backup software. Tested means that someone has actually restored the backup in a separate environment, checked whether the code compiles, whether the build succeeds and whether the application functions as expected. Only then do you know whether the recovery moment is usable and how much time it takes. A backup that is made but never restored is in practice an assumption about recovery, not proven recovery.
What you specifically recover in the development pipeline
In software development, source code is rarely the only thing you can lose. Think of the CI/CD pipeline configuration, build scripts, dependencies on external packages, access keys for registries and cloud environments, and the history in the version control system itself. A recovery plan that only covers the code but not the pipeline or the secrets still leaves an organisation at a standstill after an incident. It is therefore useful to determine for each of these components separately: where is the backup, who can restore it, and has that ever been practised.
How often testing is reasonable
There is no fixed deadline in the directive for how often you must perform a recovery test. What is considered reasonable in practice depends on how often the environment changes: a development pipeline that changes pipeline configuration weekly calls for more frequent testing than a stable environment that remains unchanged for months. Many organisations opt for a fixed calendar moment — for example every quarter — combined with a test after every major change to the infrastructure. More important than frequency is that there has been a moment at all, and that you can point to when.
What you record as evidence
A customer sending a security questionnaire rarely asks about the technique behind your backup. The question is usually simpler: when was this last tested, by whom, and what was the result. For that answer it is sufficient to record three things: the date of the last recovery test, who performed the test, and which component was restored — code, pipeline, secrets, or all three. Without that record, the answer to the questionnaire remains a memory rather than evidence, and that is exactly the difference an assessor on the other side of the table wants to see.
The relationship with the rest of the file
Backup and recovery rarely stand alone. Who may perform the recovery procedure is linked to access control for the development pipeline; what went wrong during an outage belongs in the same incident log used for other measures. Setting up such a dossier need not be a separate project: the ten measures broken down by situation shows where backup and recovery fit exactly within the whole, and which other measures directly affect them.
Whether backup and recovery constitute a due diligence measure for your organisation depends on whether you fall under NIS2 yourself or whether you receive this question from a client who does. in a few questions see where you stand provides an initial indication of this, with explanation of why. How we arrive at that indication and what sources underlie it are explained on the page about our methodology.
A backup that has never been restored is no guarantee — it is a question waiting for an answer. Do you want to know whether and how this measure is relevant for your organisation, and what else goes with it? Take the free quick-scan or browse the most frequently asked questions about NIS2 for the questions other entrepreneurs have already asked.