En 2026, NIS2 impose aux entités essentielles et importantes de mettre en place des mesures de continuité d'activité et de résilience des systèmes d'information. Sur le papier, l'obligation est claire. Dans la pratique, beaucoup de DSI peinent à traduire ces exigences en décisions concrètes
sur leur infrastructure de sauvegarde : quelles propriétés techniques sont attendues, à quel niveau de preuve, et avec quelle fréquence de vérification ?
Ce guide répond à ces questions en s'appuyant sur la lecture précise des articles 21 et 23 de la directive, et des objectifs 14 et 15 du ReCyF publié
par l'ANSSI le 17 mars 2026. Nous nous concentrons exclusivement sur la composante backup et restauration, les aspects de gouvernance et de gestion des risques sont traités dans notre guide complet NIS2 en France 2026.
Si vous n'avez pas encore déterminé votre statut entité essentielle ou entité importante, commencez par consulter notre guide :
NIS2 : comment savoir si vous êtes concerné ?
Les obligations de backup dans NIS2 ne sont pas formulées comme des spécifications techniques. La directive fixe des objectifs de sécurité, c'est le ReCyF de l'ANSSI qui les traduit en mesures concrètes attendues des entités françaises.
Trois textes sont à lire ensemble pour comprendre ce qui est réellement imposé.
L'article 21 impose aux entités concernées de prendre des mesures techniques et organisationnelles appropriées pour gérer les risques pesant sur leurs réseaux et systèmes d'information. Parmi les mesures explicitement listées figurent la continuité des activités: sauvegardes, reprise d'activité, gestion de crise, et la sécurité de la chaîne d'approvisionnement.
Ce que le texte n'impose pas : une technologie spécifique, un fournisseur particulier, ou un RTO chiffré. Ce qu'il impose : des mesures proportionnées aux risques, vérifiables et documentées.
L'article 23 fixe les obligations de notification des incidents. Son lien avec le backup est indirect mais structurant : une entité qui subit un incident majeur et ne peut pas démontrer l'état de ses sauvegardes au moment de l'incident s'expose à des questions très précises de l'ANSSI sur la qualité
de sa chaîne de reprise.
C'est ici que les obligations deviennent opérationnelles. Le ReCyF de l'ANSSI traduit l'article 21 en 20 objectifs de sécurité. Les objectifs 14 et 15 couvrent directement la continuité d'activité et la résilience des systèmes.
Ces deux objectifs s'appliquent aux entités essentielles et aux entités importantes. La différence entre les deux catégories ne porte pas sur les objectifs à atteindre, mais sur la façon dont l'ANSSI en vérifiera l'atteinte.
Le ReCyF introduit un principe de proportionnalité : le niveau d'effort attendu s'adapte à la maturité de l'entité et à ses ressources.
Une ETI de 60 salariés entité importante n'est pas tenue aux mêmes moyens qu'un opérateur d'infrastructure critique entité essentielle.
Ce qui est attendu dans les deux cas, c'est une démarche structurée, documentée et cohérente avec le niveau de risque réel de l'organisation.
Les objectifs ReCyF sur la continuité d'activité se traduisent en cinq exigences techniques que tout DSI doit être capable de documenter et de démontrer. Ce sont les points sur lesquels l'ANSSI évaluera votre conformité.
Les sauvegardes doivent être protégées contre toute modification ou suppression pendant une période de rétention définie.
Le ReCyF attend une immuabilité technique réelle, implémentée au niveau du stockage: le mécanisme WORM (Write Once Read Many) et non une simple politique de rétention logicielle configurable par un administrateur.
La distinction est importante : une sauvegarde dont la rétention peut être modifiée par un compte administrateur compromis n'est pas immuable au sens du ReCyF. Lors d'un contrôle ANSSI, c'est la preuve technique de cette immuabilité qui sera demandée, pas une déclaration commerciale du fournisseur.
Le ReCyF mentionne explicitement le cloisonnement physique des systèmes comme mesure attendue. Appliqué aux sauvegardes,
cela signifie qu'au moins une copie doit être isolée du réseau de production, air-gappée ou hors-ligne, et inaccessible depuis les systèmes principaux
en conditions normales d'exploitation.
En cas de ransomware atteignant le réseau de production, toute sauvegarde accessible depuis ce même réseau sera chiffrée dans les mêmes délais
que les données de production. L'isolation physique ou logique d'au moins une copie garantit l'existence d'une version saine après une attaque réussie.
Le ReCyF attend des RTO et RPO définis selon la criticité des systèmes, vérifiés lors de tests réguliers sur les volumes réels, et documentés
de manière à pouvoir être produits lors d'un contrôle. La valeur chiffrée seule n'a pas de valeur probante sans le rapport de test qui la confirme.
C'est l'exigence la plus fréquemment en écart lors des premiers diagnostics. Le ReCyF attend des tests périodiques sur les systèmes critiques,
avec des rapports documentant les résultats obtenus: RTO/RPO réels, périmètre testé, écarts constatés, actions correctives.
Ces rapports constituent la pièce centrale du dossier de conformité backup. Sans eux, il est impossible de démontrer l'effectivité des mesures
lors d'un contrôle ANSSI, même si l'infrastructure est techniquement solide.
Pour la méthodologie détaillée des tests, consultez notre guide : Comment tester son PRA selon l'ANSSI en 2026 ?
Le périmètre de sauvegarde doit couvrir l'intégralité des systèmes et données critiques identifiés dans l'analyse de risque.
Un périmètre partiel qui exclurait par exemple les environnements OT, les données Microsoft 365, ou certains serveurs de production,
crée des angles morts directement exploitables lors d'un incident et constitue un écart de conformité.
Pour les entreprises industrielles avec des environnements OT, cette exigence est particulièrement structurante : les systèmes SCADA,
automates et systèmes de supervision doivent être inclus dans la stratégie de sauvegarde, ce qui impose des contraintes techniques spécifiques
liées à la nature de ces environnements.
Les objectifs 14 et 15 du ReCyF s'appliquent aux entités essentielles et aux entités importantes. Le périmètre des mesures à mettre en place
est donc identique pour les deux catégories. Ce qui diffère, c'est le niveau de preuve attendu et la façon dont l'ANSSI en vérifiera l'atteinte.
L'ANSSI exerce une supervision proactive. Cela signifie qu'un audit peut intervenir sans qu'aucun incident ne l'ait déclenché.
Dans ce contexte, les preuves de conformité sur la partie backup doivent être permanentes et immédiatement produisibles :
rapports de tests datés, logs d'exécution des sauvegardes, documentation de l'architecture, preuves d'immuabilité au niveau du stockage.
Une entité essentielle qui ne peut pas produire ces documents lors d'un contrôle inopiné est en situation de non-conformité, même si ses sauvegardes fonctionnent correctement en pratique.
La supervision est réactive, elle se déclenche sur incident ou sur signalement. Mais cette réactivité ne réduit pas les obligations :
elle change le moment où elles seront vérifiées. Une entité importante qui subit une cyberattaque majeure fait face simultanément à la gestion
de l'incident et à un contrôle ANSSI potentiel sur l'état de ses sauvegardes au moment de l'attaque.
C'est souvent dans cette situation que les lacunes peuvent apparaitre: sauvegardes non testées depuis plusieurs mois, rapports inexistants,
périmètre incomplet. Le contrôle post-incident est le moment le moins favorable pour découvrir ces écarts.
Le ReCyF intègre un principe de proportionnalité: le niveau d'effort attendu s'adapte à la maturité de l'entité et à ses ressources.
Une ETI de 60 salariés entité importante n'est pas tenue aux mêmes moyens techniques qu'un opérateur d'énergie entité essentielle.
Ce qui est attendu dans les deux cas, c'est une démarche structurée, cohérente avec le niveau de risque réel, et documentée de manière exploitable.
Les exigences techniques décrites en section 2 ont des implications directes sur le choix de l'architecture de sauvegarde.
Certaines configurations répondent aux attentes du ReCyF, d'autres créent des angles morts que l'ANSSI identifiera lors d'un contrôle.
Une architecture full cloud répond à plusieurs exigences NIS2: immuabilité si activée, scalabilité, maintenance déléguée. Ses limites apparaissent
sur deux points précis du ReCyF : la souveraineté des données et le cloisonnement physique.
Sur la souveraineté, un fournisseur cloud non européen expose les données à des juridictions étrangères, incompatible avec les exigences NIS2
pour les secteurs régulés. Sur le cloisonnement, une sauvegarde cloud accessible en permanence depuis le réseau de production via une connexion internet ne satisfait pas l'exigence d'isolation physique du ReCyF, même si elle est immuable.
Une architecture on-premise offre un contrôle maximal, une latence minimale et une indépendance totale vis-à-vis d'un fournisseur tiers.
Son angle mort principal au regard de NIS2 est la redondance hors-site : si les sauvegardes sont stockées sur le même site que la production,
un sinistre physique (incendie, inondation) compromet simultanément les données et leurs copies.
NIS2 n'interdit pas le on-premise, mais exige que la stratégie de sauvegarde couvre ce scénario.
L'approche hybride: on-premise couplé à une réplication vers un cloud souverain français, adresse l'ensemble des exigences techniques du ReCyF
sur la partie backup :
L'immuabilité est implémentée sur les deux couches. L'isolation physique est assurée par la composante on-premise air-gappée.
La redondance hors-site est couverte par la réplication cloud. La souveraineté des données est garantie par le choix d'un datacenter souverain français, avec une certification de haute disponibilité Tier 3 minimum. Les RTO courts sont atteignables grâce à la restauration locale depuis la composante
on-premise.
Pour un développement complet sur le choix d'architecture, consultez notre guide : Backup on-premise vs hybride vs cloud : quel choix pour un PRA efficace en 2026 ?

