DORA : guide de conformité cybersécurité pour le secteur financier en 2026

Le Digital Operational Resilience Act, plus connu sous l’acronyme DORA, redéfinit les exigences de cybersécurité du secteur financier européen. En vigueur depuis le 17 janvier 2025, ce règlement impose un cadre harmonisé de résilience opérationnelle numérique aux banques, assurances, fintech, prestataires de paiement et leurs fournisseurs de technologies de l’information et de la communication (ICT). Pour les RSSI, DSI et responsables conformité du secteur, DORA représente un changement de doctrine, plus contraignant que les approches prudentielles antérieures et accompagné de sanctions effectives.

DORA en 50 mots. Le règlement (UE) 2022/2554 est entré en application le 17 janvier 2025. Il impose à une vingtaine de catégories d’entités financières européennes 5 piliers de résilience opérationnelle : gestion des risques ICT, notification d’incidents (4h / 72h / 1 mois), tests TLPT, supervision des fournisseurs ICT critiques, partage de menaces. Sanctions jusqu’à 1 % du chiffre d’affaires journalier mondial.

Ce guide détaille le périmètre de DORA, ses 5 piliers, les délais de notification d’incidents, les obligations de tests de résilience et la gestion des fournisseurs ICT critiques. Il s’adresse aux équipes qui doivent transformer la conformité DORA en mesures techniques et organisationnelles concrètes.

Qu’est-ce que DORA et qui est concerné ?

DORA est le nom usuel du règlement (UE) 2022/2554 du Parlement européen et du Conseil du 14 décembre 2022, complété par la directive (UE) 2022/2556 qui modifie plusieurs textes sectoriels existants. Son objectif est de bâtir un cadre unique de résilience opérationnelle numérique pour le secteur financier de l’Union, là où les exigences précédentes étaient dispersées entre la directive NIS, les orientations de l’Autorité bancaire européenne et les règles prudentielles nationales.

Le périmètre du règlement est large. Sont concernées les banques, les sociétés d’assurance et de réassurance, les sociétés de gestion de portefeuille, les prestataires de services d’investissement, les intermédiaires d’assurance significatifs, les établissements de paiement et de monnaie électronique, les contreparties centrales, les dépositaires centraux de titres, les agences de notation, les administrateurs d’indices de référence, les prestataires de services de financement participatif, les prestataires de services en cryptoactifs et les fournisseurs de données et de communication financière. Au total, DORA s’applique à une vingtaine de catégories d’entités financières listées à l’article 2 du règlement.

DORA introduit aussi une supervision directe des prestataires ICT critiques tiers (CTPP) par les autorités européennes de supervision. Une grande infrastructure cloud, un éditeur SaaS spécialisé en core banking ou un fournisseur de connectivité réseau peut donc, s’il est désigné critique, tomber sous le contrôle direct de l’EBA, l’ESMA ou l’EIOPA, indépendamment du secteur dans lequel il opère.

Calendrier d’application et entités concernées

DORA est entré en application le 17 janvier 2025, après deux ans de période de transition. Les premières échéances opérationnelles ont rapidement suivi. Le registre d’information sur les arrangements contractuels avec les prestataires ICT, exigé par l’article 28, devait être prêt à être communiqué aux autorités compétentes dès avril 2025 pour une première remise. La désignation des prestataires ICT critiques par les autorités européennes de supervision (les ESAs : EBA, ESMA, EIOPA) a démarré à partir de 2025.

En France, l’autorité compétente est l’ACPR (Autorité de contrôle prudentiel et de résolution), adossée à la Banque de France, pour les banques et assurances. L’AMF intervient pour les sociétés de gestion et certains prestataires d’investissement. Les deux autorités ont publié des fiches dédiées à DORA et organisent régulièrement des webinaires de place pour accompagner les entités assujetties. La FAQ ACPR sur DORA est régulièrement mise à jour, ce qui en fait une référence opérationnelle pour les équipes conformité françaises.

L’écosystème règlementaire européen autour de DORA mobilise les trois ESAs, qui ont publié plusieurs paquets de normes techniques de réglementation (RTS) et d’exécution (ITS) pour préciser les obligations du règlement. Le suivi de ces textes, accessible via les pages DORA de l’EBA et de l’ESMA, est indispensable pour comprendre les attentes concrètes des superviseurs.

Les 5 piliers de DORA

Le règlement DORA s’articule autour de cinq piliers qui structurent l’ensemble des obligations. Comprendre cette architecture est la première étape d’un programme de conformité DORA cohérent.

