Conformité DORA en 2026 : guide complet pour les entités financières de l’UE

DORA en 2026 : un an d’application, ce qui a changé

Il y a un an, le 17 janvier 2025, le Digital Operational Resilience Act est entré en application. En tant que règlement plutôt que directive, DORA s’est appliqué directement dans les 27 États membres de l’UE dès le premier jour — aucune transposition nécessaire, aucune variation nationale sur les obligations fondamentales. En mai 2026, le cadre a dépassé la phase de mise en œuvre pour entrer dans la phase d’application active. Les autorités nationales compétentes — la BaFin en Allemagne, l’ACPR en France, la CSSF au Luxembourg, la MNB en Hongrie, la ČNB en Tchéquie et leurs équivalents à travers l’Union — sont passées de l’émission d’orientations à la conduite d’inspections.

La transition n’a pas été fluide. L’exercice à blanc de 2024 des Autorités européennes de surveillance sur le registre d’information a constaté que seulement 6,5 % des près de 1 000 entreprises à travers l’UE ont réussi tous les 116 contrôles de qualité des données. Le cycle 2025 a montré une amélioration mais a tout de même révélé des lacunes de conformité significatives dans la documentation du risque lié aux tiers, les procédures de classification des incidents, et les tests de résilience opérationnelle. Le cycle 2026, avec la date de référence du 31 décembre 2025, est le premier à être pleinement évalué sous une posture d’application.

Deux développements de fin 2025 et début 2026 ont cristallisé le paysage réglementaire. Premièrement, le 18 novembre 2025, les Autorités européennes de surveillance ont publié la première liste officielle de 19 prestataires tiers de services TIC critiques désignés au titre de DORA — dont AWS, Microsoft Azure, Google Cloud, IBM, Bloomberg, le London Stock Exchange Group, Tata Consultancy Services et Orange. Ces désignations placent des prestataires mondiaux nommés sous la surveillance directe de l’UE, avec des équipes d’examen conjointes désormais actives.

Deuxièmement, la revue de la Commission au titre de l’article 58, due au plus tard le 17 janvier 2026, a examiné si les exigences de DORA devraient être renforcées pour les contrôleurs légaux des comptes et les cabinets d’audit — actuellement dans le champ d’application mais avec des obligations limitées. La revue ouvre la porte à des ajustements de champ incrémentaux plus tard dans la décennie. Pour l’instant, les entités dans le champ d’application opèrent au titre du cadre original, et le test pratique est de savoir si elles peuvent produire des preuves défendables dans le délai de quatre heures lorsqu’un incident se produit.

Pour les organisations soumises à DORA, ce guide se concentre sur le test opérationnel plutôt que sur le texte de politique. La cascade de signalement en trois étapes de l’article 19 est l’obligation unique la plus conséquente du règlement, et la fenêtre de notification initiale de quatre heures est nettement plus serrée que l’alerte précoce à 24 heures de NIS2. Le reste du règlement — risque lié aux tiers, tests opérationnels, sanctions — gravite autour de ce point central : lorsque quelque chose tourne mal, votre organisation peut-elle documenter ce qui s’est passé avec la rapidité et l’intégrité que le régulateur attend désormais ?

Champ d’application : qui relève de DORA

Le champ d’application de DORA est défini positivement et largement. Contrairement à NIS2, qui utilise la criticité sectorielle plus une règle de plafond de taille, DORA s’applique à pratiquement chaque entité financière réglementée de l’Union européenne — sans seuil de taille minimal pour la plupart des catégories. L’Autorité bancaire européenne estime qu’environ 22 000 entités financières relèvent du champ d’application de DORA à travers l’Union.

Entités financières dans le champ d’application (liste non exhaustive)

Les catégories incluent les établissements de crédit, les établissements de paiement et de monnaie électronique, les entreprises d’investissement, les prestataires de services sur crypto-actifs, les dépositaires centraux de titres, les contreparties centrales, les plateformes de négociation, les référentiels centraux, les gestionnaires de fonds d’investissement alternatifs, les sociétés de gestion d’OPCVM, les prestataires de services de communication de données, les entreprises d’assurance et de réassurance, les intermédiaires d’assurance, les institutions de retraite professionnelle, les agences de notation de crédit, les contrôleurs légaux des comptes et les cabinets d’audit, les administrateurs d’indices de référence critiques, les prestataires de services de financement participatif, et les référentiels des titrisations. Presque chaque catégorie spécifiquement définie dans le droit des services financiers de l’UE est incluse.

Aucune exemption générale de plafond de taille

C’est une différence fondamentale avec NIS2. Là où NIS2 exempte par défaut les entités de moins de 50 employés et 10 M€ de chiffre d’affaires, DORA s’applique généralement quelle que soit la taille. Les plus petites entités financières — petits établissements de paiement, petites entreprises d’investissement, petits prestataires de services sur crypto-actifs — relèvent du champ d’application aux côtés des plus grandes banques. DORA contient bien un principe de proportionnalité : le règlement exige explicitement que les obligations soient appliquées de manière simplifiée à certaines microentreprises et petites institutions, mais les obligations substantielles s’appliquent.

Les prestataires tiers de services TIC comme catégorie distincte

Les prestataires tiers de services TIC servant les entités financières sont traités différemment. Ils ne sont pas des sujets directs des obligations de gestion des risques ou de signalement d’incidents de DORA. Au lieu de cela, ils sont atteints indirectement via les exigences contractuelles du chapitre V imposées aux entités financières, et directement — pour les plus grands prestataires — via le cadre de surveillance des prestataires tiers de services TIC critiques (CTPP). Les 19 CTPP désignés en novembre 2025 sont désormais soumis à la surveillance directe de l’UE via des équipes d’examen conjointes et paient une redevance de surveillance.

Portée géographique et effet extraterritorial

DORA s’applique aux entités financières établies dans l’Union. Les prestataires tiers de services TIC établis hors de l’Union mais servant des entités financières de l’UE dans le champ d’application sont atteints contractuellement via les exigences du chapitre V — l’entité financière doit imposer des conditions conformes à DORA au tiers, indépendamment du lieu d’établissement du tiers. Cela a effectivement poussé des obligations équivalentes à DORA dans les conditions contractuelles standard des grands fournisseurs de cloud, éditeurs de logiciels, et partenaires d’externalisation, même lorsque ces prestataires ont leur siège aux États-Unis ou ailleurs hors de l’UE.

