Règles FCA UK du 16 avril 2026 et la voie vers DORA 2.0 : ce que les institutions financières doivent préparer architecturalement dès maintenant

8 min. de lecture

Le 16 avril 2026, l’autorité britannique de régulation financière a publié de nouvelles règles relatives aux incidents opérationnels et au reporting des tiers, inaugurant ainsi la première vague réglementaire post-DORA en Europe. La Financial Conduct Authority exige des établissements financiers et de leurs prestataires TIC tiers de nouveaux délais de classification et de notification, dont la profondeur et la rigueur d’examen vont au-delà de DORA. À Bruxelles, les préparatifs avancent en parallèle pour une évaluation de DORA devant alimenter un rapport de révision fin 2026, rendant probable un renforcement du texte en 2027. Les équipes de sécurité ne devraient pas attendre un DORA 2.0, mais tester dès maintenant leur architecture face aux lacunes identifiées.

AssociéCVE ASP.NET Core : conséquences pour la conformité DORA et NIS2  /  Sécurité OT 2026 : IEC 62443 et Cyber Resilience Act

Ce que la FCA britannique a concrètement modifié le 16 avril

La Financial Conduct Authority a publié son Policy Statement relatif aux règles de déclaration des incidents opérationnels et des tiers le 16 avril 2026. Le durcissement central est une nouvelle obligation de notification à deux niveaux : tout incident ICT opérationnellement significatif dépassant un seuil d’impact quantifié doit être signalé dans un délai de six heures sous forme d’Initial Notification, suivi d’une analyse post-incident détaillée dans les 30 jours. L’élément Third-Party-Reporting est particulièrement notable : les établissements financiers ne doivent plus seulement déclarer leurs propres incidents, mais également les incidents matériels survenus chez leurs prestataires ICT tiers lorsque ceux-ci ont des répercussions sur les services financiers britanniques.

DORA dans sa forme actuelle exige également un reporting des incidents, mais laisse les seuils de classification nettement plus ouverts à l’interprétation. Les RTS des AES de 2024 définissent des critères qualitatifs, mais la pratique de mise en œuvre au cours des quinze premiers mois révèle que les établissements financiers se trouvant dans une même situation parviennent à des évaluations très différentes. Le Royaume-Uni en a manifestement pris acte et a quantifié le catalogue de classification dans sa réglementation de substitution.

Pour les établissements financiers de la zone DACH, la vague britannique est pertinente pour trois raisons. Premièrement, la plupart des grandes banques et assureurs opèrent des entités significatives au Royaume-Uni et doivent de toute façon mettre en œuvre ces règles. Deuxièmement, le texte britannique sert de facto de modèle pour l’évaluation de DORA que la Commission européenne doit finaliser d’ici fin 2026. Troisièmement, les seuils britanniques établissent un nouveau benchmark sur lequel les superviseurs des États membres de l’UE vont calibrer leurs attentes, bien avant toute adaptation formelle de DORA.

Qu’est-ce que DORA 2.0 ? DORA 2.0 n’est actuellement pas un acte législatif adopté, mais la désignation courante dans le secteur pour la révision attendue du règlement UE 2022/2554. La Commission européenne est légalement tenue de présenter une évaluation de la mise en œuvre de DORA d’ici le 17 janvier 2028. Les premiers documents de travail des AES évoquent déjà un renforcement des normes techniques pour 2026, notamment en matière de classification des incidents, de périmètre TLPT et de risque ICT lié aux tiers. Les établissements financiers devraient lire ce terme comme un terme générique regroupant une combinaison de RTS révisés et d’éventuels amendements au règlement.

Les trois failles que les audits DORA 2025/2026 identifient systématiquement

Quiconque examine les premiers retours des superviseurs en Allemagne, en France et aux Pays-Bas retrouve toujours les mêmes trois lacunes. Ce sont elles qui concentreront vraisemblablement le renforcement à venir de DORA.

Classification des incidents sans cohérence. Les RTS définissent les critères d’impact de manière qualitative : impact sur la clientèle, durée, dimension protection des données, effet réputationnel. Cela paraît rigoureux, mais produit en pratique des décisions incohérentes. Deux établissements confrontés à la même panne cloud aboutissent souvent à des classifications différentes. Nous avons vu à plusieurs reprises, lors de revues d’incidents, qu’un événement était qualifié en interne de « major », mais déclaré à la BaFin comme « significant », parce que l’obligation de reporting s’applique plus tôt pour la catégorie « major ». L’approche britannique avec des seuils quantitatifs stricts est la réponse directe à ce problème.

