DORA après 15 mois : Ce que les équipes de sécurité des institutions financières retiennent des premiers audits de 2026

7 min de lecture

DORA est entré en vigueur le 17 janvier 2025 et s’applique désormais obligatoirement aux établissements financiers de l’UE. Après quinze mois d’application effective, les premiers cycles d’audit sont terminés. Les enseignements qui en découlent sont concrets – et souvent inconfortables – pour les équipes de sécurité des banques, assurances et gestionnaires d’actifs. Le signalement des incidents en quatre heures, les contrats avec les tiers incluant de nouvelles clauses, et le régime de tests TLPT poussent les opérations à leurs limites, bien au-delà des processus habituels.

À lire égalementNIS2 : organiser la première heure de signalement d’un incident  /  MFA adaptative dans Entra, Okta et Duo : déploiement NIS2

Ce que les premiers audits de 2026 ont réellement révélé

Les autorités de surveillance de l’UE (BaFin, ABE, AEMF, AEAPP et la BCE pour les plus grands établissements) ont mené les premières séries d’audits en 2025 et au premier trimestre 2026. Les questions de fond étaient prévisibles. Les réponses des institutions, elles, l’étaient beaucoup moins. Les constats les plus fréquents issus des échanges avec les services de conformité des banques allemandes peuvent être regroupés en trois thèmes : la classification des incidents dans des délais serrés, les lacunes contractuelles avec les prestataires tiers et des capacités de test sous-dimensionnées pour les TLPT. Aucun de ces sujets n’est nouveau, mais chacun s’inscrit désormais dans le cadre contraignant du règlement DORA, qui dépasse largement les tolérances internes antérieures. À cela s’ajoute le fait que les autorités de surveillance précisent leur interprétation à mesure que les cas se multiplient. Ce qui passait pour une interprétation pilote de la réglementation en 2025 est désormais évalué plus strictement en 2026.

La première heure suivant un incident est déterminante. La réglementation exige une notification initiale dans les quatre heures suivant la classification d’un incident ICT comme majeur. Cette classification doit elle-même reposer sur des critères traçables. En pratique, cela signifie que lorsqu’une alerte survient à trois heures du matin et qu’elle semble correspondre à un incident majeur potentiel, le SOC doit décider en quelques heures si le seuil de notification est atteint. En parallèle, la préparation de la notification elle-même doit être lancée. Ceux qui n’ont pas intégré ce processus dans l’automatisation de leur runbook se retrouvent sous pression. La leçon tirée des premiers audits : les établissements dépourvus de chaînes d’escalade claires et d’une matrice de classification définie ont accumulé plus d’un constat dans ce domaine au cours des premiers mois.

Registres des tiers et scénarios de sortie

Le deuxième chantier majeur concerne les contrats conclus avec les prestataires de services TIC tiers. DORA impose d’y inclure des clauses explicites sur les droits d’audit, les stratégies de sortie, les garanties de niveau de service, les obligations de sécurité et les obligations de déclaration des incidents. La réalité ? La plupart des contrats cloud, abonnements SaaS et accords d’externalisation conclus ces dernières années ne répondent pas entièrement à ces exigences. Leur renégociation n’est pas unilatérale. Les fournisseurs en position de force (hyperscalers, principales plateformes SaaS) imposent leurs propres standards contractuels, qui ne coïncident pas toujours avec les exigences de DORA.

Le retour d’expérience des quinze premiers mois est éloquent : les établissements qui ont abordé le sujet de manière proactive et précoce ont obtenu des annexes contractuelles adaptées de la part des hyperscalers, couvrant une grande partie des exigences de DORA. Ceux qui ont attendu doivent désormais renégocier. Leur position est bien moins favorable, car le fournisseur sait que le temps presse. Un détail souvent négligé : l’obligation de tenir à jour le registre est cumulative. Toute mise à jour d’un contrat, tout nouveau sous-traitant intégré et tout changement de criticité doit être consigné sans délai dans le registre DORA. Sans un workflow dédié à sa mise à jour continue, ce registre devient obsolète en quelques mois.

