Faire appel à un prestataire de test d’intrusion établi dans l’UE : ce que le RGPD exige

En France, la première objection opposée à un prestataire de sécurité offensive n’est presque jamais technique. Elle tient en une phrase : « vous n’êtes pas français ». Derrière cette phrase se cachent en réalité deux questions très différentes, et les confondre coûte cher aux deux parties.

La première est juridique : mes données vont-elles quitter l’Union européenne ? La seconde est contractuelle et administrative : mon marché impose-t-il un prestataire disposant d’une qualification délivrée par l’État français ?

La littérature française disponible mélange les deux. Elle traite « étranger » comme un synonyme de « hors Union européenne », enchaîne sur le Cloud Act, puis sur les qualifications d’hébergement, et laisse le lecteur avec l’impression qu’un prestataire non français implique mécaniquement un dossier de transfert international. Ce n’est pas ce que dit le règlement.

Cet article prend les deux questions séparément et donne la réponse exacte à chacune.

Ce que le RGPD exige réellement d’un prestataire de test d’intrusion

Dès qu’un testeur peut accéder à des données à caractère personnel — et c’est presque toujours le cas, puisque la plupart des applications contiennent des noms, des adresses de messagerie ou des dossiers clients — le test est lui-même un traitement au sens du règlement (UE) 2016/679.

Les rôles sont alors simples : vous êtes responsable du traitement, le prestataire est sous-traitant. Cela déclenche deux séries d’obligations.

L’article 28 : le contrat de sous-traitance

L’article 28 impose un acte juridique écrit, y compris sous forme électronique, qui définit l’objet, la durée, la nature et la finalité du traitement, les catégories de données et de personnes concernées, ainsi que les obligations et droits du responsable du traitement. Il énumère ensuite ce que le sous-traitant s’engage à faire :

• ne traiter les données que sur instruction documentée du responsable du traitement ;
• garantir la confidentialité des personnes autorisées à traiter les données ;
• mettre en œuvre les mesures de sécurité exigées par l’article 32 ;
• ne pas recruter de sous-traitant ultérieur sans autorisation écrite, préalable, spécifique ou générale — et lui imposer les mêmes obligations ;
• aider le responsable du traitement à répondre aux demandes d’exercice des droits et à respecter ses propres obligations de sécurité, de notification de violation et d’analyse d’impact ;
• supprimer ou restituer les données au terme de la prestation, selon le choix du responsable du traitement ;
• mettre à disposition les informations permettant de démontrer le respect de ces obligations et permettre la réalisation d’audits.

Ce sont les sept points sur lesquels un contrat de pentest se juge. Dans la pratique, les deux derniers — la suppression avec une échéance datée, et le droit d’audit — sont ceux qui manquent le plus souvent dans les conditions générales d’un prestataire.

L’article 32 : la sécurité, et la raison même du test

L’article 32 demande des mesures techniques et organisationnelles appropriées au risque. Il cite explicitement, parmi elles, « une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement ».

Autrement dit : le RGPD est l’un des rares textes européens qui nomme l’exercice de test. Ce n’est pas une obligation absolue de commander un test d’intrusion, c’est une norme qui suit le risque. Mais si vous traitez des données de santé, des données de paiement ou des volumes importants, il devient difficile de soutenir que vous n’avez jamais vérifié l’efficacité de vos mesures.

Ce point vaut d’être noté : le même article impose au sous-traitant de sécuriser son propre traitement. Un prestataire qui teste vos systèmes doit donc pouvoir décrire comment il protège les preuves qu’il collecte chez vous.

Pourquoi un prestataire établi dans l’UE ne pose aucune question de transfert

Le chapitre V du RGPD — les articles 44 et suivants — ne s’applique qu’à une chose : le transfert de données vers un pays tiers ou une organisation internationale. Tant que le traitement reste dans l’Union européenne et l’Espace économique européen, ce chapitre n’est tout simplement pas déclenché.

