Règlement DORA : tests de résilience, TLPT et pentest obligatoire dans
la finance

L'avenant arrive un jeudi, envoyé par la direction des achats de votre client bancaire. Quinze clauses nouvelles, non négociables : localisation des données, droit d'audit et d'inspection, stratégie de sortie, et une ligne qui fait lever un sourcil : « coopération du prestataire aux tests d'intrusion fondés sur la menace ». Vous n'êtes ni une banque ni un assureur. Vous vendez un SaaS de gestion documentaire. Et pourtant, vous venez de recevoir votre premier morceau de DORA.

Le règlement DORA (Digital Operational Resilience Act, règlement UE 2022/2554) s'applique depuis le 17 janvier 2025 à l'essentiel du secteur financier européen, et par contrat à ses prestataires informatiques. Ce guide couvre ce qui compte pour un DSI ou un RSSI : qui est concerné, ce que le texte exige comme tests de résilience (le pentest y devient une obligation écrite), ce qu'est un TLPT et qui doit en passer un, comment DORA s'articule avec NIS2, et par quoi commencer.

DORA en deux mots : un règlement, directement applicable

Première différence avec NIS2, et elle change tout le calendrier : DORA est un règlement, pas une directive. Pas de transposition nationale, pas de loi française à attendre, pas de décrets qui traînent. Le texte adopté le 14 décembre 2022 est entré en vigueur le 16 janvier 2023 et s'applique tel quel, dans toute l'Union, depuis le 17 janvier 2025. Si vous êtes dans le champ, vous êtes en retard depuis dix-huit mois, et vos superviseurs (ACPR, AMF, BCE selon votre statut) le savent.

14 déc. 2022   Adoption du règlement (UE) 2022/2554
16 janv. 2023  Entrée en vigueur
17 janv. 2025  DORA s'applique (effet direct, pas de transposition)
18 juin 2025   RTS TLPT publiées au JO (règlement délégué 2025/1190)
 8 juil. 2025  RTS TLPT applicables, désignations TLPT engagées
    ...        Cycle permanent : tests annuels + TLPT tous les 3 ans

L'objectif du texte tient en une phrase : que le système financier encaisse les incidents informatiques, cyberattaques comprises, sans casser. Là où la réglementation prudentielle demandait « avez-vous assez de capital ? », DORA demande « tenez-vous debout quand votre SI est attaqué ? ». Et surtout, il exige que vous le prouviez, en vous testant.

