Conformité DORA : un guide pratique

Dans une enquête menée en juillet 2025, 96 % des organisations de services financiers de la zone EMEA ont déclaré devoir améliorer leur résilience pour satisfaire aux exigences de DORA ^[1]. Le règlement est applicable depuis janvier 2025 ; tout écart constitue donc désormais un risque de conformité immédiat, que le prochain audit ou la prochaine attaque mettra en évidence.

Ce guide de conformité DORA explique ce qu’exige DORA, à qui il s’applique, les coûts de la non-conformité, ainsi que le maillon faible de la chaîne de conformité que la plupart des organisations sous-estiment : la capacité de restauration, c’est-à-dire l’aptitude à restaurer les données après une attaque.

Points clés

• DORA est le règlement (UE) 2022/2554. Il s’applique à plus de 22 000 entités financières et à leurs prestataires TIC depuis le 17 janvier 2025.

• La conformité DORA consiste à agir sur cinq exigences : gestion des risques TIC, déclaration des incidents, tests de résilience, gestion des risques liés aux tiers et partage d’informations.

• Les sanctions sont fixées par chaque État membre de l’UE. Les plafonds peuvent atteindre 20 M€ ou une part fixe du chiffre d’affaires, en plus d’un blâme public et d’interdictions d’exercer des fonctions de direction.

• L’article 12 est l’article spécifique aux sauvegardes. Il impose des systèmes de reprise testés, segmentés et protégés contre toute altération.

Qu’est-ce que la conformité DORA ?

DORA signifie Digital Operational Resilience Act. Il s’agit d’un règlement introduit par l’Union européenne pour renforcer la résilience numérique des entités financières.

Il est entré en vigueur le 17 janvier 2025 et garantit que les banques, compagnies d’assurance, entreprises d’investissement et autres entités financières peuvent résister aux perturbations des TIC (technologies de l’information et de la communication), y répondre et s’en remettre, telles que les cyberattaques ou les défaillances de systèmes ^[2].

La conformité DORA consiste à respecter les obligations définies dans le règlement, officiellement intitulé règlement (UE) 2022/2554.

La raison d’être est simple. Les entreprises financières sont devenues de plus en plus dépendantes des systèmes numériques pour fournir des services, piloter leurs opérations et traiter les transactions. Cette dépendance croissante a créé de nouveaux risques opérationnels et de cybersécurité. Les attaques par rançongiciel visant le secteur financier ont explosé, et une défaillance grave dans une entreprise peut désormais se propager aux autres et menacer la stabilité de l’ensemble du marché.

DORA considère une défaillance des TIC comme un risque pour la stabilité financière, au même titre que les régulateurs ont traditionnellement considéré des risques tels que les insuffisances de capital. Cela fait de la construction d’une véritable cyberrésilience une obligation réglementaire, et non une simple bonne pratique.

Qui doit se conformer à DORA ?

DORA s’applique à plus de 22 000 entités financières dans l’UE, ainsi qu’aux prestataires TIC tiers qui les servent ^[3].

Le règlement cite 20 types différents d’entités financières ^[2], répartis en cinq grands groupes :

• Banque et paiements : établissements de crédit, établissements de paiement, établissements de monnaie électronique et prestataires de services d’information sur les comptes.

• Marchés de capitaux : plateformes de négociation, entreprises d’investissement, référentiels centraux, contreparties centrales (CCP) et dépositaires centraux de titres.

• Gestion d’actifs : gestionnaires de fonds d’investissement alternatifs et sociétés de gestion d’OPCVM.

• Assurance et retraites : intermédiaires d’assurance, entreprises d’assurance et de réassurance, et institutions de retraite professionnelle.

• Autres entités réglementées : agences de notation de crédit, référentiels de titrisation, administrateurs d’indices de référence, prestataires de services sur crypto-actifs, prestataires de services de financement participatif et prestataires de services de déclaration de données.

DORA s’étend également aux fournisseurs technologiques qui se trouvent derrière ces entreprises. Tout prestataire TIC tiers qui fournit des services à une entité financière entrant dans le périmètre est soumis au règlement, y compris les prestataires basés hors de l’UE.

Cela signifie, par exemple, qu’une plateforme cloud, un prestataire de services managés ou un éditeur de logiciels ne peut pas se soustraire à DORA simplement parce que son siège social se trouve ailleurs.

Les cinq exigences de conformité DORA