Les cinq piliers de DORA en un coup d’œil

DORA est conventionnellement décrit comme reposant sur cinq piliers, correspondant à ses principaux chapitres substantiels. Comprendre les cinq piliers et comment ils s’imbriquent fournit le cadre pour le reste de ce guide.

Pilier 1 : gestion des risques TIC (articles 5 à 16)

Les entités financières doivent mettre en œuvre un cadre complet de gestion des risques TIC, la responsabilité reposant au niveau de l’organe de direction. Le cadre doit couvrir l’identification, la protection, la détection, la réponse, la récupération, et l’apprentissage continu. L’article 6 énumère les composants : dispositifs de gouvernance, politique de continuité d’activité TIC, procédures de réponse et de récupération, et mécanismes d’apprentissage et d’évolution. Le cadre doit être revu au moins annuellement et mis à jour après les incidents liés aux TIC significatifs.

Pilier 2 : gestion, classification et signalement des incidents liés aux TIC (articles 17 à 23)

Les articles 17 à 23 établissent comment les entités financières doivent détecter, classer, gérer et signaler les incidents liés aux TIC. Les obligations de signalement au titre de l’article 19 — et le calendrier serré en trois étapes qu’elles imposent — sont le composant le plus exigeant sur le plan opérationnel de DORA pour les équipes de réponse aux incidents. Ce pilier est au cœur d’une grande partie de ce guide.

Pilier 3 : tests de résilience opérationnelle numérique (articles 24 à 27)

Les entités financières doivent tester régulièrement leur résilience opérationnelle numérique, le programme de tests étant proportionné à la taille et au risque. L’article 25 spécifie les exigences de test de base applicables à toutes les entités dans le champ d’application ; l’article 26 introduit les tests de pénétration fondés sur la menace pour les entités financières significatives, sur la base du cadre TIBER-EU, conduits au moins tous les trois ans sur des systèmes de production en direct.

Pilier 4 : gestion des risques liés aux tiers TIC (articles 28 à 44)

Le chapitre V traite du risque lié aux tiers, que le régulateur considère comme le principal vecteur de perturbation systémique dans les services financiers modernes. Le chapitre inclut des obligations sur les conditions contractuelles, la due diligence des fournisseurs, le registre d’information, les contrôles de sous-traitance, et — de façon la plus distinctive — le cadre de surveillance des prestataires tiers de services TIC critiques. C’est là que se situent les innovations structurelles les plus nouvelles du règlement.

Pilier 5 : dispositifs de partage d’informations (article 45)

L’article 45 encourage les entités financières à participer à des dispositifs de partage d’informations concernant les informations et le renseignement sur les cybermenaces. La participation est volontaire, mais le règlement établit un cadre juridique permissif — clarifiant notamment que le partage d’informations dans les paramètres du cadre ne constitue pas une violation des obligations de confidentialité ou de protection des données. Le pilier est plus léger sur le plan opérationnel que les autres mais juridiquement habilitant.

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

Le chapitre II de DORA, comprenant les articles 5 à 16, établit le cadre de gestion des risques TIC que chaque entité financière dans le champ d’application doit mettre en œuvre et maintenir. Le cadre est le fondement sur lequel reposent les piliers de la réponse aux incidents, des tests, et du risque lié aux tiers. Là où le cadre est faible, les obligations dépendantes ne peuvent pas être remplies de manière crédible lors de l’inspection.

Responsabilité de l’organe de direction (article 5)

L’article 5 place la responsabilité ultime du cadre de gestion des risques TIC sur l’organe de direction — conseil d’administration ou équivalent. L’organe de direction doit définir et approuver le cadre, superviser sa mise en œuvre, et assurer un budget et des ressources humaines adéquats. Les membres de l’organe de direction doivent maintenir des connaissances et compétences suffisantes pour comprendre et évaluer le risque TIC ; c’est une obligation substantielle, pas formelle, et le régulateur peut exiger la preuve d’une formation au niveau du conseil et d’un engagement actif.

Cadre complet de gestion des risques TIC (article 6)

L’article 6 spécifie les composants : un cadre documenté approuvé par l’organe de direction, des dispositifs organisationnels avec des rôles et responsabilités clairs, une politique de continuité d’activité, des procédures de réponse et de récupération, des mécanismes d’apprentissage, et la protection des actifs TIC tout au long de leur cycle de vie. Le cadre doit être proportionné à la taille, la nature, la complexité et le profil de risque de l’entité — mais les éléments substantiels sont obligatoires. La proportionnalité affecte l’intensité, pas la couverture.

Identification, protection, détection, réponse, récupération (articles 7 à 13)

Les articles 7 à 13 élaborent les capacités fonctionnelles. L’identification couvre les systèmes TIC, la classification des actifs d’information, et l’identification des fonctions métier soutenues par les TIC. La protection couvre les politiques de sécurité, la gestion des identités et des accès, le chiffrement, et la sécurité des opérations. La détection couvre la surveillance, la détection d’anomalies, et les alertes. La réponse et la récupération couvrent la continuité d’activité, les procédures de réponse, et la communication de crise. L’apprentissage couvre les revues post-incident, l’analyse des causes racines, et l’amélioration continue.

Plan de communication de crise (article 14)

L’article 14 exige des entités qu’elles aient un plan de communication de crise couvrant le personnel interne, les clients, les contreparties financières, le public, et les autorités de contrôle. Le plan doit traiter de la façon dont la communication sera coordonnée lorsqu’un incident se produit à travers plusieurs groupes de parties prenantes — pour lequel la preuve forensique devient essentielle, à la fois comme intrant des communications et comme dossier défensif au cas où les communications seraient ultérieurement remises en question par des clients, contreparties, ou régulateurs.

Revue annuelle (article 6(5))

