a rack of electronic equipment in a dark room

Qu’est-ce que le règlement DORA ? Explication de la loi européenne sur la résilience opérationnelle numérique

Guide clair des règles européennes de cyberrésilience applicables aux banques, établissements de paiement et prestataires de services sur crypto-actifs sous MiCA : obligations, tests, risque de tiers et autorités compétentes.

Le règlement DORA — le Digital Operational Resilience Act — est la loi de l’UE sur la cyberrésilience du secteur financier. Il indique aux institutions financières comment gérer les risques de cybersécurité et informatiques. En termes simples, chaque banque, établissement de paiement, entreprise d’investissement, assureur et plateforme d’échange de crypto-actifs de l’UE doit pouvoir continuer à fonctionner lors d’un piratage, d’une panne cloud ou d’une mise à jour logicielle défaillante, et surveiller les fournisseurs IT dont il dépend.

Ce guide s’adresse aux personnes sans formation juridique ou IT. Il explique à qui DORA s’applique, ce qu’il exige, dans quels délais signaler un incident, ses différences avec NIS2 et le GDPR, les sanctions prévues, ainsi que ce que les exigences DORA impliquent pour les entreprises fintech et crypto. Il se termine par une courte checklist de conformité DORA.

DORA en termes simples : qu’est-ce que c’est ?

DORA — parfois appelé EU DORA ou DORA Act — est le règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier. L’expression peut sembler complexe, mais elle pose une seule question : votre entreprise peut-elle continuer à servir ses clients lorsque son IT dysfonctionne ? Un pirate s’introduit dans les systèmes, une mise à jour échoue, un fournisseur devient indisponible : les paiements passent-ils encore, les clients peuvent-ils se connecter, leurs données restent-elles sûres ? DORA transforme cette bonne pratique en obligation légale.

Avant DORA, chaque pays de l’UE et chaque segment du secteur financier disposait de ses propres règles de sécurité IT et formulaires d’incident. DORA remplace cet ensemble disparate par un corpus unique pour tout le secteur financier de l’UE. Comme il s’agit d’un règlement et non d’une directive, il s’applique mot pour mot dans chaque État membre, sans loi nationale nécessaire à son entrée en vigueur.

L’échéance de conformité DORA est déjà passée. La période de préparation de deux ans suivant son adoption est terminée, toutes les obligations DORA sont en vigueur et les régulateurs financiers nationaux les contrôlent. Le cadre DORA repose sur cinq piliers, présentés dans la suite de ce guide :

  • gestion des risques ICT — un plan écrit pour les risques IT, relevant de l’organe de direction (le conseil) ;
  • gestion et notification des incidents liés aux ICT — détection, enregistrement et signalement des incidents IT au superviseur ;
  • tests de résilience opérationnelle numérique — des analyses de vulnérabilités courantes aux simulations complètes d’attaques par « red team » ;
  • gestion des risques ICT liés aux tiers — contrôle des fournisseurs IT dont dépend l’entreprise, avec un registre de tous ces fournisseurs ;
  • partage d’informations — échange volontaire de renseignements sur les menaces entre entités financières.

Des résultats, pas des technologies

DORA ne vous impose aucun logiciel ni fournisseur. Il fixe des résultats : être résilient, détecter les problèmes, rétablir rapidement les services et contrôler les fournisseurs. Le conseil est chargé de démontrer que ces résultats sont obtenus, et les administrateurs doivent maintenir à jour leurs connaissances des risques IT (le règlement mentionne expressément la formation). Tout déléguer au service IT puis l’oublier est précisément ce que DORA interdit.

Explication des termes clés de DORA

Quelques termes définis reviennent dans chaque article du règlement DORA, chaque formulaire de supervision et chaque contrat fournisseur. Une fois compris, le reste devient bien plus facile à lire.