Pilier 1 : Gestion des risques ICT (articles 5 à 15). L’organe de direction est explicitement responsable de la stratégie de gestion des risques ICT. L’entité doit disposer d’un cadre de gouvernance documenté, d’une cartographie des actifs ICT, d’une politique de sécurité de l’information, d’un dispositif de détection des incidents, de procédures de continuité et de reprise d’activité, ainsi que d’un programme de sensibilisation. Ce pilier impose de passer d’une approche purement projet à une discipline permanente, intégrée à la gouvernance générale de l’entité.

Pilier 2 : Gestion, classification et notification des incidents ICT (articles 17 à 23). DORA crée un régime harmonisé d’identification, de classification et de déclaration des incidents ICT majeurs et des cybermenaces significatives. Les critères de classification reposent sur des seuils quantitatifs et qualitatifs (clients affectés, durée, impact économique, criticité des services, propagation géographique, atteinte aux données). Ce pilier est le plus visible pour les superviseurs car il alimente les rapports d’incidents qui remontent aux ESAs.

Pilier 3 : Tests de résilience opérationnelle numérique (articles 24 à 27). Toutes les entités doivent mettre en place un programme de tests proportionné à leur taille et à leur profil de risque. Les entités significatives sont en outre soumises à des tests de pénétration fondés sur la menace (TLPT, ou Threat-Led Penetration Testing) tous les trois ans, alignés sur le cadre TIBER-EU.

Pilier 4 : Gestion des risques liés aux prestataires tiers ICT (articles 28 à 44). DORA impose un registre d’information détaillé, des clauses contractuelles minimales obligatoires, une stratégie multi-fournisseurs documentée et un cadre de supervision européen pour les prestataires critiques. Ce pilier concerne autant les entités financières que leurs fournisseurs.

Pilier 5 : Partage d’informations sur les cybermenaces (article 45). Le règlement encourage les entités à participer à des dispositifs de partage de renseignement sur les menaces, sous réserve du respect du secret bancaire et de la protection des données. Concrètement, les entités financières peuvent rejoindre des structures sectorielles existantes comme FS-ISAC (Financial Services Information Sharing and Analysis Center), les ISACs nationaux, ou les groupes de partage animés par CERT-EU et l’ENISA. Le pilier 5 est le moins prescriptif, mais il s’inscrit dans une logique européenne plus large d’écosystème CTI sectoriel, complémentaire des dispositifs de Cyber Threat Intelligence déployés par les grands groupes.

Notification d’incidents : délais 4h, 24h, 1 mois

Le pilier 2 de DORA est probablement celui qui mobilise le plus d’attention opérationnelle. Sans télémétrie, sans procédure de classification écrite et sans astreinte qualifiée, les délais imposés ne sont pas tenables.

Le règlement impose trois rapports successifs pour chaque incident ICT classé majeur, conformément aux articles 17 à 19 du règlement (UE) 2022/2554 : une notification initiale dans un délai de 4 heures à compter de la classification de l’incident comme majeur (et au plus tard 24 heures après la détection), un rapport intermédiaire sous 72 heures avec une mise à jour de la situation, puis un rapport final dans un délai d’un mois précisant la cause racine, l’impact et les mesures correctives.

Le déclenchement du chronomètre est la classification interne de l’incident comme majeur, pas sa simple détection. Cela suppose une procédure de classification écrite, alignée sur les seuils du règlement délégué (UE) 2024/1772 publié par les ESAs, et exécutable par l’astreinte sécurité 24/7. Les seuils combinent des critères quantitatifs (plus de 10 % des clients affectés ou plus de 100 000 clients touchés, durée de l’incident supérieure à 24 heures ou indisponibilité de service supérieure à 2 heures pour les fonctions critiques, pertes économiques au-dessus d’un palier) et des critères qualitatifs (criticité fonctionnelle des systèmes touchés, propagation géographique, atteinte aux données à caractère personnel ou stratégiques).

Pour la plupart des entités, le délai de 4 heures n’est tenable que si la détection est automatisée. Une détection humaine via remontée d’utilisateur arrive en général trop tard. Les sources de signaux pertinentes vont au-delà des SIEM internes : exposition d’identifiants sur les forums et canaux Telegram, activité anormale détectée par des partenaires CTI, communications de fournisseurs, alertes ANSSI, signalements de clients. Les organisations matures couplent leur SIEM à des sources externes de détection de fuites d’identifiants pour réduire le délai entre la compromission et la classification.

TLPT (Threat-Led Penetration Testing) : ce que ça implique concrètement