Le cadre doit être revu au moins annuellement et mis à jour chaque fois que des incidents liés aux TIC significatifs se produisent, lorsque des instructions de contrôle surviennent, ou lorsque des changements significatifs de l’environnement TIC de l’entité ont lieu. La revue annuelle est elle-même documentée et démontrable ; elle fait partie de la piste d’audit que les autorités de contrôle examinent lors des inspections, et les lacunes dans l’historique des revues sont devenues un point récurrent du retour des superviseurs dans la phase d’application précoce.

Article 19 : le calendrier de signalement en trois étapes

L’article 19 est le cœur opérationnel de DORA pour la réponse aux incidents. Il établit une cascade de signalement en trois étapes déclenchée lorsqu’un incident lié aux TIC est classé comme majeur — et les délais sont nettement plus serrés que les obligations équivalentes de NIS2. Les délais détaillés et les exigences de contenu sont spécifiés dans le règlement délégué (UE) 2025/301 de la Commission du 23 octobre 2024, avec des modèles et procédures spécifiés dans le règlement d’exécution (UE) 2025/302 de la Commission.

Étape 1 — notification initiale : 4 heures à partir de la classification, max 24 heures à partir de la détection

La notification initiale doit parvenir à l’autorité compétente dans les 4 heures suivant le moment où l’entité financière classe l’incident comme majeur. La classification elle-même doit se produire dès que raisonnablement possible après la détection, et en tout état de cause dans les 24 heures suivant la détection. L’effet combiné : de la détection à la notification initiale, le temps écoulé maximal admissible est de 28 heures — mais en pratique, les régulateurs attendent que la chaîne se comprime à quelques heures, pas quelques jours. Retenir la notification parce que l’enquête est incomplète n’est explicitement pas conforme ; la notification initiale est destinée à fournir une conscience précoce, pas une analyse complète.

Étape 2 — rapport intermédiaire : 72 heures à partir de la notification initiale

Dans les 72 heures suivant la notification initiale, l’entité financière doit soumettre un rapport intermédiaire fournissant une description substantiellement plus riche de l’incident, dont l’état actuel, la classification affinée, l’évaluation de l’impact, et toute information supplémentaire demandée par l’autorité compétente. Lorsque l’incident reste actif ou que l’analyse des causes racines est incomplète, le rapport intermédiaire le reconnaît explicitement et esquisse les prochaines étapes. Les 72 heures courent à partir de la notification initiale, pas de la détection — une distinction cruciale par rapport au GDPR.

Étape 3 — rapport final : au plus tard un mois après le rapport intermédiaire

Au plus tard un mois après le rapport intermédiaire, l’entité financière soumet le rapport final. Celui-ci contient une description complète de l’incident, sa cause racine, les détails techniques et opérationnels, l’impact (dont la perte financière et le nombre de clients affectés), les mesures correctives prises, les leçons apprises, et les améliorations planifiées. Le rapport final est le document auquel les autorités de contrôle reviennent lors des inspections et audits ultérieurs — sa qualité détermine comment l’incident est mémorisé dans le dossier réglementaire.

Notification volontaire de cybermenaces significatives (article 19(2))

L’article 19(2) permet — mais n’exige pas — que les entités financières notifient volontairement les cybermenaces significatives. Le régime de notification volontaire permet aux entités de partager le renseignement sur les menaces même là où aucun incident ne s’est matérialisé, aidant le secteur financier plus large à se préparer. Les États membres peuvent étendre l’acheminement de la notification volontaire aux CSIRT de NIS2 également. Bien que volontaires, ces notifications font partie de la vue du régulateur sur la maturité du risque TIC et la posture d’engagement de l’entité.

Obligation de notification des clients (article 19(3))

Lorsqu’un incident majeur lié aux TIC a un impact sur les intérêts financiers des clients, l’entité financière doit — sans retard indu, dès qu’elle en prend conscience — informer les clients de l’incident et des mesures prises pour atténuer les effets négatifs. Les notifications aux clients font partie du dossier probant public ; une fois publiées, elles contraignent la façon dont l’entité peut ultérieurement caractériser l’incident dans les soumissions réglementaires ou en contentieux. La capture forensique des notifications aux clients elles-mêmes — dont la version publiée, l’horodatage, et toute mise à jour ultérieure — devient partie du dossier défensif.

Classification des incidents majeurs : les sept critères

Seuls les incidents majeurs liés aux TIC déclenchent les obligations de signalement de l’article 19. Le seuil est défini par le règlement délégué (UE) 2024/1772 de la Commission, qui spécifie sept critères de classification et les seuils de matérialité pour chacun. Comprendre précisément les critères est essentiel — une classification incorrecte est en soi un défaut de conformité, et le sur-signalement n’est pas pénalisé tandis que le sous-signalement entraîne des conséquences administratives directes.

Les sept critères de classification

Les sept critères sont : la criticité des services affectés ; le nombre et la pertinence des clients, contreparties financières et transactions affectés ; l’impact réputationnel ; la durée et l’indisponibilité du service ; l’étendue géographique ; les pertes de données ; et l’impact économique. Chaque critère a son propre seuil de matérialité, et la logique de classification les combine via une structure à double déclencheur plutôt que de traiter un seul critère comme décisif.

Le double déclencheur : services critiques + perte de données OU deux seuils

Un incident lié aux TIC est classé comme majeur lorsque des services critiques ou importants ont été altérés, et soit le seuil de matérialité pour les pertes de données a été atteint — signifiant tout accès non autorisé réussi, malveillant, aux réseaux et systèmes d’information entraînant une perte de données — soit au moins deux des autres seuils de matérialité ont été dépassés. La logique à double déclencheur garantit que les incidents graves à critère unique (en particulier les pertes de données) sont capturés aux côtés des perturbations multifacettes qui peuvent ne pas franchir individuellement un plafond unique.

Seuils de matérialité quantitatifs

Plusieurs seuils sont quantitatifs. Le nombre de contreparties financières affectées doit dépasser 30 % de toutes les contreparties financières utilisant le service affecté. Le nombre de transactions affectées doit dépasser 10 % du nombre moyen quotidien, ou 10 % de la valeur moyenne quotidienne, des transactions liées au service. D’autres seuils sont qualitatifs, dont l’impact réputationnel évalué au regard de facteurs comme la couverture médiatique grand public, l’escalade de l’examen réglementaire, et le risque matériel de perte de clientèle.

