L’essentiel en 30 secondes
- DORA ne nomme pas le test de fuite, mais il répond à deux exigences : vérifier que les mesures de protection fonctionnent et tester régulièrement les systèmes TIC.
- Sa place la plus naturelle : les tests fondés sur des scénarios de l’article 25.
- Il complète l’audit et le TLPT entre deux exercices, il ne les remplace pas.
« Notre programme de tests DORA a son pentest annuel, et peut-être bientôt un TLPT. Le test de fuite de données, on le range où ? » Nous l’entendons souvent chez les responsables des risques d’entités financières. Elle est d’ailleurs légitime.
Le règlement DORA (UE) 2022/2554 impose aux entités financières un cadre de gestion du risque TIC et un programme de tests de résilience opérationnelle numérique, applicables depuis le 17 janvier 2025. Le test de fuite de données n’y figure pas sous ce nom. Il répond pourtant à deux de ses exigences : vérifier que vos mesures de protection fonctionnent, et tester régulièrement vos outils et systèmes TIC. Notre réponse : il complète les tests prévus, sans remplacer ni l’audit ni le TLPT.
Tests de résilience DORA : ce que le règlement demande
DORA ne vous parle pas d’outils. Le règlement veut savoir si vous tenez le choc, et si vous savez repartir. Deux de ses blocs touchent quand même la fuite de données.
Le cadre de gestion du risque TIC (chapitre II)
Les articles 5 à 16 décrivent le cadre que l’entité doit mettre en place. L’article 9 (protection et prévention) vise entre autres la confidentialité et l’intégrité des données, y compris en transit. L’article 10 porte sur la détection des activités anormales. Le régulateur attend donc des mesures qui empêchent une sortie non autorisée de données, et des mécanismes capables de la repérer quand la prévention échoue.
Un point souvent sous-estimé : votre cadre doit aussi être documenté, puis réexaminé et amélioré à partir des enseignements tirés (article 13). Une règle DLP que personne n’a jamais éprouvée, vous aurez du mal à la défendre dans ce cycle.
Le programme de tests (chapitre IV)
L’article 24 impose un programme de tests de résilience opérationnelle numérique, proportionné, fondé sur les risques, avec des tests au moins annuels sur les systèmes et applications qui soutiennent les fonctions critiques ou importantes. L’article 25 liste les types de tests attendus : évaluations de vulnérabilité, analyses de sécurité des réseaux, analyses d’écarts, tests fondés sur des scénarios, tests de performance, tests de pénétration, entre autres. L’article 26 encadre les tests de pénétration fondés sur la menace (TLPT), réservés aux entités désignées par les autorités, au minimum tous les trois ans.
C’est dans l’article 25, côté « tests fondés sur des scénarios », que le test de fuite de données trouve sa place la plus naturelle.
Où se place le test d’exfiltration dans ce dispositif
Un test d’exfiltration de données rejoue, de façon contrôlée, les techniques qu’un attaquant ou un initié utiliserait pour faire sortir de l’information, puis observe ce que vos contrôles bloquent, détectent ou laissent passer. Chez Enforcis, ce scénario enchaîne, en s’alignant sur MITRE ATT&CK, découverte, collecte, préparation, automatisation puis exfiltration.
| Exigence DORA | Question posée | Apport d’un test d’exfiltration |
|---|---|---|
| Art. 9 : protection et prévention | Vos mesures empêchent-elles la sortie de données ? | Preuve observée canal par canal, au lieu d’une règle supposée active |
| Art. 10 : détection | Le SOC voit-il une tentative de sortie ? | Mesure de ce qui remonte en alerte et en combien de temps |
| Art. 13 : apprentissage et évolution | Vos mesures s’améliorent-elles ? | Posture comparée dans le temps, avant et après correction |
| Art. 24 et 25 : programme de tests | Testez-vous régulièrement, selon les risques ? | Scénarios d’attaque rejoués à fréquence définie sur les systèmes critiques |
Un scénario concret : la société de gestion et son extraction de portefeuille
Imaginez une société de gestion de 120 personnes, équipée d’une DLP sur la messagerie, d’un proxy web et d’un CASB. Vu de la console, les positions clients ne peuvent pas sortir.
L’équipe rejoue 4 scénarios avec des données synthétiques qui imitent ces fichiers de positions : envoi vers Gmail, dépôt sur un Dropbox personnel, copie dans un assistant d’IA comme Copilot, sortie par un flux HTTPS. En pratique, le schéma est souvent le suivant : la messagerie bloque, le web bloque en partie, et un canal passe sans la moindre alerte. Personne ne l’avait vu : c’est le propre des faux négatifs DLP.
Ce constat, daté et documenté, part ensuite dans votre dossier de tests DORA et dans le plan de remédiation. Avec Enforcis, les constats sur les canaux réseau et cloud testés sont datés et traçables. Les prochaines versions apporteront un reporting à plusieurs niveaux (direction, RSSI, opérations), avec des correspondances MITRE ATT&CK et, lorsque la correspondance est établie, MITRE D3FEND, ainsi que des intégrations SIEM.
Étape suivante
Quel canal passe sans alerte chez vous ?
Une démo de 30 minutes : une campagne complète sur les 8 canaux que nous testons, sur notre environnement de démonstration. Le POC montre in situ, sur un scénario simple en environnement synthétique, comment la solution se comporte chez vous. Ce qui sort réellement de vos canaux, c’est le pilote qui vous le montre.
Checklist pour intégrer le test de fuite à votre programme DORA
- Partir des fonctions critiques ou importantes. Identifiez les données qui les soutiennent et les systèmes qui les manipulent.
- Cartographier les canaux de sortie. Poste de travail, messagerie, web, OneDrive ou Google Drive, Teams, SaaS, assistants d’IA générative.
- Définir des scénarios d’attaque réalistes. Initié négligent, initié malveillant, poste compromis. Restez côté défense : l’objectif est de valider vos contrôles.
- Utiliser exclusivement des leurres. Tester en production avec de la donnée réelle crée le risque que vous cherchez à mesurer.
- Mesurer blocage et détection séparément. Un canal non bloqué mais détecté rapidement n’a pas la même gravité qu’un canal invisible.
- Hiérarchiser les corrections. Classez-les par impact et par effort, plutôt que dans l’ordre du rapport.
- Retester après chaque correction et chaque changement majeur. Une migration vers Windows 11 ou une mise à jour d’agent peut défaire une règle.
- Conserver les preuves. Date, périmètre, scénario, résultat, action menée. C’est ce qu’un contrôleur de l’ACPR ou de l’AMF vous demandera.
Ponctuel ou continu : l’arbitrage pour une entité financière
DORA demande au moins un test par an sur les systèmes qui soutiennent les fonctions critiques ou importantes. C’est un minimum. Entre deux tests annuels, votre environnement change des dizaines de fois : nouvelles applications SaaS, règles modifiées, postes migrés. Or une brèche coûte en moyenne 4,99 millions de dollars dans le monde, selon l’étude IBM Cost of a Data Breach 2026 (Ponemon, 602 organisations).
Schéma · trois rythmes de test
Le pentest et le TLPT gardent toute leur valeur : ils testent une chaîne d’attaque complète, avec l’imagination d’humains expérimentés. Le test d’exfiltration continu, lui, vérifie un contrôle précis, entre deux exercices. Notre comparatif validation continue, pentest ou red team détaille ce partage. Si une autre entité de votre groupe relève de NIS2, les mêmes résultats pourront nourrir les deux dossiers.
FAQ
DORA impose-t-il explicitement un test de fuite de données ?
Non. Le texte ne nomme pas ce test. Il impose un programme de tests fondé sur les risques, incluant des tests fondés sur des scénarios, et des mesures de protection de la confidentialité des données. Le test d’exfiltration est une manière de démontrer l’efficacité de ces mesures sur les scénarios testés.
Le test d’exfiltration peut-il remplacer le TLPT ?
Non. Le TLPT, prévu à l’article 26, obéit à un cadre spécifique, avec des testeurs répondant aux exigences de l’article 27 et une validation par l’autorité. Le test d’exfiltration le complète entre deux exercices.
Les petites entités financières sont-elles concernées ?
Oui, avec proportionnalité. Certaines entités relèvent du cadre simplifié de gestion du risque TIC de l’article 16. Le principe de tests réguliers et proportionnés demeure ; vérifiez votre régime précis avec votre autorité ou votre conseil.
Le prestataire de test doit-il figurer dans le registre d’informations ?
Un prestataire qui réalise ces tests pour vous devient un prestataire tiers de services TIC au sens de DORA (chapitre V). Voyez avec votre fonction conformité comment l’intégrer à votre registre d’informations, prévu à l’article 28, et à votre suivi des risques liés aux tiers.