Le secteur financier a subi plus de 20 000 cyberattaques en deux décennies, avec des pertes cumulées dépassant 12 milliards de dollars, selon le Fonds Monétaire International (FMI). Le même organisme avertit dans son Global Financial Stability Report de 2024 que l'ampleur des pertes extrêmes a plus que quadruplé depuis 2017, pour atteindre 2,5 milliards de dollars. C'est dans ce contexte qu'est né le règlement DORA, en vigueur depuis le 17 janvier 2025 : une norme européenne conçue précisément pour qu'une défaillance des systèmes de technologies de l'information et de la communication (TIC) ne se transforme pas en crise systémique emportant l'ensemble du système financier.
Si votre entité est une banque, une compagnie d'assurance, une société de gestion, un établissement de paiement ou un prestataire technologique au service de l'une d'elles, la conformité à DORA n'est plus facultative. Ce guide explique ce qu'est la norme, à qui elle s'applique, ses cinq piliers, les dates et délais à marquer d'une croix rouge, et une feuille de route pratique pour être prêt à temps.
Qu'est-ce que le règlement DORA et pourquoi importe-t-il au secteur financier ?
Le règlement DORA — acronyme anglais de Digital Operational Resilience Act — est le règlement (UE) 2022/2554 du Parlement européen et du Conseil, du 14 décembre 2022, relatif à la résilience opérationnelle numérique du secteur financier. Contrairement à une directive, que chaque État membre doit transposer dans sa législation nationale, un règlement est directement applicable dans tous les pays de l'Union européenne. Cela signifie que depuis le 17 janvier 2025, ses obligations sont exigibles de manière identique en France, en Allemagne, en Espagne ou en Italie, sans marge d'interprétation locale susceptible de les atténuer.
La logique de DORA est simple à énoncer et exigeante à mettre en œuvre : la stabilité d'un établissement financier ne dépend plus seulement de sa solvabilité ou de sa liquidité, mais également de sa capacité à résister, répondre et se rétablir face aux incidents liés aux TIC. Une attaque par rançongiciel qui paralyse les systèmes de paiement, une indisponibilité prolongée du fournisseur cloud hébergeant le cœur bancaire ou une défaillance en cascade d'un prestataire critique peuvent avoir un impact systémique comparable à une crise de capital.
Les données corroborent cette préoccupation. L'agence européenne de cybersécurité ENISA a analysé 488 incidents cybernétiques signalés publiquement et touchant le secteur financier européen entre janvier 2023 et juin 2024, selon son rapport Threat Landscape: Finance Sector publié en février 2025. Les banques ont été les entités les plus touchées, concentrant 46 % des incidents (301 cas). La conclusion réglementaire est directe : la résilience numérique doit être gérée avec la même rigueur que tout autre risque financier.
DORA harmonise et relève le niveau dans toute l'UE. Avant son entrée en vigueur, les exigences en matière de cybersécurité étaient dispersées dans des guides sectoriels, des recommandations de superviseurs nationaux et des normes éparses. Il existe désormais un cadre unique, contraignant et supervisé par les Autorités européennes de surveillance (les ESA : EBA pour la banque, EIOPA pour l'assurance et ESMA pour les marchés).
À qui s'applique DORA : entités financières et prestataires TIC critiques
Le champ d'application du règlement DORA est délibérément large. Il ne se limite pas aux grandes banques : il couvre pratiquement tout l'écosystème financier réglementé et, pour la première fois de manière contraignante, s'étend également aux prestataires technologiques qui fournissent des services à ces entités.
Entités financières dans le périmètre
DORA s'applique, entre autres, aux catégories d'entités financières suivantes :
- Établissements de crédit (banques) et établissements de paiement.
- Entreprises d'investissement et sociétés de gestion de fonds.
- Entreprises d'assurance et de réassurance, et intermédiaires d'assurance.
- Établissements de monnaie électronique et prestataires de services sur crypto-actifs.
- Infrastructures de marché : dépositaires centraux de titres, contreparties centrales et plateformes de négociation.
- Prestataires de services de financement participatif et agences de notation de crédit.
Le principe de proportionnalité module l'intensité des obligations : les microentreprises et certaines petites entités appliquent un régime simplifié de gestion du risque TIC, tandis que les entités d'importance significative et systémique supportent l'ensemble des exigences, y compris les tests avancés de pénétration.
Prestataires tiers de TIC : la grande nouveauté
L'élément le plus novateur de DORA est qu'il étend son regard aux prestataires tiers de services TIC : éditeurs de logiciels, services gérés, centres de données et, tout particulièrement, les grands fournisseurs de cloud computing. La dépendance du secteur financier à l'égard d'une poignée d'hyperscalers cloud constitue précisément l'un des risques de concentration que la norme entend surveiller.
Pour les prestataires jugés critiques, DORA crée une figure inédite : le prestataire tiers TIC critique (CTPP, selon l'acronyme anglais), soumis à la surveillance directe d'un superviseur principal désigné parmi les ESA. En novembre 2025, les Autorités européennes de surveillance ont publié, par l'intermédiaire de leur Comité mixte, la première liste officielle de 19 prestataires tiers TIC critiques désignés au titre de l'article 31 du règlement. Chacun d'eux relève d'un superviseur principal — EBA, EIOPA ou ESMA — disposant de pouvoirs d'inspection, de demande d'information et de sanction.
Et les sanctions sont dissuasives. Conformément à l'article 35 du règlement DORA, le superviseur principal peut imposer à un prestataire critique des astreintes périodiques pouvant atteindre 1 % du chiffre d'affaires journalier moyen mondial du prestataire pour chaque jour de manquement, pendant une durée maximale de six mois. Pour un hyperscaler mondial, ce pourcentage quotidien se traduit par des montants qu'aucun conseil d'administration ne peut ignorer.
La conséquence pratique pour les entités financières est claire : la responsabilité ne s'externalise pas. Même si vous déléguez des services critiques à un tiers, vous demeurez responsable devant votre superviseur de la résilience de toute la chaîne. C'est pourquoi la gestion contractuelle et des risques des prestataires TIC est devenue un domaine prioritaire, étroitement lié aux travaux d'automatisation et de contrôle que nous traitons dans nos services d'automatisation de la conformité pour les fintech.
Quels sont les 5 piliers du règlement DORA ?
Le règlement DORA s'articule autour de cinq piliers qui, ensemble, couvrent le cycle complet de la résilience opérationnelle numérique : prévenir, détecter, répondre, rétablir et apprendre. Les connaître est la première étape pour traduire la norme en un plan de travail concret.
| Pilier | Articles | Objectif central |
|---|---|---|
| 1. Gestion du risque TIC | Arts. 5-16 | Cadre de gouvernance, identification, protection et rétablissement face aux risques TIC |
| 2. Gestion et notification des incidents TIC | Arts. 17-23 | Classifier et notifier les incidents majeurs à l'autorité compétente dans des délais stricts |
| 3. Tests de résilience opérationnelle numérique (dont TLPT) | Arts. 24-27 | Tester périodiquement la robustesse des systèmes, y compris les tests avancés de pénétration |
| 4. Gestion du risque lié aux tiers TIC | Arts. 28-30 | Contrôler la dépendance envers les prestataires externes et la concentration des risques |
| 5. Partage d'informations sur les menaces | Arts. 45-49 | Partager le renseignement sur les cybermenaces entre entités de manière volontaire |
Pilier 1 : gestion du risque TIC
C'est l'épine dorsale de DORA. Il exige un cadre de gouvernance solide dans lequel l'organe de direction assume la responsabilité ultime de la gestion du risque TIC ; celle-ci ne peut être entièrement déléguée au département technique. Il inclut l'identification des actifs, la protection et la prévention, la détection des anomalies, les politiques de continuité d'activité ainsi que les plans de réponse et de rétablissement.
Pilier 2 : gestion et notification des incidents TIC
Il oblige à mettre en place un processus permettant de détecter, gérer, classifier et notifier les incidents liés aux TIC. Les incidents classés comme majeurs déclenchent des obligations de notification à l'autorité compétente dans des délais très stricts, que nous détaillons dans la section suivante.
Pilier 3 : tests de résilience opérationnelle numérique
Toutes les entités doivent soumettre leurs systèmes à un programme périodique de tests (analyses de vulnérabilités, évaluations de sécurité, tests de continuité). Les entités les plus significatives doivent aller plus loin et réaliser des tests de pénétration fondés sur la menace (TLPT, Threat-Led Penetration Testing), qui simulent des attaques réelles sur des systèmes en production.
Pilier 4 : gestion du risque lié aux tiers TIC
Il établit les exigences contractuelles minimales que doivent comporter les accords avec les prestataires TIC — droits d'accès, d'audit et d'inspection, stratégies de sortie, niveaux de service — et crée le cadre de surveillance directe des prestataires critiques.
Pilier 5 : partage d'informations sur les menaces
Il encourage, à titre volontaire, les entités à partager entre elles des renseignements et des informations sur les cybermenaces au sein de communautés de confiance, afin de renforcer la défense collective du secteur.
Dates clés : en vigueur depuis le 17 janvier 2025
Contrairement à d'autres normes assorties de longues périodes transitoires, DORA a fixé une date unique et ferme. Le règlement (UE) 2022/2554 a été publié en décembre 2022 et a prévu une période d'adaptation de deux ans. Depuis le 17 janvier 2025, ses obligations sont pleinement exigibles. Il n'existe pas de seconde phase : quiconque n'était pas prêt à cette date est en situation de non-conformité depuis lors.
À partir de là, le calendrier est rythmé par les jalons de développement et de supervision :
- 17 janvier 2025 : pleine application du règlement. Toutes les entités du périmètre doivent avoir mis en place leur cadre de gestion du risque TIC, leur processus de notification des incidents et leur registre des contrats avec les prestataires TIC.
- Au cours de 2025 : entrée en application des normes techniques de réglementation (RTS et ITS) élaborées par les ESA, qui précisent des aspects tels que la classification des incidents et les modèles de notification.
- Novembre 2025 : publication par les ESA de la première liste officielle de 19 prestataires tiers TIC critiques désignés, qui entament leur relation avec le superviseur principal correspondant.
Le message pour ceux qui accusent encore du retard est clair : la fenêtre de grâce est désormais fermée. La priorité n'est plus de débattre si DORA s'applique, mais de combler les lacunes existantes avant qu'un incident ou une inspection ne les mette en lumière.
Notification des incidents majeurs : délais de 4 heures, 72 heures et 1 mois
S'il est une obligation de DORA qu'il convient de retenir par cœur, c'est le régime de notification des incidents majeurs. Les délais sont définis dans les normes techniques de réglementation (RTS) élaborées conjointement par l'EBA, l'ESMA et l'EIOPA et repris dans le règlement délégué (UE) 2025/302. Le processus s'articule en trois rapports successifs :
- Notification initiale : elle doit être transmise à l'autorité compétente dès que possible, dans les 4 heures suivant la classification de l'incident comme majeur et, en tout état de cause, au plus tard 24 heures après en avoir eu connaissance.
- Rapport intermédiaire : dans un délai de 72 heures à compter de la notification initiale, avec les informations actualisées sur l'état de l'incident et les mesures prises.
- Rapport final : dans un délai maximal d'un mois, avec l'analyse de la cause profonde, l'impact réel et les actions correctives mises en œuvre pour éviter la récurrence.
| Rapport | Délai | Contenu |
|---|---|---|
| Notification initiale | 4 h après classification comme majeur (max. 24 h après en avoir eu connaissance) | Alerte précoce de l'incident majeur |
| Rapport intermédiaire | 72 h à compter de la notification initiale | État actualisé et mesures en cours |
| Rapport final | 1 mois | Cause profonde, impact et actions correctives |
Respecter ces délais n'est pas seulement une question de bonne volonté : cela exige de disposer d'une capacité de détection et de classification quasi en temps réel. Quatre heures, c'est très peu si l'équipe de sécurité doit découvrir l'incident, évaluer sa gravité, escalader en interne et préparer la notification manuellement. C'est pourquoi l'automatisation de la détection, de la classification et des flux de notification est l'un des projets à meilleur retour sur investissement pour les entités soumises à DORA.
Il convient de souligner la cohérence avec d'autres cadres européens. Les entités ayant déjà travaillé à leur mise en conformité avec la directive sur la cybersécurité des secteurs essentiels partiront avec un avantage, car de nombreux contrôles sont communs ; nous l'expliquons dans notre guide des services de conformité à la directive NIS2. DORA est, de fait, la lex specialis du secteur financier par rapport au cadre général de NIS2.
Comment se préparer à la conformité DORA : feuille de route pratique
La question que nous recevons le plus souvent n'est pas ce que DORA exige, mais par où commencer. Voici une feuille de route en six phases qui ordonne les travaux en fonction de l'impact et des dépendances entre tâches.
1. Diagnostic et analyse des écarts (gap analysis)
Avant d'investir, mesurez. Comparez votre situation actuelle par rapport aux cinq piliers et documentez chaque écart avec son niveau de criticité. Le résultat est une carte thermique qui priorise les efforts et évite de dépenser des ressources là où vous êtes déjà conforme.
2. Gouvernance et responsabilité de l'organe de direction
DORA exige que le conseil d'administration ou l'organe de direction assume formellement la supervision du risque TIC. Cela se traduit par des politiques approuvées au plus haut niveau, une attribution claire des responsabilités et une formation spécifique des dirigeants. La résilience numérique cesse d'être une affaire purement technique pour devenir une responsabilité de gouvernance d'entreprise.
3. Inventaire et registre des prestataires TIC
Constituez et tenez à jour le registre des informations relatif à l'ensemble des accords contractuels avec les prestataires de services TIC, en identifiant ceux qui soutiennent des fonctions essentielles ou importantes. Sans cet inventaire, il est impossible de gérer le risque lié aux tiers ni de répondre à une demande du superviseur.
4. Révision contractuelle et stratégies de sortie
Renégociez les contrats avec les prestataires afin d'y intégrer les clauses minimales exigées par DORA : droits d'audit et d'inspection, niveaux de service, localisation du traitement des données et, notamment, des stratégies de sortie documentées permettant de migrer le service sans interruption critique si le prestataire venait à défaillir.
5. Capacité de détection et de notification des incidents
Mettez en place ou renforcez les outils et processus vous permettant de détecter, classifier et notifier les incidents majeurs dans les délais de 4 heures, 72 heures et un mois. L'automatisation fait ici la différence entre la conformité et l'exposition à la sanction.
6. Programme de tests de résilience
Définissez un calendrier de tests périodiques et, si votre entité fait partie des entités significatives, planifiez les tests de pénétration fondés sur la menace (TLPT). Documentez les résultats, les plans de remédiation et leur suivi.
Un conseil de terrain : abordez DORA comme un programme pluriannuel doté d'une gouvernance propre, et non comme un projet à livraison unique. La supervision est continue et la norme est vivante, avec de nouvelles RTS et de nouvelles désignations de prestataires critiques qui apparaîtront régulièrement.
Récapitulatif de la feuille de route
| Phase | Focalisation | Résultat attendu |
|---|---|---|
| 1. Diagnostic | Gap analysis par rapport aux 5 piliers | Carte des écarts priorisée |
| 2. Gouvernance | Responsabilité de l'organe de direction | Politiques approuvées et rôles définis |
| 3. Inventaire TIC | Registre des prestataires et des fonctions | Registre d'informations à jour |
| 4. Contrats | Clauses DORA et stratégies de sortie | Contrats conformes et plans de sortie |
| 5. Incidents | Détection et notification dans les délais | Flux opérationnel de 4 h / 72 h / 1 mois |
| 6. Tests | Programme de tests et TLPT | Calendrier et preuves de remédiation |
Conclusion : transformer la conformité en résilience réelle
Le règlement DORA n'est pas un simple exercice de conformité administrative. Son objectif de fond — empêcher qu'une défaillance TIC n'escalade jusqu'à devenir une crise financière systémique — s'aligne sur l'intérêt propre de toute entité : continuer à opérer lorsque quelque chose tourne mal. Les chiffres du FMI et de l'ENISA montrent clairement que les incidents cybernétiques dans le secteur financier ne sont pas une hypothèse, mais une réalité quotidienne et croissante. Bien compris, se conformer à DORA revient à investir dans la continuité d'activité et dans la confiance des clients.
La différence entre les entités qui arrivent avec de la marge et celles qui arrivent en retard tient souvent à avoir commencé par un bon diagnostic et à avoir automatisé les processus critiques — détection, classification et notification des incidents — plutôt que d'essayer de les résoudre manuellement sous la pression du temps.
Chez Technova Partners, nous aidons les établissements financiers et leurs prestataires technologiques à parcourir cette feuille de route de bout en bout : du gap analysis à l'automatisation des flux de conformité. Si vous souhaitez une évaluation rapide de votre point de départ, commencez par notre diagnostic gratuit de cybersécurité et conformité, qui couvre également les synergies avec DORA. Et lorsque vous souhaitez concevoir un plan sur mesure, parlez à notre équipe : nous vous aidons à transformer une obligation réglementaire en véritable avantage opérationnel.