Qui est concerné par DORA (et pourquoi votre PME l'est peut-être déjà)

L'article 2 du règlement liste 20 catégories d'entités financières : établissements de crédit, de paiement et de monnaie électronique, entreprises d'investissement, prestataires de services sur crypto-actifs, sociétés de gestion, entreprises d'assurance et de réassurance, intermédiaires d'assurance, institutions de retraite professionnelle, plateformes de financement participatif, agences de notation, infrastructures de marché... La logique est l'exhaustivité : si vous êtes agréé ou enregistré auprès d'un superviseur financier, vous êtes très probablement dedans.

Le texte n'est pas aveugle à la taille pour autant. Les micro-entreprises et certaines petites entités bénéficient d'un cadre allégé (le régime simplifié de l'article 16), et les intermédiaires d'assurance qui sont des micro, petites ou moyennes entreprises sortent du champ. Mais une fintech de 30 personnes agréée établissement de paiement est concernée, plein pot. Le critère est le statut réglementaire, pas l'effectif.

Le cas des prestataires TIC : l'angle mort des PME

Et puis il y a la 21^e population, celle qui ne se sait pas concernée : les prestataires tiers de services TIC. Hébergeurs, éditeurs SaaS, infogéreurs, fournisseurs de briques logicielles : si vos clients sont des entités financières, DORA vous rattrape par deux chemins.

• Le chemin contractuel, qui touche tout le monde. L'article 30 impose aux entités financières un socle de clauses dans chaque contrat de service TIC, durci quand le service soutient une fonction critique ou importante : droits d'audit et d'inspection, objectifs de niveau de service, notification d'incident, stratégie de sortie, et coopération aux tests, TLPT compris. L'entité financière doit aussi tenir un registre d'informations de tous ses contrats TIC (article 28), remis chaque année au superviseur. 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 celui que subissent les PME rattrapées par NIS2 via leurs donneurs d'ordre.
• Le chemin de la désignation, pour les gros. Les prestataires jugés critiques pour le secteur (cloud majeurs, éditeurs dont dépend une part significative du marché, critères fixés par le règlement délégué 2024/1502) sont désignés par les autorités européennes de surveillance et passent sous surveillance directe d'un superviseur principal, avec astreintes pouvant atteindre 1 % du chiffre d'affaires quotidien moyen mondial.

Les cinq chantiers du règlement

DORA s'organise en cinq blocs d'obligations. Les quatre premiers sont contraignants, le cinquième est incitatif. Les tests, notre sujet, forment le troisième étage, mais ils reposent sur les autres : on ne teste bien que ce qu'on a cartographié et gouverné.

Le pentest obligatoire : ce que DORA exige comme tests de résilience

Le chapitre IV (articles 24 à 27) est celui qui transforme la sécurité offensive en obligation réglementaire. L'article 24 impose à chaque entité financière (hors micro-entreprises) un programme de tests de résilience opérationnelle numérique documenté, proportionné, et surtout cadencé : au moins une fois par an, tous les systèmes et applications TIC qui soutiennent des fonctions critiques ou importantes doivent être testés. Pas « quand le budget le permet ». Chaque année.

L'article 25 détaille la panoplie attendue, et elle est large : évaluations et analyses de vulnérabilités, analyses de sources ouvertes, évaluations de la sécurité des réseaux, analyses d'écarts, examens de la sécurité physique, revues de code source lorsque c'est réalisable, tests fondés sur des scénarios, tests de compatibilité, de performance, de bout en bout, et tests de pénétration. Le mot est dans le texte. À la question « le pentest est-il obligatoire avec DORA ? », la réponse honnête est donc : oui, comme composante d'un programme de tests annuel sur vos fonctions critiques, avec un second étage bien plus lourd pour les entités désignées. Si vous hésitez encore entre un scanner et un vrai test, notre comparatif pentest ou scan de vulnérabilités tranche le débat : l'article 25 attend les deux, pas l'un ou l'autre.

TLPT : le test d'intrusion fondé sur la menace, tous les trois ans

Au-dessus du programme annuel, l'article 26 crée le TLPT (threat-led penetration testing, test de pénétration fondé sur la menace) : un exercice de red team grandeur nature, calqué sur le cadre TIBER-EU de la BCE, à réaliser au moins tous les trois ans. Il ne concerne pas tout le monde : seules les entités désignées par leur autorité (selon leur importance systémique et leur profil de risque TIC) y sont tenues, et les micro-entreprises comme les entités du régime simplifié en sont exemptées. En France, les autorités TLPT sont la Banque de France, l'ACPR et l'AMF, réunies dans une équipe commune (la TCT-FR) qui applique la déclinaison nationale TIBER-FR ; pour les grands établissements de crédit dits « significatifs », c'est la BCE. La liste des désignés est confidentielle : on l'apprend par courrier, pas par communiqué.

Le cadre opérationnel est fixé par les normes techniques de réglementation, le règlement délégué (UE) 2025/1190, applicable depuis le 8 juillet 2025. Et il ne ressemble à aucun pentest que vous avez commandé jusqu'ici.

Trois exigences donnent la mesure de l'exercice. Le test se joue sur les systèmes de production réels, pas sur une préprod aseptisée. Le renseignement sur la menace vient obligatoirement d'un prestataire externe. Et les testeurs répondent aux critères stricts de l'article 27 : expertise démontrée en renseignement, pentest et red teaming, certification ou adhésion à un code de conduite, assurance professionnelle. Des testeurs internes restent possibles sous conditions (approbation de l'autorité notamment), mais un test sur trois doit recourir à des testeurs externes, et les établissements de crédit significatifs n'ont pas le choix : externes, point.

Un détail concerne directement les sous-traitants. Quand une fonction critique est opérée par un prestataire TIC, celui-ci peut être inclus dans le périmètre du TLPT de son client, le texte organisant même des tests mutualisés entre plusieurs clients d'un même prestataire. Votre SaaS peut donc se retrouver cible contractuelle d'une red team mandatée par votre client bancaire. Mieux vaut l'apprendre dans ce paragraphe que dans l'avenant.

DORA et NIS2 : lequel s'applique ?

Les deux textes sont entrés en scène presque en même temps et se marchent apparemment dessus. La règle de départage est simple : 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, une fintech agréée suivent DORA pour leur gestion du risque TIC, leurs notifications d'incident et leurs tests, pas NIS2. En revanche, un prestataire TIC 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 de ses clients financiers. Pour situer votre organisation côté NIS2, notre guide de la directive NIS2 (périmètre, obligations, sanctions) fait le tour du texte.

Sur le fond, les deux régimes convergent : inventaire des actifs, sécurité de la chaîne d'approvisionnement, preuve d'efficacité des mesures. La méthode que nous décrivons pour l'audit NIS2 par le test d'intrusion (tester, corriger, retester, documenter) se transpose telle quelle à DORA, avec une différence de taille : côté DORA, la fréquence annuelle et la panoplie de tests ne sont pas une bonne pratique, elles sont écrites dans le règlement.

Comment s'y préparer : cartographier, tester, prouver

Entité financière de taille moyenne ou prestataire TIC de celle-ci : l'ordre de marche est le même, et il tient en trois verbes.

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 d'EASM, la gestion de la surface d'attaque externe : découvrir en continu vos actifs exposés, les rattacher à vos 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 est un socle de test d'intrusion web en conditions réelles sur le périmètre exposé, complété en profondeur par un pentest whitebox sur les applications qui portent vos fonctions critiques, et un scan continu entre deux campagnes. Pour les entités désignées TLPT, ce socle est aussi le meilleur entraînement : une red team TIBER trouvera en trois 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 de test 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. Le retard se compte déjà en mois, pas en années de délai de grâce.
• 20 catégories d'entités financières sont couvertes, des banques aux fintechs agréées, plus les prestataires TIC : par contrat (article 30) pour tous, par désignation « critique » pour les plus gros.
• Le pentest devient une obligation écrite : programme de tests annuel sur tous les systèmes soutenant des fonctions critiques ou importantes (article 24), panoplie complète listée à l'article 25.
• Le TLPT vise les entités désignées, tous les 3 ans : red team sur production réelle, cadre TIBER-EU, RTS 2025/1190, autorités françaises Banque de France, ACPR et AMF (BCE pour les banques significatives).
• DORA prime sur NIS2 pour les entités financières (lex specialis) ; un prestataire TIC peut 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 programme de tests DORA tient aujourd'hui sur une ligne de budget et une bonne intention, le plus court chemin commence par la visibilité : cartographier votre surface d'attaque externe pour asseoir le périmètre, puis un test d'intrusion qui produit le dossier de preuve que l'article 24 attend. Parlons de votre périmètre : entité financière ou prestataire TIC, l'échéance est la même, et elle est déjà derrière vous.