Le TLPT (Threat-Led Penetration Testing) est un test red team obligatoire au minimum tous les 3 ans pour les entités financières significatives désignées par l’ACPR ou l’AMF, fondé sur le cadre TIBER-EU de la Banque centrale européenne (2018), conduit sans préavis sur les systèmes de production par un prestataire certifié indépendant.

Le pilier 3 introduit une obligation de tests de résilience à plusieurs niveaux. Toutes les entités doivent mener des tests réguliers (vulnérabilité, scénarios, continuité), proportionnés à leur taille. Mais une catégorie spécifique d’entités, désignée par les autorités compétentes selon des critères de taille, profil de risque et impact systémique, est soumise au régime renforcé du TLPT.

TIBER-EU prévoit un test red team conduit sur les systèmes de production, sans préavis aux équipes opérationnelles, à partir d’un renseignement de menace personnalisé pour l’entité. Le test imite les tactiques, techniques et procédures (TTPs) d’attaquants réels susceptibles de cibler l’organisation. Le test doit inclure les fonctions critiques de l’entité, y compris les services hébergés chez des prestataires tiers ICT critiques, sous réserve d’un accord contractuel adapté. L’implication des fournisseurs ICT critiques dans les TLPT est l’un des points opérationnels les plus complexes du dispositif et nécessite une renégociation contractuelle anticipée.

Mobilisation type d’un TLPT. Un cycle TLPT s’étale en pratique sur 6 à 9 mois et se découpe en trois phases. La phase de préparation (2 à 3 mois) couvre la sélection du prestataire de threat intelligence, la sélection du prestataire red team, la définition du périmètre des fonctions critiques, la validation du plan de test par l’autorité compétente et la constitution d’une white team restreinte (3 à 5 personnes au plus, RSSI inclus) qui est la seule informée du test côté entité. La phase d’exécution (3 à 4 mois) couvre la collecte de renseignement et la conduite du test red team, opéré sans préavis sur les systèmes de production. La phase de clôture (1 à 2 mois) couvre la restitution croisée red team / blue team, la validation par l’autorité, la rédaction du plan d’action et la communication à la direction générale.

Pour les RSSI, le TLPT n’est pas un audit : c’est un exercice de validation par la preuve de l’efficacité des contrôles. Les défaillances révélées doivent être traitées dans un plan d’action documenté, dont le superviseur peut demander le suivi. Préparer un TLPT suppose au préalable une cartographie à jour des fonctions critiques, une chaîne de détection mature et une capacité de réponse à incident testée par des exercices internes moins ambitieux.

Gestion des fournisseurs ICT critiques : ce qui change dans vos contrats

Le pilier 4 transforme la gestion des prestataires ICT en un processus structuré, contrôlable par le superviseur. La pierre angulaire est le registre d’information de l’article 28, qui recense l’ensemble des arrangements contractuels avec des prestataires ICT, avec un niveau de détail élevé (nature du service, criticité, dépendances, localisation des données et du traitement, droit applicable, sous-traitance).

Le registre n’est pas un livrable ponctuel. Il doit être tenu à jour en permanence et communiqué aux autorités compétentes à leur demande. Le format de remise est précisé par les normes techniques d’exécution (ITS) publiées par les ESAs en 2024, avec un schéma de données harmonisé qui rend non négociable la qualité des métadonnées contractuelles. En France, l’ACPR a précisé les modalités de remise et le calendrier, avec des échéances annuelles ou ad hoc selon les évolutions du périmètre. La maintenance du registre est un projet en soi, qui mobilise les équipes achats, juridique, sécurité et conformité.

DORA impose également des clauses contractuelles obligatoires avec tout prestataire ICT, et des clauses renforcées pour les prestataires supportant des fonctions critiques ou importantes. Ces clauses couvrent au minimum :

la description précise des services et des niveaux de service attendus,
la localisation des données et du traitement, avec des restrictions possibles de sous-traitance hors UE,
les droits d’audit, d’accès et d’inspection, étendus aux superviseurs,
les obligations de coopération en cas d’incident et de test de résilience,
les conditions de résiliation et de stratégie de sortie, y compris la portabilité des données,
le respect des obligations DORA par le prestataire et son devoir d’information sur ses propres sous-traitants.

La supervision européenne directe des prestataires ICT critiques est l’autre nouveauté structurante. Les ESAs désignent les CTPP selon des critères de taille, de substituabilité et d’impact systémique, et exercent sur eux une supervision directe (recommandations, demandes d’information, sanctions). Cette logique de supervision en cascade implique que les entités financières doivent surveiller activement la solidité de leurs fournisseurs, y compris au niveau de leurs propres dépendances. Le suivi de l’exposition des fournisseurs ICT à des fuites d’identifiants ou à des compromissions est devenu, en pratique, un élément du dispositif DORA.

