Une sauvegarde ne compte que si vous avez également testé que vous pouviez la restaurer — non seulement si le fichier est présent, mais si le code source, la chaîne de développement et les secrets associés fonctionnent à nouveau après un incident. Dans le développement logiciel, il ne s'agit pas seulement d'un dépôt que vous pouvez restaurer, mais de toute une chaîne : gestion des versions, serveurs de compilation, pipelines, environnements de test et les clés et tokens qui y sont associés. Sans une procédure de récupération testée, vous ne saurez que pendant un incident si cela fonctionne, et c'est le pire moment pour le découvrir.
L'obligation de diligence de la NIS2 mentionne explicitement la continuité et la récupération comme faisant partie des dix mesures de l'article 21. La directive ne prescrit pas de fréquence de test fixe ni de forme concrète — cela est rempli par organisation, et la transposition spécifique au pays peut y ajouter ses propres accents. Ce qui revient toujours, dans les questionnaires des clients et dans ce que les autorités de contrôle considèrent comme raisonnable, c'est la distinction entre avoir une sauvegarde et avoir une sauvegarde que vous avez restaurée et dont vous savez que le résultat fonctionne.
Ce que « testé » signifie exactement
Un test n'est pas la même chose qu'une coche verte dans le logiciel de sauvegarde. Testé signifie que quelqu'un a réellement restauré la sauvegarde dans un environnement séparé, a vérifié que le code compile, que la compilation réussit et que l'application fonctionne comme prévu. C'est seulement alors que vous savez si le moment de la récupération est utilisable et combien de temps cela prend. Une sauvegarde qui est effectuée mais jamais restaurée est, en pratique, une hypothèse sur la récupération, pas une récupération prouvée.
Ce que vous restaurez spécifiquement dans la chaîne de développement
Dans le développement logiciel, le code source est rarement la seule chose que vous pouvez perdre. Pensez à la configuration du pipeline CI/CD, aux scripts de compilation, aux dépendances des paquets externes, aux clés d'accès pour les registres et les environnements cloud, et à l'historique du système de gestion des versions lui-même. Un plan de récupération qui ne couvre que le code mais pas le pipeline ou les secrets laisse une organisation immobilisée après un incident. Il est donc judicieux de déterminer pour chacun de ces éléments séparément : où se trouve la sauvegarde, qui peut la restaurer, et cela a-t-il déjà été exercé.
À quelle fréquence les tests sont raisonnables
Il n'y a pas de terme fixe dans la directive pour savoir à quelle fréquence vous devez effectuer un test de récupération. Ce qui est considéré comme raisonnable dans la pratique dépend de la fréquence des modifications de l'environnement : une chaîne de développement qui change de configuration de pipeline chaque semaine exige des tests plus fréquents qu'un environnement stable qui reste inchangé pendant des mois. De nombreuses organisations choisissent un moment calendaire fixe — par exemple, chaque trimestre — combiné à un test après chaque modification majeure de l'infrastructure. Plus important que la fréquence est qu'il y ait eu un moment quelconque, et que vous puissiez indiquer quand.
Ce que vous conservez comme preuve
Un client qui envoie un questionnaire de sécurité demande rarement la technique derrière votre sauvegarde. La question est généralement plus simple : quand cela a-t-il été testé pour la dernière fois, par qui, et quel était le résultat. Pour cette réponse, il suffit de consigner trois choses : la date du dernier test de récupération, qui a effectué le test, et quelle partie a été restaurée — code, pipeline, secrets, ou tous les trois. Sans cette consignation, la réponse au questionnaire reste un souvenir au lieu d'une preuve, et c'est exactement la différence qu'un évaluateur de l'autre côté de la table veut voir.
Le lien avec le reste du dossier
La sauvegarde et la restauration vont rarement de pair. Qui a le droit d'effectuer la procédure de restauration dépend du contrôle d'accès à la chaîne de développement; ce qui s'est mal passé lors d'une panne doit figurer dans le même registre d'incidents que celui utilisé pour les autres mesures. La mise en place d'un tel dossier ne doit pas être un projet distinct : les dix mesures détaillées par situation montre exactement où la sauvegarde et la restauration s'inscrivent dans l'ensemble et quelles autres mesures y sont directement liées.
Que la sauvegarde et la restauration constituent une obligation de diligence pour votre organisation dépend de votre statut sous NIS2 ou du fait que vous receviez cette question d'un donneur d'ordre qui relève du champ d'application. en quelques questions, voir où vous en êtes donne une première indication à ce sujet, avec explication sur notre approche. La manière dont nous parvenons à cette indication et les sources sur lesquelles elle s'appuie sont expliquées sur la page sur nos méthodes.
Une sauvegarde qui n'a jamais été restaurée n'est pas une garantie — c'est une question qui attend une réponse. Vous voulez savoir si et comment cette mesure est pertinente pour votre organisation et ce qui va avec? Effectuez le diagnostic rapide gratuit ou parcourez les questions les plus fréquemment posées sur NIS2 pour les questions que d'autres entrepreneurs ont déjà posées.