Périmètre TLPT trop étroit. Les tests de pénétration fondés sur les menaces (Threat-Led Penetration Testing) sont obligatoires sous DORA pour les établissements d’importance systémique, et le cadre TIBER-EU constitue le standard de facto. Lors des premiers cycles TLPT en 2025, de nombreux établissements ont restreint le périmètre à leurs propres canaux numériques. La chaîne d’approvisionnement ICT a souvent été exclue. L’ESMA a indiqué dans un rapport trimestriel du T1 2026 que les prochains contrôles devront couvrir l’ensemble de la chaîne ICT critique. C’est un saut technique considérable : mener des scénarios Red Team contre des prestataires de services managés et leur infrastructure suppose des contrats et une disposition à coopérer qui sont aujourd’hui rarement documentés.

Registre ICT tiers incomplet. Le registre ICT DORA est, en théorie, une représentation exhaustive de tous les services ICT critiques. En pratique, les relations avec les sous-traitants (sub-processors) ne sont souvent pas recensées. Le rapprochement de Commvault avec Google Cloud du 22 avril en est un bon exemple : quiconque référence aujourd’hui Commvault comme prestataire de sauvegarde dans le registre doit potentiellement y ajouter Google Cloud en tant que sub-processor après l’intégration. Si ces évolutions ne sont pas répercutées, il se crée un écart entre la réalité opérationnelle et l’état du registre, qui sera relevé lors du prochain contrôle.

Tenir un registre ICT comme un inventaire mis à jour une fois par an, c’est ne pas avoir compris en 2026 ni la réglementation britannique ni le renforcement à venir de DORA. En 2026, les registres sont opérationnels – ou ils sont inutiles.

Ce que les premières évaluations des AES 2025/26 révèlent sobrement

Les autorités européennes de surveillance EBA, ESMA et EIOPA ont publié début 2026 une évaluation commune de la première phase d’application de DORA. Les conclusions principales recoupent largement les observations des superviseurs nationaux tels que la BaFin et la DNB néerlandaise. Trois constats traversent l’ensemble des rapports de manière constante.

Premièrement : la qualité du reporting est inégale. Pour un même type d’incident, les données d’impact varient d’un facteur trois à cinq entre établissements. Il s’agit moins d’un problème de mauvaise volonté que d’un problème méthodologique. Les RTS définissent des critères qualitatifs sans modèle de calcul concret ; les gestionnaires d’incidents dans les banques ne disposent d’aucun modèle standardisé sur lequel s’appuyer. Il en résulte que les superviseurs peinent à effectuer des comparaisons transversales, alors que c’est précisément l’objectif d’un règlement à l’échelle européenne.

Deuxièmement : la visibilité sur les prestataires tiers s’arrête presque toujours au premier niveau. Un établissement connaît ses fournisseurs ICT directs, mais rarement le deuxième ou le troisième niveau. Cela contredit l’ambition de DORA, qui exige une transparence sur toute la chaîne jusqu’aux sub-processors critiques. La pratique de conformité reste en deçà des attentes réglementaires. Lorsqu’un incident majeur survenant chez un sub-processor impacte la banque, la reconstruction a posteriori est laborieuse, voire impossible.

Troisièmement : les résultats des TLPT sont souvent traités en interne comme des événements isolés. Les RTS prévoient que les enseignements tirés alimentent l’analyse de risque continue. En pratique, ils atterrissent fréquemment dans un rapport volumineux présenté une fois au conseil d’administration, sans qu’en découlent systématiquement des décisions d’architecture. L’effet d’apprentissage reste inférieur à ce que le règlement avait prévu.

Cinq étapes que les équipes sécurité doivent engager dès maintenant

Le renforcement du cadre est en route, mais pas pour aujourd’hui. La réponse utile n’est pas l’attente, mais un travail préparatoire ciblé qui fait sens indépendamment du libellé exact d’un futur RTS DORA 2. Cinq points à mettre en œuvre dans les 120 prochains jours.

Premièrement : une taxonomie unifiée des incidents. Aligner la classification interne sur les seuils de la FCA, même si l’établissement n’opère pas au Royaume-Uni. Des critères quantitatifs réduisent la variance entre les différents responsables de gestion des incidents et fournissent une argumentation défendable face aux superviseurs. L’effort représente une semaine d’atelier plus les ajustements d’outillage.

Deuxièmement : élargir le périmètre du TLPT. Lorsque la prochaine fenêtre TLPT s’ouvrira en 2026 ou 2027, la chaîne d’approvisionnement ICT devrait être intégrée au périmètre. Concrètement, cela signifie inclure explicitement au moins un prestataire de services managés central dans le scénario red team, avec accord contractuel. Même si DORA 2.0 ne l’exige pas encore, le bénéfice en termes de connaissance de sa propre architecture est élevé.

Troisièmement : maintenir le registre ICT en conditions opérationnelles. Ne pas traiter le registre comme un document de conformité, mais comme une base de données active avec des intégrations automatisées vers le contract management et la CMDB. Chaque nouvelle intégration d’un prestataire ICT devrait alimenter le registre automatiquement. Une revue trimestrielle en cas de modification dans la chaîne des sous-traitants.