Entité financière Le terme du règlement pour une entreprise financière agréée — l’un des vingt types énumérés à l’article 2. Si vous détenez l’un de ces agréments, DORA vous concerne.
Prestataire tiers de services ICT Toute entreprise fournissant de l’IT à une entité financière : hébergement cloud, logiciels, flux de données, sécurité gérée ou traitement des paiements.
Prestataire tiers critique de services ICT (CTPP) Un très grand prestataire — notamment les grandes plateformes cloud — que les autorités de l’UE ont désigné pour une supervision directe par un superviseur principal, car de nombreuses entreprises en dépendent.
Fonction critique ou importante Une fonction opérationnelle dont l’arrêt nuirait gravement aux finances de l’entreprise, compromettrait ses obligations légales ou interromprait ses services agréés. Les paiements et comptes clients en sont des exemples typiques.
Incident majeur lié aux ICT Un incident IT suffisamment important — selon le nombre de clients affectés, sa durée, les données perdues ou les montants en jeu — pour déclencher une notification obligatoire au superviseur.
Test d’intrusion guidé par la menace (TLPT) Un test avancé dans lequel des hackers éthiques attaquent des systèmes en production comme le ferait un véritable attaquant. Il est exigé au moins tous les trois ans pour les entreprises désignées par le superviseur ; celui-ci peut le demander plus souvent.
Registre d’informations Une liste structurée de tous les contrats IT de l’entreprise, tenue à jour et transmise au superviseur au moins une fois par an.
Normes techniques de réglementation (RTS) Les règles détaillées de mise en œuvre — modèles, seuils et méthodes — publiées par les autorités de l’UE pour préciser le règlement.

À qui DORA s’applique-t-il ?

Le champ d’application de DORA est défini par l’article 2, qui énumère vingt catégories d’entités financières. Si une institution financière détient l’un de ces agréments dans l’UE, elle est couverte — quelle que soit sa taille — sauf exemption spécifique. Les principaux groupes figurent ci-dessous.

Secteur Entités concernées À savoir
Banques et paiements Banques, établissements de paiement, établissements de monnaie électronique, prestataires de services d’information sur les comptes Les émetteurs de jetons de monnaie électronique au titre de MiCA sont couverts car ils doivent être des banques ou établissements de monnaie électronique
Investissement et fonds Entreprises d’investissement, gestionnaires de fonds (AIFMs et UCITS), plates-formes de négociation, contreparties centrales, dépositaires centraux de titres Les petites entreprises d’investissement non interconnectées suivent un cadre allégé
Crypto-actifs Prestataires de services sur crypto-actifs et émetteurs de jetons se référant à un ou des actifs Tous deux agréés au titre de MiCA ; couverts dès l’octroi de l’agrément
Assurance et retraites Assureurs, réassureurs, intermédiaires d’assurance, fonds de pension professionnels Les intermédiaires micro, petits et moyens sont exemptés
Données et infrastructures de marché Agences de notation, prestataires de déclaration de données, référentiels centraux de transactions et de titrisation, administrateurs d’indices de référence critiques Plusieurs sont supervisés directement au niveau de l’UE
Autres Plateformes de financement participatif, prestataires tiers de services ICT Voir ci-dessous comment les prestataires IT sont couverts

Qu’en est-il des entreprises IT elles-mêmes ? Les plateformes cloud, centres de données, éditeurs de logiciels et entreprises de sécurité gérée ne sont pas des entités financières, mais DORA les atteint de deux manières. Premièrement, toute entité financière doit intégrer des clauses conformes à DORA dans ses contrats avec elles ; un fournisseur qui refuse risque donc de perdre son client. Deuxièmement, les plus grands prestataires — grands fournisseurs de cloud, de centres de données, de télécommunications et de logiciels financiers — sont désignés prestataires tiers critiques de services ICT et supervisés directement au niveau de l’UE ; la liste est mise à jour chaque année.

DORA s’applique-t-il aux entreprises hors UE ? Directement, uniquement aux entreprises agréées dans l’UE — y compris les filiales et succursales européennes de groupes britanniques, américains ou asiatiques. Indirectement, il atteint tout fournisseur étranger servant une entreprise financière de l’UE, car les clauses contractuelles obligatoires s’appliquent quel que soit son lieu d’établissement. Un prestataire hors UE désigné critique doit créer une filiale dans l’UE dans les douze mois.

Enfin, DORA est proportionné : les obligations augmentent avec la taille et la complexité de l’institution financière. Les microentreprises — moins de dix salariés et moins de deux millions d’euros de chiffre d’affaires ou de bilan — sont dispensées de plusieurs exigences, dont les tests d’intrusion guidés par la menace et certaines obligations de gouvernance et de notification. Un groupe défini de petites entreprises, notamment les petites entreprises d’investissement non interconnectées et certains établissements de paiement et de monnaie électronique exemptés, suit le cadre simplifié de gestion des risques ICT de l’article 16. Être petit ne sort pas une entreprise agréée du champ de DORA ; cela allège seulement la charge.