Concrètement, cela veut dire qu’avec un prestataire établi dans l’Union :

• pas de décision d’adéquation à vérifier ;
• pas de clauses contractuelles types à annexer — celles adoptées par la décision d’exécution (UE) 2021/914 de la Commission du 4 juin 2021 ;
• pas d’analyse d’impact du transfert, cet exercice supplémentaire imposé depuis l’arrêt de la Cour de justice de l’Union européenne du 16 juillet 2020 (affaire C-311/18) ;
• pas de règles d’entreprise contraignantes à instruire.

Il reste le contrat de sous-traitance de l’article 28 — que vous devez de toute façon signer avec un prestataire français. Sur le plan du transfert, un prestataire établi à Tallinn, à Madrid ou à Lille se traite exactement de la même manière.

Le RGPD ne connaît pas la nationalité d’un prestataire.
Il connaît le lieu du traitement et l’existence, ou non, d’un transfert hors de l’Union.

L’établissement ne suffit pas : vérifiez la chaîne

Il serait malhonnête de s’arrêter là. Un prestataire établi dans l’Union peut parfaitement organiser un transfert : en hébergeant ses rapports chez un fournisseur non européen, en utilisant une plateforme de gestion de vulnérabilités opérée depuis un pays tiers, ou en faisant intervenir un sous-traitant ultérieur hors Union.

L’établissement supprime la question au niveau du prestataire lui-même. Les trois questions qui subsistent sont opérationnelles, et vous devez les poser :

1. où sont hébergés les rapports, les preuves et les échanges ?
2. quels sous-traitants ultérieurs sont nommés au contrat, et où sont-ils établis ?
3. quels outils interviennent sur les données, et où traitent-ils ?

Un prestataire sérieux répond à ces trois questions par écrit, avec des noms, avant la signature. Un prestataire qui répond « tout est en Europe » sans nommer personne ne vous donne rien d’opposable.

Ce que recouvre vraiment l’exposition au Cloud Act

Le Clarifying Lawful Overseas Use of Data Act, adopté aux États-Unis en 2018, permet aux autorités américaines d’obtenir des données détenues par un fournisseur soumis à la juridiction des États-Unis, indépendamment du lieu de stockage. C’est un texte d’extraterritorialité, et l’inquiétude française à son sujet est légitime.

Ce qu’il faut comprendre, c’est son critère de rattachement. Il ne vise pas les entreprises « étrangères » au sens français du terme : il vise celles qui relèvent de la juridiction américaine — par leur établissement aux États-Unis, par leur société mère, ou par l’exercice d’une activité qui les y soumet.

Deux conséquences pratiques, et elles vont dans le sens inverse de l’intuition :

• une entreprise française qui héberge vos données chez un fournisseur relevant de la juridiction américaine, ou qui utilise une plateforme américaine pour gérer ses rapports d’audit, vous expose ;
• une entreprise établie dans un autre État membre, sans rattachement américain et sans outil américain dans la chaîne, ne vous expose pas davantage qu’un prestataire français équivalent.

La nationalité de l’enseigne n’est pas le critère. La chaîne de traitement l’est. C’est aussi pour cette raison que la réponse honnête à « êtes-vous exposés au Cloud Act ? » n’est jamais un simple « non », mais la liste des maillons : qui héberge, qui opère, qui accède.

Le mandat écrit : l’autre contrat, celui qui relève du code pénal

Le RGPD encadre les données. Il n’autorise pas le test. Cette autorisation relève d’un texte entièrement distinct : les articles 323-1 et suivants du code pénal, qui répriment l’accès et le maintien frauduleux dans un système de traitement automatisé de données.

Ce qui sépare un test d’intrusion d’une infraction, c’est l’autorisation du responsable du système. Elle doit être écrite, antérieure aux travaux, et porter sur un périmètre défini.

