TLPT et DORA : ce que l'obligation de test de pénétration avancé change concrètement

Depuis le 17 janvier 2025, DORA (Digital Operational Resilience Act) est applicable dans toute l'Union européenne. La plupart des établissements financiers ont concentré leurs efforts de conformité sur les piliers les plus visibles : registre des contrats ICT, gestion des incidents, continuité d'activité. Mais l'article 26 prévoit une obligation qui va plus loin que le reste : les TLPT, ou Threat-Led Penetration Tests.

Ce n'est pas un audit de sécurité classique. Ce n'est pas non plus un pentest standard. C'est une simulation d'attaque ciblée, conduite par des red teamers externes, sur vos systèmes de production, basée sur une analyse de renseignement sur les menaces réelles qui vous visent.

L'article 26 distingue clairement les TLPT des tests de sécurité courants prévus à l'article 25 (scans de vulnérabilités, pentests classiques, etc.). Les TLPT sont les tests de niveau avancé, réservés aux entités dont la défaillance aurait un impact systémique.

Les exigences précises :

• Le test doit couvrir plusieurs ou toutes les fonctions critiques de l'entité
• Il doit être conduit sur les systèmes de production en activité — pas sur des environnements de staging
• Les testeurs externes doivent être indépendants et qualifiés selon les critères définis dans les RTS
• L'entité doit fournir à son superviseur une synthèse des résultats, un plan de remédiation et une attestation de conformité

Le cadre technique est précisé dans les RTS publiées en juin 2025 par l'EBA, l'EIOPA et l'ESMA, qui intègrent directement l'approche TIBER-EU dans DORA.

L'obligation TLPT ne s'applique pas à toutes les entités couvertes par DORA. Les superviseurs désignent les entités concernées selon des critères objectifs.

Critères de désignation :

Les autorités compétentes (ACPR et AMF en France) sélectionnent les entités en fonction de leur taille, leur profil de risque, leur degré d'interconnexion avec le système financier, la criticité des services qu'elles assurent, et leurs antécédents en matière d'incidents ICT. Plus une entité est systémique, plus la probabilité d'être désignée est élevée.

Entités directement concernées :

Banques, compagnies d'assurance, sociétés de gestion, entreprises d'investissement, établissements de paiement et de monnaie électronique, plateformes de négociation, chambres de compensation — dès lors qu'elles atteignent les seuils de matérialité définis par leur superviseur national.

Prestataires TIC tiers critiques :

Au niveau européen, les prestataires ICT désignés "critiques" par les autorités européennes de supervision (typiquement les hyperscalers et les plateformes SaaS systémiques) font l'objet d'un régime de surveillance distinct via l'article 28. Mais même en dessous de ce seuil, la chaîne contractuelle vous atteint.

La Banque de France a publié en mars 2025 le guide TIBER-FR, qui adapte TIBER-EU aux spécificités françaises. C'est le cadre de référence pour tous les TLPT conduits sous supervision ACPR ou AMF.

1. Phase 1

   Préparation et renseignement sur les menaces (Threat Intelligence)

   Un prestataire de Threat Intelligence (indépendant de l'équipe red team) analyse les menaces réelles qui visent votre secteur et votre entité spécifiquement. OSINT, analyse des groupes cybercriminels actifs, tactiques, techniques et procédures (TTPs). Ce renseignement pilote les scénarios d'attaque — c'est ce qui distingue un TLPT d'un pentest classique.

2. Phase 2

   Reconnaissance et accès initial (RECON + IN)

   Le red team externe commence par la reconnaissance externe : empreinte numérique, services exposés, identifiants compromis disponibles sur les marchés criminels, relations de confiance avec des tiers. Puis tentatives d'accès initial réalistes : phishing ciblé, exploitation de vulnérabilités, ingénierie sociale, parfois intrusion physique selon le scope défini.

3. Phase 3

   Progression latérale et escalade (THROUGH)

   Une fois un premier accès obtenu, le red team progresse latéralement dans le SI comme le ferait un attaquant réel : escalade de privilèges, contournement des contrôles de sécurité, pivotement vers des systèmes adjacents. La blue team (défense) ne sait généralement pas que le test est en cours — c'est un test de détection réelle.

4. Phase 4

   Objectifs, clôture et purple team (OUT)

   Le red team atteint les objectifs prédéfinis (exfiltration de données cibles, compromission d'un service critique, démonstration d'impact). Vient ensuite la phase de clôture : debriefing avec la blue team, purple team pour tester des scénarios complémentaires, rapport complet et attestation remise au superviseur.

• Rapport technique complet : chronologie de l'attaque, vecteurs utilisés, systèmes compromis, données accessibles, TTPs employées. Ce rapport est confidentiel — il ne circule qu'entre l'entité, les testeurs et le superviseur.
• Plan de remédiation : pour chaque finding, une action corrective avec propriétaire, délai et niveau de priorité. Le superviseur suit l'avancement. Les vulnérabilités critiques découvertes pendant le test doivent être traitées dans des délais contraints.
• Attestation de conformité : document formel remis à l'ACPR ou à l'AMF, signé par l'entité et les testeurs, attestant que le TLPT a été conduit conformément aux exigences DORA et au guide TIBER-FR.
• Restitution purple team : workshop entre le red team et la blue team pour rejouer les scénarios d'attaque, tester des variantes, et renforcer les règles de détection du SOC à partir des TTPs utilisées.

Un TLPT ne s'improvise pas. Les entités qui lancent un TLPT sans préparation se retrouvent avec un rapport qui expose tout, un plan de remédiation impossible à tenir, et un superviseur qui en tire les conclusions.

• Constituer le White Team : identifier les 3 à 5 personnes internes qui pilotent le TLPT sans en informer le SOC. Ce groupe coordonne avec les prestataires, valide le scope et gère les situations imprévues.
• Définir le scope précisément : quelles fonctions critiques, quels systèmes, quels prestataires ICT inclus. Le scope est validé avec le superviseur avant le démarrage du test. Un scope mal défini est une source de litiges.
• Sélectionner des prestataires qualifiés séparément : le prestataire Threat Intelligence et l'équipe red team doivent être indépendants l'un de l'autre. Les RTS DORA définissent les critères de qualification — vérifiez que vos prestataires y répondent explicitement.
• Préparer les clauses contractuelles avec vos sous-traitants : si des prestataires ICT entrent dans le scope, des clauses contractuelles permettant le test doivent être en place avant le démarrage.
• Anticiper la gestion de crise pendant le test : que se passe-t-il si le red team déclenche une vraie alerte ? Si un système tombe ? Le White Team doit avoir un protocole d'escalade clair.

Un TLPT complet représente un engagement significatif — en temps humain et en budget. Les entités qui se lancent sans estimation réaliste sous-budgètent systématiquement.

Ces fourchettes varient selon la taille de l'entité, le nombre de systèmes dans le scope, le nombre de prestataires ICT impliqués et la durée de la phase red team. Les petites entités désignées peuvent s'en sortir en bas de fourchette ; les groupes transfrontaliers avec de nombreux systèmes critiques atteindront le haut.

Cyber Expert accompagne les entités financières et leurs prestataires ICT dans la préparation et la conduite de TLPT conformes DORA. Contactez-nous pour un premier échange sur votre situation et votre calendrier de conformité.