DORA TLPT : ce que les tests adversariaux révèlent que vos audits documentaires ne voient pas

94 % des entités financières dans le scope DORA ont une politique ICT documentée. Moins de 12 % ont réalisé un test TLPT conforme à TIBER-EU. Cette divergence révèle une incompréhension structurelle : la conformité documentaire et la résilience opérationnelle réelle ne mesurent pas la même chose.

Simulation adversariale et tests de résilience opérationnelle — DORA TLPT

Selon les premières observations publiées par les régulateurs européens sur la mise en conformité DORA, 94 % des entités financières dans le scope ont constitué leur politique de gestion du risque ICT et tenu un registre d'incidents. Moins de 12 % ont réalisé un test de pénétration basé sur les menaces (TLPT — Threat-Led Penetration Testing) conforme au cadre TIBER-EU. Cette divergence ne traduit pas un problème de priorisation — elle révèle une incompréhension structurelle de ce que DORA attend réellement des programmes de tests avancés. Ce que les premiers TLPT européens révèlent est systématiquement révélateur : la conformité documentaire et la résilience opérationnelle réelle ne mesurent pas la même chose.

DORA distingue deux catégories de tests — et la plupart des organisations ne maîtrisent que la première

DORA structure les obligations de tests de résilience opérationnelle autour de deux niveaux distincts. L'Article 25 impose des tests "généraux" pour toutes les entités dans le scope : revues d'évaluation des vulnérabilités, scans de sécurité réseau, analyses d'impact business, tests de continuité et de reprise. Ces tests valident que les contrôles documentés existent et fonctionnent dans des conditions nominales. L'Article 26 impose des tests avancés — dont le TLPT — pour les entités d'importance significative, désignées par les autorités compétentes sur la base d'une évaluation du profil de risque systémique.

En France, l'ACPR a publié en 2025 les critères de désignation TLPT. Les entités concernées sont principalement les établissements de crédit et d'investissement d'importance significative, les dépositaires centraux et les infrastructures de marché — avec une extension possible aux entités présentant des interconnexions ICT critiques avec ces acteurs. La BCE, autorité directe pour les 113 établissements significatifs supervisés directement, a intégré le TLPT dans son programme de supervision 2025-2026.

Mais l'enjeu dépasse le champ d'application réglementaire strict. Le TLPT est révélateur d'une tension structurelle que toutes les équipes GRC doivent comprendre : la différence entre un contrôle documenté et une capacité opérationnelle réelle. Et les résultats des premiers TLPT permettent aujourd'hui de cartographier cette tension avec une précision que les audits documentaires ne peuvent pas atteindre.

Ce que les tests adversariaux révèlent là où les audits ne regardent pas

Un TLPT conforme TIBER-EU n'est pas un test d'intrusion amélioré. C'est un exercice construit à partir d'un renseignement sur les menaces réelles produit spécifiquement pour l'entité testée, simulant les tactiques, techniques et procédures (TTPs) des groupes d'acteurs menaçants qui ciblent effectivement le secteur financier européen. Le Red Team opère avec les mêmes contraintes qu'un attaquant réel : il n'a pas accès aux procédures internes, et il doit franchir les contrôles réels — pas leurs représentations documentaires.

Trois observations dominent dans les rapports TLPT agrégés publiés par TIBER-EU et les régulateurs nationaux.

La détection SIEM échoue sur les attaques lentes. La grande majorité des scénarios d'infiltration multi-étapes d'une durée supérieure à 72 heures ne déclenchent aucune alerte dans les SIEM configurés avec des règles orientées sur la rapidité d'exécution — brute force, mouvements latéraux rapides, exfiltrations massives. Les acteurs étatiques, profil de menace de référence dans les Threat Intelligence TIBER-EU pour les entités financières critiques, opèrent lentement et méthodiquement. Un compte de service qui interroge des bases de données inhabituelles à des heures atypiques, progressivement, sur plusieurs semaines, ne déclenche aucune alerte si la baseline comportementale n'a pas été définie.

Les playbooks IR ne couvrent pas les incidents réels. Les scénarios d'incident décrits dans les playbooks correspondent rarement à la structure des attaques sophistiquées constatées lors des TLPT. La question opérationnelle lors d'un incident n'est pas "quel playbook activer ?" — c'est "à quel stade de compromission sommes-nous ?" Confinement, investigation forensique et récupération sont trois séquences d'actions différentes qui ne peuvent pas être menées simultanément avec les mêmes ressources. La majorité des entités testées n'avaient pas opérationnalisé cette distinction.

La communication vers la direction et le régulateur n'est pas opérationnelle. Quand le Red Team déclenche un scénario à impact visible — indisponibilité d'un service de paiement, exfiltration de données clients — le processus de communication vers le Comex et le régulateur ne se déclenche pas dans les délais réglementaires. NIS2 impose une notification en 24 heures, DORA en délais similaires. La décision de notification doit pouvoir être prise à 3h00 du matin, sans le RSSI titulaire, en moins de 30 minutes. Cette décision implique plus de deux niveaux d'approbation dans la majorité des organisations testées.

Le paradoxe de la conformité documentaire