Tous nos tests d’intrusion sont réalisés sur mandat écrit,
dans un périmètre défini contractuellement (articles 323-1 et suivants du code pénal).

Un mandat exploitable contient au minimum :

• l’identification précise du périmètre : domaines, adresses IP, comptes de test, applications, bornes de l’environnement ;
• la fenêtre d’intervention, avec les dates et les plages horaires ;
• les techniques exclues — déni de service, ingénierie sociale non consentie, actions destructives ;
• la procédure d’escalade et le contact joignable pendant toute la fenêtre ;
• la signature d’une personne habilitée à engager l’organisation.

Un point que beaucoup d’entreprises découvrent tard : si votre application est hébergée chez un tiers, vous devez vérifier ce que ses conditions contractuelles prévoient en matière de tests. Vous ne pouvez autoriser que ce dont vous disposez. Un mandat signé par vous ne couvre pas l’infrastructure d’autrui.

Pour les tests qui visent des personnes plutôt que des machines, la question se dédouble : informer les salariés, consulter les instances représentatives et ne jamais rapporter de résultats nominatifs. Nous traitons ce cas séparément dans simulation de phishing, CSE et RGPD.

Où sont conservées les preuves : hébergement, conservation, suppression

C’est la partie que les prestataires décrivent le moins et que les directions juridiques lisent le plus. Un test produit des artefacts : captures d’écran, extraits de bases, jetons, journaux, rapport final. Ce sont ces artefacts, et non le test lui-même, qui constituent le risque résiduel.

Les principes se traduisent en clauses vérifiables.

Ce dernier point mérite une insistance. Un rapport de test circule : il part au comité de direction, parfois à un assureur, parfois à un client qui a exigé la preuve d’un audit. Un rapport truffé de données réelles crée un nouveau traitement, avec ses propres risques, et il vous survit.

Votre autorité de contrôle ne change pas

Une inquiétude fréquente : « si le prestataire est établi ailleurs, qui contrôle ? »

La réponse est rassurante pour un acheteur français. Vous restez responsable du traitement, établi en France, soumis au règlement (UE) 2016/679 et à la loi n° 78-17 du 6 janvier 1978 modifiée. La CNIL reste votre autorité de contrôle, et le recours à un sous-traitant établi dans un autre État membre ne modifie ni vos obligations, ni les droits des personnes concernées, ni la compétence de la CNIL à votre égard.

Ce que cela change, en revanche : le sous-traitant tient son propre registre au titre de l’article 30, relève de sa propre autorité de contrôle pour ses traitements propres, et doit rester mobilisable si vous devez notifier une violation. Cette dernière obligation se contractualise : exigez un délai de réponse chiffré, pas une formule d’assistance générale.

Côté registre, l’ajout est simple. Le prestataire figure comme destinataire dans le traitement concerné, avec sa raison sociale, son État d’établissement et la référence du contrat de sous-traitance. Aucune mention de transfert n’est à porter s’il n’y en a pas.

Quand la souveraineté pèse vraiment

Il serait aussi malhonnête de prétendre que la question de la souveraineté est purement rhétorique. Elle est réelle, mais elle porte sur un périmètre précis, et il vaut mieux le dire clairement que de le contourner.

Les contrôles des systèmes d’information d’importance vitale. Les contrôles ordonnés au titre de l’article L. 1332-6-3 du code de la défense sont réalisés par l’ANSSI, par des services de l’État désignés par le Premier ministre, ou par des prestataires de service qualifiés. Ce n’est pas un argument commercial : c’est le texte.

Les marchés couverts par le secret de la défense nationale. L’habilitation des personnels et des locaux y conditionne l’accès. Aucun contrat de sous-traitance ne remplace une habilitation.

Les marchés qui exigent des prestataires ou un hébergement qualifiés par l’ANSSI. Certains acheteurs publics, et certains acheteurs privés qui s’alignent sur eux, en font une condition de recevabilité. C’est leur droit, et c’est une exigence contractuelle parfaitement licite.

