Test d’Intrusion Ciblé par la Menace (TLPT) : Ce Que DORA Exige

Sommaire

Les sections suivantes détaillent ce qu’est un TLPT, qui y est soumis, comment il se déroule concrètement, comment le budgétiser correctement, et comment en tirer une vraie valeur plutôt qu’un simple exercice de conformité archivé.

• Un Exercice Bien Plus Exigeant qu’un Test de Pénétration Classique
• Qu’est-ce qu’un TLPT, Précisément
• Qui Est Soumis à cette Exigence
• Le Cadre TIBER-EU, Fondation Méthodologique du TLPT
• Les Phases d’un TLPT, Étape par Étape
• Le Renseignement sur la Menace, Cœur de la Méthode
• TLPT et Test de Pénétration Classique : les Différences
• Le Rôle de l’Équipe Red Team et du Contrôleur Indépendant
• Définir le Périmètre : les Fonctions Critiques Concernées
• Coordonner un TLPT avec les Prestataires Tiers Impliqués
• Budgétiser Correctement un Programme TLPT
• La Fréquence du Cycle TLPT
• Ce Qui Compte Vraiment : l’Après-Test
• Le Changement Culturel que le TLPT Impose
• Documenter le TLPT pour les Autorités de Supervision
• Les Erreurs qui Réduisent la Valeur d’un TLPT
• Étude de Cas : une Banque d’Investissement Face à son Premier TLPT
• Checklist de Préparation TLPT
• FAQ
• Regard d’Expert
• Références

Un Exercice Bien Plus Exigeant qu’un Test de Pénétration Classique

Pour les entités financières les plus significatives désignées par les autorités compétentes, DORA impose une forme de test de résilience bien plus exigeante qu’un test de pénétration classique : le test d’intrusion ciblé par la menace, communément désigné par son acronyme anglais TLPT (Threat-Led Penetration Testing). Beaucoup d’organisations abordent cette exigence en pensant qu’elle ressemble à un audit de sécurité qu’elles ont déjà mené par le passé — une erreur d’appréciation qui coûte cher en termes de préparation insuffisante et de budget mal calibré.

Un TLPT ne se limite pas à rechercher des vulnérabilités techniques sur un périmètre défini. Il simule une attaque réaliste, construite à partir de renseignements sur des menaces effectivement observées contre le secteur financier, exécutée par une équipe d’attaquants spécialisés qui ne connaît pas nécessairement à l’avance les défenses en place, et supervisée de bout en bout par un contrôleur indépendant garant de la rigueur méthodologique de l’exercice — une exigence bien plus lourde qu’un simple audit de sécurité annuel.

Qu’est-ce qu’un TLPT, Précisément

Le TLPT se distingue d’un test de pénétration traditionnel sur plusieurs dimensions essentielles. D’abord, son point de départ n’est pas une liste de vulnérabilités techniques à rechercher, mais un renseignement sur la menace réel et documenté, portant sur les techniques, tactiques et procédures effectivement utilisées par des groupes d’attaquants ciblant le secteur financier. Ensuite, l’exercice se déroule généralement en conditions réelles, souvent sans que l’ensemble des équipes de sécurité internes de l’entité ne soient informées à l’avance, pour tester la détection et la réponse dans des conditions aussi proches que possible d’une attaque authentique.

Enfin, contrairement à un test de pénétration classique qui peut se limiter à un système ou une application isolée, un TLPT vise typiquement les fonctions critiques ou importantes de l’entité dans leur ensemble, ce qui implique souvent de tester la chaîne complète depuis le point d’entrée initial jusqu’aux systèmes les plus sensibles, en passant par les mouvements latéraux qu’un attaquant réel chercherait à effectuer.

Qui Est Soumis à cette Exigence

DORA applique le principe de proportionnalité à cette exigence : tous les établissements financiers ne sont pas tenus de conduire un TLPT. Cette obligation cible spécifiquement les entités désignées comme significatives par les autorités compétentes, généralement les grandes banques, les infrastructures de marché systémiques, et certaines entités dont la défaillance aurait un impact disproportionné sur la stabilité du secteur financier dans son ensemble.

Pour les entités qui ne sont pas soumises à l’obligation formelle de TLPT, DORA n’exempte pas pour autant de tests de résilience réguliers — des exigences moins intensives mais bien réelles s’appliquent selon une échelle de proportionnalité, incluant des tests de vulnérabilité classiques, des analyses de code source, et des tests basés sur scénarios, adaptés à la taille et à la criticité systémique de chaque entité, avec une intensité qui reste toutefois amenée à évoluer si le profil de risque de l’entité change dans le temps.

