Tests de pénétration pour la conformité DORA : ce que les entités financières européennes doivent savoir

Le Règlement sur la Résilience Opérationnelle Numérique – DORA – représente le changement le plus important en matière de réglementation de la cybersécurité que le secteur financier de l'UE ait jamais connu. Et en son cœur, aux côtés des cadres de gestion des risques liés aux TIC et des obligations de signalement des incidents, se trouve un ensemble d'exigences de test qui transforme le "Penetration Testing" d'un exercice volontaire en une activité légalement obligatoire avec des fréquences définies, des règles de portée, des qualifications de testeur et une surveillance prudentielle.

Si vous êtes une banque, un assureur, un établissement de paiement, une entreprise d'investissement ou toute autre entité réglementée par le droit européen des services financiers, cela s'applique à vous. Si vous êtes d'importance systémique, cela devient encore plus intense. Et si vous êtes un fournisseur tiers de TIC desservant ces entités, vous n'êtes pas non plus à l'abri.

Ce guide vous explique tout ce que vous devez comprendre : ce que DORA exige, qui est concerné, la différence entre les tests annuels standard et le régime avancé de "Threat-Led Penetration Testing" (TLPT), et comment élaborer un programme de test qui vous permette de rester conforme sans vous noyer dans la complexité réglementaire.

Qu'est-ce que DORA et pourquoi existe-t-il ?

Le Règlement sur la Résilience Opérationnelle Numérique (Règlement UE 2022/2554) a été adopté par le Conseil européen en décembre 2022, est entré en vigueur le 16 janvier 2023 et est devenu applicable le 17 janvier 2025. Contrairement à une Directive, qui nécessite une transposition en droit national, DORA est un Règlement, ce qui signifie qu'il est directement applicable dans tous les États membres de l'UE sans modification.

DORA existe parce que le secteur financier de l'UE avait un problème de disparité. Auparavant, différents pays appliquaient des exigences de cybersécurité différentes à leurs institutions financières. Certains avaient des cadres de test solides (les Pays-Bas avaient TIBER-NL, l'Allemagne avait TIBER-DE), tandis que d'autres avaient des exigences techniques minimales. Une banque transfrontalière pouvait être confrontée à trois régimes de test différents selon la juridiction concernée.

Parallèlement, le secteur financier devenait de plus en plus dépendant des infrastructures numériques et des fournisseurs tiers de TIC. Une simple panne de "cloud" ou une cyberattaque pouvait se propager en cascade à travers les institutions, les frontières et les marchés. DORA a été conçu pour créer un cadre harmonisé qui garantit que chaque entité financière de l'UE peut résister aux perturbations liées aux TIC, y répondre et s'en remettre.

Le règlement repose sur cinq piliers : la gestion des risques liés aux TIC, la gestion et la déclaration des incidents liés aux TIC, les tests de résilience opérationnelle numérique, la gestion des risques liés aux tiers en matière de TIC et le partage d'informations. Le "Penetration Testing" relève du troisième pilier, couvert au chapitre IV (articles 24 à 27) du règlement, et c'est le pilier le plus contraignant pour les équipes de sécurité au quotidien.

Qui est concerné ?

DORA s'applique largement au secteur financier. Les entités soumises à ses exigences comprennent les établissements de crédit (banques), les établissements de paiement, les établissements de monnaie électronique, les entreprises d'investissement, les compagnies d'assurance et de réassurance, les prestataires de services sur actifs virtuels relevant de MiCA, les dépositaires centraux de titres, les plateformes de négociation, les référentiels centraux, les sociétés de gestion de fonds, les agences de notation de crédit et les prestataires de services de financement participatif, entre autres.

En termes pratiques : si votre organisation est réglementée par le droit européen des services financiers, vous êtes presque certainement concerné par DORA. Le règlement vise délibérément un large éventail d'entités afin de garantir une résilience opérationnelle numérique cohérente dans l'ensemble du secteur.

