Règlement DORA : qui est concerné, ce qu'il exige, comment
s'y préparer

Pour le secteur financier, l'échéance DORA est déjà derrière. Le règlement s'applique dans toute l'Union européenne depuis le 17 janvier 2025, directement, sans transposition ni loi française à attendre. Beaucoup d'entités le découvrent pourtant avec un tableau de conformité où la ligne « DORA » affiche encore « à cadrer », alors que la date d'application, elle, est passée depuis des mois. Un règlement européen ne prévient pas deux fois, et le superviseur peut le rappeler quand il veut.

DORA (Digital Operational Resilience Act, règlement UE 2022/2554) impose au secteur financier européen un cadre unique de résilience opérationnelle numérique. Reste à savoir qui est concerné, ce que le texte exige vraiment, comment il s'articule avec la directive NIS2, et par où commencer quand on réalise qu'on est déjà dans le champ.

Le règlement DORA en clair : un texte directement applicable

La première chose à comprendre tient à sa nature juridique. DORA est un règlement, pas une directive. La nuance n'est pas de la pédanterie : un règlement s'applique tel quel dans tous les États membres, là où une directive doit d'abord passer par une loi de transposition dans chaque pays. Le texte a été adopté fin 2022 et il est entré en vigueur début 2023 ; il s'applique dans toute l'Union depuis le 17 janvier 2025. Autrement dit, il n'y a plus de délai de grâce à espérer : les obligations sont exigibles maintenant.

L'objectif du texte tient en une idée. Là où la réglementation prudentielle classique demande « avez-vous assez de fonds propres pour absorber un choc financier ? », DORA demande « votre système d'information tient-il debout quand il est attaqué ou qu'il tombe ? ». La cybersécurité cesse d'être une bonne pratique optionnelle pour devenir une obligation prudentielle à part entière, contrôlée par les mêmes autorités qui surveillent votre solvabilité. En France, selon votre statut, cela veut dire l'ACPR, l'AMF ou la BCE.

DORA, qui est concerné ?

La question « DORA, qui est concerné ? » a une réponse plus large qu'on ne le croit. L'article 2 du règlement énumère une vingtaine de catégories d'entités financières, et la logique de cette liste est l'exhaustivité : si vous êtes agréé ou enregistré auprès d'un superviseur financier, vous êtes très probablement dedans. On y trouve notamment :

• Les établissements de crédit et de paiement, les établissements de monnaie électronique : banques traditionnelles comme néobanques et fintechs agréées.
• Les entreprises d'assurance et de réassurance ainsi que les intermédiaires d'assurance, au-delà d'un certain seuil de taille.
• Les sociétés de gestion et entreprises d'investissement, fonds, dépositaires et infrastructures de marché qui font tourner la place.
• Les prestataires de services sur crypto-actifs, agréés au titre du règlement MiCA, explicitement rattrapés par DORA.

Le texte n'est pas aveugle à la taille. Les micro-entreprises et certaines petites entités bénéficient d'un régime simplifié, et quelques acteurs très modestes sortent du champ. Mais le critère d'entrée reste le statut réglementaire, pas l'effectif : une fintech de trente personnes agréée établissement de paiement est concernée au même titre qu'une grande banque, seule l'intensité des obligations varie.

Les prestataires tiers de services TIC : l'angle mort

Il y a une population qui ne se sait presque jamais concernée : les prestataires tiers de services TIC. Hébergeurs, éditeurs SaaS, infogéreurs, fournisseurs de briques logicielles. Vous n'êtes ni une banque ni un assureur, vous vendez de la technologie à qui en veut, et pourtant DORA vous rattrape par deux chemins bien distincts.

Le premier chemin touche tout le monde. Les articles 28 à 30 imposent aux entités financières un socle de clauses dans chaque contrat de service TIC, durci quand le service soutient une fonction critique : droits d'audit et d'inspection, notification d'incident, stratégie de sortie, coopération aux tests de résilience. Concrètement, vos clients financiers vous envoient des avenants et des questionnaires, et votre posture de sécurité devient un critère de référencement. C'est le même effet ricochet que subissent les PME rattrapées par la directive NIS2 via leurs donneurs d'ordre. Le second chemin ne vise que les plus gros : les prestataires jugés critiques pour le secteur, comme les grands cloud, sont désignés par les autorités européennes et passent sous surveillance directe, avec des astreintes à la clé.

Les cinq piliers de DORA

DORA s'organise en cinq blocs d'obligations. Les quatre premiers sont contraignants, le cinquième relève de l'incitation. Il faut les lire comme un empilement, pas comme une liste : on ne teste bien que ce qu'on a d'abord cartographié et gouverné, et on ne partage utilement du renseignement que si on sait déjà détecter ses propres incidents.