La stratégie de sortie est le domaine où de nombreux établissements ont sous-estimé les exigences. DORA ne se contente pas d’une clause de résiliation : elle impose un plan solide pour assurer, en cas de défaillance d’un fournisseur ou de résiliation du contrat, la migration vers une solution alternative dans un délai maîtrisé. Pour un système bancaire central en mode SaaS, cela ne relève pas du juridique, mais d’un projet de transition pluriannuel. Les autorités de surveillance ont d’ores et déjà documenté, lors des premiers audits, qu’un plan de sortie théorique, sans simulation réaliste, ne suffisait pas.

Concrètement, cela signifie que chaque établissement doit élaborer, pour ses cinq à dix principaux prestataires tiers critiques, un plan de transition détaillé, incluant un calendrier, une architecture cible, une approche de migration des données et une responsabilité claire. Pour les fournisseurs cloud, cela passe souvent par une configuration multi-cloud ou multi-région. Pour les systèmes bancaires centraux en SaaS, une stratégie de secours avec un fournisseur de backup ou une solution interne de repli s’impose. La documentation de ces plans constitue une première étape. Leur mise à jour périodique et des exercices de simulation occasionnels en sont la suite logique. Les établissements qui s’y attellent sérieusement découvrent des failles dans leurs propres processus, invisibles en temps normal.

Points clés : TLPT en pratique – marché, capacités et maturité interne

Le Threat-Led Penetration Testing (TLPT) selon le cadre TIBER-EU représente l’exigence de test la plus stricte imposée par le règlement DORA. Il concerne les établissements financiers qui dépassent les seuils TLPT (en simplifiant : les grandes banques, les prestataires de services de paiement et les opérateurs d’infrastructures de marché). Ce test est réalisé par des fournisseurs accrédités de services Red Team, ciblant directement les systèmes de production en conditions réelles, sans préavis pour les équipes de défense opérationnelles. Le défi à relever d’ici 2026 est double.

Premièrement, le marché des prestataires accrédités est restreint. En Allemagne et en Europe, on compte seulement quelques dizaines – et non quelques centaines – de fournisseurs Red Team agréés pour le TLPT. Leurs plannings sont déjà complets six à neuf mois à l’avance. Les établissements souhaitant réaliser un test au second semestre 2026 doivent donc engager les négociations dès maintenant. Deuxièmement, la maturité interne est un facteur clé. Un TLPT ne génère des enseignements pertinents que si le Blue Team, la chaîne de détection et les processus de réponse aux incidents sont suffisamment matures pour analyser la simulation. Certains établissements ayant programmé leur TLPT trop tôt ont gaspillé des ressources précieuses en tests Red Team pour obtenir des résultats qui auraient pu être identifiés dès un simple inventaire des actifs.

La démarche pragmatique qui s’impose en 2026 se structure ainsi : d’abord une évaluation de la maturité interne, puis des exercices ciblés Purple Team sur six mois, et enfin le TLPT avec un prestataire externe accrédité. Les établissements qui se lancent directement dans le TLPT s’exposent à un audit coûteux, aux conclusions majoritairement génériques. En revanche, ceux qui préparent les étapes en amont obtiennent des rapports de vulnérabilités spécifiques, justifiant pleinement l’investissement.

Un autre enjeu, qui se précise lors de la deuxième phase de mise en œuvre de DORA, concerne l’intégration des résultats du TLPT dans la gestion continue des risques. De nombreux établissements traitent les rapports TLPT comme des comptes-rendus classiques de tests d’intrusion : les vulnérabilités sont priorisées, corrigées et classées sans suite. Cette approche est insuffisante. Les autorités de supervision attendent que les enseignements du TLPT alimentent l’analyse stratégique des risques, que les tendances en matière de vulnérabilités soient documentées sur plusieurs tests, et que l’efficacité des mesures d’atténuation soit vérifiée lors des tests suivants. La différence entre un simple suivi des tests d’intrusion et une véritable gestion de la résilience deviendra un critère d’évaluation lors de la deuxième vague d’audits.