Le Cadre TIBER-EU, Fondation Méthodologique du TLPT

La méthodologie sous-jacente au TLPT s’appuie largement sur le cadre TIBER-EU (Threat Intelligence-Based Ethical Red Teaming), développé initialement par la Banque Centrale Européenne avant l’entrée en vigueur de DORA, et désormais intégré comme référence méthodologique standard pour la conduite des TLPT dans le cadre réglementaire. Ce cadre définit précisément les rôles, les phases, et les garde-fous nécessaires pour qu’un exercice d’attaque simulée reste à la fois réaliste et suffisamment contrôlé pour ne pas créer de dommage réel aux systèmes de production testés.

L’existence de ce cadre méthodologique préexistant à DORA explique pourquoi de nombreuses grandes institutions financières européennes, en particulier celles supervisées directement par la BCE, disposaient déjà d’une expérience TIBER-EU avant que DORA ne rende cette pratique obligatoire pour un périmètre plus large d’entités. Pour les organisations nouvellement soumises à cette obligation, s’appuyer sur la documentation TIBER-EU existante représente un raccourci méthodologique précieux plutôt que de partir d’une page blanche, à condition de l’adapter au contexte réglementaire spécifique de DORA plutôt que de l’appliquer telle quelle sans adaptation.

Les Phases d’un TLPT, Étape par Étape

Un TLPT se structure généralement en trois phases distinctes, chacune avec ses propres livrables et responsables. La phase de préparation, souvent la plus longue, définit le périmètre exact du test, identifie les fonctions critiques à cibler, collecte le renseignement sur la menace pertinent pour le secteur et la région de l’entité, et établit les scénarios d’attaque qui seront simulés.

La phase de test actif, généralement la plus courte en durée mais la plus intense, voit l’équipe d’attaquants spécialisés (la red team) exécuter les scénarios définis contre les systèmes de production réels de l’entité, dans des conditions aussi proches que possible d’une attaque authentique, avec un contrôleur indépendant garantissant que les limites convenues ne sont jamais dépassées.

La phase de clôture et de restitution, enfin, rassemble les enseignements de l’exercice : ce que l’attaque a réussi à atteindre, à quel moment elle aurait pu être détectée mais ne l’a pas été, et quelles recommandations concrètes en découlent pour améliorer la posture de sécurité réelle de l’entité — pas seulement produire un rapport de conformité à archiver.

Les trois phases d’un TLPT exigent une coordination fine entre équipes internes et prestataires externes.

Le Renseignement sur la Menace, Cœur de la Méthode

Ce qui distingue fondamentalement un TLPT d’un test de pénétration générique est sa dépendance à un renseignement sur la menace réel et spécifique. Avant même de concevoir les scénarios d’attaque, un fournisseur de renseignement sur la menace qualifié doit produire une analyse documentée des groupes d’attaquants effectivement actifs contre le secteur financier de la région concernée, de leurs techniques privilégiées, et des cibles qu’ils ont historiquement visées dans des contextes comparables.

Cette étape de renseignement n’est pas cosmétique — elle détermine directement la crédibilité et la valeur de l’ensemble de l’exercice. Un TLPT construit sur des scénarios génériques, sans ancrage réel dans les menaces effectivement pertinentes pour l’entité testée, produit un exercice qui ressemble à un TLPT sur la forme mais qui manque l’objectif de fond : évaluer la résilience réelle face aux attaques que l’entité est statistiquement susceptible de subir, pas face à des scénarios théoriques déconnectés du paysage de menace réel.

Concrètement, un bon fournisseur de renseignement sur la menace s’appuie sur plusieurs sources croisées : des flux de renseignement commerciaux spécialisés dans le secteur financier, des rapports d’incidents publiquement documentés touchant des institutions comparables, et lorsque disponible, des échanges d’informations sectoriels entre entités financières elles-mêmes, ce cinquième pilier de DORA sur le partage d’informations sur les menaces jouant ici un rôle direct dans la qualité du renseignement disponible pour construire des scénarios de TLPT réalistes.

TLPT et Test de Pénétration Classique : les Différences Concrètes

