← Tous les articles

consultant

ANSSI ReCyF: sauvegardes immuables et isolées pour tenir DORA art. 12

Le ReCyF de l’ANSSI (17/03/2026) exige des sauvegardes immuables et isolées pour contrer le rançongiciel. Voici comment les déployer et prouver la conformité DORA art. 12 et NIS 2.

Le 17 mars 2026, l’ANSSI publie le Référentiel Cyber France (ReCyF), avec des exigences concrètes de sauvegardes résilientes face au rançongiciel. Voici comment mettre en œuvre des backups immuables et isolés qui prouvent la conformité DORA art. 12.

Les faits

Le 17 mars 2026, l’ANSSI a présenté au Campus Cyber le « Référentiel Cyber France » (ReCyF) — version de travail 2.5 — qui décline opérationnellement les mesures NIS 2 pour les entités essentielles et importantes. Le document introduit des attendus très concrets en matière de continuité et de reprise d’activité, dont l’isolement et la protection des sauvegardes pour parer au rançongiciel, avec des exemples comme le « stockage hors‑ligne » quand c’est nécessaire. Le PDF officiel (47 pages) est accessible sur la plateforme MesServicesCyber de l’ANSSI (ANSSI, 17/03/2026). L’annonce a été relayée par la presse IT française, qui souligne la mise à disposition d’outils et d’un comparateur pour guider les entreprises (ChannelNews, 24/03/2026).

Pourquoi c’est critique pour le Luxembourg et la Grande Région (BE/FR/DE) en 2026 ? Parce que les mêmes exigences de résilience pèsent déjà sur les acteurs financiers sous DORA, et que les autorités nationales (CSSF au Luxembourg, ILR pour NIS 2) attendent des preuves de capacité à restaurer rapidement et proprement après incident. Le ReCyF fournit une grille « pratico‑pratique » que les dirigeants peuvent reprendre dès maintenant pour matérialiser leurs contrôles de sauvegarde et de reprise. Pour les acteurs régulés, notre page dédiée à DORA au Luxembourg et la CSSF résume les attentes locales.

Le cadre légal qui s’applique

  • DORA — Règlement (UE) 2022/2554, article 12 : impose des politiques et procédures de sauvegarde, ainsi que des procédures et méthodes de restauration et de reprise éprouvées et régulièrement testées. Les sauvegardes doivent pouvoir être activées et restaurées sous le contrôle de l’entité, y compris après incident majeur (EUR‑Lex — DORA; voir aussi une Q&A des ESA sur l’interprétation de l’art. 12(3) EIOPA Q&A DORA038).
  • NIS 2 — article 21(2)(c) : exige des mesures de continuité d’activité, y compris la sauvegarde et la reprise. Le ReCyF de l’ANSSI, publié le 17/03/2026, décline ces attentes : Objectif 13 « Continuité et reprise », Objectif 14 « Réaction aux crises », avec la recommandation explicite d’isoler et protéger les systèmes et les sauvegardes, et de prévoir un stockage hors‑ligne en cas de rançongiciel (ANSSI — ReCyF).
  • Luxembourg — CSSF (DORA) : rappels 2026 sur le registre TIC et les attentes de préparation DORA, y compris la traçabilité des services et contrôles soutenant la restauration (CSSF, 11/02/2026; CSSF, 12/03/2026).

La solution technique à déployer

Objectif : rendre vos sauvegardes résistantes au rançongiciel et opérationnelles en restauration, avec des preuves auditablement DORA/NIS 2. Pour structurer votre plan de continuité et reprise, alignez architecture et procédures sur les points ci‑dessous.

  • Stratégie 3‑2‑1‑1‑0 : 3 copies, 2 supports différents, 1 copie hors site, 1 copie immuable/hors‑ligne, 0 erreur vérifiée par tests de restauration. Alignez la politique avec ReCyF Objectif 13 et DORA art. 12.
  • Immutabilité (WORM) et verrouillage objet sur la cible de backup (ex. S3 Object Lock, appliances WORM, snapshots immuables) avec rétention et verrouillage juridique quand c’est requis. Contrôles : accès append‑only, journalisation inviolable, MFA sur la console.
  • Isolation réseau de la fabrique de sauvegarde : VLAN/segment dédié, accès via jump hosts durcis et PAM, règles deny‑all par défaut, air‑gap périodique ou stockage entièrement offline pour la copie « 1 ».
  • Chaîne d’authentification et d’administration durcie : comptes d’admin de backup séparés, MFA résistante au phishing, coffres de secrets, et bastions. Journalisation signée.
  • Détection et validation : scan antimalware/spécifique rançongiciel avant l’ingestion des lots (préconisation fréquente dans les guides ENISA/NIS2), scoring d’anomalies (volumétrie, entropie), malware canary.
  • Tests de restauration trimestriels au minimum, en enclave de reprise (réseau de quarantaine) avec procédures documentées T‑0/T‑24/T‑72, et temps objectifs de reprise (RTO/RPO) réalistes.
  • Preuve et traçabilité : registres de politiques, journaux d’accès, rapports de tests, mapping DORA art. 12 et NIS 2 art. 21 via le tableau de correspondance ReCyF.