Savoir comment se conformer à DORA se résume à cinq exigences : gestion des risques, déclaration des incidents, tests de résilience, supervision des tiers et partage d’informations.

Ne pas satisfaire à l’une d’entre elles rend une organisation non conforme.

1. Gestion des risques TIC

C’est le socle. Les entités financières ont besoin d’un cadre documenté de gestion des risques TIC couvrant l’ensemble du cycle de vie du risque : identification, protection, détection, réponse et reprise. La responsabilité doit relever de la direction générale, l’organe de direction étant comptable de son approbation et de sa supervision.

Le cadre doit également définir une tolérance au risque claire, c’est-à-dire la perturbation maximale qu’une fonction critique peut absorber avant que le préjudice ne devienne inacceptable. Ces exigences DORA en matière de cybersécurité font de la gestion des risques une responsabilité au niveau du conseil d’administration.

2. Déclaration des incidents TIC

Lorsqu’un incident majeur survient, les régulateurs veulent être informés rapidement. DORA exige que les organisations mettent en place un système de classification de la gravité et un processus de notification qui escalade un incident significatif vers l’autorité compétente sans retard injustifié.

En pratique, cela signifie trois étapes : une alerte initiale dans les 24 heures suivant la classification de l’incident, une mise à jour de statut dans les 72 heures, puis un rapport final d’analyse des causes racines environ un mois après la résolution de l’incident ^[5]. L’objectif est un récit clair et cohérent de ce qui s’est passé et pourquoi.

3. Tests de résilience opérationnelle numérique

Chaque entité entrant dans le périmètre doit tester régulièrement sa résilience. Les entités les plus grandes et les plus critiques doivent aller plus loin et réaliser des tests d’intrusion pilotés par la menace (Threat-Led Penetration Testing, TLPT), qui consistent en des attaques simulées en conditions réelles, menées par des testeurs indépendants et certifiés, selon un cycle de trois ans.

Un plan de continuité d’activité peut être convaincant sur le papier et pourtant s’effondrer dès sa première mise en œuvre. Les tests sont le seul moyen de savoir s’il tiendra réellement, avant que des attaquants n’imposent la réponse.

4. Gestion des risques TIC liés aux tiers

Une entité financière n’est résiliente qu’à hauteur des fournisseurs dont elle dépend. DORA exige que les entreprises évaluent, surveillent et conservent un levier contractuel sur chaque prestataire TIC, et qu’elles tiennent un registre d’informations à jour couvrant l’ensemble de ces prestataires.

Les prestataires TIC dont les services sont largement utilisés dans le secteur financier et qu’il serait difficile de remplacer peuvent être désignés comme critiques. Ces prestataires répondent directement aux régulateurs de l’UE, dans le cadre d’un dispositif de supervision dédié assorti de ses propres sanctions.

5. Partage d’informations

C’est la seule exigence volontaire. DORA encourage les entités financières à échanger des renseignements sur les menaces cyber au sein de communautés de confiance, afin que le secteur apprenne collectivement de chaque attaque plutôt qu’au rythme d’une victime à la fois.

Sanctions DORA en cas de non-conformité

DORA ne fixe pas une amende unique pour l’ensemble de l’UE. Chaque État membre établit ses propres sanctions maximales au titre de l’article 50, ce qui signifie que l’amende potentielle dépend du lieu d’activité de l’entité ^[4].

Les sanctions visent deux groupes : les entités financières et leurs prestataires TIC les plus critiques. Dans les deux cas, les conséquences vont au-delà des amendes et peuvent inclure des sanctions réglementaires et réputationnelles significatives.

• Entités financières : les régulateurs nationaux fixent des plafonds très variables. Les plafonds absolus atteignent jusqu’à 20 M€ en Italie, tandis que les plafonds basés sur le chiffre d’affaires vont de 5 % en Espagne à 10 % en Suède ^[4].

• Prestataires TIC tiers critiques : le superviseur principal de l’UE peut imposer des astreintes périodiques pouvant atteindre 1 % du chiffre d’affaires mondial moyen quotidien du prestataire, pour chaque jour de non-conformité, pendant une durée pouvant aller jusqu’à six mois ^[5].

• Au-delà des amendes : les régulateurs peuvent publier des avis publics nommant la partie responsable, ordonner à une entreprise de cesser un comportement spécifique, interdire à des personnes d’exercer des fonctions de direction, ou suspendre une licence.

