7 min de lecture<\/p>\n
DORA est entr\u00e9 en vigueur le 17 janvier 2025 et s\u2019applique d\u00e9sormais obligatoirement aux \u00e9tablissements financiers de l\u2019UE. Apr\u00e8s quinze mois d\u2019application effective, les premiers cycles d\u2019audit sont termin\u00e9s. Les enseignements qui en d\u00e9coulent sont concrets – et souvent inconfortables – pour les \u00e9quipes de s\u00e9curit\u00e9 des banques, assurances et gestionnaires d\u2019actifs. Le signalement des incidents en quatre heures, les contrats avec les tiers incluant de nouvelles clauses, et le r\u00e9gime de tests TLPT poussent les op\u00e9rations \u00e0 leurs limites, bien au-del\u00e0 des processus habituels.<\/strong><\/p>\n Points cl\u00e9s<\/p>\n \u00c0 lire \u00e9galement<\/span>NIS2 : organiser la premi\u00e8re heure de signalement d\u2019un incident<\/a> \/<\/span> MFA adaptative dans Entra, Okta et Duo : d\u00e9ploiement NIS2<\/a><\/p>\n Les autorit\u00e9s de surveillance de l’UE (BaFin, ABE, AEMF, AEAPP et la BCE pour les plus grands \u00e9tablissements) ont men\u00e9 les premi\u00e8res s\u00e9ries d’audits en 2025 et au premier trimestre 2026. Les questions de fond \u00e9taient pr\u00e9visibles. Les r\u00e9ponses des institutions, elles, l’\u00e9taient beaucoup moins. Les constats les plus fr\u00e9quents issus des \u00e9changes avec les services de conformit\u00e9 des banques allemandes peuvent \u00eatre regroup\u00e9s en trois th\u00e8mes : la classification des incidents dans des d\u00e9lais serr\u00e9s, les lacunes contractuelles avec les prestataires tiers et des capacit\u00e9s de test sous-dimensionn\u00e9es pour les TLPT. Aucun de ces sujets n’est nouveau, mais chacun s’inscrit d\u00e9sormais dans le cadre contraignant du r\u00e8glement DORA, qui d\u00e9passe largement les tol\u00e9rances internes ant\u00e9rieures. \u00c0 cela s’ajoute le fait que les autorit\u00e9s de surveillance pr\u00e9cisent leur interpr\u00e9tation \u00e0 mesure que les cas se multiplient. Ce qui passait pour une interpr\u00e9tation pilote de la r\u00e9glementation en 2025 est d\u00e9sormais \u00e9valu\u00e9 plus strictement en 2026.<\/p>\n La premi\u00e8re heure suivant un incident est d\u00e9terminante. La r\u00e9glementation exige une notification initiale dans les quatre heures suivant la classification d’un incident ICT comme majeur. Cette classification doit elle-m\u00eame reposer sur des crit\u00e8res tra\u00e7ables. En pratique, cela signifie que lorsqu’une alerte survient \u00e0 trois heures du matin et qu’elle semble correspondre \u00e0 un incident majeur potentiel, le SOC doit d\u00e9cider en quelques heures si le seuil de notification est atteint. En parall\u00e8le, la pr\u00e9paration de la notification elle-m\u00eame doit \u00eatre lanc\u00e9e. Ceux qui n’ont pas int\u00e9gr\u00e9 ce processus dans l’automatisation de leur runbook se retrouvent sous pression. La le\u00e7on tir\u00e9e des premiers audits : les \u00e9tablissements d\u00e9pourvus de cha\u00eenes d’escalade claires et d’une matrice de classification d\u00e9finie ont accumul\u00e9 plus d’un constat dans ce domaine au cours des premiers mois.<\/p>\n Le deuxi\u00e8me 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\u00e9gies de sortie, les garanties de niveau de service, les obligations de s\u00e9curit\u00e9 et les obligations de d\u00e9claration des incidents. La r\u00e9alit\u00e9 ? La plupart des contrats cloud, abonnements SaaS et accords d’externalisation conclus ces derni\u00e8res ann\u00e9es ne r\u00e9pondent pas enti\u00e8rement \u00e0 ces exigences. Leur ren\u00e9gociation n’est pas unilat\u00e9rale. Les fournisseurs en position de force (hyperscalers, principales plateformes SaaS) imposent leurs propres standards contractuels, qui ne co\u00efncident pas toujours avec les exigences de DORA.<\/p>\n Le retour d’exp\u00e9rience des quinze premiers mois est \u00e9loquent : les \u00e9tablissements qui ont abord\u00e9 le sujet de mani\u00e8re proactive et pr\u00e9coce ont obtenu des annexes contractuelles adapt\u00e9es de la part des hyperscalers, couvrant une grande partie des exigences de DORA. Ceux qui ont attendu doivent d\u00e9sormais ren\u00e9gocier. Leur position est bien moins favorable, car le fournisseur sait que le temps presse. Un d\u00e9tail souvent n\u00e9glig\u00e9 : l’obligation de tenir \u00e0 jour le registre est cumulative. Toute mise \u00e0 jour d’un contrat, tout nouveau sous-traitant int\u00e9gr\u00e9 et tout changement de criticit\u00e9 doit \u00eatre consign\u00e9 sans d\u00e9lai dans le registre DORA. Sans un workflow d\u00e9di\u00e9 \u00e0 sa mise \u00e0 jour continue, ce registre devient obsol\u00e8te en quelques mois.<\/p>\n O\u00f9 les mises en \u0153uvre de DORA \u00e9choueront en 2026<\/p>\n Ce qui renforce la conformit\u00e9 \u00e0 DORA<\/p>\n La strat\u00e9gie de sortie est le domaine o\u00f9 de nombreux \u00e9tablissements ont sous-estim\u00e9 les exigences. DORA ne se contente pas d’une clause de r\u00e9siliation : elle impose un plan solide pour assurer, en cas de d\u00e9faillance d’un fournisseur ou de r\u00e9siliation du contrat, la migration vers une solution alternative dans un d\u00e9lai ma\u00eetris\u00e9. Pour un syst\u00e8me bancaire central en mode SaaS, cela ne rel\u00e8ve pas du juridique, mais d’un projet de transition pluriannuel. Les autorit\u00e9s de surveillance ont d’ores et d\u00e9j\u00e0 document\u00e9, lors des premiers audits, qu’un plan de sortie th\u00e9orique, sans simulation r\u00e9aliste, ne suffisait pas.<\/p>\n Concr\u00e8tement, cela signifie que chaque \u00e9tablissement doit \u00e9laborer, pour ses cinq \u00e0 dix principaux prestataires tiers critiques, un plan de transition d\u00e9taill\u00e9, incluant un calendrier, une architecture cible, une approche de migration des donn\u00e9es et une responsabilit\u00e9 claire. Pour les fournisseurs cloud, cela passe souvent par une configuration multi-cloud ou multi-r\u00e9gion. Pour les syst\u00e8mes bancaires centraux en SaaS, une strat\u00e9gie de secours avec un fournisseur de backup ou une solution interne de repli s’impose. La documentation de ces plans constitue une premi\u00e8re \u00e9tape. Leur mise \u00e0 jour p\u00e9riodique et des exercices de simulation occasionnels en sont la suite logique. Les \u00e9tablissements qui s’y attellent s\u00e9rieusement d\u00e9couvrent des failles dans leurs propres processus, invisibles en temps normal.<\/p>\n Le Threat-Led Penetration Testing (TLPT) selon le cadre TIBER-EU repr\u00e9sente l’exigence de test la plus stricte impos\u00e9e par le r\u00e8glement DORA. Il concerne les \u00e9tablissements financiers qui d\u00e9passent les seuils TLPT (en simplifiant : les grandes banques, les prestataires de services de paiement et les op\u00e9rateurs d’infrastructures de march\u00e9). Ce test est r\u00e9alis\u00e9 par des fournisseurs accr\u00e9dit\u00e9s de services Red Team, ciblant directement les syst\u00e8mes de production en conditions r\u00e9elles, sans pr\u00e9avis pour les \u00e9quipes de d\u00e9fense op\u00e9rationnelles. Le d\u00e9fi \u00e0 relever d’ici 2026 est double.<\/p>\n Premi\u00e8rement, le march\u00e9 des prestataires accr\u00e9dit\u00e9s est restreint. En Allemagne et en Europe, on compte seulement quelques dizaines – et non quelques centaines – de fournisseurs Red Team agr\u00e9\u00e9s pour le TLPT. Leurs plannings sont d\u00e9j\u00e0 complets six \u00e0 neuf mois \u00e0 l’avance. Les \u00e9tablissements souhaitant r\u00e9aliser un test au second semestre 2026 doivent donc engager les n\u00e9gociations d\u00e8s maintenant. Deuxi\u00e8mement, la maturit\u00e9 interne est un facteur cl\u00e9. Un TLPT ne g\u00e9n\u00e8re des enseignements pertinents que si le Blue Team, la cha\u00eene de d\u00e9tection et les processus de r\u00e9ponse aux incidents sont suffisamment matures pour analyser la simulation. Certains \u00e9tablissements ayant programm\u00e9 leur TLPT trop t\u00f4t ont gaspill\u00e9 des ressources pr\u00e9cieuses en tests Red Team pour obtenir des r\u00e9sultats qui auraient pu \u00eatre identifi\u00e9s d\u00e8s un simple inventaire des actifs.<\/p>\n La d\u00e9marche pragmatique qui s’impose en 2026 se structure ainsi : d’abord une \u00e9valuation de la maturit\u00e9 interne, puis des exercices cibl\u00e9s Purple Team sur six mois, et enfin le TLPT avec un prestataire externe accr\u00e9dit\u00e9. Les \u00e9tablissements qui se lancent directement dans le TLPT s’exposent \u00e0 un audit co\u00fbteux, aux conclusions majoritairement g\u00e9n\u00e9riques. En revanche, ceux qui pr\u00e9parent les \u00e9tapes en amont obtiennent des rapports de vuln\u00e9rabilit\u00e9s sp\u00e9cifiques, justifiant pleinement l’investissement.<\/p>\n Un autre enjeu, qui se pr\u00e9cise lors de la deuxi\u00e8me phase de mise en \u0153uvre de DORA, concerne l’int\u00e9gration des r\u00e9sultats du TLPT dans la gestion continue des risques. De nombreux \u00e9tablissements traitent les rapports TLPT comme des comptes-rendus classiques de tests d’intrusion : les vuln\u00e9rabilit\u00e9s sont prioris\u00e9es, corrig\u00e9es et class\u00e9es sans suite. Cette approche est insuffisante. Les autorit\u00e9s de supervision attendent que les enseignements du TLPT alimentent l’analyse strat\u00e9gique des risques, que les tendances en mati\u00e8re de vuln\u00e9rabilit\u00e9s soient document\u00e9es sur plusieurs tests, et que l’efficacit\u00e9 des mesures d’att\u00e9nuation soit v\u00e9rifi\u00e9e lors des tests suivants. La diff\u00e9rence entre un simple suivi des tests d’intrusion et une v\u00e9ritable gestion de la r\u00e9silience deviendra un crit\u00e8re d’\u00e9valuation lors de la deuxi\u00e8me vague d’audits.<\/p>\n L’articulation avec la planification de la continuit\u00e9 d’activit\u00e9 (BCP) fait \u00e9galement l’objet d’un examen approfondi. Le TLPT simule des sc\u00e9narios d’attaque, tandis que le BCP anticipe des sc\u00e9narios de d\u00e9faillance. Pourtant, ces deux disciplines restent souvent cloisonn\u00e9es au sein des \u00e9tablissements. DORA exige d\u00e9sormais leur coordination. Les institutions qui alignent leurs exercices fournissent des preuves de r\u00e9silience bien plus solides que des justificatifs isol\u00e9s.<\/p>\n Pour les \u00e9quipes de s\u00e9curit\u00e9 qui ont surv\u00e9cu \u00e0 la premi\u00e8re ann\u00e9e de DORA et pr\u00e9parent d\u00e9sormais le deuxi\u00e8me cycle d’audit, un rythme en quatre phases s’est av\u00e9r\u00e9 efficace.<\/p>\n Ce rythme pr\u00e9sente deux avantages. Premi\u00e8rement, il dissocie l’ex\u00e9cution du TLPT (*Threat-Led Penetration Testing* – test d’intrusion dirig\u00e9 par les menaces) de la pr\u00e9paration \u00e0 l’audit, permettant ainsi \u00e0 chaque sujet de recevoir l’attention n\u00e9cessaire. Deuxi\u00e8mement, il laisse au service de gestion des incidents le temps d’int\u00e9grer les modifications des runbooks apr\u00e8s chaque phase, \u00e9vitant ainsi les accumulations. Ceux qui concentrent tout sur le quatri\u00e8me trimestre obtiennent une documentation qui semble parfaite sur le papier, mais qui n’est pas appliqu\u00e9e dans la r\u00e9alit\u00e9 op\u00e9rationnelle.<\/p>\n Une observation r\u00e9currente lors des \u00e9changes avec les auditeurs : les superviseurs ne v\u00e9rifient pas seulement l’existence des processus, mais aussi leur application effective. Un processus de classification des incidents qui n’a pas \u00e9t\u00e9 utilis\u00e9 au cours des six derniers mois, faute d’incident majeur, sera tout de m\u00eame examin\u00e9. Les superviseurs exigeront alors des exercices ou des *tabletop exercises* (simulations de crise) pour attester de l’\u00e9tat de pr\u00e9paration. Les \u00e9tablissements qui r\u00e9alisent ces exercices trimestriellement s’en sortent bien mieux que ceux qui ne les font qu’une fois par an.<\/p>\n Un autre aspect souvent relev\u00e9 lors de la deuxi\u00e8me vague concerne le r\u00f4le de la direction g\u00e9n\u00e9rale. DORA (*Digital Operational Resilience Act* – r\u00e8glement europ\u00e9en sur la r\u00e9silience op\u00e9rationnelle num\u00e9rique) n’est ni une simple question de conformit\u00e9, ni un sujet purement informatique. La responsabilit\u00e9 incombe au directoire, et non \u00e0 la deuxi\u00e8me ligne manag\u00e9riale. Les superviseurs v\u00e9rifient si le directoire pilote activement les mesures DORA, s’il re\u00e7oit r\u00e9guli\u00e8rement des rapports et s’il a co-d\u00e9cid\u00e9 la feuille de route des rem\u00e9diations. Ceux qui d\u00e9l\u00e8guent cette responsabilit\u00e9 \u00e0 la direction informatique re\u00e7oivent des constats au niveau du directoire. Les \u00e9tablissements dot\u00e9s 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\u00e9di\u00e9, fournissent des preuves bien plus cr\u00e9dibles que ceux qui traitent DORA comme un projet technique.<\/p>\n Enfin, DORA modifie la collaboration entre la s\u00e9curit\u00e9 de l’information, l’exploitation informatique et la conformit\u00e9 op\u00e9rationnelle. Ces trois fonctions doivent s’inscrire dans les m\u00eames flux de travail, et non dans des silos distincts. Les \u00e9tablissements qui, lors du premier cycle, utilisaient encore des transferts manuels bas\u00e9s sur Excel entre le RSSI (*Responsable de la S\u00e9curit\u00e9 des Syst\u00e8mes d’Information*), le DSI (*Directeur des Syst\u00e8mes d’Information*) et la conformit\u00e9, mettent en place lors du deuxi\u00e8me cycle des plateformes GRC (*Governance, Risk and Compliance*) communes. Celles-ci permettent de centraliser les constats, les mesures et les preuves, r\u00e9duisant ainsi les temps de recherche lors des audits et pr\u00e9sentant aux superviseurs une organisation coordonn\u00e9e plut\u00f4t que plusieurs documentations isol\u00e9es.<\/p>\n Pour conclure, un point qui fait la diff\u00e9rence entre l’obligation d’audit et l’utilit\u00e9 en termes de r\u00e9silience. Dans la pratique, DORA constitue un cadre qui \u00e9l\u00e8ve la maturit\u00e9 de la r\u00e9ponse aux incidents et la gestion des risques li\u00e9s aux tiers \u00e0 un niveau dont de nombreux \u00e9tablissements ont de toute fa\u00e7on besoin. Ceux qui per\u00e7oivent ces exigences comme une simple obligation de conformit\u00e9 obtiennent une documentation co\u00fbteuse sans valeur ajout\u00e9e. En revanche, ceux qui les consid\u00e8rent comme une opportunit\u00e9 d’am\u00e9liorer leur r\u00e9silience face aux perturbations TIC disposent, apr\u00e8s douze mois, non seulement d’un rapport d’audit irr\u00e9prochable, 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\u00e9pendamment de la r\u00e9glementation. DORA fixe simplement le calendrier dans lequel ils doivent \u00eatre mis en place.<\/p>\n Le r\u00e8glement s\u2019applique \u00e0 l\u2019ensemble des institutions financi\u00e8res supervis\u00e9es au sein de l\u2019UE : banques, assurances, soci\u00e9t\u00e9s de gestion d\u2019actifs, prestataires de services de paiement, \u00e9tablissements de monnaie \u00e9lectronique, fonds d\u2019investissement, infrastructures de march\u00e9 et prestataires tiers critiques en mati\u00e8re de TIC (technologies de l\u2019information et de la communication). Des all\u00e8gements sont pr\u00e9vus pour les petits \u00e9tablissements sous certains seuils, mais aucune exemption totale n\u2019est accord\u00e9e. Les prestataires travaillant pour des institutions financi\u00e8res sans \u00eatre eux-m\u00eames r\u00e9gul\u00e9s se voient imposer, par le biais des clauses relatives aux tiers incluses dans les contrats de leurs clients, des exigences indirectement li\u00e9es \u00e0 DORA.<\/p>\n Contexte DACH :<\/em> DORA (Digital Operational Resilience Act) est un r\u00e8glement europ\u00e9en entr\u00e9 en vigueur en 2023, visant \u00e0 renforcer la r\u00e9silience op\u00e9rationnelle num\u00e9rique du secteur financier. Il s\u2019inscrit dans une strat\u00e9gie plus large de l\u2019UE pour harmoniser la cybers\u00e9curit\u00e9 et la gestion des risques li\u00e9s aux TIC.<\/p>\n DORA est sp\u00e9cifique au secteur financier et impose des exigences plus d\u00e9taill\u00e9es en mati\u00e8re de signalement des incidents, de tests et de gestion des prestataires tiers. NIS2, en revanche, s\u2019applique de mani\u00e8re transversale \u00e0 plusieurs secteurs et reste plus g\u00e9n\u00e9ral sur certains aspects. Lorsqu\u2019un \u00e9tablissement est soumis aux deux r\u00e8glements, DORA prime dans son champ d\u2019application.<\/p>\n Contexte r\u00e9glementaire :<\/em> NIS2 (Network and Information Security Directive 2) est une directive europ\u00e9enne visant \u00e0 am\u00e9liorer la cybers\u00e9curit\u00e9 des op\u00e9rateurs critiques et des fournisseurs de services num\u00e9riques dans l\u2019UE. Elle a \u00e9t\u00e9 transpos\u00e9e dans les l\u00e9gislations nationales des \u00c9tats membres.<\/p>\n Les autorit\u00e9s europ\u00e9ennes de surveillance d\u00e9signent comme CTPP (Critical Third-Party Providers) les prestataires jug\u00e9s critiques pour plusieurs institutions financi\u00e8res. Ces derniers sont soumis \u00e0 un r\u00e9gime de supervision sp\u00e9cifique. Il s\u2019agit g\u00e9n\u00e9ralement des grands fournisseurs de cloud, des prestataires centraux de services de paiement et des \u00e9diteurs sp\u00e9cialis\u00e9s dans les syst\u00e8mes bancaires centraux. La liste des CTPP est mise \u00e0 jour chaque ann\u00e9e.<\/p>\n Pour les \u00e9tablissements soumis \u00e0 l\u2019obligation de TLPT (Threat-Led Penetration Testing, ou test d\u2019intrusion dirig\u00e9 par les menaces), un test doit \u00eatre effectu\u00e9 au moins tous les trois ans. Toutefois, en cas de modifications majeures dans l\u2019environnement informatique ou apr\u00e8s des incidents significatifs, l\u2019autorit\u00e9 de surveillance peut exiger un test anticip\u00e9. La planification de ces tests n\u00e9cessite un d\u00e9lai de six \u00e0 neuf mois.<\/p>\n L\u2019audit interne joue un r\u00f4le central. Il v\u00e9rifie en continu que les processus de gestion des risques li\u00e9s aux TIC respectent les exigences de DORA et rend compte directement au directoire et au conseil de surveillance. Sans une capacit\u00e9 d\u2019audit interne suffisante, l\u2019examen externe men\u00e9 par les autorit\u00e9s de r\u00e9gulation peut se transformer en un v\u00e9ritable test de r\u00e9sistance pour lequel vous ne seriez pas pr\u00e9par\u00e9.<\/p>\n\n
Ce que les premiers audits de 2026 ont r\u00e9ellement r\u00e9v\u00e9l\u00e9<\/h2>\n
Registres des tiers et sc\u00e9narios de sortie<\/h2>\n
\n
\n
Points cl\u00e9s : TLPT en pratique – march\u00e9, capacit\u00e9s et maturit\u00e9 interne<\/h2>\n
Feuille de route op\u00e9rationnelle pour les \u00e9quipes de s\u00e9curit\u00e9 dans la deuxi\u00e8me phase de DORA<\/h2>\n
Questions fr\u00e9quentes<\/h2>\n
Quels \u00e9tablissements sont concern\u00e9s par DORA ?<\/h3>\n
Quelles sont les diff\u00e9rences entre DORA et NIS2 ?<\/h3>\n
Quel est le r\u00f4le des prestataires tiers critiques en TIC (CTPP) ?<\/h3>\n
\u00c0 quelle fr\u00e9quence un TLPT doit-il \u00eatre r\u00e9alis\u00e9 ?<\/h3>\n
Quel est le r\u00f4le des audits internes dans la mise en \u0153uvre de DORA ?<\/h3>\n
Plus d’articles du r\u00e9seau m\u00e9dia MBF<\/h2>\n