Tests de résilience DORA : TLPT et obligations

DORA demande de choisir des tests adaptés aux risques puis de corriger les faiblesses constatées. Le programme ordinaire et les tests avancés fondés sur la menace, ou TLPT, suivent des règles différentes. Il serait inexact d’imposer chaque année tous les types de tests à toutes les entités financières.

Les références principales sont les Art. 24 à 27 du règlement (UE) 2022/2554, complétés notamment par le règlement délégué (UE) 2025/1190 pour les TLPT, répertorié par l’ESMA.

Déterminer les obligations de test de l’entité

L’Art. 25(1) donne des exemples de tests appropriés : vulnérabilités, réseaux, scénarios, performance, bout en bout, pénétration ou revue de code lorsque possible. Il ne signifie pas que chacun doit être exécuté à fréquence identique sur chaque application. La qualification de l’entité DORA précède le programme.

Construire une couverture vérifiable

Reliez chaque fonction critique ou importante aux systèmes et dépendances qui la soutiennent. Choisissez les tests selon les risques : restauration pour une perte de données, basculement pour une indisponibilité, contrôle des habilitations pour une divulgation ou altération.

Le plan précise le périmètre, le scénario, les préconditions, les résultats attendus, l’indépendance des testeurs et les limites. Pour les entités visées, l’Art. 24(4) admet des parties indépendantes internes ou externes ; les ressources et conflits d’intérêts doivent être traités lorsque les testeurs sont internes.

Le dossier de gestion des risques TIC doit recevoir les résultats. Un test n’est pas achevé du point de vue du suivi parce qu’un rapport a été livré : l’Art. 24(5) prévoit la priorisation, la résolution et la validation des corrections.

Comprendre ce qui déclenche un TLPT

L’Art. 26(1) vise les entités identifiées par l’autorité, en excluant les entités de l’Art. 16(1), premier alinéa, et les microentreprises. La désignation tient compte notamment des facteurs d’incidence, de la stabilité financière et du profil de risque TIC selon l’Art. 26(8). Elle ne se résume pas au qualificatif informel « systémique ».

La fréquence de principe est d’au moins un test tous les trois ans. L’autorité peut demander de réduire ou d’augmenter cette fréquence selon le profil de risque et les circonstances opérationnelles. Chaque TLPT couvre plusieurs, voire toutes, les fonctions critiques ou importantes pertinentes, sur les systèmes de production qui les soutiennent. Le périmètre est validé par l’autorité dans les conditions de l’Art. 26(2). Source : Art. 26.

Sélectionner les testeurs selon les règles applicables

L’Art. 27 prévoit compétences, réputation, garanties de gestion des risques et couverture d’assurance. Le recours à des testeurs internes est possible sous conditions, dont l’approbation de l’autorité et un fournisseur externe de renseignements sur la menace.

L’Art. 26(8) exige un testeur externe tous les trois tests lorsqu’une entité utilise des testeurs internes. Les établissements de crédit classés importants selon le règlement (UE) n° 1024/2013 doivent recourir uniquement à des testeurs externes. Vérifiez cette classification avant de choisir les intervenants.

Préparer les prestataires et les garanties

Si des services TIC tiers entrent dans le périmètre, l’entité organise leur participation et conserve sa responsabilité. Les tests groupés de l’Art. 26(4) répondent à des conditions précises, notamment lorsque la participation du prestataire pourrait affecter la qualité, la sécurité ou la confidentialité de services fournis à d’autres clients hors champ.

La préparation doit définir les responsabilités, les canaux d’urgence et les mesures limitant l’incidence du test. Les accords de sous-traitance TIC DORA doivent permettre la coopération nécessaire. Les rapports et éléments techniques sensibles exigent des accès maîtrisés.

Fermer les écarts et conserver les preuves

Après un TLPT, l’Art. 26(6) prévoit la transmission d’une synthèse des conclusions pertinentes, des plans de mesures correctives et des preuves de conformité du test. L’attestation destinée à permettre la reconnaissance mutuelle relève de l’Art. 26(7), sans supprimer la responsabilité de l’entité.

Suivez chaque correction avec un responsable, une échéance et une vérification. Une attestation sur le déroulement du test ne signifie pas absence de vulnérabilités ni conformité totale de l’organisation. Le guide DORA aide à articuler ces résultats avec la gouvernance.

Passer de l’inventaire à un programme réalisable

Commencez par une question métier vérifiable : après la perte d’un composant, quelle opération doit encore pouvoir être réalisée, par qui et avec quelles données ? Le nom d’une application ne répond pas à cette question. Une fonction peut dépendre simultanément d’un outil, d’un service d’identité, d’une liaison réseau et d’une intervention du prestataire. Une couverture limitée à l’outil laisserait ces dépendances sans réponse.