L’application s’opère à deux niveaux. Les autorités compétentes nationales, telles que la BaFin en Allemagne ou la Banque centrale d’Irlande, supervisent les entités financières.

L’une des trois autorités européennes de surveillance (EBA, ESMA ou EIOPA) agit en tant que superviseur principal pour chaque prestataire TIC critique.

Prouver la résilience grâce à la sauvegarde et à la restauration

Réussir un audit sur le papier n’est pas la même chose que de démontrer concrètement sa capacité à restaurer les données après une attaque.

Les cybercriminels ciblent généralement d’abord les systèmes de sauvegarde, précisément parce qu’ils savent que les organisations en dépendent pour la reprise. Corrompre ou supprimer les sauvegardes donne donc aux attaquants davantage de levier lors des tentatives d’extorsion. Sans surprise, parmi les organisations touchées par un rançongiciel, 94 % ont signalé des tentatives de compromission de leurs données de sauvegarde, et 57 % ont indiqué que ces tentatives avaient réussi ^[6].

Le déploiement d’un stockage sauvegarde immuable vérifiable et d’une restauration rapide garantit qu’une organisation peut démontrer sa résilience aux régulateurs, et pas seulement présenter un document de politique.

Cette approche de protection des données de sauvegarde est pleinement alignée sur l’intention de DORA et sur ses exigences concrètes : des restaurations testées qui respectent les objectifs de temps et de point de reprise (RTO et RPO) en conditions réelles, ainsi qu’une piste de preuves qu’un auditeur peut suivre.

Cette preuve correspond à deux des cinq exigences principales de DORA : la gestion des risques TIC, qui exige une capacité de reprise planifiée, et les tests de résilience, qui exigent de démontrer que cela fonctionne.

Une solution de stockage sauvegarde immuable avec restauration rapide doit constituer l’épine dorsale du plan de reprise d’une organisation. C’est Résilience des données en pratique.

 Qu’exige l’article 12 de DORA en matière de sauvegardes ?

L’article 12 traduit les principes de résilience de DORA en exigences spécifiques de sauvegarde et de restauration. 

Il fixe quatre obligations concrètes : 

• Une politique de sauvegarde documentée précisant quelles données sont sauvegardées et à quelle fréquence, en fonction du caractère critique ou confidentiel de ces données. 

• Des procédures documentées de restauration et de reprise. 

• Des tests périodiques de ces procédures de sauvegarde et de reprise. L’activation d’une sauvegarde ne doit jamais compromettre la sécurité, la disponibilité, l’authenticité, l’intégrité ou la confidentialité des données. 

• Lors de la restauration, les systèmes utilisés doivent être physiquement et logiquement séparés du système source et protégés contre tout accès non autorisé ou toute corruption. 

Les termes mêmes du règlement méritent d’être lus : 

"Les entités financières mettent en place des systèmes de sauvegarde pouvant être activés conformément aux politiques et procédures de sauvegarde ... Les procédures et méthodes de test des procédures de sauvegarde ainsi que des procédures de restauration et de reprise sont réalisées périodiquement ... Lors de la restauration des données de sauvegarde au moyen de leurs propres systèmes, les entités financières utilisent des systèmes TIC physiquement et logiquement séparés du système TIC source." ^[5] 

La conformité peut être atteinte en maintenant des sauvegardes immuables, ce qui signifie que, pendant une fenêtre de temps prédéfinie, une sauvegarde ne peut pas être modifiée ni supprimée. Il faut toutefois être vigilant, car de nombreux systèmes qui prétendent proposer des sauvegardes immuables comportent des exceptions et des failles cachées. 

Une solution consiste à utiliser l’immutabilité absolue Immuabilité, ce qui signifie que même l’administrateur le plus privilégié, ou un attaquant ayant accès au stockage de sauvegarde, ne peut ni modifier ni supprimer les données. Ce niveau de protection ne peut être atteint qu’avec un système de stockage de sauvegarde Sécurisé-by-Design, avec un modèle Zero Access pour exécuter des actions destructrices, et ce Zero Access doit être vérifiable via des tests réalisés par des tiers. 

Le modèle Zero Access est complété par la règle de sauvegarde 3-2-1-1-0 : au moins trois copies des données sur deux types de supports différents, avec une copie stockée hors site et au moins une conservée hors ligne ou immuable afin d’empêcher toute altération. Le dernier zéro signifie zéro erreur de restauration, vérifiée par les tests réguliers exigés par DORA pour garantir le respect des objectifs RTO et RPO, même dans des scénarios extrêmes. 