Sanctions et risques de non-conformité

DORA prévoit un régime de sanctions à plusieurs étages. Pour les prestataires ICT critiques tiers soumis à supervision européenne directe, les ESAs peuvent infliger des amendes administratives périodiques pouvant atteindre 1 % du chiffre d’affaires journalier mondial moyen de l’année précédente, par jour, jusqu’à un maximum de six mois. Le mécanisme est conçu pour être dissuasif sans plafonner l’amende à une somme symbolique pour les hyperscalers.

Pour les entités financières, les sanctions relèvent du droit national, conformément aux régimes prudentiels existants. En France, l’ACPR dispose de l’arsenal habituel : avertissement, blâme, sanction pécuniaire, interdiction d’effectuer certaines opérations, retrait d’agrément. La directive (UE) 2022/2556 a ajusté les régimes sectoriels pour intégrer les manquements DORA dans le périmètre des sanctions disponibles. Des sanctions individuelles à l’encontre des dirigeants sont possibles dans plusieurs cas.

Au-delà des amendes, le risque réputationnel pèse lourd. Un incident ICT majeur mal géré, ou un manquement public à une obligation DORA, peut affecter la confiance des clients institutionnels, le coût du risque opérationnel dans les modèles internes (Pilier 2 de Bâle III) et les relations avec les contreparties. Le secteur financier reste un secteur de confiance, et la résilience opérationnelle est désormais un critère de marché autant qu’une exigence réglementaire.

D’un point de vue quantitatif, l’ENISA Threat Landscape 2025 recense 4 875 incidents cyber sur la période juillet 2024 à juin 2025 dans l’UE, dont environ 230 visant directement le secteur financier (4,7 %), avec le ransomware (81,1 % des incidents cybercriminels) et le phishing (60 % des intrusions initiales) comme principaux vecteurs. Pour les entités assujetties à DORA, ces chiffres rendent concrète la probabilité d’un incident ICT majeur sur un horizon de quelques mois, pas de plusieurs années. L’incident de septembre 2024 sur la branche londonienne d’ICBC, où le groupe Hunters International a revendiqué l’exfiltration de 6,6 To de données, illustre la vulnérabilité de l’écosystème financier global et la propagation rapide des incidents via les services ICT mutualisés. À ne pas confondre avec l’incident LockBit de novembre 2023 sur ICBC Financial Services à New York, qui avait paralysé temporairement le règlement de Treasuries américains.

Stealed et la conformité DORA

Stealed est une plateforme française (hébergée chez Scaleway, région fr-par) de détection de fuites d’identifiants qui surveille plus de 100 millions de credentials par jour issus de logs d’infostealers, forums underground et canaux Telegram privés, sources non couvertes par HaveIBeenPwned, avec une latence d’alerte de quelques minutes compatible avec le délai DORA de 4 heures. Pour les équipes sécurité d’entités assujetties, Stealed apporte des briques opérationnelles directement utiles à plusieurs piliers du règlement.

Détection en temps réel pour respecter le délai de 4 heures (pilier 2). L’alerte se déclenche en quelques minutes lorsqu’un identifiant lié à un domaine surveillé apparaît dans une nouvelle fuite. Cette latence courte est compatible avec la fenêtre de 4 heures imposée pour la notification initiale d’incident majeur. La couverture inclut les canaux Telegram privés et les forums underground, qui restent les sources les plus actives en 2026 et qui sont absentes des services basés sur les seules brèches publiques.

Surveillance des fournisseurs ICT et localisation souveraine (pilier 4). Le module External Insight permet de surveiller des domaines tiers (sous-traitants, fournisseurs critiques, plateformes cloud, éditeurs SaaS) et d’identifier les fuites d’identifiants des collaborateurs de ces fournisseurs sur des sites où ils se connectent au nom de l’entité financière. Cette visibilité étendue alimente le suivi de la posture de sécurité des prestataires ICT critiques et nourrit la documentation du registre d’information. L’hébergement Scaleway en France apporte par ailleurs un point de localisation des données qui facilite l’analyse de risque tiers ICT et la documentation des clauses contractuelles relatives à la localisation du traitement.

Intégration SIEM et SOAR (pilier 1). La plateforme expose une API REST documentée et des connecteurs pour Slack, Microsoft Teams, webhook et les principales solutions SIEM/SOAR (Splunk, QRadar, Sentinel). Les alertes Stealed peuvent être ingérées directement dans le SIEM de l’entité, corrélées avec les événements internes et orchestrées dans les playbooks de réponse à incident, ce qui réduit le délai de qualification et accélère la classification DORA.