Quatrièmement : le monitoring des tiers. La réglementation britannique exige des notifications concernant les incidents survenus chez les prestataires. Cela ne fonctionne que si l’établissement dispose d’un monitoring actif auprès de ses prestataires critiques. Concrètement : API d’incidents, scraping de pages de statut et appels réguliers de coordination SOC. De nombreux établissements disposent de cela pour leurs systèmes cœur, mais pas pour leurs sous-traitants.

Cinquièmement : réviser les runbooks. Le délai de notification de six heures de la FCA n’est réalistement tenable que si le runbook interne définit strictement les 90 premières minutes. Ceux qui débattent encore, en plein incident majeur, de qui doit appeler la hotline de la BaFin ne respecteront pas ce délai.

Un détail souvent négligé dans le débat : ni DORA ni la réglementation britannique n’exigent une publication simultanée à destination du grand public. La notification est adressée au superviseur ; la communication avec les clients et la presse reste du ressort de l’établissement. Confondre les deux génère des risques réputationnels inutiles. Pour la défense en trois lignes, cela signifie que la conformité, la communication et la sécurité informatique doivent avoir des rôles clairement définis dans le playbook de réponse aux incidents. Cela semble trivial, mais c’est en pratique l’une des causes de défaillance les plus fréquentes.

L’écart de discipline entre les ambitions de DORA et leur mise en œuvre explique également pourquoi certains établissements supportent soudainement des coûts de remédiation disproportionnés après un seul incident. Ceux qui rédigent leurs runbooks proprement à l’avance et les testent trois à quatre fois par an via des exercices de tabletop se situent dans la fourchette des cinq chiffres moyens. Ceux qui réagissent après qu’un incident majeur a été documenté atteignent rapidement plusieurs centaines de milliers d’euros de conseil externe, car chaque ajustement s’effectue sous pression de temps.

En pratique, il apparaît également que la coordination avec les prestataires ICT critiques est bien plus fluide lorsque l’établissement dispose de processus internes clairs. Un prestataire qui reçoit de son client bancaire trois demandes contradictoires pour un seul et même incident adopte une posture défensive 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ération nettement plus substantielle. Ce n’est pas un argument réglementaire, mais une expérience opérationnelle concrète ; elle est souvent confirmée lors d’échanges informels avec des superviseurs.

Pour la planification budgétaire 2027, un simple reality-check s’impose. Les établissements qui ont jusqu’ici considéré leur architecture DORA comme un poste de coût devraient profiter des douze prochains mois pour rendre la valeur opérationnelle visible. Un registre ICT correctement tenu, connecté à la CMDB et au contract management, n’est pas seulement un exercice de conformité, mais le fondement d’un vendor management rigoureux. Un modèle de taxonomie des incidents opérationnalisé accélère les post-mortems et réduit le Mean Time to Resolution. Ceux qui formulent cela de manière convaincante auront plus facilement accès aux budgets pour la phase deux.

Questions fréquentes

Quand DORA 2.0 entrera-t-il en vigueur ?

Aucune date n’a été confirmée. La Commission européenne doit présenter une évaluation d’ici le 17 janvier 2028. Des ajustements des RTS sont probables entre 2026 et 2027. Le terme DORA 2.0 est communément utilisé dans le secteur pour désigner ces révisions, mais ne constitue pas un acte juridique officiel.

Les règles britanniques sont-elles contraignantes pour les établissements de l’UE ?

Uniquement si un établissement opère dans le périmètre britannique, auquel cas oui. Pour les établissements purement établis 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és comme référence lors des futures révisions des RTS.

En quoi consiste concrètement le TLPT ?

Le Threat-Led Penetration Testing est un test Red Team approfondi réalisé dans des conditions réelles d’attaque. Le cadre TIBER-EU de la BCE constitue le standard européen. Le périmètre, les règles et le déroulement sont nettement plus stricts que lors des tests d’intrusion classiques. Pour les établissements d’importance systémique, le TLPT est obligatoire dans le cadre de DORA.

À quelle fréquence le registre ICT doit-il être mis à jour ?

Au minimum chaque trimestre, et immédiatement en cas de modification dans la chaîne des prestataires critiques. En règle générale : lorsqu’un nouveau sous-traitant est intégré ou qu’un prestataire existant migre son infrastructure, le registre doit être mis à jour en temps réel. Des outils comme OneTrust ou Archer proposent des workflows adaptés à cet effet.

Quels sont les coûts réalistes pour les cinq étapes ?

Pour un établissement financier de taille moyenne, les coûts supplémentaires se situent entre 150 000 et 400 000 euros la première année, selon le niveau de maturité du dispositif existant de gestion des risques ICT. L’effort le plus important réside dans l’extension du périmètre TLPT, le moins important dans l’alignement taxonomique.

Source image de couverture : Pexels / Sora Shimazaki (px:5669619)

À propos de l'auteur: Alec Chizhik

Plus d'articles de Alec Chizhik