Dans ces trois cas, l’argument RGPD développé plus haut est juste mais inopérant : l’obstacle n’est pas le transfert de données, c’est une exigence de qualification ou d’habilitation.

Pour le reste — un éditeur de logiciel, une ETI industrielle, une PME de services, un programme ISO/IEC 27001, une préparation aux exigences de la directive (UE) 2022/2555 dans le secteur privé — aucune règle française n’impose de qualification pour commander un test d’intrusion. Nous détaillons ce point dans faut-il un prestataire qualifié PASSI pour votre test d’intrusion ?.

Et la directive NIS 2 ?

Elle ne change pas la réponse, et elle mérite une précision d’état.

Au 11 septembre 2026, la directive (UE) 2022/2555 (NIS 2) n’est pas transposée en droit français. Le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité est en cours d’examen parlementaire. Toute obligation, tout délai et tout plafond de sanction que vous lirez à ce sujet doivent donc être attribués à la directive, et non au droit français en vigueur.

Sur le fond, la directive demande aux entités concernées des mesures de gestion des risques et impose des obligations de notification. Elle ne désigne aucun prestataire. L’ANSSI le formule elle-même dans sa foire aux questions consacrée à NIS 2 : « Il peut être pertinent de recourir si besoin aux prestataires ou solutions qualifiés par l’ANSSI mais cela n’est pas une obligation. »

La conduite raisonnable, en attendant la transposition, est de tester ce que vous exploitez déjà — ce travail restera valable quel que soit le texte final. Nous détaillons le calendrier dans NIS 2 en France : où en est la loi Résilience et l’approche technique sur la page préparation à NIS 2.

Dernière vérification : 11 septembre 2026.

Les sept questions à poser avant de signer

Elles remplacent avantageusement la question « êtes-vous français ? », qui ne prédit rien sur le traitement de vos données.

1. Signez-vous un contrat de sous-traitance au titre de l’article 28 ? Demandez le modèle avant l’appel d’offres, pas après.
2. Où sont hébergés les rapports et les preuves ? Un pays, un fournisseur, nommés.
3. Quels sous-traitants ultérieurs interviennent ? Liste nominative annexée, procédure de notification en cas de changement.
4. Y a-t-il un transfert hors Union européenne ? Si oui, quel instrument du chapitre V, et quelle analyse d’impact du transfert.
5. Quelle durée de conservation des preuves, et quelle attestation de suppression ? Une date, pas une intention.
6. Comment réagissez-vous à la découverte d’une violation réelle ? Canal, délai, conservation des traces.
7. Qui réalise concrètement le test ? Des personnes nommées, leurs certifications individuelles, leur employeur. C’est aussi une question de protection des données : l’article 28 exige un engagement de confidentialité des personnes autorisées.

Ces mêmes critères, élargis à la méthodologie et aux livrables, sont réunis dans comment choisir un prestataire de test d’intrusion.

En résumé

Le RGPD ne demande pas que votre prestataire soit français. Il demande que le traitement soit encadré par un contrat, sécurisé, documenté, et qu’aucune donnée ne parte hors de l’Union sans instrument de transfert.

Un prestataire établi dans l’Union européenne satisfait la dernière condition par construction. Les trois autres se vérifient sur pièces, et elles se vérifient exactement de la même façon quel que soit l’État membre d’établissement.

Restent les cas où une qualification ou une habilitation est exigée. Ils existent, ils sont identifiables à l’avance, et nous vous disons quand vous êtes dedans plutôt que de vous faire perdre un tour d’appel d’offres.

Vous préparez un cadrage ? Voyez notre approche du test d’intrusion et de l’audit de sécurité informatique, notre politique de confidentialité et nos mentions légales, ou demandez directement un devis.

Nos services associés : tests d’intrusion sur vos applications et vos infrastructures · audit de sécurité informatique de votre environnement · pentest d’ingénierie sociale et simulations de phishing