Le troisième pilier est celui qui change le métier des équipes sécurité. L'article 24 impose un programme de tests de résilience documenté et cadencé au moins une fois par an sur tous les systèmes qui soutiennent des fonctions critiques, et l'article 25 en détaille la panoplie : analyses de vulnérabilités, évaluations de sécurité réseau, revues de code, et tests de pénétration. Le mot est écrit noir sur blanc dans le règlement. Au-dessus de ce socle annuel, les entités désignées doivent passer, tous les trois ans, un test d'intrusion TLPT, un exercice de red team calqué sur le cadre TIBER-EU que l'on détaille en entier dans notre guide dédié aux tests de pénétration guidés par la menace. On ne le refait pas ici : il mérite son propre article.

DORA et NIS2 : lequel s'applique ?

Les deux textes sont arrivés presque en même temps et semblent se marcher dessus. La règle de départage est nette : DORA est une lex specialis, un texte sectoriel qui prime sur NIS2 pour les entités financières qu'il couvre. Une banque, un assureur ou une fintech agréée suivent DORA pour leur gestion du risque TIC, leurs notifications d'incident et leurs tests, et non la directive NIS2. Les deux régimes ne s'opposent pas sur le fond : ils convergent vers les mêmes exigences (inventaire des actifs, sécurité de la chaîne d'approvisionnement, preuve d'efficacité des mesures), mais pour un acteur financier, c'est DORA qui fait foi.

Le cas ambigu, c'est le prestataire TIC. Lui peut cumuler : soumis à NIS2 en direct s'il coche les critères de secteur et de taille de la directive, et tenu par les clauses DORA que ses clients financiers lui imposent. Dans ce cas, la bonne nouvelle est que le travail de fond se recoupe largement, et qu'un même programme de sécurité sérieux nourrit les deux régimes.

Comment s'y préparer au règlement DORA

Entité financière de taille moyenne ou prestataire pris dans le ricochet contractuel, l'ordre de marche est le même, et il tient en trois verbes. Une précision d'honnêteté d'abord : nous ne sommes pas un cabinet de conformité et nous ne rédigerons pas votre politique de gouvernance à votre place. Notre terrain, c'est le volet technique du troisième pilier, celui où il faut prouver que ça tient.

Cartographier d'abord. Le programme de tests de l'article 24 et le registre d'informations de l'article 28 présupposent un inventaire exact de ce que vous exposez, sous-domaines oubliés et services hérités de vos prestataires compris. C'est précisément le travail d'une plateforme de gestion de la surface d'attaque externe : découvrir en continu les actifs exposés, les rattacher aux fonctions, et détecter ce qui apparaît entre deux audits. Un test annuel sur un périmètre faux est un test annuel perdu.

Tester ensuite, au rythme du texte. L'annualité de l'article 24 se prête mal au pentest « grand soir » tous les trois ans. La bonne mécanique combine un test d'intrusion régulier sur le périmètre exposé, une revue en profondeur des applications qui portent vos fonctions critiques, et une gestion des vulnérabilités continue entre deux campagnes pour traiter le flot de failles au fil de l'eau plutôt qu'en rafale la veille de l'audit. Pour les entités désignées TLPT, ce socle est aussi le meilleur entraînement : une red team fondée sur la menace trouvera en quelques mois ce qu'un programme de tests sérieux aurait éliminé en un an.

Prouver enfin. DORA est un régime de supervision : ce qui compte n'est pas d'avoir testé, mais de pouvoir montrer le rapport, le plan de remédiation, le retest qui confirme la fermeture, et la trace de tout cela dans la gouvernance. Chaque campagne doit sortir avec son dossier de preuve daté, celui qu'attendent le superviseur, l'auditeur et vos clients financiers.

À retenir

• DORA est un règlement, applicable depuis le 17 janvier 2025 : effet direct dans toute l'UE, sans transposition ni délai de grâce.
• Le champ est large : une vingtaine de catégories d'entités financières, des banques aux prestataires de crypto-actifs, plus les prestataires tiers de services TIC rattrapés par contrat ou par désignation.
• Cinq piliers : gestion du risque TIC, notification des incidents, tests de résilience (dont le TLPT), risque prestataires, et partage d'informations.
• Le pentest devient une obligation écrite via le programme de tests annuel de l'article 24, avec un TLPT tous les trois ans pour les entités désignées.
• DORA prime sur NIS2 pour les entités financières (lex specialis) ; un prestataire TIC peut, lui, cumuler les deux régimes.
• L'ordre de marche : cartographier, tester, prouver. Un inventaire faux rend le programme de tests non conforme par construction.

Si votre conformité DORA tient aujourd'hui sur une bonne intention et une ligne de budget, le plus court chemin commence par la visibilité, puis par un test qui produit de la preuve. C'est exactement le volet sur lequel on intervient : cadrer le périmètre exposé, dérouler le test de résilience, et vous remettre le dossier que l'article 24 attend. Entité financière ou prestataire TIC pris dans le ricochet contractuel, écrivez-nous via la page contact pour cadrer ce périmètre.