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
DORA signifie Digital Operational Resilience Act, un règlement de l’UE établissant des règles uniformes de gestion des risques ICT, de notification des incidents, de tests de résilience et de risques liés aux tiers pour le secteur financier. Il s’applique directement dans tous les États membres et est pleinement en vigueur.
À vingt catégories d’institutions financières agréées dans l’UE — banques, établissements de paiement et de monnaie électronique, entreprises d’investissement, gestionnaires de fonds, assureurs, prestataires de services sur crypto-actifs et infrastructures de marché — ainsi qu’aux prestataires IT qui les servent, par l’intermédiaire des contrats et de la supervision de l’UE.
Oui. La période de préparation suivant l’adoption est terminée et toutes les obligations s’appliquent pleinement. Les superviseurs traitent désormais DORA comme une composante ordinaire de l’agrément et de l’inspection, et non comme un projet à venir.
Uniquement à leurs filiales et succursales agréées dans l’UE. Les fournisseurs hors UE servant des entreprises financières de l’UE sont liés indirectement par des clauses contractuelles obligatoires, et un prestataire hors UE désigné critique doit établir une filiale dans l’UE dans les douze mois.
NIS2 est une directive générale sur la cybersécurité des secteurs critiques ; DORA est le règlement spécialisé pour la finance. Lorsque les deux pourraient s’appliquer, DORA prévaut pour la gestion des risques IT et la notification des incidents, et les entreprises financières signalent les incidents à leur superviseur financier plutôt qu’à l’agence nationale de cybersécurité.
Oui. Les prestataires de services sur crypto-actifs et émetteurs de jetons se référant à un ou des actifs agréés sous MiCA sont des entités financières au sens de DORA. Les émetteurs de jetons de monnaie électronique sont couverts en tant que banques ou établissements de monnaie électronique. Les fournisseurs non agréés de ces entreprises respectent indirectement DORA par les clauses contractuelles.
En trois étapes : une première notification dans les quatre heures suivant la qualification de l’incident comme majeur et au plus tard 24 heures après en avoir eu connaissance, un rapport intermédiaire dans les 72 heures suivant le premier, puis un rapport final dans le mois suivant le rapport intermédiaire.
Les sanctions applicables aux entreprises financières sont fixées par le droit national en vertu de l’article 50 et appliquées par le superviseur national ; elles vont des injonctions de remédier aux problèmes aux amendes et à la perte de l’agrément. Le chiffre de un pour cent du chiffre d’affaires quotidien mondial est une sanction visant les prestataires tiers critiques de services ICT sous supervision de l’UE, et non les entreprises financières.
Oui, mais de manière proportionnée. Les microentreprises sont dispensées des tests d’intrusion guidés par la menace, de l’obligation fixe de tests annuels et de certaines obligations de gouvernance ; un groupe défini de petites entreprises suit un cadre simplifié de gestion des risques ICT. Une petite taille ne retire pas une entreprise agréée du champ d’application.