Il existe une exception à noter. Les microentreprises — définies comme des entités employant moins de 10 personnes et dont le chiffre d'affaires annuel ou le bilan est inférieur à 2 millions d'euros — sont soumises à un régime de test allégé. Elles doivent toujours appliquer une approche basée sur les risques aux tests TIC, mais les exigences sont proportionnellement adaptées. Pour toutes les autres, les obligations complètes en matière de test s'appliquent.

Et surtout, la portée de DORA s'étend au-delà des entités financières elles-mêmes. Les fournisseurs tiers de services TIC — plateformes "cloud", fournisseurs de SaaS, fournisseurs de services gérés, entreprises d'analyse de données — relèvent du cadre de surveillance de DORA, en particulier s'ils sont considérés comme essentiels à la stabilité du secteur financier. Si vous êtes un fournisseur de technologies au service des institutions financières de l'UE, les obligations DORA de vos clients deviennent rapidement votre problème.

Les deux niveaux de tests DORA

DORA établit une approche à deux niveaux pour les tests de résilience. Il est essentiel de comprendre cette structure, car les exigences, la fréquence et la complexité diffèrent considérablement entre les niveaux.

Niveau 1 : "Penetration Testing" annuel en vertu des articles 24 et 25

L'exigence de test de base s'applique à toute entité financière réglementée par DORA qui n'est pas une microentreprise. L'article 24 exige des entités financières qu'elles établissent, maintiennent et examinent un programme complet de tests de résilience opérationnelle numérique dans le cadre de leur cadre de gestion des risques liés aux TIC.

L'article 24, paragraphe 6, est la clause essentielle : les entités financières doivent s'assurer que des tests appropriés sont effectués sur tous les systèmes et applications TIC soutenant les fonctions critiques ou importantes au moins une fois par an.

L'article 25 énumère ensuite les types de tests que le programme de test devrait inclure. Le règlement n'oblige pas chaque entité à effectuer tous les types de tests — le principe de proportionnalité s'applique — mais les exemples donnent une image claire de ce que les régulateurs attendent. Il s'agit notamment des évaluations et analyses de vulnérabilité, des analyses "open source", des évaluations de la sécurité du réseau, des analyses des écarts, des examens de la sécurité physique, des examens du code source (dans la mesure du possible), des tests basés sur des scénarios, des tests de compatibilité, des tests de performance, des tests de bout en bout et du "Penetration Testing".

Pour la plupart des entités financières disposant d'une infrastructure TIC significative, le "Penetration Testing" sera un élément essentiel de leur programme annuel. Le règlement est clair : vous devez démontrer que vos systèmes peuvent résister aux techniques d'attaque du monde réel, et pas seulement qu'ils ont été analysés pour détecter les vulnérabilités connues.

Ce que signifie "Fonctions Critiques ou Importantes"

DORA définit une fonction critique ou importante comme une fonction dont la perturbation nuirait sensiblement à la performance de l'entité financière, à la solidité ou à la continuité de ses services, ou au respect continu de ses obligations réglementaires. En termes pratiques, cela couvre vos opérations commerciales de base : traitement des paiements, plateformes de négociation, portails destinés aux clients, systèmes de décision en matière de crédit, plateformes de règlement des sinistres, infrastructure de règlement et les systèmes "backend" qui les prennent en charge.

L'identification de ces fonctions est la première étape de la définition de la portée de votre programme de test. Si un système prend en charge une fonction critique ou importante — directement ou par le biais de dépendances — il entre dans le champ d'application des tests annuels.

Proportionnalité : Adapter les tests à votre profil de risque

DORA reconnaît explicitement que toutes les entités financières n'ont pas la même taille ou le même profil de risque. L'article 4, paragraphe 2, établit un principe de proportionnalité : la profondeur et la fréquence de vos tests doivent être adaptées à la taille et à la complexité de votre entité, à votre profil de risque global, à la criticité des systèmes TIC testés, à l'exposition par le biais de l'externalisation ou des dépendances du "cloud", aux changements importants apportés à votre infrastructure TIC, ainsi qu'à la gravité et aux résultats des incidents précédents.