L’accès non autorisé malveillant réussi comme déclencheur automatique

Comme avec le règlement d’exécution 2024/2690 de la Commission de NIS2, les règles de classification de DORA traitent l’accès non autorisé malveillant réussi comme un indicateur de significativité automatique. Lorsqu’un attaquant a obtenu l’accès aux réseaux et systèmes d’information avec une intention malveillante apparente, et que l’accès a entraîné ou peut entraîner une perte de données, l’incident est majeur indépendamment des autres seuils. Cela supprime le débat pendant les premières heures de la réponse : si un intrus est confirmé et que l’accès est suspect, le chronomètre de quatre heures se déclenche.

Incidents récurrents et évaluation agrégée

Une série de plus petits incidents peut collectivement atteindre le seuil majeur même si aucun événement individuel ne l’atteindrait. Le règlement de classification exige des entités qu’elles évaluent les incidents récurrents en agrégat, en particulier lorsque la même cause racine produit plusieurs événements distincts. Documenter le lien entre les incidents est en soi un défi probant — exigeant une rétention de journaux cohérente, une capture forensique des artefacts d’attaque tournés vers le web récurrents, et une chaîne analytique documentée reliant les événements sur ce qui peut être des semaines ou des mois.

Pourquoi la préservation des preuves équivaut à la conformité DORA

La fenêtre de notification initiale de quatre heures de DORA change le calcul opérationnel de la réponse aux incidents d’une manière que peu d’entités réglementées par DORA de première année ont pleinement intériorisée. Là où l’alerte précoce à 24 heures de NIS2 permet un certain temps de triage, DORA attend que la notification initiale soit soumise avec quelque information que ce soit disponible — et affinée plus tard dans les rapports intermédiaire et final. Cela signifie que la preuve soutenant le rapport final éventuel doit être capturée pendant les premières heures de l’incident, lorsque les équipes contiennent simultanément l’attaque, restaurent les services, et notifient les autorités. La fenêtre pour le renforcement des capacités se ferme au moment où la détection se produit.

Le règlement délégué (UE) 2025/301 de la Commission, qui spécifie le contenu des notifications initiale et ultérieures, exige que le rapport initial inclue — lorsque disponibles — des informations sur si l’incident implique une activité malveillante, l’impact immédiat sur les services, l’étendue géographique, et les contreparties financières affectées. Au stade du rapport intermédiaire, ce contenu doit être affiné et étendu. Au stade du rapport final, l’analyse des causes racines, les détails techniques de l’attaque, et les leçons apprises doivent tous être documentés. Aucun de ceux-ci n’est réalisable sans preuve forensique préservée dès le moment de la détection.

La catégorie de preuve la plus vulnérable sur le plan opérationnel pour les entités financières est l’infrastructure d’attaque tournée vers le web. Les pages de hameçonnage usurpant les interfaces de banque de détail, les faux portails d’autorisation de paiement, les fausses pages de soumission de documents KYC, les plateformes d’investissement sosies, et les campagnes d’usurpation de marque sur les réseaux sociaux sont toutes conçues pour récolter des identifiants financiers, des données de paiement, ou de la documentation d’intégration. Chacune de celles-ci est hébergée sur une infrastructure que l’entité financière ne contrôle pas. Les fournisseurs d’hébergement retirent les pages de hameçonnage dans les heures suivant la notification. Les attaquants abandonnent l’infrastructure qui a été détectée. Le temps que le rapport intermédiaire soit dû 72 heures plus tard, la preuve a disparu à moins qu’elle n’ait été capturée pendant les premières heures.

C’est la lacune opérationnelle que les plateformes de preuve web forensique comme GetProofAnchor sont conçues pour combler. Une capture faite au moment de la détection de l’incident produit un paquet inviolable — HTML complet, capture d’écran rendue, contenu extrait, métadonnées réseau, et le cas échéant la chaîne de certificats TLS — liés ensemble par un horodatage électronique qualifié au titre de l’article 42 d’eIDAS et ancrés indépendamment dans la blockchain Bitcoin via OpenTimestamps. Lorsque l’autorité nationale compétente demande deux semaines plus tard la preuve que la page de hameçonnage existait et opérait contre les clients de la banque, la preuve est disponible avec une intégrité mathématique plutôt qu’une mémoire reconstituée.

Le point n’est pas que chaque entité DORA doit adopter un outil spécifique. Le point est que la préservation des preuves pendant les premières heures d’un incident est une obligation de conformité de premier ordre au titre de DORA — et que les entités financières qui n’ont pas bâti cette capacité avant qu’un incident ne se produise découvriront, pendant le délai de quatre heures, que l’absence de preuve préservée devient son propre défaut à signaler. Le rapport intermédiaire est dû 72 heures après la notification initiale. Le rapport final est dû un mois plus tard. La preuve soutenant les deux doit être intacte, et elle doit être défendable devant un superviseur.

Capturer forensiquement les preuves d’incidents TIC du secteur financier

Les incidents TIC du secteur financier laissent leur trace forensique primaire selon des schémas distinctifs. Comprendre les catégories de preuves spécifiques qui reviennent dans les incidents majeurs DORA — et comment les capturer d’une manière qui satisfait les attentes de l’autorité compétente — est l’une des capacités opérationnelles à plus fort levier qu’une entité financière peut développer en 2026. Les cinq catégories suivantes couvrent l’essentiel de la preuve forensique tournée vers le web dans les incidents DORA.

Pages de hameçonnage usurpant les interfaces de banque de détail

Les pages de hameçonnage de banque de détail sont le vecteur d’attaque unique le plus courant contre les clients des banques, et elles sont aussi les plus fragiles sur le plan probant. Un opérateur de hameçonnage met en place la page sur un domaine sosie, exécute la campagne pendant des heures ou des jours, et abandonne ou migre l’infrastructure une fois la page signalée. La capture forensique doit inclure le HTML complet, le rendu visuel sur les fenêtres d’affichage bureau et mobile, la chaîne TLS montrant le certificat du domaine sosie (souvent un certificat Let’s Encrypt gratuit, qui est en soi pertinent sur le plan probant), et les captures réseau montrant le point d’exfiltration des identifiants. L’autorité de contrôle voudra le DOM sous-jacent et l’identité réseau de l’infrastructure malveillante, pas une capture d’écran.