Stockage de sauvegarde conforme à DORA : comment Object First aide 

Pour s’aligner pleinement sur les exigences de l’article 12 de DORA, le stockage de sauvegarde doit être inviolable, testé et rapidement restaurable. C’est là que Object First intervient. 

Object First fournit un stockage de sauvegarde sécurisé, simple et puissant, conçu spécifiquement pour Veeam. Il intègre l’immutabilité absolue Immuabilité, appliquée via le modèle Zero Access aux actions destructrices : cela signifie que même l’administrateur le plus privilégié ou un attaquant ayant accès au stockage de sauvegarde ne peut ni modifier ni supprimer les données. Cela a été vérifié par des tests indépendants réalisés par des tiers. 

Le résultat : une copie de reprise testée et inviolable, à partir de laquelle une entité financière peut restaurer rapidement — et une preuve de résilience pouvant être présentée aux régulateurs. 

Téléchargez notre guide sur le Digital Operational Resilience Act (DORA) et découvrez comment des sauvegardes absolument immuables peuvent garantir la résilience opérationnelle et, par extension, la conformité réglementaire.

FAQ 

DORA vs NIS2 : quelle est la différence ? 

NIS2 définit des règles générales de cybersécurité pour de nombreux secteurs. DORA est spécifique au secteur financier et prévaut pour les entités financières partout où les deux textes se recoupent, selon un principe juridique appelé lex specialis. 

Une organisation relevant de DORA n’a pas à se conformer à NIS2 pour les mêmes obligations en matière de cybersécurité et de déclaration d’incidents. Pour la directive plus large, utilisez notre check-list de conformité NIS2. 

Quelles sont les exigences de cybersécurité pour être conforme à DORA ?

Les exigences de cybersécurité de DORA s’inscrivent dans son cadre de gestion des risques TIC. Trois articles portent l’essentiel du contenu technique : 

• Article 9 (protection et prévention) : couvre la sécurité réseau, le chiffrement, la gestion des accès et l’application des correctifs. 

• Article 10 (détection) : exige une surveillance continue afin de détecter rapidement les activités anormales et les incidents potentiels. 

• Article 12 (sauvegarde, restauration et reprise) : établit les exigences les plus détaillées de DORA en matière de résilience des sauvegardes, notamment les tests de reprise, la séparation des environnements de restauration et la protection contre les altérations.. 

Ensemble, ils définissent concrètement à quoi ressemble la conformité DORA en cybersécurité. 

Quelle est la date limite de conformité à DORA ?

DORA est en vigueur depuis le 17 janvier 2025 ; la date limite est donc déjà dépassée. En 2025, l’accent a été mis en grande partie sur la mise en œuvre. En 2026, les régulateurs testent de plus en plus la capacité des entreprises à démontrer les capacités de résilience exigées par DORA.  

Quelles institutions supervisent DORA ?

Les autorités nationales compétentes (ANC) de chaque État membre supervisent au quotidien les entités financières individuelles. 

Au-dessus d’elles, les trois autorités européennes de surveillance (ABE, ESMA et EIOPA) ont élaboré les normes techniques de DORA et supervisent directement les prestataires tiers TIC critiques via le cadre de supervision (Oversight Framework), une autorité jouant le rôle de Lead Overseer pour chaque prestataire.

Références

[1] Veeam Software / Censuswide. "96% of EMEA Financial Services Organizations Believe They Need to Improve Their Resilience to Meet DORA Requirements." 2025. https://www.veeam.com/company/press-release/96-percent-of-emea-financial-services-organizations-believe-they-need-to-improve-their-resilience-to-meet-dora-requirements.html 

[2] EIOPA. "Digital Operational Resilience Act (DORA)." https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en 

[3] LRQA. "DORA Compliance." https://www.lrqa.com/en-gb/dora-compliance/ 

[4] DLA Piper. "Divergence in administrative penalties under DORA." 2025. https://www.dlapiper.com/en-us/insights/publications/2025/10/divergence-in-administrative-penalties-under-dora 

[5] Regulation (EU) 2022/2554 (Digital Operational Resilience Act), EUR-Lex. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554 

[6] Sophos. "The State of Ransomware 2025." 2025. https://www.sophos.com/en-us/blog/the-state-of-ransomware-2025 

[7] Veeam. "2025 Ransomware Trends Report." 2025. https://www.veeam.com/blog/ransomware-trends.html