Cela signifie qu'une petite entreprise de "fintech" avec un produit ciblé et une infrastructure limitée n'est pas censée égaler le programme de test d'un établissement d'importance systémique mondiale (G-SII). Mais cela signifie également que vous ne pouvez pas utiliser la proportionnalité comme une excuse générale pour effectuer un minimum de tests. Le principe adapte la profondeur des tests, et non l'obligation de tester.

Niveau 2 : "Threat-Led Penetration Testing" (TLPT) en vertu des articles 26 et 27

Si les tests annuels standard sont la base de DORA, le TLPT est le niveau avancé — et c'est une bête fondamentalement différente.

Le TLPT est un exercice de "red team" à grande échelle, piloté par le renseignement et mené sur des systèmes de production en direct, en secret des équipes de défense de l'organisation, imitant les tactiques, les techniques et les procédures que de véritables acteurs de menace utiliseraient contre l'entité. Il ne s'agit pas d'une analyse de vulnérabilité avec un nom fantaisiste. Il s'agit d'une cyberattaque contrôlée conçue pour tester si votre institution — sa technologie, ses processus et son personnel — peut résister et détecter une intrusion sophistiquée et ciblée.

Le TLPT n'est obligatoire que pour certaines entités financières identifiées par leurs autorités compétentes en fonction de leur importance systémique, de leur profil de risque et de leur maturité en matière de TIC. Les entités les plus susceptibles d'être désignées comprennent les banques d'importance systémique mondiale (G-SII) et les autres établissements d'importance systémique (O-SII), les plus grands établissements de paiement (ceux qui traitent plus de 150 milliards d'euros de transactions au total au cours de chacune des deux années précédentes), les grandes compagnies d'assurance et de réassurance, les contreparties centrales et les dépositaires centraux de titres, ainsi que les principales plateformes de négociation.

Si votre autorité compétente vous désigne pour le TLPT, vous devez effectuer des tests avancés au moins tous les trois ans. L'autorité peut également augmenter ou diminuer cette fréquence en fonction de votre profil de risque et de votre situation opérationnelle.

Comment fonctionne le TLPT : les six phases

Les normes techniques de réglementation sur le TLPT (Règlement délégué (UE) 2025/1190 de la Commission, publié en juin 2025) définissent un processus structuré qui comprend plusieurs phases distinctes.

La phase de préparation commence lorsque l'autorité compétente (votre autorité TLPT) notifie à votre entité qu'elle doit effectuer un TLPT. Vous constituez une équipe de contrôle — un petit groupe de confiance au sein de votre organisation qui gère le test — et identifiez les fonctions critiques à tester. La portée est ensuite soumise à l'autorité TLPT pour validation.

La phase de renseignement sur les menaces implique un fournisseur de renseignement sur les menaces produisant un rapport de renseignement sur les menaces ciblé et spécifique à votre institution. Ce rapport analyse les acteurs de menace les plus susceptibles de cibler votre entité, leurs tactiques et techniques connues, et les scénarios d'attaque les plus pertinents pour votre modèle commercial, votre pile technologique et votre zone géographique. Ce renseignement alimente l'ensemble du test, garantissant qu'il reflète les menaces du monde réel, et non des manuels d'attaque génériques.

La phase de test de l'équipe "red team" est l'exécution. L'équipe "red team" — travaillant à partir du renseignement sur les menaces — mène une campagne offensive soutenue contre vos systèmes de production en direct. Contrairement au "pentesting" standard, le test se déroule sur une période prolongée (généralement de trois à quatre mois), l'équipe "blue team" (vos défenseurs) n'est pas informée et l'objectif est de simuler une véritable menace persistante avancée.

La phase de clôture comprend un exercice obligatoire de "purple teaming", qui est une différence essentielle par rapport au cadre TIBER-EU précédent où le "purple teaming" était seulement recommandé. Pendant le "purple teaming", l'équipe "red team" et l'équipe "blue team" travaillent ensemble pour parcourir les scénarios d'attaque, examiner ce qui a été détecté et ce qui a été manqué, et identifier en collaboration les améliorations. Cela garantit que le test génère un apprentissage, et pas seulement des conclusions.

Enfin, la phase de rapport et de correction produit une documentation qui est soumise à l'autorité compétente pour validation et attestation. L'autorité confirme que le TLPT a été mené conformément aux exigences de DORA et délivre une attestation formelle.

TLPT vs. "Penetration Testing" standard : comprendre l'écart

La distinction entre le TLPT et le "Penetration Testing" standard est l'un des concepts les plus importants pour la conformité à DORA, et l'un des plus souvent mal compris.

Un "Penetration Testing" standard cible généralement un système ou une application spécifique — une application web, une API, un segment de réseau. Il dure d'une à trois semaines. L'équipe de sécurité sait qu'il a lieu. La portée est délimitée et convenue à l'avance. Le testeur recherche les vulnérabilités techniques, tente de les exploiter et produit un rapport avec les conclusions et les conseils de correction. Il s'agit d'une évaluation technique d'une surface définie.

Un TLPT couvre l'ensemble de l'organisation. Il cible les fonctions commerciales critiques — et non des systèmes spécifiques. Il dure des mois, et non des semaines. L'équipe de défense n'est absolument pas au courant. Le test est piloté par un renseignement sur les menaces sur mesure, et non par une méthodologie générique. Les testeurs simulent le cycle de vie complet d'une attaque réelle : reconnaissance, accès initial, persistance, mouvement latéral, élévation de privilèges et exfiltration de données ou perturbation opérationnelle. Et il teste non seulement la technologie, mais aussi les personnes (le personnel se fait-il piéger par l'"hameçonnage" ?) et les processus (le SOC détecte-t-il l'intrusion ? Le plan de réponse aux incidents fonctionne-t-il réellement ?).

Voyez les choses de cette façon : un "pentest" demande "quelqu'un peut-il entrer dans cette pièce ?" Le TLPT demande "un adversaire sophistiqué peut-il entrer dans notre bâtiment, trouver la chambre forte, l'ouvrir, prendre ce qu'il veut et repartir sans que personne ne s'en aperçoive ?"

Fournisseurs tiers de TIC : vous n'êtes pas à l'abri

L'une des innovations les plus importantes de DORA est le traitement du risque lié aux tiers en matière de TIC comme une préoccupation systémique plutôt que comme une question contractuelle bilatérale. Si vous êtes un fournisseur de "cloud", un fournisseur de SaaS, un service de sécurité géré ou toute autre entreprise technologique desservant des institutions financières de l'UE, DORA vous atteint de plusieurs manières importantes.

Premièrement, les entités financières doivent exiger contractuellement de leurs fournisseurs tiers de services TIC qu'ils participent et coopèrent au TLPT lorsque ces fournisseurs sont inclus dans le champ d'application du test. L'article 30, paragraphe 3, point d), de DORA le précise. Si votre plateforme "cloud" héberge l'infrastructure de traitement des paiements d'une banque et que cette banque est désignée pour le TLPT, la banque doit s'assurer de votre participation au test — et vous devez la faciliter.

Deuxièmement, les fournisseurs de TIC jugés essentiels à la stabilité du secteur financier seront désignés comme Fournisseurs Tiers Critiques (CTPP) par les Autorités Européennes de Surveillance (AES). Les CTPP sont soumis à la surveillance directe des AES, y compris des exigences spécifiques en matière de tests de sécurité, de gestion des risques et de résilience opérationnelle. La première vague de désignations de CTPP est attendue en 2025, à la suite des évaluations de criticité réalisées par les AES.

Troisièmement, même si vous n'êtes pas désigné comme CTPP, DORA devient rapidement un filtre d'approvisionnement. Les entités financières qui évaluent les fournisseurs de technologies exigeront de plus en plus la preuve de programmes de test de sécurité robustes, la capacité de prendre en charge les simulations dirigées par les clients et la préparation à des tests opérationnels conjoints. La non-conformité n'entraînera pas seulement un risque réglementaire, elle entraînera la perte d'accès aux clients financiers européens.

Si vous desservez des entités financières réglementées par l'UE, le conseil pratique est simple : préparez-vous à soutenir les exigences de test DORA de vos clients, offrez des environnements de test isolés le cas échéant et soyez prêt à démontrer votre propre résilience opérationnelle grâce à des programmes de test documentés.

Qui peut effectuer les tests ?

DORA établit des exigences de qualification spécifiques pour les testeurs, en particulier pour le TLPT.

Tests standard (articles 24 à 25)

Pour le programme de test annuel, DORA autorise les tests à être effectués par des équipes internes indépendantes ou par des fournisseurs externes qualifiés. L'exigence essentielle est l'indépendance : les testeurs ne doivent pas avoir de conflits d'intérêts et ne doivent pas avoir d'intérêt direct dans les résultats. Si vous utilisez des testeurs internes, une séparation organisationnelle appropriée est requise.

Le règlement ne prévoit pas de certifications spécifiques pour les tests standard, mais il exige que les testeurs possèdent les compétences et l'expertise nécessaires. En pratique, les autorités compétentes s'attendent à ce que les testeurs aient des qualifications professionnelles reconnues et une expérience démontrable dans les types de tests effectués.

TLPT (articles 26 à 27)

Pour le TLPT, les exigences sont considérablement plus strictes. Le règlement exige que les testeurs soient de la plus haute aptitude et réputation, possèdent des capacités techniques et organisationnelles avec une expertise spécifique dans le renseignement sur les menaces, le "Penetration Testing" ou les tests de "red team", soient certifiés par un organisme d'accréditation dans un État membre ou adhèrent à des codes de conduite formels ou à des cadres éthiques, et pour les testeurs externes, détiennent une assurance responsabilité civile professionnelle contre les risques de faute professionnelle.

Une nuance importante : DORA autorise les testeurs internes à effectuer la composante "red team" du TLPT, mais avec deux contraintes essentielles. Le renseignement sur les menaces doit toujours être fourni par une partie externe, et tous les trois TLPT doivent être effectués par un fournisseur externe d'équipe "red team". En pratique, cela signifie que même si vous développez une capacité interne d'équipe "red team", vous aurez besoin de testeurs externes pour au moins un cycle de TLPT sur trois.

Correction, rapport et attestation

DORA ne considère pas les tests comme une activité autonome — ils sont intégrés dans une boucle d'amélioration continue. Le règlement exige des entités financières qu'elles établissent des procédures et des politiques pour hiérarchiser, classer et corriger tous les problèmes révélés par les tests, et pour s'assurer que toutes les vulnérabilités et les lacunes identifiées sont entièrement corrigées.

Pour les tests annuels standard, l'attente est que votre programme de test génère des conclusions documentées, que ces conclusions soient triées par gravité, que la correction soit suivie et menée à bien, et que les résultats soient réinjectés dans votre cadre de gestion des risques liés aux TIC. Votre documentation doit être mise à la disposition des autorités compétentes sur demande.

Pour le TLPT, les exigences sont plus formelles. Une fois le test terminé — y compris l'exercice obligatoire de "purple teaming" — l'entité financière et les testeurs externes fournissent à l'autorité compétente une documentation confirmant que le TLPT a été mené conformément aux exigences de DORA. L'autorité compétente valide cette documentation et délivre une attestation. Cette attestation peut ensuite être partagée avec d'autres autorités compétentes afin de permettre une reconnaissance mutuelle, réduisant ainsi la nécessité de tests en double dans les différentes juridictions.

Le mécanisme de reconnaissance mutuelle est l'une des innovations les plus pratiques de DORA. Si vous êtes une institution transfrontalière opérant dans plusieurs États membres de l'UE, une seule attestation TLPT peut satisfaire aux exigences de surveillance dans toutes les juridictions — une amélioration significative par rapport au paysage antérieur à DORA où des cadres de test nationaux distincts nécessitaient des tests distincts.

Principales échéances

Le calendrier est important sur le plan stratégique. Si vous êtes candidat à la désignation TLPT, les premières notifications sont attendues en 2026. Le délai de six mois entre la notification et la soumission de la portée est serré pour les organisations qui n'ont pas préparé le terrain. Commencez la cartographie des fonctions, identifiez votre responsable d'équipe de contrôle et évaluez vos options de fournisseurs avant de recevoir la lettre.

Construire votre programme de test DORA

Que vous soyez un établissement de paiement de taille moyenne qui construit un programme de test à partir de zéro ou un G-SII qui aligne un programme existant sur les exigences de DORA, voici un cadre pratique.

Étape 1 : Cartographier vos fonctions critiques et importantes

Avant de pouvoir tester quoi que ce soit, vous devez savoir ce qui compte. Identifiez toutes les fonctions dont la perturbation nuirait sensiblement à la performance de votre entité, à la continuité de ses services ou à sa conformité réglementaire. Ensuite, cartographiez les systèmes TIC, les applications et les dépendances de tiers qui prennent en charge chaque fonction. Cette cartographie devient la base de votre portée de test et alimente directement votre cadre de gestion des risques liés aux TIC.

Étape 2 : Établir un programme de test basé sur les risques

Concevez un programme de test qui couvre tous les systèmes TIC soutenant les fonctions critiques ou importantes, qui intègre les types de tests énumérés à l'article 25 (adaptés à votre profil de proportionnalité), qui fonctionne au moins sur un cycle annuel et qui s'adapte en fonction des changements importants apportés à votre infrastructure, des résultats des tests précédents et de l'évolution du renseignement sur les menaces.

Documentez formellement le programme. DORA exige que votre programme de test soit documenté, examiné et maintenu dans le cadre de votre cadre de gestion des risques liés aux TIC. Cette documentation doit être mise à la disposition de votre autorité compétente sur demande.

Étape 3 : Faire appel à des fournisseurs de test qualifiés

Pour la plupart des entités, les fournisseurs externes de "Penetration Testing" assureront la composante de test annuel. Sélectionnez des fournisseurs qui ont une expérience démontrée dans le secteur financier, qui comprennent les exigences spécifiques de DORA et qui peuvent produire des rapports qui répondent aux attentes réglementaires. Assurez-vous que les contrats d'engagement traitent des exigences d'indépendance, des obligations de confidentialité et du processus d'alignement de la portée.

Si vous êtes candidat au TLPT, vous devrez également identifier les fournisseurs de renseignement sur les menaces et les fournisseurs d'équipe "red team" qui répondent aux qualifications strictes énoncées à l'article 27 et aux RTS TLPT. Commencez cette évaluation tôt — le nombre de fournisseurs TLPT qualifiés est plus petit que le marché général des "pentest", et les créneaux horaires se remplissent rapidement.

Étape 4 : Construire la boucle de correction

Tester sans correction, c'est performer sans but. Établissez un flux de travail documenté qui prend en compte les conclusions de l'identification à la correction et à la vérification. Classez les conclusions par gravité, attribuez la propriété, définissez les délais de réponse et suivez la clôture. Chaque correction doit être vérifiée — soit par un nouveau test, soit par la mise en œuvre validée d'un contrôle.

Réinjectez les résultats de vos tests dans votre cadre de gestion des risques liés aux TIC. DORA considère les tests comme un élément d'un tableau de résilience plus large — et non comme un exercice de conformité autonome.

Étape 5 : Se préparer au TLPT (le cas échéant)

Si votre entité est susceptible d'être désignée pour le TLPT, la préparation doit commencer bien avant l'arrivée de la notification. Identifiez un responsable d'équipe de contrôle — quelqu'un d'assez haut placé pour gérer le test à travers les frontières organisationnelles et d'assez confiance pour maintenir le secret vis-à-vis de l'équipe "blue team". Cartographiez les fonctions critiques qui seront probablement dans le champ d'application. Évaluez les dépendances de tiers qui pourraient devoir être incluses. Passez en revue vos accords contractuels avec les fournisseurs de TIC pour vous assurer que des clauses de participation conformes à DORA sont en place.

Erreurs courantes dans la conformité des tests DORA

Traiter les tests comme une case à cocher

Toute la philosophie de DORA est la résilience — et non le théâtre de la conformité. Les régulateurs ont conçu les exigences de test pour s'assurer que les entités financières peuvent réellement résister aux cyberattaques, et pas seulement produire des rapports indiquant qu'elles ont essayé. Si votre programme de test génère des conclusions qui ne sont jamais corrigées, couvre les systèmes faciles tout en évitant les systèmes complexes, ou produit des rapports qui restent dans un tiroir jusqu'au prochain audit, vous passez à côté de l'essentiel et le régulateur le remarquera.

Confondre l'analyse des vulnérabilités avec le "Penetration Testing"

L'article 25 énumère à la fois les évaluations et analyses de vulnérabilité et le "Penetration Testing" comme composantes d'un programme de test. Il s'agit d'activités distinctes. L'analyse automatisée des vulnérabilités identifie les faiblesses connues à grande échelle. Le "Penetration Testing" implique un testeur humain qualifié qui tente activement d'exploiter ces faiblesses, de les enchaîner et d'évaluer l'impact réel. L'exécution d'une analyse Nessus et le fait de la qualifier de "Penetration Testing" ne satisferont pas à DORA.

Ignorer les dépendances de tiers

Si vos fonctions critiques dépendent de fournisseurs tiers de TIC — et dans les services financiers modernes, c'est presque certainement le cas — votre programme de test doit tenir compte de ces dépendances. Pour les tests standard, cela signifie évaluer la posture de sécurité de vos connexions et interfaces de tiers. Pour le TLPT, cela signifie s'assurer contractuellement que vos fournisseurs participeront au test. Les entités financières qui ignorent le risque lié aux tiers dans leur portée de test créent exactement le type d'angle mort que DORA a été conçu pour éliminer.

Supposer que le TLPT n'est qu'un "pentest" plus grand

Nous l'avons déjà dit, mais il est utile de le répéter. Le TLPT est une activité fondamentalement différente du "Penetration Testing". Il est piloté par le renseignement, mené sur des systèmes de production en direct, exécuté en secret de vos équipes de défense, exécuté sur des mois plutôt que sur des semaines, nécessite un "purple teaming" obligatoire et est validé et attesté par votre autorité compétente. Aborder le TLPT avec un état d'esprit de "pentest" — portée limitée, échéancier court, focalisation uniquement technique — se traduira par un test qui ne répond pas aux exigences réglementaires et ne fournit pas d'informations significatives sur la résilience.

Attendre la notification

Si vous êtes un établissement d'importance systémique, attendre que votre autorité compétente vous notifie formellement avant de vous préparer au TLPT est une erreur stratégique. La fenêtre entre la notification et la portée est d'environ six mois, et la préparation requise — cartographie des fonctions, sélection des fournisseurs, négociation des contrats, formation de l'équipe de contrôle, acquisition du renseignement sur les menaces — est substantielle. Les organisations qui commencent tôt exécuteront des tests plus fluides, généreront de meilleurs résultats et démontreront à leurs superviseurs qu'elles prennent la résilience opérationnelle au sérieux.