L'essentiel de ce que DORA demande à un éditeur de logiciels est de la paperasse : clauses, registres, rapports. Les tests de pénétration fondés sur la menace sont la partie qui n'en est pas. L'article 26 du règlement (UE) 2022/2554 fait exécuter aux entités financières que leurs autorités identifient un test de pénétration fondé sur la menace, TLPT, au moins tous les 3 ans, sur les systèmes de production soutenant des fonctions critiques ou importantes, et le paragraphe 2 dit que le périmètre inclut les systèmes soutenant ces fonctions qui ont été externalisés ou confiés par contrat à des prestataires tiers de services TIC. Si votre produit soutient une telle fonction chez une banque qui a été identifiée, une équipe rouge engagée par la banque peut passer trois mois à attaquer votre environnement de production sans que votre personnel d'exploitation en soit informé. Le règlement délégué (UE) 2025/1190 de la Commission du 13 février 2025, publié le 18 juin 2025 et en vigueur depuis le 8 juillet 2025, en précise le comment en dix-sept articles et huit annexes. Cet article lit les articles 26 et 27 de DORA et le règlement délégué au Journal officiel sur CELLAR le 12 septembre 2026, du côté du prestataire. Ce n'est pas un avis juridique.

Qui est testé, et pourquoi votre client pourrait en faire partie

Toutes les entités financières ne mènent pas de TLPT. L'article 26, paragraphe 8, de DORA fait identifier par les autorités compétentes les entités qui y sont tenues, selon des facteurs liés à l'impact, des préoccupations de stabilité financière et le profil de risque TIC de l'entité, et l'article 2 du règlement délégué liste les critères : la taille, l'interconnexion, la criticité et la substituabilité des services que l'entité fournit, la complexité de son modèle d'affaires, son appartenance à un groupe de caractère systémique et, côté TIC, son profil de risque, son paysage de menaces, le degré de dépendance de ses fonctions critiques ou importantes aux TIC, la complexité de son architecture et, point b) v), les services et fonctions TIC soutenus par des prestataires tiers de services TIC ainsi que la quantité et le type d'accords contractuels avec eux. Les microentreprises et les petites entités de l'article 16, paragraphe 1, sont exclues. Les clients qui vous atteignent avec un TLPT sont donc les grands, et le nombre de prestataires dont ils dépendent est l'une des raisons pour lesquelles ils ont été choisis.

Ce que le contrat dit déjà

Le point d) de l'article 30, paragraphe 3, de DORA exige que tout contrat portant sur un service soutenant une fonction critique ou importante contienne l'obligation du prestataire de participer et de coopérer pleinement au TLPT du client au titre des articles 26 et 27. C'est l'une des six clauses de la liste de l'article 30 pour les fonctions critiques ou importantes, et elle n'est pas négociable dans son principe, seulement dans sa mécanique. L'article 26, paragraphe 3, ajoute que lorsque des prestataires sont inclus dans le périmètre, l'entité prend les mesures et garanties nécessaires pour assurer leur participation et reste pleinement responsable, et l'article 26, paragraphe 5, exige que l'entité, avec la coopération de ses prestataires et des testeurs, applique des contrôles de gestion des risques contre l'impact sur les données, les dommages aux actifs et la perturbation des fonctions critiques ou importantes, chez l'entité, ses contreparties et dans le secteur financier.

La mécanique : l'équipe de contrôle, l'équipe bleue et les 12 semaines

Le règlement délégué définit les rôles. L'équipe de contrôle, article 1, point 1, est le personnel de l'entité testée et, lorsque le périmètre le justifie, le personnel de ses prestataires tiers, qui gère le test ; l'équipe bleue, article 1, point 3, est le personnel de l'entité et, le cas échéant, de ses prestataires qui défend les systèmes et qui n'est pas au courant du TLPT. L'article 4 exige que les dispositions organisationnelles de l'entité garantissent que l'équipe de contrôle soit informée de toute détection du test par le personnel de l'entité ou de ses prestataires. Un prestataire dans le périmètre a donc des gens des deux côtés : une ou deux personnes qui savent, dans l'équipe de contrôle, et une équipe d'exploitation qui ne doit pas savoir.