L’articulation avec la planification de la continuité d’activité (BCP) fait également l’objet d’un examen approfondi. Le TLPT simule des scénarios d’attaque, tandis que le BCP anticipe des scénarios de défaillance. Pourtant, ces deux disciplines restent souvent cloisonnées au sein des établissements. DORA exige désormais leur coordination. Les institutions qui alignent leurs exercices fournissent des preuves de résilience bien plus solides que des justificatifs isolés.

Feuille de route opérationnelle pour les équipes de sécurité dans la deuxième phase de DORA

Pour les équipes de sécurité qui ont survécu à la première année de DORA et préparent désormais le deuxième cycle d’audit, un rythme en quatre phases s’est avéré efficace.

Ce rythme présente deux avantages. Premièrement, il dissocie l’exécution du TLPT (*Threat-Led Penetration Testing* – test d’intrusion dirigé par les menaces) de la préparation à l’audit, permettant ainsi à chaque sujet de recevoir l’attention nécessaire. Deuxièmement, il laisse au service de gestion des incidents le temps d’intégrer les modifications des runbooks après chaque phase, évitant ainsi les accumulations. Ceux qui concentrent tout sur le quatrième trimestre obtiennent une documentation qui semble parfaite sur le papier, mais qui n’est pas appliquée dans la réalité opérationnelle.

Une observation récurrente lors des échanges avec les auditeurs : les superviseurs ne vérifient pas seulement l’existence des processus, mais aussi leur application effective. Un processus de classification des incidents qui n’a pas été utilisé au cours des six derniers mois, faute d’incident majeur, sera tout de même examiné. Les superviseurs exigeront alors des exercices ou des *tabletop exercises* (simulations de crise) pour attester de l’état de préparation. Les établissements qui réalisent ces exercices trimestriellement s’en sortent bien mieux que ceux qui ne les font qu’une fois par an.

Un autre aspect souvent relevé lors de la deuxième vague concerne le rôle de la direction générale. DORA (*Digital Operational Resilience Act* – règlement européen sur la résilience opérationnelle numérique) n’est ni une simple question de conformité, ni un sujet purement informatique. La responsabilité incombe au directoire, et non à la deuxième ligne managériale. Les superviseurs vérifient si le directoire pilote activement les mesures DORA, s’il reçoit régulièrement des rapports et s’il a co-décidé la feuille de route des remédiations. Ceux qui délèguent cette responsabilité à la direction informatique reçoivent des constats au niveau du directoire. Les établissements dotés d’une revue trimestrielle des risques TIC (*Technologies de l’Information et de la Communication*) au sein du directoire, avec un ordre du jour dédié, fournissent des preuves bien plus crédibles que ceux qui traitent DORA comme un projet technique.

Enfin, DORA modifie la collaboration entre la sécurité de l’information, l’exploitation informatique et la conformité opérationnelle. Ces trois fonctions doivent s’inscrire dans les mêmes flux de travail, et non dans des silos distincts. Les établissements qui, lors du premier cycle, utilisaient encore des transferts manuels basés sur Excel entre le RSSI (*Responsable de la Sécurité des Systèmes d’Information*), le DSI (*Directeur des Systèmes d’Information*) et la conformité, mettent en place lors du deuxième cycle des plateformes GRC (*Governance, Risk and Compliance*) communes. Celles-ci permettent de centraliser les constats, les mesures et les preuves, réduisant ainsi les temps de recherche lors des audits et présentant aux superviseurs une organisation coordonnée plutôt que plusieurs documentations isolées.