Il est utile de détailler, point par point, ce qui distingue réellement un TLPT d’un test de pénétration traditionnel, tant les deux exercices sont parfois confondus par des organisations qui pensent, à tort, satisfaire l’exigence DORA en reconduisant simplement leurs tests de sécurité habituels sous un nouveau nom.

Un test de pénétration classique définit généralement un périmètre technique précis (une application, un réseau) et cherche à identifier un maximum de vulnérabilités exploitables dans un temps imparti, souvent avec la connaissance et la coopération des équipes internes concernées. Un TLPT, à l’inverse, part d’un scénario de menace réaliste et cherche à savoir si, dans des conditions proches d’une attaque réelle, l’entité est capable de détecter et de répondre à une intrusion avant qu’elle n’atteigne les fonctions critiques ciblées — un objectif de résilience organisationnelle globale, pas seulement de découverte de vulnérabilités techniques isolées.

Cette différence d’objectif se traduit par une différence de méthode : un test de pénétration produit typiquement une liste de vulnérabilités classées par sévérité technique, tandis qu’un TLPT produit une évaluation de la capacité de détection et de réponse dans la durée, avec des enseignements qui touchent autant à l’organisation humaine (temps de réaction des équipes, qualité de l’escalade interne) qu’aux failles techniques elles-mêmes.

Le Rôle de l’Équipe Red Team et du Contrôleur Indépendant

L’équipe red team, chargée d’exécuter l’attaque simulée, doit posséder une expertise technique pointue et une connaissance actualisée des techniques d’attaque réelles, souvent fournie par des prestataires spécialisés accrédités selon les critères définis par le cadre TIBER-EU ou son équivalent national. Cette équipe opère selon un mandat strictement défini en amont, avec des limites explicites sur ce qui peut être tenté et ce qui reste hors périmètre pour éviter tout dommage réel aux systèmes de production.

Le contrôleur indépendant, distinct à la fois de l’équipe red team et de l’entité testée, joue un rôle de garant méthodologique tout au long de l’exercice. Il valide que le renseignement sur la menace utilisé est pertinent et de qualité suffisante, supervise le déroulement du test pour s’assurer du respect des limites convenues, et certifie in fine que l’exercice a été mené selon les standards méthodologiques attendus par les autorités de supervision — une certification qui devient elle-même un livrable important attendu dans le cadre de la conformité DORA globale.

Définir le Périmètre : les Fonctions Critiques Concernées

Définir correctement le périmètre d’un TLPT exige d’identifier précisément quelles fonctions de l’entité sont réellement critiques ou importantes au sens de DORA — un exercice qui recoupe directement la méthodologie de classification développée pour le Registre d’Information. Une entité qui n’a pas encore clarifié rigoureusement sa classification de criticité aborde son premier TLPT avec un handicap méthodologique significatif, puisque le périmètre du test lui-même dépend directement de cette classification.

Le périmètre ne se limite pas nécessairement aux systèmes techniques de l’entité elle-même. Lorsqu’une fonction critique dépend d’un prestataire tiers, le TLPT peut, selon les cas, nécessiter d’inclure ce prestataire dans le périmètre testé, ce qui exige une coordination contractuelle et opérationnelle préalable, souvent absente des contrats signés avant l’entrée en application de DORA.

Coordonner un TLPT avec les Prestataires Tiers Impliqués

Lorsqu’une fonction critique testée repose en tout ou partie sur un prestataire TIC tiers, la coordination du TLPT avec ce prestataire devient un exercice à part entière, souvent sous-estimé dans la planification initiale. Le prestataire doit être informé et consentant à la conduite du test sur les composants qu’il opère, ce qui nécessite des clauses contractuelles spécifiques prévues à l’avance, plutôt qu’une négociation improvisée au moment de planifier le test.

Cette coordination devient particulièrement délicate lorsque plusieurs entités financières clientes du même prestataire souhaitent chacune conduire leur propre TLPT incluant ce prestataire commun — une situation qui peut rapidement devenir ingérable pour le prestataire si chaque client négocie et planifie son test indépendamment. Certains cadres réglementaires commencent à explorer des mécanismes de tests mutualisés ou de reconnaissance croisée pour éviter cette duplication d’effort, mais ces mécanismes restent encore peu matures en pratique en 2026.