Ce qui rend les résultats TLPT structurellement utiles pour les organisations non-désignées, c'est qu'ils révèlent une lacune systémique que l'audit documentaire de conformité DORA ne peut pas détecter.

Un audit de conformité classique — interne ou conduit par un prestataire — valide des preuves documentaires : la politique ICT existe, le registre des incidents est tenu, les contrats fournisseurs incluent les clauses Article 28. Ces contrôles de premier niveau sont essentiels et nécessaires. Mais ils ne répondent pas à la question centrale que le TLPT pose : vos capacités de détection et de réponse fonctionneront-elles sous les conditions d'une attaque sophistiquée et prolongée ?

La segmentation réseau documentée dans les politiques n'est pas toujours la segmentation réseau effective. La dérive de configuration — changements opérationnels non documentés, règles firewall non révisées, exceptions temporaires devenues permanentes — crée des chemins d'attaque invisibles pour un audit documentaire mais immédiatement visibles pour un Red Team. Cette observation apparaît dans environ 65 % des rapports TLPT conduits sur des entités européennes en 2025-2026.

Ce que font les organisations dont les TLPT donnent des résultats solides

Les organisations qui obtiennent des résultats TLPT opérationnellement solides — pas parfaits, mais avec des lacunes identifiées et adressables — partagent trois pratiques distinctives.

Elles traitent le TLPT comme un outil de calibration, pas comme un examen de conformité. La différence d'état d'esprit est fondamentale. Elles conduisent des exercices adversariaux internes réguliers — purple teaming — dans les 12 mois précédant le TLPT, ce qui calibre progressivement leur détection sur des TTPs réels. Les organisations qui traitent le TLPT comme un audit à préparer ne développent pas de capacité — elles produisent de la documentation.

Elles ont une baseline comportementale documentée pour chaque service ICT critique. Pour chaque système critique, elles ont formalisé ce que constitue un comportement normal : flux réseau typiques, plages horaires d'utilisation, patterns d'accès aux données. Cette baseline n'est pas un livrable technologique — c'est le résultat d'une décision de gouvernance explicite : qui est responsable de définir et de maintenir le comportement normal de ce service, et selon quelle fréquence de révision.

La communication IR est exercée trimestriellement comme une décision sous incertitude. Pas comme un test de plan de continuité, mais comme un exercice où les équipes reçoivent un scénario incomplet, sont chronométrées sur la prise de décision de notification, et analysent les lacunes de raisonnement sous pression. Les organisations qui n'ont jamais soumis leur chaîne de décision IR à un exercice chronométré découvrent systématiquement, lors du TLPT, que la décision de notification est structurellement à risque.

Évaluer votre exposition — trois indicateurs

Le TLPT n'est pas nécessairement dans votre champ réglementaire immédiat. Mais les lacunes qu'il révèle — absence de baseline comportementale, playbooks non-opérationnels, communication IR non exercée — sont présentes dans la quasi-totalité des organisations qui n'ont jamais soumis leur résilience opérationnelle à un test adversarial réel.

Trois questions permettent de situer votre exposition sans attendre une désignation TLPT.

Avez-vous une baseline comportementale documentée pour vos systèmes ICT critiques ? Un inventaire de "ce qui est normal" par service, maintenu par un responsable identifié ? Si la réponse est non, votre SIEM détecte les anomalies flagrantes — pas les intrusions lentes.

Votre dernier exercice IR comprenait-il un scénario de compromission longue durée (>30 jours de présence attaquante avant découverte) ? Si non, votre plan IR n'a jamais été testé dans les conditions les plus fréquentes des incidents significatifs réels.

La décision de notification réglementaire peut-elle être prise en moins de 30 minutes, sans le RSSI titulaire, à n'importe quelle heure ? Si la réponse implique plus de deux niveaux d'approbation, votre délai de notification est structurellement à risque sous NIS2 et DORA.

Presidio centralise la qualification des incidents, les templates de notification NIS2/DORA, et la traçabilité des décisions IR pour l'audit trail : contactez notre équipe pour un diagnostic de 30 minutes. Lire aussi : DORA et la résilience opérationnelle : où résident vraiment vos risques.

Conclusion

DORA TLPT révèle ce que les audits documentaires ne mesurent pas : la différence entre une politique de détection et une capacité de détection effective ; entre un playbook archivé et une équipe capable de qualifier un incident sous pression ; entre une obligation de notification et une décision qui peut être prise en 30 minutes à 3h00 du matin.

Trois enseignements pour votre programme GRC : votre SIEM ne détecte probablement pas les attaques lentes — calibrez vos règles de détection sur des TTPs adversariaux réels, pas sur des scénarios documentaires. Vos playbooks sont des hypothèses de travail, pas des capacités — les capacités se développent par l'exercice chronométré. Et la communication IR est une compétence de décision sous incertitude — elle s'entraîne, elle ne s'archive pas. Les organisations qui progressent le plus vite sont celles qui traitent la résilience opérationnelle comme une capacité organisationnelle à exercer, et non comme un ensemble de documents à produire.

Un projet ? Une question ?

Nous contacter →