Une matrice de préparation peut relier cinq éléments. Ce format est une méthode de travail proposée, à adapter au périmètre réglementaire de l’entité.

Définissez les critères avant de connaître les résultats. Une durée de reprise observée ne devient pas automatiquement un objectif acceptable parce qu’elle paraît raisonnable. Comparez-la au besoin documenté de la fonction, ainsi qu’aux conséquences d’une interruption. Si le scénario exige une intervention manuelle indisponible hors horaires ouvrés, le résultat doit conserver cette réserve.

La planification doit aussi rendre visibles les trous de couverture. Lorsqu’une dépendance critique n’est pas incluse dans la campagne, indiquez le motif, le risque restant et l’action permettant de l’évaluer. Un rapport du fournisseur peut éclairer ce point ; vérifiez néanmoins sa période, son périmètre et les configurations réellement couvertes avant d’en tirer une conclusion pour votre environnement.

Lire un résultat sans lui donner une portée excessive

Prenons un dossier entièrement fictif. L’entité financière Aulne prépare un exercice de restauration d’un outil utilisé pour une fonction qu’elle a classée importante. Le scénario prévoit une copie isolée et des données de démonstration. L’équipe doit vérifier le redémarrage de l’outil, les habilitations nécessaires et la possibilité de reprendre une opération de bout en bout.

Supposons que le compte rendu indique un redémarrage réussi, mais que l’accès au service d’identité n’ait pas été reproduit et qu’aucun représentant métier n’ait validé l’opération finale. Le dossier permettrait de constater la restauration technique dans l’environnement décrit. Il ne suffirait pas à conclure que la fonction pourrait reprendre en production dans les conditions attendues. La réserve porte ici sur deux dépendances précises ; elle ne rend pas inexistants les résultats techniques déjà obtenus.

La suite proposée serait de faire examiner ces limites par les responsables concernés, puis de définir les vérifications complémentaires. Pour chacune, précisez le résultat attendu et le document qui permettra de l’établir. Cet exemple n’est ni un test réalisé, ni une démonstration de conformité : il montre pourquoi le périmètre de la preuve doit accompagner la conclusion.

Organiser la réception et la correction des écarts

La réception d’un rapport demande deux lectures. La première vérifie que la mission convenue a été exécutée : systèmes inclus, scénario, conditions, incidents rencontrés, traces et limites. La seconde examine ce que les résultats impliquent pour l’activité. La présence d’un livrable complet ne résout pas, à elle seule, une faiblesse révélée par le test.

Pour chaque écart, consignez le composant affecté, les fonctions exposées et les conditions dans lesquelles le problème se produit. Le responsable de correction doit disposer d’une action suffisamment précise pour agir. « Renforcer la sécurité » ne permet ni de vérifier l’avancement ni de contrôler l’efficacité. Identifiez plutôt le défaut constaté, la modification envisagée et le contrôle qui devra confirmer sa résolution.

Distinguez ensuite trois dates : la décision de corriger, la mise en œuvre annoncée et la validation de la correction. Ces étapes peuvent relever de personnes différentes. Un ticket fermé par le prestataire est une information utile, mais il faut encore déterminer si la preuve fournie couvre la faiblesse observée. Une nouvelle vérification peut révéler un problème résiduel ou une conséquence sur une autre dépendance ; gardez alors l’écart ouvert avec une explication actualisée.

Enfin, protégez le dossier lui-même. Les détails techniques, comptes utilisés et faiblesses restantes ne doivent circuler qu’auprès des destinataires qui en ont besoin. Préparez une synthèse adaptée aux décisions de gouvernance et conservez séparément les pièces sensibles nécessaires aux équipes de correction. Pour les TLPT, cette organisation doit s’articuler avec les exigences précises de transmission à l’autorité et de gestion des résultats prévues par les Art. 26(6) et 27(3).

Ce qu’il faut retenir

Le programme doit couvrir les risques et fonctions applicables avec des tests appropriés. Distinguez périodicité annuelle ciblée, régime des microentreprises et TLPT. La preuve essentielle reste la correction vérifiée des lacunes observées.

FAQ

Tous les tests de pénétration sont-ils des TLPT ?

Non. Le TLPT suit un cadre spécifique de menace, périmètre, gouvernance et supervision. Un test technique ponctuel ne suffit pas à lui donner cette qualification.

Peut-on toujours utiliser une équipe interne ?

Non. Les conditions des Art. 26 et 27 doivent être vérifiées, et certains établissements doivent utiliser uniquement des testeurs externes.

Tous les systèmes doivent-ils subir chaque type de test annuellement ?

Non. L’Art. 24(6) impose des tests appropriés sur le périmètre qu’il définit. Le choix et les fréquences doivent aussi respecter les autres exigences applicables et le profil de risque.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.