Fausses pages d’autorisation et de confirmation de paiement

Une variante plus sophistiquée intercepte le flux d’authentification de paiement — typiquement en présentant une fausse page 3-D Secure ou d’authentification forte du client PSD2 pendant ce qui semble être une transaction légitime. Ces pages existent pour capturer les codes à usage unique aux côtés des identifiants principaux. La valeur probante réside dans le fait de montrer la mimétique visuelle précise, les appels réseau capturant l’OTP, et la logique de redirection. La capture doit se produire pendant l’opération en direct de la campagne ; après le retrait de la page, la trace forensique consiste exclusivement en ce qui a été capturé à l’époque, et la position défensive de la banque dépend de la qualité de cette capture.

Plateformes d’investissement et échanges de crypto usurpant la marque

Une part croissante des incidents significatifs DORA en 2025 et 2026 a impliqué de fausses plateformes d’investissement et des interfaces sosies de prestataires de services sur crypto-actifs. Celles-ci combinent typiquement l’usurpation de domaine avec une mimétique multipage substantielle — faux tableaux de bord de comptes, faux historiques de transactions, fausses interfaces de dépôt. La capture forensique doit parcourir le parcours utilisateur complet de l’usurpation, capturant idéalement chaque page de l’interface de l’attaquant aux côtés de l’état réseau au moment de la capture. Le paquet de preuve résultant soutient à la fois le signalement DORA et l’engagement ultérieur des forces de l’ordre au titre du droit national de procédure pénale.

Faux portails de soumission de documents KYC et d’intégration

Certaines campagnes d’attaquants ciblent l’intégration des clients plutôt que les comptes actifs. Les faux portails KYC récoltent des documents d’identité — passeports, permis de conduire, justificatifs de domicile — qui sont ensuite revendus ou utilisés dans une fraude ultérieure. Du point de vue de l’entité financière, la preuve de ces campagnes est pertinente à la fois pour le signalement d’incidents DORA et pour les notifications de violation de données personnelles au titre de l’article 33 du GDPR. Une seule capture forensique soutient les deux voies réglementaires, à condition qu’elle soit construite avec les primitives d’intégrité que les deux régulateurs attendent.

Preuve de panne et d’incident de prestataire tiers de services TIC critique

Lorsqu’un prestataire tiers de services TIC critique désigné subit une panne qui affecte les services d’une entité financière, l’entité financière doit capturer la preuve de l’état du tiers au moment de l’incident. C’est un territoire probant réellement nouveau au titre de DORA — l’entité doit documenter quelque chose qu’elle ne contrôle pas, sur une infrastructure exploitée par un CTPP sous la surveillance directe des AES. La capture forensique de la page d’état du CTPP, de la télémétrie de dégradation de service propre à l’entité, et de toute déclaration publique émise par le CTPP pendant l’incident devient le fondement du rapport d’incident DORA de l’entité et de toute réclamation de récupération ultérieure contre le CTPP.

Gestion des risques liés aux tiers TIC (chapitre V)

Le chapitre V de DORA — articles 28 à 44 — traite de ce que les superviseurs européens considèrent comme le principal vecteur de perturbation systémique dans les services financiers modernes : la dépendance des entités financières envers un petit nombre de grands prestataires tiers de services TIC. Le chapitre est l’élément le plus controversé en interne de DORA dans les consultations sectorielles et le plus exigeant sur le plan opérationnel pour les entités dans le champ d’application, en particulier celles qui ont externalisé des portions substantielles de leur pile technologique au cours de la dernière décennie.

L’article 28 établit le principe général : les entités financières restent pleinement responsables du respect de toutes leurs obligations au titre de DORA, indépendamment de la mesure dans laquelle elles s’appuient sur des prestataires tiers de services TIC. Ce principe de non-délégation est le fondement du régime des tiers — le régulateur ne peut pas poursuivre le tiers pour les défaillances de l’entité, mais l’entité ne peut pas échapper à sa responsabilité en pointant le tiers. La chaîne contractuelle doit amener le comportement du tiers dans le contrôle de l’entité via des mécanismes spécifiques et exécutoires.

L’article 30 spécifie les dispositions contractuelles obligatoires pour les services TIC des tiers soutenant des fonctions critiques ou importantes. Les contrats doivent inclure — entre autres éléments — une description complète des services, les lieux où les services sont fournis et où les données sont traitées, les exigences de niveau de service, les exigences de sécurité et de résilience TIC, les droits d’audit de l’entité, les droits de résiliation dont les stratégies de sortie, la coopération avec les autorités compétentes, et les obligations de notification d’incidents du tiers vers l’entité financière. Le règlement délégué (UE) 2025/532 de la Commission du 24 mars 2025 spécifie les éléments que les entités financières doivent déterminer et évaluer lors de la sous-traitance de services TIC soutenant des fonctions critiques ou importantes.

Le registre d’information — requis au titre de l’article 28(3) et spécifié dans les normes techniques d’exécution — est l’inventaire centralisé que les entités financières doivent maintenir de tous leurs arrangements contractuels avec les prestataires tiers de services TIC, y compris les sous-traitants. Le cycle de signalement 2026 couvre les arrangements avec la date de référence du 31 décembre 2025, avec des échéances de soumission nationales variant selon l’État membre. L’exercice à blanc de 2024 des AES a constaté que seulement 6,5 % des près de 1 000 entreprises à travers l’UE ont réussi tous les 116 contrôles de qualité des données — illustrant l’ampleur de l’ajustement opérationnel encore requis pour la pleine conformité, même avec les obligations documentaires du chapitre V.

Prestataires tiers de services TIC critiques : les désignations de novembre 2025

Le 18 novembre 2025, les Autorités européennes de surveillance — l’ABE, l’AEAPP, et l’AEMF — ont publié la première liste officielle de 19 prestataires tiers de services TIC critiques désignés au titre de DORA. La désignation place ces prestataires sous la surveillance directe de l’UE pour la première fois, séparée de et en plus de toute réglementation sectorielle déjà applicable. Les 19 CTPP désignés incluent les fournisseurs de cloud hyperscale dominants (AWS, Microsoft Azure, Google Cloud), les principaux fournisseurs de données et plateformes financières (Bloomberg, le London Stock Exchange Group, IBM), et d’autres grands prestataires de services servant le secteur financier de l’UE (Tata Consultancy Services, Orange).