Référentiels : ISO/IEC 27001:2022 Annexe A 8.13 « Information backup », A 5.30 « ICT readiness for business continuity » ; NIST CSF 2.0 PR.DS‑08 (safeguards to protect data), RC.IM‑01/02 (recovery plans and exercises) ; CIS Controls v8 Contrôle 11 « Data Recovery ».

Comment Luxgap déploie cela

  • Notre gouvernance ISO 27001 : nous cadrons la politique de sauvegarde (périmètre, RTO/RPO, classes de données), le modèle de menaces spécifique rançongiciel, et le plan de tests récurrents. Nous livrons un mapping DORA art. 12 / NIS 2 art. 21 / ReCyF Obj. 13‑14, avec les preuves attendues par les régulateurs.
  • Notre SOC managed 24/7 : intégration des consoles de sauvegarde (API) dans le SIEM, détection d’anomalies (suppression de jobs, raccourcissement de rétention, pics d’échec), alertes corrélées avec l’EDR/XDR pour décider d’un freeze des snapshots et du basculement vers la copie immuable.
  • Nos consultants DPO et CISO externalisés : articulation avec RGPD art. 32 (sécurité), politiques de conservation et registres, et coordination avec le plan de notification incidents (NIS 2/DORA) pour prouver la capacité de restauration et limiter l’impact sur les personnes.

Cas concret au Luxembourg ou en UE

Une entreprise d’investissement luxembourgeoise (soumise DORA) a déployé en 6 semaines : une cible WORM objet avec rétention 30 jours, un tier hors site chiffré, l’isolation réseau de la fabrique de sauvegarde, et un runbook de restauration testé sur une enclave. Résultats observables : tests de restauration mensuels automatisés (~2 h pour un service critique), journaux signés exportés au SIEM, et un rapport de preuves prêt pour la CSSF (politique, schémas d’architecture, captures d’audit, procès‑verbaux de tests) mappé DORA art. 12 et ReCyF Obj. 13‑14.

Premiers pas concrets

  1. Figer la politique de sauvegarde (DORA art. 12) : périmètre applicatif, RTO/RPO par service, périodicité des tests, rôles et responsabilités. Faites valider par le management.
  2. Ajouter une copie immuable : activer WORM/« object lock » sur une cible S3‑compatible ou une appliance, définir une rétention minimale (≥ 14–30 jours) et isoler l’admin via un bastion + PAM.
  3. Séparer le réseau de backup : segment dédié, listes de contrôle d’accès explicites, deny‑all par défaut, accès via jump server, MFA résistante au phishing pour les consoles.
  4. Automatiser les tests de restauration sur une enclave de quarantaine : un scénario « or » par mois (fichiers), un scénario « platine » par trimestre (application critique), avec PV et métriques.
  5. Brancher vos preuves au SIEM : ingestion des journaux de backup, des preuves WORM et des PV de tests pour constituer un dossier DORA/NIS 2 prêt à l’audit (et déclencher des alertes si écart).

Sources officielles

Source actualité

Besoin d’un accompagnement pour prioriser et exécuter ces chantiers ? Contactez-nous via la page Luxgap ou notre formulaire de contact.

NEWSLETTER LUXGAP

Recevez nos analyses des qu'elles sortent.

Articles d'expertise RGPD, NIS 2, IA, et invitations aux webinaires + formations gratuites Luxgap. 1 a 2 emails par semaine maximum, desabonnement en un clic.

Vos données ne sont jamais partagées. Conformité RGPD garantie (logique : on est DPO).

Une question sur ce sujet ?

Notre équipe répond généralement sous 24 h ouvrées. Configurez votre devis ou écrivez-nous.

Configurer mon devis →