L'article 9 fixe la phase de préparation : l'entité soumet les informations d'initiation dans les 3 mois suivant la notification de l'autorité et une spécification de périmètre dans les 6 mois, approuvée par son organe de direction, et l'équipe de contrôle sélectionne le fournisseur de renseignement sur les menaces et les testeurs. L'article 10 est la phase de renseignement sur les menaces, qui produit un rapport ciblé sur l'entité et son périmètre. L'article 11 est le test d'équipe rouge : une phase active d'équipe rouge proportionnée au périmètre et au nombre d'entités et de prestataires impliqués, et en tout cas d'au moins 12 semaines. Si un membre du personnel de l'entité ou de ses prestataires détecte le test, l'équipe de contrôle propose des mesures pour le poursuivre en préservant le secret. Dans des circonstances exceptionnelles faisant peser un risque sur les données, les actifs ou la perturbation de fonctions critiques ou importantes de l'entité ou de ses prestataires, le responsable de l'équipe de contrôle peut suspendre le test ou, en dernier recours et avec la validation de l'autorité, le poursuivre sous forme d'exercice violet limité.

L'article 12 est la clôture : l'équipe bleue est informée ; les testeurs remettent un rapport d'équipe rouge dans les 4 semaines ; l'équipe bleue remet son rapport dans les 10 semaines ; dans les mêmes 10 semaines, les deux rejouent les actions offensives et défensives et mènent un exercice violet sur les vulnérabilités trouvées ; et l'entité soumet un rapport de synthèse à l'autorité dans les 8 semaines suivant l'évaluation des deux rapports par l'autorité. L'article 13 exige un plan de remédiation dans les 8 semaines suivantes, avec, pour chaque constat, les lacunes, les mesures avec priorité et dates d'achèvement, une analyse des causes profondes, les responsables et les risques de ne pas remédier. L'article 14 et l'article 26, paragraphe 7, de DORA donnent à l'entité une attestation pour la reconnaissance mutuelle entre autorités.

L'article 7 protège le prestataire autant que l'entité : les testeurs et le fournisseur de renseignement sur les menaces ne peuvent pas exercer de tâches d'équipe bleue pour l'entité ou pour un prestataire impliqué dans le test, ne peuvent pas être employés par un fournisseur de renseignement qui le fait, et ne doivent pas se livrer à la destruction non autorisée d'équipements ni à la modification incontrôlée d'informations et d'actifs TIC de l'entité ou de ses prestataires. L'article 27 de DORA exige que les testeurs soient de la plus haute aptitude, certifiés ou liés par un code de conduite, couverts par une assurance de responsabilité professionnelle, et contractuellement tenus à une gestion saine des résultats, y compris la protection des informations confidentielles.

Le test groupé, article 26, paragraphe 4 : l'option écrite pour le SaaS

Un prestataire multi-locataire a un problème que le règlement a anticipé : une équipe rouge qui attaque son environnement de production pour une banque attaque l'environnement de tous ses autres clients, y compris ceux hors DORA. L'article 26, paragraphe 4, y répond. Lorsque la participation du prestataire au TLPT d'un client est raisonnablement susceptible d'avoir une incidence négative sur la qualité ou la sécurité des services qu'il fournit à des clients hors du champ de DORA, ou sur la confidentialité de leurs données, l'entité et le prestataire peuvent convenir par écrit que le prestataire contracte directement avec un testeur externe et mène, sous la direction d'une entité financière désignée, un TLPT groupé pour plusieurs entités financières auxquelles il fournit les services. Le test groupé couvre l'éventail pertinent des services soutenant des fonctions critiques ou importantes contractés par ces entités, et compte comme le TLPT de chaque entité participante. L'article 16 du règlement délégué fait convenir aux autorités quelle entité dirige, en considérant les services fournis par le prestataire et l'efficacité du test, et les articles 6 et 8 fixent la gestion des risques et les spécificités des tests groupés.