Pour les prestataires eux-mêmes, en particulier ceux désignés critiques au titre du quatrième pilier de DORA, se préparer à ce type de sollicitation devient une compétence à construire en interne plutôt qu’à découvrir au moment où un client le demande. Un prestataire ayant déjà défini une politique claire d’accueil des TLPT clients — quels systèmes peuvent être testés, sous quelles conditions, avec quel préavis contractuel — traite ces demandes bien plus efficacement qu’un prestataire découvrant la question contrat par contrat, sans cadre interne préétabli, une situation qui se traduit fréquemment par des retards de plusieurs semaines dans le calendrier global du TLPT.

Budgétiser Correctement un Programme TLPT

Un TLPT complet représente un investissement significatif, souvent sous-estimé par les organisations qui l’abordent pour la première fois. Au-delà du coût direct du prestataire spécialisé conduisant le test et du contrôleur indépendant, le budget réel doit intégrer le temps interne mobilisé pour la phase de préparation (définition du périmètre, coordination avec les prestataires tiers), le temps de restitution et d’analyse post-test, et surtout le budget de remédiation qui découle des constats — souvent le poste le plus significatif et le moins anticipé dans les budgets initiaux.

Les organisations qui budgétisent uniquement le coût du test lui-même, sans provisionner pour la remédiation qui en découlera nécessairement, se retrouvent régulièrement à devoir arbitrer en urgence des priorités de sécurité une fois les constats connus, sous pression de calendrier, plutôt que d’avoir anticipé cette charge dès la planification initiale du programme.

La Fréquence du Cycle TLPT

DORA prévoit un cycle de test à intervalles réguliers, généralement tous les trois ans pour les entités soumises à l’obligation TLPT, bien que les autorités compétentes puissent exiger une fréquence plus rapprochée pour certaines entités selon leur profil de risque spécifique. Ce rythme de trois ans peut sembler éloigné, mais il n’exclut pas la conduite de tests intermédiaires plus légers, ni surtout l’exigence continue de maintenir et d’actualiser la posture de sécurité entre deux cycles TLPT formels.

Une erreur fréquente consiste à traiter l’intervalle entre deux TLPT comme une période de relâchement, alors que les enseignements du premier test devraient au contraire structurer un programme d’amélioration continue actif pendant toute la durée de l’intervalle, de sorte que le TLPT suivant parte d’une base de maturité déjà rehaussée plutôt que de retrouver les mêmes lacunes trois ans plus tard.

Ce Qui Compte Vraiment : l’Après-Test

La valeur réelle d’un TLPT ne réside pas dans sa seule exécution technique, mais dans ce qui se passe après : comment les constats sont triés, priorisés, et transformés en feuille de route de remédiation avec une visibilité exécutive réelle. Les organisations qui traitent le rapport post-test comme une formalité à archiver, sans l’intégrer dans une démarche d’amélioration continue de leur posture de sécurité, en tirent une valeur nettement moindre que celles qui le considèrent comme un véritable outil de pilotage du risque.

Un TLPT bien exploité alimente directement les priorités du comité des risques et, dans certains cas, du conseil d’administration lui-même, avec des indicateurs concrets sur la capacité réelle de détection et de réponse de l’entité, pas seulement une liste de vulnérabilités techniques corrigées isolément sans lien avec une amélioration structurelle de la résilience globale.

Les Erreurs qui Réduisent la Valeur d’un TLPT

Traiter le TLPT comme un simple exercice de conformité à cocher. Sans intégration dans une démarche d’amélioration continue, l’exercice perd l’essentiel de sa valeur réelle pour la posture de sécurité de l’organisation.

Négliger la qualité du renseignement sur la menace en amont. Des scénarios génériques, déconnectés des menaces réellement pertinentes pour le secteur et la région, produisent un test qui ressemble à un TLPT sans en avoir la valeur de fond.

Sous-estimer la coordination nécessaire avec les prestataires tiers impliqués. Une coordination improvisée au dernier moment retarde le test ou en réduit le périmètre réel par rapport à ce qui était initialement prévu.

Ne pas clarifier la classification de criticité avant de définir le périmètre du test. Un périmètre mal défini, parce que la classification sous-jacente reste floue, teste soit trop peu, soit inutilement trop large.

Sous-provisionner le budget de remédiation qui découlera nécessairement des constats. Beaucoup d’organisations budgétisent uniquement le coût du test lui-même, sans anticiper que les corrections identifiées representeront souvent le poste de dépense le plus significatif du programme.

Considérer l’intervalle entre deux cycles TLPT comme une période sans obligation active. Les enseignements du premier test doivent structurer un programme d’amélioration continue, pas être archivés jusqu’au prochain cycle réglementaire.