Exigences DORA : explication des cinq piliers

Les exigences de conformité DORA se répartissent en cinq groupes. Ensemble, elles forment un cycle unique — prévenir, détecter, réagir, rétablir, apprendre — et le régulateur attend des preuves à chaque étape.

Cadre de gestion des risques ICT (articles 5 à 16)

En clair : sachez quels outils IT vous possédez, ce qui peut mal tourner et disposez d’un plan écrit pour les protéger et les rétablir. Le cadre doit répertorier les actifs et dépendances IT, expliquer comment l’entreprise prévient et détecte les problèmes, y répond et se rétablit, puis tire les enseignements des incidents. Il est revu au moins une fois par an et après chaque incident majeur. L’organe de direction l’approuve, décide du niveau de risque acceptable et fournit le budget. Les fonctions critiques doivent être cartographiées, les sauvegardes réellement testées et un plan de continuité IT doit compléter le plan général de continuité de l’entreprise.

Notification des incidents : délais de 4 heures, 72 heures et un mois

Chaque incident lié aux ICT doit être enregistré et classé selon les mêmes critères dans toute l’UE : nombre de clients touchés, atteinte à la réputation de l’entreprise, durée, propagation, données perdues, criticité du service et montants en jeu. Un incident dépassant les seuils est « majeur » et doit être notifié au superviseur en trois étapes : une première notification dans les quatre heures suivant sa qualification comme majeur (et jamais plus de 24 heures après que l’entreprise en a eu connaissance), un rapport intermédiaire dans les 72 heures suivant cette première notification, puis un rapport final dans le mois suivant le rapport intermédiaire. Les clients dont l’argent ou les données sont touchés doivent être informés sans délai. Les cybermenaces graves qui ne sont pas devenues des incidents peuvent être signalées volontairement.

Tests de résilience et tests d’intrusion guidés par la menace (TLPT)

Les tests de résilience opérationnelle numérique constituent un programme annuel : tout système soutenant une fonction critique ou importante doit faire l’objet d’analyses de vulnérabilités, d’analyses d’écarts, de revues de code source, de tests de scénarios, de performance et d’intrusion. Les entreprises que le superviseur considère importantes — en raison de leur taille ou de l’impact de leur défaillance — doivent aussi effectuer un TLPT au moins tous les trois ans. Il s’agit d’une attaque contrôlée contre des systèmes en production, menée par des hackers éthiques qualifiés selon un cadre reconnu. Les microentreprises et entreprises soumises au cadre simplifié sont exemptées de TLPT et testent selon un calendrier allégé fondé sur les risques.

Risque de tiers, externalisation et registre d’informations

Externaliser l’IT — auprès d’un fournisseur cloud ou de tout autre prestataire — n’externalise pas la responsabilité. La gestion des risques liés aux prestataires tiers de services ICT commence par une stratégie écrite de risque fournisseur ; l’entreprise doit vérifier les fournisseurs avant signature, éviter une dépendance excessive à un seul prestataire et tenir un registre d’informations — une liste structurée de chaque contrat IT — transmis au superviseur au moins une fois par an. Les contrats doivent eux-mêmes contenir un ensemble fixe de clauses : le service et le niveau promis, le lieu de stockage des données, le droit d’inspection et d’audit, le devoir d’assistance lors d’incidents, les modalités de résiliation et la façon de changer de fournisseur si nécessaire. L’entreprise reste pleinement responsable, même si le fournisseur critique est supervisé au niveau de l’UE.

Partage d’informations sur les cybermenaces

Les entités financières peuvent échanger des renseignements sur les menaces — schémas d’attaque, indicateurs de compromission — au sein de groupes de confiance. Personne n’est obligé d’y participer, mais une entreprise qui le fait doit en informer son superviseur, et l’échange doit respecter les règles de confidentialité et de protection des données.

DORA, NIS2 et GDPR : articulation des règles