Pour conclure, un point qui fait la différence entre l’obligation d’audit et l’utilité en termes de résilience. Dans la pratique, DORA constitue un cadre qui élève la maturité de la réponse aux incidents et la gestion des risques liés aux tiers à un niveau dont de nombreux établissements ont de toute façon besoin. Ceux qui perçoivent ces exigences comme une simple obligation de conformité obtiennent une documentation coûteuse sans valeur ajoutée. En revanche, ceux qui les considèrent comme une opportunité d’améliorer leur résilience face aux perturbations TIC disposent, après douze mois, non seulement d’un rapport d’audit irréprochable, mais aussi de moins de surprises nocturnes. Les investissements dans l’automatisation des SIEM (*Security Information and Event Management*), des runbooks clairs et des plans de sortie robustes se rentabilisent indépendamment de la réglementation. DORA fixe simplement le calendrier dans lequel ils doivent être mis en place.

Questions fréquentes

Quels établissements sont concernés par DORA ?

Le règlement s’applique à l’ensemble des institutions financières supervisées au sein de l’UE : banques, assurances, sociétés de gestion d’actifs, prestataires de services de paiement, établissements de monnaie électronique, fonds d’investissement, infrastructures de marché et prestataires tiers critiques en matière de TIC (technologies de l’information et de la communication). Des allègements sont prévus pour les petits établissements sous certains seuils, mais aucune exemption totale n’est accordée. Les prestataires travaillant pour des institutions financières sans être eux-mêmes régulés se voient imposer, par le biais des clauses relatives aux tiers incluses dans les contrats de leurs clients, des exigences indirectement liées à DORA.

Contexte DACH : DORA (Digital Operational Resilience Act) est un règlement européen entré en vigueur en 2023, visant à renforcer la résilience opérationnelle numérique du secteur financier. Il s’inscrit dans une stratégie plus large de l’UE pour harmoniser la cybersécurité et la gestion des risques liés aux TIC.

Quelles sont les différences entre DORA et NIS2 ?

DORA est spécifique au secteur financier et impose des exigences plus détaillées en matière de signalement des incidents, de tests et de gestion des prestataires tiers. NIS2, en revanche, s’applique de manière transversale à plusieurs secteurs et reste plus général sur certains aspects. Lorsqu’un établissement est soumis aux deux règlements, DORA prime dans son champ d’application.

Contexte réglementaire : NIS2 (Network and Information Security Directive 2) est une directive européenne visant à améliorer la cybersécurité des opérateurs critiques et des fournisseurs de services numériques dans l’UE. Elle a été transposée dans les législations nationales des États membres.

Quel est le rôle des prestataires tiers critiques en TIC (CTPP) ?

Les autorités européennes de surveillance désignent comme CTPP (Critical Third-Party Providers) les prestataires jugés critiques pour plusieurs institutions financières. Ces derniers sont soumis à un régime de supervision spécifique. Il s’agit généralement des grands fournisseurs de cloud, des prestataires centraux de services de paiement et des éditeurs spécialisés dans les systèmes bancaires centraux. La liste des CTPP est mise à jour chaque année.

À quelle fréquence un TLPT doit-il être réalisé ?

Pour les établissements soumis à l’obligation de TLPT (Threat-Led Penetration Testing, ou test d’intrusion dirigé par les menaces), un test doit être effectué au moins tous les trois ans. Toutefois, en cas de modifications majeures dans l’environnement informatique ou après des incidents significatifs, l’autorité de surveillance peut exiger un test anticipé. La planification de ces tests nécessite un délai de six à neuf mois.

Quel est le rôle des audits internes dans la mise en œuvre de DORA ?

L’audit interne joue un rôle central. Il vérifie en continu que les processus de gestion des risques liés aux TIC respectent les exigences de DORA et rend compte directement au directoire et au conseil de surveillance. Sans une capacité d’audit interne suffisante, l’examen externe mené par les autorités de régulation peut se transformer en un véritable test de résistance pour lequel vous ne seriez pas préparé.

Plus d’articles du réseau média MBF

Source de l’image d’en-tête : Pexels / Erik Mclean (px:9218590)

À propos de l'auteur: Alec Chizhik

Plus d'articles de Alec Chizhik