Le cadre de désignation opère via des critères établis à l’article 31 et élaborés dans des actes délégués. Les CTPP sont désignés sur la base de l’importance systémique — mesurée au regard du nombre et de l’importance des entités financières dans le champ d’application qui s’appuient sur eux, de l’irremplaçabilité de leurs services, et des conséquences de leur défaillance. La désignation déclenche une surveillance directe par des équipes d’examen conjointes coordonnées par le superviseur principal pertinent, une redevance de surveillance payée par le CTPP, et une gamme de pouvoirs de contrôle dont l’investigation, l’inspection sur place, et les recommandations contraignantes.

Pour les entités financières, les implications pratiques de la désignation CTPP sont substantielles. La dépendance envers un CTPP désigné doit être documentée explicitement dans le registre d’information. Le risque de concentration — le risque que l’entité financière soit excessivement dépendante d’un CTPP ou d’un petit groupe de CTPP opérant de manière corrélée — doit être évalué et géré. Les stratégies de sortie doivent être crédibles : les contrats doivent permettre la transition vers un prestataire alternatif dans un délai gérable, même là où la réalité pratique est qu’aucune alternative pleinement équivalente n’existe.

Les équipes d’examen conjointes ont commencé les activités de surveillance au cours du premier trimestre 2026. Les CTPP eux-mêmes opèrent désormais sous un engagement de contrôle direct au niveau de l’UE pour la première fois, en plus de toute réglementation sectorielle — souvent aux États-Unis, où la plupart des entités désignées ont leur siège — déjà applicable. L’interaction entre la surveillance de l’UE et la réglementation du pays d’origine est en soi un domaine de pratique en développement qui façonnera la réalité d’application de DORA au cours des prochaines années.

Pour la réponse aux incidents spécifiquement, la désignation CTPP crée une nouvelle dimension probante. Lorsqu’un CTPP désigné subit un incident affectant les services d’une entité financière, le rapport DORA de l’entité financière devra se coordonner avec la propre réponse aux incidents du CTPP, avec l’engagement de surveillance de l’équipe d’examen conjointe, et avec toute enquête réglementaire parallèle. La capture forensique de l’état externe du CTPP pendant l’incident — pages d’état publiques, communications d’incident, preuve de service partiel — devient une pièce critique du dossier défensif de l’entité financière, en particulier lorsque des négociations contractuelles ou des réclamations de crédit de service surviennent ultérieurement.

Tests de pénétration fondés sur la menace (article 26) et TIBER-EU

L’article 26 de DORA introduit une obligation de test opérationnel substantiellement nouvelle pour les entités financières significatives : les tests de pénétration fondés sur la menace, ou TLPT. Le cadre est fondé sur TIBER-EU — le cadre de red teaming éthique fondé sur le renseignement sur les menaces développé par la Banque centrale européenne — et représente un changement radical par rapport aux tests de pénétration conventionnels en termes de portée, d’intensité, et d’engagement réglementaire.

Le TLPT est requis pour les entités financières identifiées comme significatives par l’autorité compétente. La liste n’est pas publique, mais les critères sont fondés sur l’importance systémique de l’entité, son rôle dans les infrastructures critiques des marchés financiers, et son profil de risque TIC. Une fois identifiée, l’entité doit conduire un exercice TLPT au moins une fois tous les trois ans. Le test est conduit sur des systèmes de production en direct — pas des environnements de test isolés — couvrant des fonctions critiques ou importantes, et suit une méthodologie structurée dont la préparation du renseignement sur les menaces, l’exécution de la red team, et la remédiation.

La portée du test doit couvrir plusieurs fonctions critiques ou importantes et doit inclure la production en direct. C’est l’obligation unique la plus invasive sur le plan opérationnel au titre de DORA. L’autorité compétente est impliquée tout au long, de la définition de la portée à la sélection de la red team (qui doit inclure des testeurs accrédités) jusqu’à l’évaluation des résultats. L’autorité compétente peut exiger des tests supplémentaires si l’exercice initial produit une couverture inadéquate ou des résultats insatisfaisants.

La reconnaissance mutuelle entre les États membres est une caractéristique clé : un exercice TLPT conduit sous la supervision de l’autorité compétente d’un État membre est reconnu par d’autres États membres où l’entité financière opère. Cela évite les tests redondants pour les entités transfrontalières, tout en garantissant que chaque entité est testée sous un régime coordonné unique. La mise en œuvre du cadre a été progressive tout au long de 2025 et 2026, avec le premier cycle d’exercices TLPT désormais en cours à travers les entités financières significatives.

Du point de vue de la preuve, le TLPT génère une trace documentaire substantielle — évaluations du renseignement sur les menaces, plans de red team, résultats d’exploitation, plans de remédiation, et rapports post-exercice. L’intégrité de cette documentation compte car les résultats du TLPT peuvent eux-mêmes devenir la base d’une action de contrôle lorsque des fonctions critiques ou importantes s’avèrent inadéquatement protégées. Maintenir cette piste d’audit avec la même intégrité probante attendue pour le signalement d’incidents fait partie de la construction d’une architecture de preuve DORA cohérente.

Sanctions, responsabilité personnelle, et coopération intersectorielle

Le cadre de sanctions de DORA opère à deux niveaux : les sanctions administratives imposées par les autorités nationales compétentes sur les entités financières, et les astreintes imposées par le superviseur principal sur les prestataires tiers de services TIC critiques au titre du cadre de surveillance. Les États membres peuvent aussi prévoir des sanctions pénales au titre du droit national lorsque les violations de DORA impliquent des violations du droit pénal national (article 52).

L’article 50 exige des États membres qu’ils veillent à ce que les autorités compétentes aient le pouvoir d’imposer des sanctions administratives et des mesures correctives appropriées pour les violations de DORA. Les limites quantitatives spécifiques sont laissées à la transposition nationale de la directive de soutien (UE) 2022/2556, avec le résultat que les amendes maximales varient à travers l’Union. En pratique, plusieurs États membres ont mis en œuvre des maxima de l’ordre de 5 à 10 millions d’euros ou 10 % du chiffre d’affaires annuel total, reflétant l’ampleur des sanctions comparables du secteur financier pour les défaillances de gouvernance.