Trois textes de l’UE se recoupent en matière de cyberrésilience et de notification des incidents, et de nombreuses institutions financières relèvent de plusieurs d’entre eux. Le tableau indique qui chacun couvre et en quoi leurs délais de notification diffèrent.

Aspect DORA Directive NIS2 GDPR
Entités couvertes Entreprises financières et leurs fournisseurs IT Entités essentielles et importantes de dix-huit secteurs critiques, dont la banque Toute personne traitant des données personnelles
Ce qui est protégé Continuité des services financiers et de leur IT Sécurité des réseaux et systèmes d’information des secteurs critiques Données personnelles des personnes physiques
Première notification due Dans les 4 heures suivant la classification, au plus tard 24 heures après la connaissance Alerte précoce dans les 24 heures Dans les 72 heures à l’autorité de protection des données
Rapports de suivi Intermédiaire à 72 heures ; final dans le mois Notification à 72 heures ; final dans le mois Par étapes, au fur et à mesure des faits connus
Forme juridique Règlement — application directe Directive — chaque pays rédige sa propre loi Règlement — application directe
Articulation Loi spécialisée : prévaut sur NIS2 pour les entreprises financières S’applique aux entreprises financières seulement lorsque DORA est silencieux S’applique parallèlement ; un incident peut déclencher les deux

En pratique, une entreprise financière signale les incidents IT à son superviseur financier, et non à l’agence nationale de cybersécurité. Le GDPR s’applique parallèlement : si une cyberattaque divulgue des données clients, l’entreprise effectue deux notifications — au superviseur financier sous DORA et à l’autorité de protection des données sous GDPR — selon deux délais distincts.

DORA et crypto : conséquences pour les CASPs et émetteurs de jetons

Pour les entreprises crypto, le règlement DORA et le cadre MiCA fonctionnent ensemble. MiCA détermine qui peut fournir des services sur crypto-actifs ou émettre des jetons dans l’UE ; DORA détermine comment la technologie sous-jacente doit être exploitée. Un prestataire de services sur crypto-actifs agréé au titre de MiCA devient une entité financière au sens de DORA dès l’octroi de son agrément, tout comme tout émetteur de jetons se référant à un ou des actifs. MiCA renvoie lui-même à DORA pour les exigences IT et de sécurité ; les superviseurs lisent donc les deux textes conjointement.

En pratique, la résilience est vérifiée dès la procédure d’agrément, et pas seulement après. Lorsqu’un superviseur examine une demande de CASP, le cadre de risque IT, le plan de continuité d’activité, les procédures d’incident et les dispositifs d’externalisation font partie du dossier ; DORA sert de référence pour leur évaluation. Une plateforme d’échange ou un dépositaire de crypto-actifs ne peut obtenir — ni conserver — son agrément avec un plan de résilience qui n’existe que sur le papier.

Les entreprises crypto ont aussi des dépendances IT qu’une banque n’a pas : conservation de clés privées, fournisseurs de nœuds blockchain, infrastructure de portefeuilles tierce, composants de smart contracts et marchés négociant en continu sans fenêtre de maintenance. Sous DORA, chacun constitue un actif IT ou une relation fournisseur à répertorier, évaluer, contractualiser et tester. C’est aussi ainsi que les fournisseurs non agréés d’hébergement, de gestion de clés ou d’infrastructure blockchain respectent indirectement DORA : par les contrats de leurs clients.

Sanctions, amendes et conséquences du non-respect de DORA

Il n’existe pas de barème unique de sanctions DORA pour toute l’UE. L’article 50 charge plutôt chaque État membre de prévoir des sanctions « effectives, proportionnées et dissuasives » et permet aux superviseurs d’exiger des documents, mener des inspections, ordonner des corrections et publier des avertissements. L’autorité compétente nationale de chaque État membre les applique selon le droit d’agrément du secteur concerné ; une banque, un établissement de paiement et une plateforme crypto font donc face au barème de leur propre secteur.