Informer l’ensemble des équipes de sécurité internes à l’avance. Cela réduit artificiellement la valeur du test en matière d’évaluation réelle de la détection et de la réponse aux incidents.

Étude de Cas : une Banque d’Investissement Face à son Premier TLPT

Une banque d’investissement européenne, récemment désignée entité significative par son autorité de supervision, aborde son premier TLPT avec une équipe de sécurité interne convaincue de sa maturité, forte de plusieurs années de tests de pénétration réguliers menés sur ses applications critiques. Le renseignement sur la menace préparé par le prestataire spécialisé révèle pourtant un vecteur d’attaque privilégié par les groupes ciblant le secteur — l’ingénierie sociale contre le personnel du service client disposant d’accès aux systèmes de gestion des comptes clients — que la banque n’avait jamais formellement testé, ses exercices précédents s’étant concentrés exclusivement sur les vulnérabilités techniques des applications elles-mêmes.

L’équipe red team, suivant ce vecteur identifié par le renseignement sur la menace, parvient à obtenir un accès initial via un scénario d’ingénierie sociale téléphonique ciblant un agent du service client, puis progresse latéralement pendant plusieurs jours avant d’être détectée par l’équipe de sécurité interne — un délai de détection jugé significativement trop long par le contrôleur indépendant au regard des standards attendus pour une institution de cette taille.

La restitution post-test conduit la banque à revoir intégralement sa formation de sensibilisation du personnel en contact avec la clientèle, à renforcer sa surveillance des mouvements latéraux sur son réseau interne, et à intégrer des scénarios d’ingénierie sociale dans ses exercices de sécurité réguliers, pas seulement dans le cadre du TLPT réglementaire. Le deuxième TLPT, mené dix-huit mois plus tard, montre une détection de l’accès initial en quelques heures plutôt que plusieurs jours — un progrès que la banque attribue directement aux enseignements tirés du premier exercice, pas à une amélioration générique de sa posture de sécurité.

Un enseignement secondaire de cette expérience mérite d’être souligné : la banque avait initialement prévu un budget de remédiation modeste, fondé sur l’hypothèse que son premier TLPT confirmerait globalement sa maturité déjà établie par des années de tests de pénétration classiques. La découverte d’une lacune aussi significative sur un vecteur d’attaque non technique a nécessité une réallocation budgétaire en cours d’exercice, une situation que la direction des risques a explicitement identifiée comme évitable si le budget initial avait intégré une marge de contingence plus réaliste pour un premier cycle TLPT, par nature moins prévisible qu’un cycle de renouvellement ultérieur.

Le Changement Culturel que le TLPT Impose

Au-delà de sa dimension technique, l’introduction du TLPT dans le paysage réglementaire européen impose un changement culturel significatif pour beaucoup d’organisations financières. Le réflexe naturel face à un exercice de sécurité consiste souvent à vouloir maximiser le taux de réussite apparent — bien détecter l’attaque, bien réagir, présenter un résultat flatteur au comité de direction. Le TLPT, par sa conception même, inverse cette logique : un test qui ne révèle aucune faiblesse significative est presque toujours le signe d’un exercice mal calibré, pas d’une sécurité parfaite.

Les organisations qui réussissent le mieux leur programme TLPT sur la durée sont celles qui parviennent à transformer culturellement cette logique auprès de leur comité de direction : accepter qu’un premier TLPT révèle des lacunes n’est pas un échec de l’équipe de sécurité, c’est précisément la fonction de l’exercice, et la vraie mesure de succès se situe dans l’amélioration mesurée d’un cycle à l’autre, pas dans un score parfait dès le premier test.

Documenter le TLPT pour les Autorités de Supervision

Au-delà de sa valeur opérationnelle propre, le TLPT génère une documentation attendue par les autorités de supervision dans le cadre plus large de la conformité DORA. Cette documentation doit couvrir la méthodologie utilisée, la qualité et les sources du renseignement sur la menace mobilisé, le déroulement effectif du test avec les limites respectées, et la certification du contrôleur indépendant attestant du respect du cadre méthodologique attendu.

Cette exigence documentaire, souvent perçue comme une charge administrative supplémentaire après un exercice déjà exigeant en soi, gagne à être anticipée dès la phase de préparation plutôt que reconstruite a posteriori. Les organisations qui intègrent la production de cette documentation comme un livrable natif du processus TLPT, pas comme une tâche administrative ajoutée après coup, réduisent significativement la charge de travail associée et la qualité de ce qui est finalement soumis aux autorités compétentes.