Pour les prestataires tiers de services TIC critiques, l’article 35 habilite le superviseur principal à imposer des astreintes allant jusqu’à 1 % du chiffre d’affaires quotidien mondial moyen du CTPP au cours de l’exercice précédent. La nature périodique est significative : la sanction s’accumule quotidiennement pendant la période de non-conformité, créant une pression soutenue pour remédier plutôt que de traiter une sanction fixe comme un coût de fonctionnement. Les premières invocations de ce pouvoir sont attendues au cours de 2026 et 2027 à mesure que les engagements de surveillance des équipes d’examen conjointes mûrissent.

La responsabilité personnelle de la direction senior est implicite plutôt que structurée explicitement comme elle l’est à l’article 20 de NIS2. DORA place les responsabilités de gestion des risques TIC sur l’organe de direction (article 5) et sur la direction senior plus largement, avec le résultat que les défaillances dans ces domaines déclenchent des considérations d’honorabilité et de compétence au titre de la réglementation financière sectorielle — supervision bancaire, supervision des assurances, supervision des valeurs mobilières — qui peuvent inclure des sanctions personnelles, des interdictions de gestion, et des disqualifications. Le mécanisme est indirect mais les conséquences sont directes.

L’article 47 établit une coopération formelle entre les autorités compétentes de DORA et l’architecture NIS2 — les CSIRT désignés au titre de NIS2, le réseau des CSIRT de l’UE, et l’ENISA. La coopération opère dans les deux sens : les autorités DORA reçoivent des informations des CSIRT de NIS2 sur les incidents affectant potentiellement les entités financières, et elles peuvent acheminer les incidents signalés à DORA vers les CSIRT de NIS2 lorsque les implications intersectorielles le justifient. Pour les entités financières, cela signifie qu’un seul incident peut produire un engagement réglementaire à travers DORA, NIS2 (via le canal de coopération des CSIRT), GDPR (lorsque des données personnelles sont impliquées), et la réglementation financière sectorielle — chaque régulateur évaluant les mêmes faits sous-jacents de manière indépendante.

DORA, NIS2 et GDPR : lex specialis et obligations qui se chevauchent

DORA opère au sein d’un cluster réglementaire qui inclut NIS2, GDPR, la directive CER, et la supervision financière sectorielle. Pour un seul incident significatif lié aux TIC, une entité financière peut faire face à des obligations simultanées au titre de trois, quatre, ou cinq de ces cadres. Comprendre comment ils s’imbriquent est essentiel pour éviter à la fois les lacunes et les efforts dupliqués pendant ce qui est déjà une phase de réponse à forte pression.

DORA est lex specialis à NIS2 pour les entités financières. L’article 4 de la directive (UE) 2022/2555 (NIS2) exempte explicitement les entités financières des obligations de gestion des risques et de signalement d’incidents de NIS2, reconnaissant DORA comme le cadre applicable. L’exemption n’est pas absolue — les États membres peuvent tout de même désigner les entités financières comme entités critiques au titre de la directive CER, et le canal de coopération des CSIRT de NIS2 s’applique via l’article 47 de DORA — mais les obligations opérationnelles reposent dans DORA. C’est la relation intercadre la plus nette du droit de la cybersécurité de l’UE.

L’article 33 du GDPR, en revanche, s’applique en parallèle sans déplacement. Si un incident majeur lié aux TIC au titre de DORA implique une violation de données personnelles — et la plupart des attaques contre les entités financières en impliquent — la notification à 72 heures à l’autorité de protection des données pertinente court aux côtés de la cascade de 4 heures / 72 heures / 1 mois de DORA. Les déclencheurs diffèrent (DORA : impact opérationnel ; GDPR : risque pour les personnes concernées), donc un seul incident peut déclencher les deux. La preuve soutenant les deux doit être préservable sous une forme qui satisfait les exigences applicables les plus strictes — signifiant typiquement le hachage cryptographique des artefacts, les horodatages électroniques qualifiés au titre de l’article 42 d’eIDAS, et la vérifiabilité indépendante par des tiers.

Les plateformes de preuve web forensique comme GetProofAnchor sont conçues pour produire des paquets de preuve qui satisfont les trois régulateurs simultanément. Le ZIP de preuve — scellé avec un horodatage qualifié eIDAS délivré par un prestataire de services de confiance qualifié inscrit dans l’UE, ancré indépendamment dans la blockchain Bitcoin via OpenTimestamps, et fourni avec un utilitaire de vérification open source — fonctionne également pour l’autorité compétente de DORA, le CSIRT de NIS2 (lorsque le canal de coopération est invoqué), et l’autorité de protection des données. Une seule capture faite au moment de la détection de l’incident sert toutes les obligations de signalement ultérieures sans travail supplémentaire.

Au-delà de ces trois régulateurs, les entités financières devraient aussi considérer les interactions sectorielles. Le signalement des incidents opérationnels et de sécurité au titre de la directive sur les services de paiement 2 (PSD2) a été largement remplacé par DORA pour les établissements de paiement dans le champ d’application, mais ses obligations substantielles ont migré dans la cascade de l’article 19 de DORA. Le règlement eIDAS régit les services de confiance utilisés pour la préservation des preuves. La réglementation financière sectorielle continue d’opérer aux côtés de DORA. Construire une architecture de preuve cohérente — plutôt que des flux de preuve séparés pour chaque régulateur — est l’efficacité opérationnelle qui distingue les entités financières bien préparées dans l’ère DORA.

Liste de contrôle des preuves d’incidents DORA (15 points)

La liste de contrôle suivante consolide les priorités opérationnelles de ce guide. Elle ne remplace pas un conseil juridique ni les orientations spécifiques de votre autorité nationale compétente, mais elle capture les caractéristiques distinctives des entités financières qui sont opérationnellement prêtes pour DORA par opposition à simplement prêtes sur le plan documentaire.