Vous avez peut-être vu une « amende DORA » de un pour cent du chiffre d’affaires quotidien mondial moyen. Ce chiffre est réel, mais vise une autre catégorie : il s’agit de l’astreinte quotidienne que les autorités européennes de surveillance peuvent infliger à un prestataire tiers critique de services ICT qui ignore une décision de supervision, pendant six mois au maximum. Ce n’est pas une amende pour les banques ou entreprises crypto. Le « 2 % du chiffre d’affaires annuel » parfois cité avec ce chiffre ne figure pas non plus dans DORA : il provient de NIS2, où il constitue le plafond minimal que les pays doivent fixer pour les entités essentielles. Pour une entreprise financière, les conséquences réalistes sont :

  • mesures de surveillance — injonctions de remédier aux problèmes, restrictions d’activité et, dans les cas graves, suspension ou perte de l’agrément ;
  • amendes administratives prévues par le droit national du secteur ;
  • responsabilité personnelle des membres du conseil, car DORA rend le conseil responsable du cadre IT ;
  • responsabilité pénale dans les pays ayant choisi de l’ajouter, comme l’autorise l’article 52 ;
  • préjudice réputationnel et commercial — perte de clients, partenaires bancaires et investisseurs.

Risque d’agrément pour les entreprises autorisées MiCA

Pour un prestataire de services sur crypto-actifs, le risque principal concerne l’agrément lui-même. Une gouvernance IT solide est une condition d’obtention d’un agrément MiCA ; des défaillances DORA répétées peuvent donc être considérées comme le non-respect des conditions d’autorisation, et non comme un simple manquement ponctuel à la conformité.

Qui supervise DORA ? Régulateurs nationaux et européens

La supervision quotidienne de DORA reste assurée par le régulateur qui délivre déjà l’agrément à l’entreprise — la banque centrale ou l’autorité de surveillance financière de son État membre d’origine. Cette autorité compétente reçoit les notifications d’incident et registres d’informations, décide qui doit réaliser un TLPT et contrôle le cadre de risque IT dans le cadre de la supervision ordinaire. La plupart publient sur leur site des orientations, modèles et échéances DORA.

Au niveau de l’UE, trois organismes se partagent le travail : l’Autorité européenne des marchés financiers, l’Autorité bancaire européenne et l’EIOPA, l’autorité des assurances et des pensions. Ils élaborent les normes techniques précisant les détails et désignent conjointement les prestataires tiers critiques de services ICT, chacun étant ensuite supervisé par l’un des trois en tant que superviseur principal.

Checklist de conformité DORA : comment se conformer

Qu’une entreprise demande un agrément ou soit déjà supervisée, le même ensemble de documents prouve la conformité DORA lors d’un audit. Voici un point de départ pratique pour un plan de mise en œuvre DORA ou une analyse d’écarts :

  • Confirmez votre champ d’application : catégorie de l’article 2 dont vous relevez et éventuelle application du cadre simplifié ou d’une exemption de microentreprise.
  • Cartographiez chaque actif IT, système et flux de données soutenant une fonction critique ou importante.
  • Adoptez une politique de gestion des risques ICT approuvée par le conseil, avec des responsables désignés et une revue annuelle.
  • Mettez en place une classification des incidents, un journal d’incidents et des modèles de notification conformes aux délais légaux.
  • Établissez un calendrier annuel de tests et vérifiez si le superviseur vous a inscrit sur la liste TLPT.
  • Constituez le registre d’informations sur tous les fournisseurs IT et actualisez leurs contrats avec les clauses obligatoires.
  • Évaluez le risque de concentration et rédigez des plans de sortie pour les fournisseurs soutenant des fonctions critiques.
  • Testez au moins une fois par an les sauvegardes, la restauration et le plan de continuité IT.
  • Formez le conseil et conservez la preuve de cette formation.

Eesti Firma conseille les entreprises fintech et crypto sur le volet juridique de DORA : détermination des obligations applicables, alignement du cadre IT sur les exigences d’agrément MiCA, examen des contrats fournisseurs et préparation des documents attendus par un superviseur. Contactez-nous pour discuter de l’application du règlement à votre entreprise.

Questions fréquentes sur DORA

Ce guide a été préparé par l’équipe d’Eesti Firma, avec la participation de Cofondateur et directeur juridique Ilja Nikiforov, uniquement à titre informatif. Aucun élément de son contenu ne constitue un conseil juridique, fiscal ou en matière d’investissement. Bien que tout ait été mis en œuvre pour garantir l’exactitude des informations à la date de publication, les lois et réglementations peuvent évoluer. Pour obtenir un accompagnement juridique personnalisé, veuillez contacter directement Eesti Firma.