Checklist de Préparation TLPT

• La classification de criticité des fonctions et systèmes est-elle suffisamment claire pour définir un périmètre de test pertinent ?
• Un renseignement sur la menace spécifique au secteur et à la région a-t-il été collecté avant de concevoir les scénarios ?
• Les prestataires tiers potentiellement inclus dans le périmètre ont-ils été contractuellement préparés à cette éventualité ?
• Un processus est-il en place pour transformer les constats post-test en feuille de route de remédiation suivie dans la durée ?
• Le comité des risques ou le conseil d’administration reçoit-il une restitution structurée des enseignements, pas seulement un rapport technique archivé ?
• Un budget de contingence réaliste pour la remédiation post-test a-t-il été provisionné, distinct du seul coût du test lui-même ?
• Un plan d’amélioration continue est-il actif entre deux cycles TLPT, plutôt qu’une période d’attente jusqu’au prochain exercice réglementaire ?

FAQ

Toutes les entités financières doivent-elles conduire un TLPT ?
Non — cette obligation cible spécifiquement les entités désignées significatives par les autorités compétentes selon le principe de proportionnalité de DORA, les autres entités restant soumises à des exigences de test moins intensives.

Combien de temps prend un TLPT complet, de la préparation à la restitution ?
Variable selon la complexité du périmètre, mais un cycle complet s’étale généralement sur plusieurs mois, la phase de préparation et de collecte de renseignement représentant souvent la majorité du temps total.

Un TLPT peut-il endommager les systèmes de production réels ?
Le cadre méthodologique, notamment via le contrôleur indépendant, est précisément conçu pour éviter ce risque, avec des limites strictes définies en amont, mais le risque n’est jamais totalement nul, ce qui justifie la rigueur méthodologique exigée.

Faut-il recourir à un prestataire externe pour l’équipe red team ?
Dans la grande majorité des cas oui, l’expertise et l’indépendance nécessaires dépassent généralement les capacités internes des équipes de sécurité, même matures, d’une entité financière quelle que soit sa taille.

Que se passe-t-il si l’entité échoue largement à détecter l’attaque simulée ?
Ce n’est pas en soi une sanction — c’est précisément l’objectif de l’exercice de révéler ces lacunes avant qu’une attaque réelle ne les exploite, à condition que les enseignements soient réellement exploités par la suite.

Le budget de remédiation doit-il être fixé avant ou après le test ?
Une enveloppe de contingence raisonnable doit être provisionnée avant le test, précisément parce que l’ampleur exacte des constats reste imprévisible à l’avance, tout en sachant qu’un budget de remédiation définitif ne peut être fixé qu’après la restitution complète des résultats.

Un prestataire tiers peut-il refuser d’être inclus dans le périmètre d’un TLPT ?
En pratique cela dépend des clauses contractuelles négociées à l’avance — un prestataire n’ayant pas anticipé cette possibilité dans ses contrats standards se retrouve en position de négociation défavorable une fois la demande formulée par un client dans l’urgence d’un cycle de conformité.

Regard d’Expert

Ayant coordonné des programmes de cybersécurité dans des contextes multi-pays, je constate que la vraie valeur d’un TLPT se joue rarement pendant le test lui-même, mais dans la capacité de l’organisation à transformer des constats parfois inconfortables en changements structurels réels — une discipline de gouvernance, pas seulement un exercice technique ponctuel.

Écrit par Steeve Vignissy, consultant senior en transformation digitale chez Notoriti, avec une expérience de coordination de programmes de cybersécurité et d’audits de conformité dans des contextes multi-pays.

👉 Contactez Notoriti pour préparer votre premier TLPT ou structurer le suivi de vos exercices précédents, en particulier si les enseignements des cycles antérieurs n’ont pas encore été pleinement intégrés à votre programme de sécurité continu.

Pour Aller Plus Loin

• Le Registre d’Information DORA : Ce Qu’il Faut Fournir et Avant Quand
• Incident Reporting Under DORA (EN)
• DORA Third-Party Risk (EN)

Références

• Orbiq, DORA Compliance Guide 2026: Requirements & Deadlines, mars 2026
• Banque Centrale Européenne, cadre TIBER-EU, documentation méthodologique
• Mitratech, What Is DORA? What Financial Institutions Need to Know in 2026, juin 2026