DORA impose une isolation physique et logique des systèmes de sauvegarde, séparés des systèmes sources. Cette exigence, formulée à l'Article 12
du Règlement (UE) 2022/2554, est applicable depuis le 17 janvier 2025 à toutes les entités financières françaises, sans délai de transposition nationale.
Pour un DSI de banque régionale ou de société de gestion, cette obligation est souvent mal comprise. Beaucoup estiment que leur solution de backup cloud suffit. L'Article 12 exige explicitement une séparation physique et logique: un compte cloud isolé (tenant séparé, VLAN dédié) satisfait la condition logique mais pas la condition physique. La distinction remet en cause la conformité de la plupart des architectures cloud-only déployées avant 2025.
Cet article décrypte les cinq obligations concrètes de l'Article 12, identifie les trois erreurs les plus fréquentes, et propose une checklist opérationnelle utilisable lors d'un contrôle ACPR.
L'Article 12 du règlement DORA porte sur les politiques de sauvegarde, les méthodes de restauration et les procédures de rétablissement. Son objectif: garantir que les données critiques d'une entité financière sont récupérables après un incident, sans que l'activation des sauvegardes ne compromette l'intégrité du système en place.
Le texte fixe cinq obligations directement actionnables.
Les entités définissent leurs propres objectifs de sauvegarde: fréquence, périmètre, priorité. DORA impose que ces objectifs soient formalisés et calibrés selon la criticité réelle de chaque système. Un serveur de messagerie interne et un système de traitement des paiements n'ont pas le même régime.
En pratique, cela implique une analyse d'impact sur l'activité (BIA) pour identifier les systèmes critiques, puis la définition des RTO (Recovery Time Objective) et RPO (Recovery Point Objective) associés. Notre guide [RTO et RPO: définitions et calcul](https://www.vytalx.fr/rto-rpo-definitions) structure cette démarche étape par étape.
C'est l'obligation la plus contraignante. L'Article 12 §5 précise que lors de la restauration, les entités utilisent des systèmes TIC
"physiquement et logiquement séparés du système TIC source".
La séparation logique (VLAN isolé, tenant cloud dédié) satisfait la condition logique. Elle ne satisfait pas la condition physique. Un backup sur Azure ou AWS dans un compte séparé reste sur la même infrastructure matérielle que votre environnement de production. L'Article 12 exige des médias ou des équipements physiquement distincts: serveur de backup on-premise avec accès réseau restreint, système air-gappé, ou copie sur site géographiquement distinct avec connexion dédiée.
Consultez notre article sur l'isolation physique des sauvegardes pour les modalités techniques de mise en oeuvre.
DORA impose des tests réguliers des procédures de sauvegarde et des procédures de restauration. Ces tests produisent des preuves formalisées: rapports datés avec métriques RTO/RPO mesurées en conditions réelles, pas simulées sur papier.
Le règlement ne fixe pas de fréquence minimale. Les entités la définissent dans leur politique. La jurisprudence de supervision indique qu'un test annuel est le minimum attendu pour les systèmes critiques. Pour les entités de paiement ou les banques, deux tests par an sont recommandés.
L'Article 12 précise que l'activation des systèmes de sauvegarde "ne doit pas compromettre la sécurité du réseau et des systèmes d'information". Cette exigence vise un scénario précis: une entité compromise par un ransomware qui déclenche la restauration, mais dont le processus réinfecte les systèmes cibles via des backups eux-mêmes contaminés.
En pratique, cela impose de scanner les sauvegardes avant restauration, de vérifier l'intégrité des fichiers restaurés, et de contrôler que le processus de bascule n'ouvre pas de vecteur d'attaque supplémentaire. Une sauvegarde immuable WORM avec scan antimalware intégré satisfait cette obligation directement.
Après restauration, l'entité effectue "des contrôles nécessaires, y compris tout contrôle multiple et rapprochement, afin de garantir le niveau d'intégrité des données le plus haut possible". Ces contrôles couvrent aussi les données provenant de partenaires externes, pour assurer la cohérence entre systèmes après une remise en production.
DORA est un règlement européen directement applicable en France depuis le 17 janvier 2025. Contrairement à NIS2, il ne nécessite aucune loi de transposition nationale. Toutes les entités financières opérant en France sous supervision de l'ACPR ou de l'AMF sont soumises à ses exigences.
Le principe de proportionnalité s'applique: les micro-entreprises bénéficient d'un régime allégé sur certaines obligations, mais les exigences de base
de l'Article 12 restent applicables.
Une ETI financière de 200 salariés (société de gestion régionale, banque mutualiste locale, compagnie d'assurance spécialisée) est pleinement dans le périmètre DORA et doit satisfaire l'intégralité de l'Article 12.
Sur la relation NIS2/DORA : pour les entités financières, DORA s'applique en priorité sur NIS2 pour tout ce qui concerne la résilience opérationnelle numérique. Les obligations de sauvegarde NIS2) restent pertinentes pour les entités concernées par les deux régimes (ex: un prestataire TIC critique soumis à NIS2 Annexe I et opérateur DORA).
Prise de position directe: un backup uniquement cloud ne satisfait pas l'Article 12 de DORA, si les données sont hébergées sur la même infrastructure physique que les systèmes sources.
Sophie dirige l'équipe IT d'une société de gestion parisienne de 120 personnes.
En janvier 2025, lors de l'entrée en vigueur de DORA, elle a présenté un plan de conformité à sa direction. Son argument:
"Nous sauvegardons nos données sur Azure dans un tenant isolé, avec des accès restreints. L'isolation logique est en place." Neuf mois plus tard,
lors d'un audit interne, son prestataire conseil a identifié le problème: l'Article 12 §5 exige une isolation physique explicite. L'infrastructure Azure partagée, même dans un tenant séparé, ne remplit pas cette condition.
Les orientations techniques (RTS) publiées par les autorités de supervision européennes précisent que l'isolation logique seule est insuffisante pour les systèmes de sauvegarde critiques. La séparation physique signifie concrètement:
Le backup cloud conserve sa place dans une architecture conforme DORA), comme copie secondaire ou tertiaire dans une logique 3-2-1. Il ne peut pas être la seule couche de sauvegarde pour les systèmes critiques.
DORA distingue la politique de sauvegarde (Article 12) du plan de continuité opérationnelle (Article 11). L'une porte sur la protection et la récupération des données. L'autre couvre la continuité opérationnelle globale en cas de sinistre.
Beaucoup d'entités financières disposent d'un PRA documenté, mais sans politique de sauvegarde formalisée qui en constitue le socle. L'ACPR attend les deux. Un PRA sans politique de backup testée et documentée est un document sans preuves.
La différence entre un log de sauvegarde et un rapport de test est fondamentale pour un superviseur. Un log indique que la sauvegarde s'est exécutée. Un rapport de test prouve que la restauration a fonctionné, avec les métriques RTO et RPO mesurées en conditions réelles.
L'ACPR, lors de ses contrôles, demande des rapports de tests de restauration avec métriques datées, pas des historiques de jobs. Si votre prestataire ne produit pas de rapports formalisés, votre conformité DORA n'est pas prouvable lors d'un contrôle.
Un backup compromis par un ransomware peut réinfecter les systèmes lors de la restauration. DORA l'a anticipé en exigeant que l'activation des backups ne compromette pas la sécurité. Cela implique un scan antimalware des données sauvegardées avant toute restauration en production.
Cette exigence est absente de la plupart des architectures de sauvegarde classiques. Un backup immuable avec scan antimalware intégré satisfait directement cette obligation: les données sont non modifiables et vérifiées avant tout usage.
Utilisez cette liste pour évaluer l'état de conformité de votre stratégie de sauvegarde:
L'ACPR supervise la conformité DORA pour les banques et assurances françaises. Ses premiers contrôles de supervision ont ciblé plusieurs points précis.
L'ACPR ne s'arrête pas à la documentation. Elle demande des preuves d'exécution:
La notification d'incident grave est fixée à 4 heures après classification de l'incident comme majeur. Cette exigence DORA est deux fois plus contraignante que NIS2 (24 heures). Elle suppose que la politique de sauvegarde permette d'identifier rapidement l'étendue des données impactées et l'état des sauvegardes disponibles.
Un délai de notification à 4 heures implique une cartographie à jour des données critiques et des systèmes de sauvegarde, accessible sans délai en situation de crise.
Les manquements aux obligations DORA exposent les entités à des sanctions pouvant atteindre 10 millions d'euros ou 5 % du chiffre d'affaires mondial annuel* (selon le montant le plus élevé). Les membres de l'organe de gouvernance peuvent également être mis en cause individuellement selon les circonstances du manquement.
La conformité DORA Article 12 requiert une architecture de sauvegarde correcte et des preuves de tests. Les deux peuvent être externalisées.
Marc est DSI d'une société de gestion d'actifs de 85 personnes, à Lyon. Fin 2024, il a réalisé un diagnostic de son infrastructure backup avant l'entrée en vigueur de DORA. Résultat: un backup cloud sans isolation physique, aucun test de restauration documenté depuis 18 mois, et pas de politique de sauvegarde formalisée. Sa direction était exposée aux sanctions.
En trois mois, son prestataire a déployé un équipement de backup on-premise avec isolation réseau stricte, configuré un scan antimalware des sauvegardes, réalisé un premier test de restauration documenté avec rapport formel comprenant les métriques RTO mesurées, et produit une politique de sauvegarde compatible avec les exigences DORA. Les tests sont désormais réalisés deux fois par an avec rapports transmis automatiquement à la direction pour archivage.
La voie la plus efficace pour une structure sans RSSI dédié: un prestataire qui prend en charge l'installation, les tests et la production des rapports de conformité. Les critères à vérifier avant de choisir:
Planifier un audit de votre stratégie backup DORA en 30 minutes
La conformité DORA sur la sauvegarde repose sur trois impératifs pratiques: isoler physiquement les backups des systèmes sources, tester régulièrement la restauration avec preuves formelles, et documenter une politique approuvée par votre direction.
L'Article 12 ne laisse pas de place à l'interprétation sur l'isolation physique. Un backup cloud-only ne suffit pas pour les systèmes critiques. L'architecture la plus conforme combine un équipement on-premise avec isolation réseau et une copie secondaire en datacenter français certifié,
selon la règle 3-2-1-1-0
Pour les ETI financières sans équipe de sécurité dédiée, l'externalisation de la gestion de la sauvegarde à un prestataire spécialisé est la voie la plus directe vers la conformité DORA, avec tests inclus dans le SLA et documentation produite automatiquement pour vos auditeurs.