Disposer d'une infrastructure de sauvegarde techniquement solide ne suffit pas.
L'ANSSI évalue la conformité sur la base de preuves documentées, pas sur la qualité perçue d'une solution. Constituer ce dossier de conformité backup est une démarche à engager bien avant tout contrôle.
La preuve de l'immuabilité ne peut pas reposer sur une déclaration commerciale du fournisseur. Ce qui est attendu : une documentation technique décrivant le mécanisme WORM implémenté au niveau du stockage, avec la période de rétention verrouillée applicable, et l'absence de possibilité
de modification par un compte administrateur pendant cette période.
En pratique, cela se traduit par un extrait de la configuration du système de stockage, ou par un rapport d'audit technique produit par le prestataire.
Un schéma d'architecture documentant la séparation physique ou logique entre le réseau de production et les sauvegardes. Pour la composante
air-gappée, la preuve que cette copie n'est accessible que lors d'opérations de restauration contrôlées, avec traçabilité des accès.
C'est le volet le plus structurant du dossier de conformité backup. Chaque test de restauration doit produire un rapport documentant :
la date et le périmètre du test, les RTO/RPO réels obtenus, les éventuels écarts constatés par rapport aux objectifs, et les actions correctives engagées.
Ces rapports doivent être conservés et immédiatement produisibles lors d'un contrôle. Pour les entités essentielles, ils constituent la pièce centrale
que l'ANSSI demandera en premier lors d'un audit proactif.
Un inventaire des systèmes et données critiques couverts par la stratégie de sauvegarde, avec la fréquence de sauvegarde applicable à chaque système, et la politique de rétention associée. Cet inventaire doit être maintenu à jour après chaque changement d'infrastructure.
Un dossier de conformité backup exploitable lors d'un contrôle ANSSI contient quatre éléments :
Un prestataire backup qui accompagne ses clients dans la conformité NIS2 doit être capable de produire les éléments techniques du dossier :
rapports de tests, documentation d'architecture, preuves d'immuabilité. Un prestataire qui ne peut pas fournir ces documents lors d'un renouvellement
de contrat ou d'un audit client devient lui-même un risque de conformité pour l'entité qu'il accompagne.
Non. La directive et le ReCyF fixent des objectifs de sécurité à atteindre : immuabilité, isolation, tests réguliers, RTO/RPO documentés, sans prescrire
de solution technique particulière. C'est à l'entité de démontrer que les mesures en place permettent d'atteindre ces objectifs, quelle que soit
la technologie retenue. En pratique, certaines architectures y répondent mieux que d'autres.
Une rétention logicielle peut être modifiée ou désactivée par un administrateur avec les droits suffisants, y compris un attaquant ayant compromis
un compte privilégié. L'immuabilité WORM (Write Once Read Many) est implémentée au niveau du stockage physique : aucune opération
de modification ou suppression n'est possible pendant la période de rétention, quelle que soit l'identité de l'opérateur. C'est cette dernière que le ReCyF attend comme mesure de protection contre les ransomwares ciblant les sauvegardes.
Le ReCyF n'impose pas de fréquence chiffrée. Il attend des tests réguliers, proportionnés à la criticité des systèmes et produisant des rapports exploitables lors d'un contrôle.
En pratique, un test partiel tous les 6 mois sur les systèmes critiques et un test complet annuel constituent le minimum attendu pour une entité importante. Pour une entité essentielle soumise à une supervision proactive, la fréquence et la profondeur des tests seront évaluées directement par l'ANSSI lors des audits.
Un cloud souverain français répond aux exigences de souveraineté des données et, si l'immuabilité est activée, aux exigences de protection contre
la suppression. La limite principale est l'exigence de cloisonnement physique du ReCyF : une sauvegarde cloud accessible en permanence depuis le réseau de production ne satisfait pas cette exigence.
Une architecture hybride: composante on-premise air-gappée combinée à une réplication cloud souveraine, adresse l'ensemble des exigences du ReCyF.
Quatre éléments sont attendus :
- Un document d'architecture décrivant la stratégie de sauvegarde et les mécanismes d'immuabilité et d'isolation en place
- Un registre des tests de restauration avec les RTO/RPO réels obtenus,
- Une politique de sauvegarde formalisée couvrant les fréquences et rétentions par système
- Un SLA contractualisé avec le prestataire backup.
Pour une entité essentielle, ces documents doivent être disponibles immédiatement. Pour une entité importante, ils doivent être produisibles sur demande en cas de contrôle post-incident.
En 2026, les exigences NIS2 sur le backup se concentrent sur un point : la capacité à démontrer que les sauvegardes fonctionnent, sur quel périmètre, dans quels délais, avec quels résultats documentés. L'infrastructure technique seule ne suffit pas si les preuves ne sont pas constituées et disponibles.
Pour les entités essentielles, cette démonstration doit être permanente et immédiatement produisible. Pour les entités importantes,
elle doit être disponible sur demande en cas de contrôle post-incident. Dans les deux cas, le dossier de conformité backup se construit avant l'incident, pas pendant.
Sur la composante technique, VYTALX accompagne les ETI et entreprises des secteurs régulés dans la mise en place d'une infrastructure de backup conforme aux objectifs ReCyF: immuabilité au niveau du stockage, cloisonnement physique, architecture hybride souveraine, tests assistés et rapports auditables.