• Déterminez votre classification DORA (sous-catégorie d’entité financière) et documentez la détermination avec des références à l’appui aux dispositions de champ d’application de l’article 2 et à votre cadre de contrôle national.
• Identifiez l’autorité compétente et toute autorité de contrôle applicable spécifique à votre sous-catégorie, et établissez des canaux de communication pré-incident dont des modèles pour la notification initiale, le rapport intermédiaire, et le rapport final.
• Définissez des critères de classification internes pour les incidents majeurs liés aux TIC alignés sur le règlement délégué (UE) 2024/1772 de la Commission, dont la logique à double déclencheur (services critiques + perte de données OU services critiques + deux seuils), et révisez-les au moins annuellement.
• Assurez une capacité de détection 24/7 afin que le chronomètre de notification initiale de quatre heures puisse se déclencher au moment de la classification, indépendamment des heures ouvrables ou des week-ends.
• Désignez un responsable principal du signalement d’incidents et au moins un adjoint avec pleine autorité pour déposer les notifications initiales dans la fenêtre de quatre heures sans délais de ratification par la direction.
• Mettez en œuvre une journalisation inviolable à travers le patrimoine TIC avec des primitives d’intégrité documentées (chaînes d’empreintes, horodatages électroniques qualifiés, ou équivalent) et une rétention proportionnée aux attentes sectorielles — typiquement 12 mois minimum, avec des périodes plus longues pour des catégories spécifiques.
• Établissez des procédures de capture forensique pour les artefacts d’attaque tournés vers le web les plus pertinents pour les entités financières — pages de hameçonnage usurpant les interfaces de détail, fausses pages d’autorisation de paiement, plateformes d’investissement usurpant la marque, faux portails KYC, et état des prestataires tiers de services TIC critiques pendant les pannes.
• Liez les artefacts de capture ensemble via des manifestes cryptographiques (SHA-256 sur tous les fichiers) et soumettez l’empreinte du manifeste à un prestataire de services de confiance qualifié inscrit dans l’UE pour un horodatage électronique qualifié au titre de l’article 42 du règlement (UE) 910/2014.
• Ancrez les paquets de preuve indépendamment — par exemple, via la blockchain Bitcoin via OpenTimestamps — afin que l’intégrité puisse être vérifiée sans dépendre de l’entité, du prestataire de services de confiance, ni d’un quelconque point de défaillance unique.
• Documentez la chaîne de preuve conformément aux phases de l’ISO/IEC 27037:2012 (identification, collecte, acquisition, préservation) pour chaque élément de preuve, avec les rôles, horodatages, et actions enregistrés.
• Maintenez un registre d’information à jour pour tous les arrangements avec des tiers TIC soutenant des fonctions critiques ou importantes, avec une cartographie des sous-traitants alignée sur le règlement délégué (UE) 2025/532 de la Commission, prêt pour soumission au cycle de signalement national.
• Identifiez votre dépendance envers chacun des 19 prestataires tiers de services TIC critiques désignés (à novembre 2025), évaluez le risque de concentration, et documentez les stratégies de sortie comme requis par l’article 28.
• Conduisez ou planifiez l’exercice de tests de pénétration fondés sur la menace au titre de l’article 26 si vous êtes une entité financière significative, avec le plan d’exercice convenu avec l’autorité compétente et une préservation de preuves documentée pour le test lui-même.
• Cartographiez le chevauchement entre DORA et les autres réglementations applicables (canal de coopération NIS2 via l’article 47, article 33 du GDPR, transition PSD2, réglementation financière sectorielle) afin qu’un seul incident produise des notifications coordonnées à travers tous les régimes applicables, soutenues par un seul paquet de preuve cohérent.
• Rendez tous les paquets de preuve vérifiables indépendamment par des tiers — autorités compétentes, superviseur principal pour les affaires liées aux CTPP, tribunaux, assureurs, conseils — à l’aide d’outils de vérification open source et sans dépendance envers l’infrastructure de l’entité productrice.

Questions fréquentes et conclusion

Les réponses suivantes traitent des questions qui surviennent le plus souvent lorsque les entités financières commencent à opérationnaliser le traitement des preuves DORA. Elles sont destinées comme orientation pratique, pas comme conseil juridique pour une situation spécifique.

La première année d’application de DORA a confirmé ce qui était largement anticipé pendant la phase de préparation : le règlement est exigeant sur le plan opérationnel, les délais sont serrés, et l’engagement de contrôle est soutenu. Le taux de réussite de 6,5 % de l’exercice à blanc de 2024 a illustré l’écart entre la conformité de politique et la préparation opérationnelle. Le cycle de signalement 2026, conduit sous une application active, produira un tableau plus clair de la position des entités individuelles.

Les capacités qui distinguent les entités financières opérationnellement prêtes pour DORA sont reconnaissables. Des systèmes de détection qui peuvent classer les incidents rapidement. Des workflows de signalement qui produisent les notifications initiales dans la fenêtre de quatre heures sans délais de ratification par la direction. La préservation forensique des artefacts d’incident — en particulier l’infrastructure d’attaque tournée vers le web qui disparaît le plus vite dans les heures suivant la détection. La vérifiabilité indépendante de la preuve résultante par l’autorité compétente, le superviseur principal dans les affaires liées aux CTPP, et tout tribunal ou assureur ultérieur. Aucune de ces capacités n’est exotique ; ce qui distingue l’entité bien préparée, c’est qu’elles sont toutes en place avant le premier incident majeur.

GetProofAnchor existe pour rendre le composant de préservation forensique de cette pile — spécifiquement les artefacts tournés vers le web qui disparaissent le plus vite dans les moments suivant la détection — simple, défendable, et vérifiable indépendamment à travers DORA, la coopération NIS2, et GDPR simultanément. Si votre entité financière bâtit sa capacité de traitement des preuves DORA et souhaiterait voir comment la capture web forensique à horodatage qualifié s’intègre au workflow de signalement à quatre heures, le moyen le plus direct est de créer un exemple de preuve à partir de toute URL publique et d’inspecter le ZIP de preuve. La vérification est open source et s’exécute sur n’importe quel ordinateur portable. Le standard est reproductible parce que, au titre de DORA, il doit l’être.