8 min. de lecture<\/p>\n
Le 16 avril 2026, l’autorit\u00e9 britannique de r\u00e9gulation financi\u00e8re a publi\u00e9 de nouvelles r\u00e8gles relatives aux incidents op\u00e9rationnels et au reporting des tiers, inaugurant ainsi la premi\u00e8re vague r\u00e9glementaire post-DORA en Europe. La Financial Conduct Authority exige des \u00e9tablissements financiers et de leurs prestataires TIC tiers de nouveaux d\u00e9lais de classification et de notification, dont la profondeur et la rigueur d’examen vont au-del\u00e0 de DORA. \u00c0 Bruxelles, les pr\u00e9paratifs avancent en parall\u00e8le pour une \u00e9valuation de DORA devant alimenter un rapport de r\u00e9vision fin 2026, rendant probable un renforcement du texte en 2027. Les \u00e9quipes de s\u00e9curit\u00e9 ne devraient pas attendre un DORA 2.0, mais tester d\u00e8s maintenant leur architecture face aux lacunes identifi\u00e9es.<\/strong><\/p>\n L’essentiel en bref<\/p>\n Associ\u00e9<\/span>CVE ASP.NET Core : cons\u00e9quences pour la conformit\u00e9 DORA et NIS2<\/a> \/<\/span> S\u00e9curit\u00e9 OT 2026 : IEC 62443 et Cyber Resilience Act<\/a><\/p>\n La Financial Conduct Authority a publi\u00e9 son Policy Statement relatif aux r\u00e8gles de d\u00e9claration des incidents op\u00e9rationnels et des tiers le 16 avril 2026. Le durcissement central est une nouvelle obligation de notification \u00e0 deux niveaux : tout incident ICT op\u00e9rationnellement significatif d\u00e9passant un seuil d’impact quantifi\u00e9 doit \u00eatre signal\u00e9 dans un d\u00e9lai de six heures sous forme d’Initial Notification, suivi d’une analyse post-incident d\u00e9taill\u00e9e dans les 30 jours. L’\u00e9l\u00e9ment Third-Party-Reporting est particuli\u00e8rement notable : les \u00e9tablissements financiers ne doivent plus seulement d\u00e9clarer leurs propres incidents, mais \u00e9galement les incidents mat\u00e9riels survenus chez leurs prestataires ICT tiers lorsque ceux-ci ont des r\u00e9percussions sur les services financiers britanniques.<\/p>\n DORA dans sa forme actuelle exige \u00e9galement un reporting des incidents, mais laisse les seuils de classification nettement plus ouverts \u00e0 l’interpr\u00e9tation. Les RTS des AES de 2024 d\u00e9finissent des crit\u00e8res qualitatifs, mais la pratique de mise en \u0153uvre au cours des quinze premiers mois r\u00e9v\u00e8le que les \u00e9tablissements financiers se trouvant dans une m\u00eame situation parviennent \u00e0 des \u00e9valuations tr\u00e8s diff\u00e9rentes. Le Royaume-Uni en a manifestement pris acte et a quantifi\u00e9 le catalogue de classification dans sa r\u00e9glementation de substitution.<\/p>\n Pour les \u00e9tablissements financiers de la zone DACH, la vague britannique est pertinente pour trois raisons. Premi\u00e8rement, la plupart des grandes banques et assureurs op\u00e8rent des entit\u00e9s significatives au Royaume-Uni et doivent de toute fa\u00e7on mettre en \u0153uvre ces r\u00e8gles. Deuxi\u00e8mement, le texte britannique sert de facto de mod\u00e8le pour l’\u00e9valuation de DORA que la Commission europ\u00e9enne doit finaliser d’ici fin 2026. Troisi\u00e8mement, les seuils britanniques \u00e9tablissent un nouveau benchmark sur lequel les superviseurs des \u00c9tats membres de l’UE vont calibrer leurs attentes, bien avant toute adaptation formelle de DORA.<\/p>\n Qu’est-ce que DORA 2.0 ?<\/strong> DORA 2.0 n’est actuellement pas un acte l\u00e9gislatif adopt\u00e9, mais la d\u00e9signation courante dans le secteur pour la r\u00e9vision attendue du r\u00e8glement UE 2022\/2554. La Commission europ\u00e9enne est l\u00e9galement tenue de pr\u00e9senter une \u00e9valuation de la mise en \u0153uvre de DORA d’ici le 17 janvier 2028. Les premiers documents de travail des AES \u00e9voquent d\u00e9j\u00e0 un renforcement des normes techniques pour 2026, notamment en mati\u00e8re de classification des incidents, de p\u00e9rim\u00e8tre TLPT et de risque ICT li\u00e9 aux tiers. Les \u00e9tablissements financiers devraient lire ce terme comme un terme g\u00e9n\u00e9rique regroupant une combinaison de RTS r\u00e9vis\u00e9s et d’\u00e9ventuels amendements au r\u00e8glement.<\/p>\n Quiconque examine les premiers retours des superviseurs en Allemagne, en France et aux Pays-Bas retrouve toujours les m\u00eames trois lacunes. Ce sont elles qui concentreront vraisemblablement le renforcement \u00e0 venir de DORA.<\/p>\n Classification des incidents sans coh\u00e9rence.<\/strong> Les RTS d\u00e9finissent les crit\u00e8res d’impact de mani\u00e8re qualitative : impact sur la client\u00e8le, dur\u00e9e, dimension protection des donn\u00e9es, effet r\u00e9putationnel. Cela para\u00eet rigoureux, mais produit en pratique des d\u00e9cisions incoh\u00e9rentes. Deux \u00e9tablissements confront\u00e9s \u00e0 la m\u00eame panne cloud aboutissent souvent \u00e0 des classifications diff\u00e9rentes. Nous avons vu \u00e0 plusieurs reprises, lors de revues d’incidents, qu’un \u00e9v\u00e9nement \u00e9tait qualifi\u00e9 en interne de \u00ab major \u00bb, mais d\u00e9clar\u00e9 \u00e0 la BaFin comme \u00ab significant \u00bb, parce que l’obligation de reporting s’applique plus t\u00f4t pour la cat\u00e9gorie \u00ab major \u00bb. L’approche britannique avec des seuils quantitatifs stricts est la r\u00e9ponse directe \u00e0 ce probl\u00e8me.<\/p>\n P\u00e9rim\u00e8tre TLPT trop \u00e9troit.<\/strong> Les tests de p\u00e9n\u00e9tration fond\u00e9s sur les menaces (Threat-Led Penetration Testing) sont obligatoires sous DORA pour les \u00e9tablissements d’importance syst\u00e9mique, et le cadre TIBER-EU constitue le standard de facto. Lors des premiers cycles TLPT en 2025, de nombreux \u00e9tablissements ont restreint le p\u00e9rim\u00e8tre \u00e0 leurs propres canaux num\u00e9riques. La cha\u00eene d’approvisionnement ICT a souvent \u00e9t\u00e9 exclue. L’ESMA a indiqu\u00e9 dans un rapport trimestriel du T1 2026 que les prochains contr\u00f4les devront couvrir l’ensemble de la cha\u00eene ICT critique. C’est un saut technique consid\u00e9rable : mener des sc\u00e9narios Red Team contre des prestataires de services manag\u00e9s et leur infrastructure suppose des contrats et une disposition \u00e0 coop\u00e9rer qui sont aujourd’hui rarement document\u00e9s.<\/p>\n Registre ICT tiers incomplet.<\/strong> Le registre ICT DORA est, en th\u00e9orie, une repr\u00e9sentation exhaustive de tous les services ICT critiques. En pratique, les relations avec les sous-traitants (sub-processors) ne sont souvent pas recens\u00e9es. Le rapprochement de Commvault avec Google Cloud du 22 avril en est un bon exemple : quiconque r\u00e9f\u00e9rence aujourd’hui Commvault comme prestataire de sauvegarde dans le registre doit potentiellement y ajouter Google Cloud en tant que sub-processor apr\u00e8s l’int\u00e9gration. Si ces \u00e9volutions ne sont pas r\u00e9percut\u00e9es, il se cr\u00e9e un \u00e9cart entre la r\u00e9alit\u00e9 op\u00e9rationnelle et l’\u00e9tat du registre, qui sera relev\u00e9 lors du prochain contr\u00f4le.<\/p>\n \nTenir un registre ICT comme un inventaire mis \u00e0 jour une fois par an, c’est ne pas avoir compris en 2026 ni la r\u00e9glementation britannique ni le renforcement \u00e0 venir de DORA. En 2026, les registres sont op\u00e9rationnels – ou ils sont inutiles.\n<\/p><\/blockquote>\n Les autorit\u00e9s europ\u00e9ennes de surveillance EBA, ESMA et EIOPA ont publi\u00e9 d\u00e9but 2026 une \u00e9valuation commune de la premi\u00e8re phase d’application de DORA. Les conclusions principales recoupent largement les observations des superviseurs nationaux tels que la BaFin et la DNB n\u00e9erlandaise. Trois constats traversent l’ensemble des rapports de mani\u00e8re constante.<\/p>\n Premi\u00e8rement : la qualit\u00e9 du reporting est in\u00e9gale. Pour un m\u00eame type d’incident, les donn\u00e9es d’impact varient d’un facteur trois \u00e0 cinq entre \u00e9tablissements. Il s’agit moins d’un probl\u00e8me de mauvaise volont\u00e9 que d’un probl\u00e8me m\u00e9thodologique. Les RTS d\u00e9finissent des crit\u00e8res qualitatifs sans mod\u00e8le de calcul concret ; les gestionnaires d’incidents dans les banques ne disposent d’aucun mod\u00e8le standardis\u00e9 sur lequel s’appuyer. Il en r\u00e9sulte que les superviseurs peinent \u00e0 effectuer des comparaisons transversales, alors que c’est pr\u00e9cis\u00e9ment l’objectif d’un r\u00e8glement \u00e0 l’\u00e9chelle europ\u00e9enne.<\/p>\n Deuxi\u00e8mement : la visibilit\u00e9 sur les prestataires tiers s’arr\u00eate presque toujours au premier niveau. Un \u00e9tablissement conna\u00eet ses fournisseurs ICT directs, mais rarement le deuxi\u00e8me ou le troisi\u00e8me niveau. Cela contredit l’ambition de DORA, qui exige une transparence sur toute la cha\u00eene jusqu’aux sub-processors critiques. La pratique de conformit\u00e9 reste en de\u00e7\u00e0 des attentes r\u00e9glementaires. Lorsqu’un incident majeur survenant chez un sub-processor impacte la banque, la reconstruction a posteriori est laborieuse, voire impossible.<\/p>\n Troisi\u00e8mement : les r\u00e9sultats des TLPT sont souvent trait\u00e9s en interne comme des \u00e9v\u00e9nements isol\u00e9s. Les RTS pr\u00e9voient que les enseignements tir\u00e9s alimentent l’analyse de risque continue. En pratique, ils atterrissent fr\u00e9quemment dans un rapport volumineux pr\u00e9sent\u00e9 une fois au conseil d’administration, sans qu’en d\u00e9coulent syst\u00e9matiquement des d\u00e9cisions d’architecture. L’effet d’apprentissage reste inf\u00e9rieur \u00e0 ce que le r\u00e8glement avait pr\u00e9vu.<\/p>\n Le renforcement du cadre est en route, mais pas pour aujourd’hui. La r\u00e9ponse utile n’est pas l’attente, mais un travail pr\u00e9paratoire cibl\u00e9 qui fait sens ind\u00e9pendamment du libell\u00e9 exact d’un futur RTS DORA 2. Cinq points \u00e0 mettre en \u0153uvre dans les 120 prochains jours.<\/p>\n Premi\u00e8rement : une taxonomie unifi\u00e9e des incidents.<\/strong> Aligner la classification interne sur les seuils de la FCA, m\u00eame si l’\u00e9tablissement n’op\u00e8re pas au Royaume-Uni. Des crit\u00e8res quantitatifs r\u00e9duisent la variance entre les diff\u00e9rents responsables de gestion des incidents et fournissent une argumentation d\u00e9fendable face aux superviseurs. L’effort repr\u00e9sente une semaine d’atelier plus les ajustements d’outillage.<\/p>\n Deuxi\u00e8mement : \u00e9largir le p\u00e9rim\u00e8tre du TLPT.<\/strong> Lorsque la prochaine fen\u00eatre TLPT s’ouvrira en 2026 ou 2027, la cha\u00eene d’approvisionnement ICT devrait \u00eatre int\u00e9gr\u00e9e au p\u00e9rim\u00e8tre. Concr\u00e8tement, cela signifie inclure explicitement au moins un prestataire de services manag\u00e9s central dans le sc\u00e9nario red team, avec accord contractuel. M\u00eame si DORA 2.0 ne l’exige pas encore, le b\u00e9n\u00e9fice en termes de connaissance de sa propre architecture est \u00e9lev\u00e9.<\/p>\n Troisi\u00e8mement : maintenir le registre ICT en conditions op\u00e9rationnelles.<\/strong> Ne pas traiter le registre comme un document de conformit\u00e9, mais comme une base de donn\u00e9es active avec des int\u00e9grations automatis\u00e9es vers le contract management et la CMDB. Chaque nouvelle int\u00e9gration d’un prestataire ICT devrait alimenter le registre automatiquement. Une revue trimestrielle en cas de modification dans la cha\u00eene des sous-traitants.<\/p>\n Quatri\u00e8mement : le monitoring des tiers.<\/strong> La r\u00e9glementation britannique exige des notifications concernant les incidents survenus chez les prestataires. Cela ne fonctionne que si l’\u00e9tablissement dispose d’un monitoring actif aupr\u00e8s de ses prestataires critiques. Concr\u00e8tement : API d’incidents, scraping de pages de statut et appels r\u00e9guliers de coordination SOC. De nombreux \u00e9tablissements disposent de cela pour leurs syst\u00e8mes c\u0153ur, mais pas pour leurs sous-traitants.<\/p>\n Cinqui\u00e8mement : r\u00e9viser les runbooks.<\/strong> Le d\u00e9lai de notification de six heures de la FCA n’est r\u00e9alistement tenable que si le runbook interne d\u00e9finit strictement les 90 premi\u00e8res minutes. Ceux qui d\u00e9battent encore, en plein incident majeur, de qui doit appeler la hotline de la BaFin ne respecteront pas ce d\u00e9lai.<\/p>\n Un d\u00e9tail souvent n\u00e9glig\u00e9 dans le d\u00e9bat : ni DORA ni la r\u00e9glementation britannique n’exigent une publication simultan\u00e9e \u00e0 destination du grand public. La notification est adress\u00e9e au superviseur ; la communication avec les clients et la presse reste du ressort de l’\u00e9tablissement. Confondre les deux g\u00e9n\u00e8re des risques r\u00e9putationnels inutiles. Pour la d\u00e9fense en trois lignes, cela signifie que la conformit\u00e9, la communication et la s\u00e9curit\u00e9 informatique doivent avoir des r\u00f4les clairement d\u00e9finis dans le playbook de r\u00e9ponse aux incidents. Cela semble trivial, mais c’est en pratique l’une des causes de d\u00e9faillance les plus fr\u00e9quentes.<\/p>\n L’\u00e9cart de discipline entre les ambitions de DORA et leur mise en \u0153uvre explique \u00e9galement pourquoi certains \u00e9tablissements supportent soudainement des co\u00fbts de rem\u00e9diation disproportionn\u00e9s apr\u00e8s un seul incident. Ceux qui r\u00e9digent leurs runbooks proprement \u00e0 l’avance et les testent trois \u00e0 quatre fois par an via des exercices de tabletop se situent dans la fourchette des cinq chiffres moyens. Ceux qui r\u00e9agissent apr\u00e8s qu’un incident majeur a \u00e9t\u00e9 document\u00e9 atteignent rapidement plusieurs centaines de milliers d’euros de conseil externe, car chaque ajustement s’effectue sous pression de temps.<\/p>\n En pratique, il appara\u00eet \u00e9galement que la coordination avec les prestataires ICT critiques est bien plus fluide lorsque l’\u00e9tablissement dispose de processus internes clairs. Un prestataire qui re\u00e7oit de son client bancaire trois demandes contradictoires pour un seul et m\u00eame incident adopte une posture d\u00e9fensive et fournit un minimum d’informations. Un client bancaire disposant d’un point de contact unique et d’un chemin d’escalade clair obtient une coop\u00e9ration nettement plus substantielle. Ce n’est pas un argument r\u00e9glementaire, mais une exp\u00e9rience op\u00e9rationnelle concr\u00e8te ; elle est souvent confirm\u00e9e lors d’\u00e9changes informels avec des superviseurs.<\/p>\n Pour la planification budg\u00e9taire 2027, un simple reality-check s’impose. Les \u00e9tablissements qui ont jusqu’ici consid\u00e9r\u00e9 leur architecture DORA comme un poste de co\u00fbt devraient profiter des douze prochains mois pour rendre la valeur op\u00e9rationnelle visible. Un registre ICT correctement tenu, connect\u00e9 \u00e0 la CMDB et au contract management, n’est pas seulement un exercice de conformit\u00e9, mais le fondement d’un vendor management rigoureux. Un mod\u00e8le de taxonomie des incidents op\u00e9rationnalis\u00e9 acc\u00e9l\u00e8re les post-mortems et r\u00e9duit le Mean Time to Resolution. Ceux qui formulent cela de mani\u00e8re convaincante auront plus facilement acc\u00e8s aux budgets pour la phase deux.<\/p>\n Aucune date n’a \u00e9t\u00e9 confirm\u00e9e. La Commission europ\u00e9enne doit pr\u00e9senter une \u00e9valuation d’ici le 17 janvier 2028. Des ajustements des RTS sont probables entre 2026 et 2027. Le terme DORA 2.0 est commun\u00e9ment utilis\u00e9 dans le secteur pour d\u00e9signer ces r\u00e9visions, mais ne constitue pas un acte juridique officiel.<\/p>\n Uniquement si un \u00e9tablissement op\u00e8re dans le p\u00e9rim\u00e8tre britannique, auquel cas oui. Pour les \u00e9tablissements purement \u00e9tablis dans l’UE, elles ont une valeur de signal. Les superviseurs du continent alignent leurs attentes sur celles du voisinage ; les seuils de la FCA seront vraisemblablement utilis\u00e9s comme r\u00e9f\u00e9rence lors des futures r\u00e9visions des RTS.<\/p>\n Le Threat-Led Penetration Testing est un test Red Team approfondi r\u00e9alis\u00e9 dans des conditions r\u00e9elles d’attaque. Le cadre TIBER-EU de la BCE constitue le standard europ\u00e9en. Le p\u00e9rim\u00e8tre, les r\u00e8gles et le d\u00e9roulement sont nettement plus stricts que lors des tests d’intrusion classiques. Pour les \u00e9tablissements d’importance syst\u00e9mique, le TLPT est obligatoire dans le cadre de DORA.<\/p>\n Au minimum chaque trimestre, et imm\u00e9diatement en cas de modification dans la cha\u00eene des prestataires critiques. En r\u00e8gle g\u00e9n\u00e9rale : lorsqu’un nouveau sous-traitant est int\u00e9gr\u00e9 ou qu’un prestataire existant migre son infrastructure, le registre doit \u00eatre mis \u00e0 jour en temps r\u00e9el. Des outils comme OneTrust ou Archer proposent des workflows adapt\u00e9s \u00e0 cet effet.<\/p>\n Pour un \u00e9tablissement financier de taille moyenne, les co\u00fbts suppl\u00e9mentaires se situent entre 150 000 et 400 000 euros la premi\u00e8re ann\u00e9e, selon le niveau de maturit\u00e9 du dispositif existant de gestion des risques ICT. L’effort le plus important r\u00e9side dans l’extension du p\u00e9rim\u00e8tre TLPT, le moins important dans l’alignement taxonomique.<\/p>\n S\u00e9lection de la r\u00e9daction<\/p>\n Plus du r\u00e9seau MBF Media<\/p>\n\n
Ce que la FCA britannique a concr\u00e8tement modifi\u00e9 le 16 avril<\/h2>\n
Les trois failles que les audits DORA 2025\/2026 identifient syst\u00e9matiquement<\/h2>\n
Ce que les premi\u00e8res \u00e9valuations des AES 2025\/26 r\u00e9v\u00e8lent sobrement<\/h2>\n
Cinq \u00e9tapes que les \u00e9quipes s\u00e9curit\u00e9 doivent engager d\u00e8s maintenant<\/h2>\n
Questions fr\u00e9quentes<\/h2>\n
Quand DORA 2.0 entrera-t-il en vigueur ?<\/h3>\n
Les r\u00e8gles britanniques sont-elles contraignantes pour les \u00e9tablissements de l’UE ?<\/h3>\n
En quoi consiste concr\u00e8tement le TLPT ?<\/h3>\n
\u00c0 quelle fr\u00e9quence le registre ICT doit-il \u00eatre mis \u00e0 jour ?<\/h3>\n
Quels sont les co\u00fbts r\u00e9alistes pour les cinq \u00e9tapes ?<\/h3>\n
\n