Pour un prestataire ayant plusieurs clients financiers, c'est la phrase à négocier dans chaque contrat : un test groupé tous les 3 ans, dirigé par un client, avec un testeur que le prestataire sélectionne au titre de l'article 27, au lieu d'une équipe rouge distincte par client. Écrivez-la dans la clause de l'article 30, paragraphe 3, point d), quand l'avenant arrive, pas quand la notification arrive.

Ce que vous ne pouvez pas refuser, et ce que vous pouvez

Vous ne pouvez pas refuser la participation : la clause est obligatoire et l'autorité de l'entité valide le périmètre. Vous pouvez, au titre de l'article 26, paragraphe 4, refuser que votre environnement de production partagé soit attaqué pour le compte d'un seul client, à condition d'offrir le test groupé. Vous pouvez exiger, au titre de l'article 27, paragraphe 3, et de l'article 7, que le contrat du testeur le lie à la protection de vos informations confidentielles et à l'interdiction de destruction et de modification incontrôlée. Vous pouvez avoir votre propre personnel dans l'équipe de contrôle, et vous le devriez, car c'est là que se prend la décision de suspension de l'article 11 lorsque le test menace d'autres clients. Et vous pouvez insister pour que la rediffusion et l'exercice violet de la phase de clôture incluent votre équipe bleue, car les constats qui concernent votre infrastructure sont les vôtres à remédier.

Ce qu'un système ISO 27001 contient déjà

Le règlement délégué ne nomme aucune norme, et ce qui suit est la lecture de StandardOS de l'endroit où un système de management ISO/IEC 27001:2022 produit ce qu'un TLPT cherchera, sans présomption de conformité. La phase de renseignement sur les menaces lit votre propre enregistrement de renseignement sur les menaces A.5.7 et votre surface d'attaque telle que l'inventaire des actifs, A.5.9, la décrit. La phase d'équipe rouge teste la journalisation et la surveillance de A.8.15 et A.8.16, avec lesquelles l'équipe bleue défend, et la planification de la gestion des incidents de A.5.24, que l'équipe bleue suit lorsqu'elle détecte. Le plan de remédiation de la phase de clôture correspond à la mesure de gestion des vulnérabilités, A.8.8, et à l'enregistrement des actions correctives de la clause 10.2, avec cause profonde, responsable et dates déjà dans le format que l'article 13 demande. Les contrôles de gestion des risques de l'article 26, paragraphe 5, sont les mesures de continuité, A.5.29 et A.5.30, appliquées à la fenêtre de test. Et les conditions de confidentialité que vous imposez au testeur sont des termes d'accord avec un fournisseur, A.5.20. Ce que la norme ne vous donne pas, c'est le secret : une équipe bleue qui n'est pas informée est une disposition organisationnelle au titre de l'article 4, et elle doit être conçue avec le client.

Que faire avant la notification

Décidez dès maintenant si une équipe rouge peut attaquer votre environnement de production, et sinon, mettez le test groupé de l'article 26, paragraphe 4, dans la clause de l'article 30, paragraphe 3, point d), de chaque contrat financier. Choisissez, au titre de l'article 27, le testeur externe que vous contracteriez pour un test groupé, et réglez à l'avance avec lui les conditions de confidentialité et d'interdiction de destruction. Nommez les deux personnes qui siégeraient dans l'équipe de contrôle d'un client et tenez-les à l'écart de l'exploitation. Répétez une suspension : qui décide, sur quelles preuves, en combien de minutes, quand le test menace un autre client. Et gardez l'enregistrement des incidents et celui des vulnérabilités dans une forme qui produit un plan de remédiation sous 8 semaines, parce que l'article sur les incidents majeurs montre les mêmes enregistrements répondant à un autre délai. Le hub DORA tient les dates du règlement et de ses actes.