Évaluez votre dispositif

Réservez 30 minutes avec notre CTO pour échanger sur votre dispositif actuel de détection de fuites d’identifiants et son alignement avec les piliers 1, 2 et 4 de DORA. Si vous préférez tester la plateforme avant tout échange, créez un compte gratuitement pour démarrer la surveillance d’un domaine et évaluer la valeur opérationnelle de Stealed sur vos propres flux.

Questions fréquentes sur DORA

Qui est concerné par DORA en France ? DORA s’applique à toutes les entités financières définies à l’article 2 du règlement (UE) 2022/2554, soit principalement les banques, sociétés d’assurance, sociétés de gestion, prestataires de services d’investissement, établissements de paiement et de monnaie électronique, prestataires de services en cryptoactifs, ainsi que leurs fournisseurs ICT. En France, les autorités compétentes sont l’ACPR pour les banques et assurances, et l’AMF pour les sociétés de gestion. Les microentreprises bénéficient d’un régime allégé, mais ne sont pas exemptées.

Quelle est la différence entre DORA et NIS2 ? NIS2 est une directive transversale qui s’applique à de nombreux secteurs essentiels et importants, tandis que DORA est un règlement sectoriel dédié au secteur financier, d’application directe et plus prescriptif. Pour les entités financières, DORA prime en application du principe de lex specialis : si une exigence est traitée par DORA, elle prévaut sur l’équivalent NIS2. NIS2 reste pertinente pour les fournisseurs ICT non couverts par DORA et pour les autres secteurs.

Quels sont les délais de notification d’incident DORA ? Pour tout incident ICT classé majeur, une notification initiale est due dans un délai de 4 heures à compter de la classification (et au plus tard 24 heures après la détection), un rapport intermédiaire dans les 72 heures, et un rapport final dans un délai d’un mois. Les seuils de classification reposent sur des critères quantitatifs (clients affectés, durée, impact économique) et qualitatifs (criticité fonctionnelle, atteinte aux données) précisés par les normes techniques de réglementation publiées par les ESAs.

Le TLPT est-il obligatoire pour toutes les entités DORA ? Non. Le TLPT (Threat-Led Penetration Testing) est obligatoire pour les entités significatives désignées par les autorités compétentes selon des critères de taille, profil de risque et impact systémique. Les autres entités sont soumises à un programme de tests de résilience proportionné, sans obligation TLPT. Le cadre méthodologique de référence est TIBER-EU, et la fréquence minimale est triennale.

Quel est le coût d’une non-conformité DORA ? Pour les prestataires ICT critiques tiers soumis à supervision européenne directe, les ESAs peuvent infliger des amendes administratives périodiques pouvant atteindre 1 % du chiffre d’affaires journalier mondial moyen, par jour, jusqu’à un maximum de six mois. Pour les entités financières, les sanctions relèvent du droit national (en France, l’ACPR peut prononcer avertissements, blâmes, sanctions pécuniaires, interdictions d’opérations, voire retrait d’agrément, ainsi que des sanctions individuelles à l’encontre des dirigeants). Au-delà des amendes, le risque réputationnel pèse lourd auprès des contreparties et clients institutionnels.

Comment se préparer à un audit ACPR DORA ? Sept dossiers doivent être à jour et accessibles aux superviseurs : (1) la cartographie ICT et la liste des fonctions critiques, (2) le registre d’information des prestataires ICT au sens de l’article 28, (3) la politique de gestion des risques ICT signée par l’organe de direction, (4) les procédures de classification d’incident alignées sur le règlement délégué (UE) 2024/1772, (5) les rapports d’incidents majeurs déjà déclarés et leurs suites, (6) le programme de tests de résilience et les preuves d’exécution, (7) les comptes rendus des comités où DORA est traité au niveau direction. La FAQ ACPR sur DORA et les communications de l’EBA et de l’ESMA précisent les attentes des superviseurs.

Pour aller plus loin

Qu’est-ce qu’un infostealer ? : comprendre le malware à l’origine de la majorité des fuites d’identifiants traitées par les piliers 1 et 2 de DORA.
Glossaire dark web monitoring : vocabulaire et sources de référence pour structurer la veille externe d’une entité financière.
Rapport menaces infostealers mars 2026 : panorama trimestriel des familles d’infostealers et tendances exploitables pour les programmes de tests TLPT.