Fuite de données chez un sous-traitant : RGPD art. 28 et contrôles

Une fuite de données chez un sous-traitant est une exfiltration de vos données depuis un système que vous ne contrôlez pas directement : celui d’un prestataire, d’un éditeur SaaS ou d’une intégration connectée à votre SI. Au sens du RGPD, vous restez responsable du traitement, même si l’incident se produit chez le tiers. La seule réponse sérieuse combine des garanties contractuelles (article 28) et des vérifications techniques sur ce qui sort réellement de chez vous vers ce tiers.

Pourquoi le tiers est devenu le chemin de fuite le plus probable

Vos données ne vivent plus seulement dans votre SI. Elles transitent par un infogéreur, un outil de paie, un CRM en SaaS, un prestataire de support qui accède à vos postes à distance, un connecteur qui synchronise votre messagerie avec une application tierce. Chacun de ces flux est un canal de sortie légitime. C’est précisément ce qui le rend dangereux : vos contrôles sont réglés pour le laisser passer.

Trois situations reviennent sans cesse :

• Le tiers est compromis et l’attaquant récupère les données que vous lui avez confiées, ou utilise ses accès pour entrer chez vous.
• Le flux vers le tiers est trop large : on envoie toute une base alors que le prestataire n’avait besoin que de trois colonnes.
• L’intégration est oubliée : un jeton d’API créé pour un projet terminé fonctionne toujours, avec des droits de lecture étendus.

Ce que le RGPD exige vraiment de vous et du sous-traitant

L’article 28 du RGPD encadre la relation avec le sous-traitant. Il impose au responsable de traitement de ne recourir qu’à des sous-traitants présentant des garanties suffisantes quant à la mise en œuvre de mesures techniques et organisationnelles appropriées. Il exige un contrat (ou un autre acte juridique) qui fixe notamment :

• le traitement uniquement sur instruction documentée du responsable ;
• la confidentialité des personnes autorisées à traiter les données ;
• la mise en œuvre des mesures de sécurité prévues à l’article 32 ;
• l’autorisation écrite préalable avant tout recours à un sous-traitant ultérieur, avec les mêmes obligations répercutées ;
• l’aide apportée au responsable pour respecter ses propres obligations, dont la notification des violations ;
• la mise à disposition des informations nécessaires pour démontrer la conformité, et la possibilité d’audits et d’inspections.

L’article 33 ajoute une obligation directe pour le sous-traitant : notifier au responsable toute violation de données personnelles dans les meilleurs délais après en avoir pris connaissance. Le responsable, lui, dispose en principe de 72 heures pour notifier la CNIL. Concrètement, ce délai commence à courir chez vous. Si votre prestataire met une semaine à vous prévenir, c’est votre gestion de crise qui en paie le prix. La Commission européenne a publié des clauses contractuelles types pour cette relation (décision d’exécution 2021/915), et la CNIL propose un guide du sous-traitant et un exemple de clauses.

Les vérifications contractuelles à ne pas oublier

Au-delà du socle de l’article 28, quelques clauses font la différence le jour d’un incident :

Faites défiler le tableau →

Les vérifications techniques : ce qui se contrôle de votre côté

Vous n’avez pas la main sur le SI du prestataire. Vous avez la main sur ce que vous lui envoyez et sur les accès que vous lui donnez. C’est là que se joue l’essentiel.

Cartographier les flux sortants vers les tiers

Listez chaque destination externe qui reçoit des données : domaines SaaS, serveurs SFTP de partenaires, API, boîtes e-mail de prestataires. Pour chacune, notez le type de données attendu. Sans cette liste, aucune règle DLP ne peut distinguer un flux légitime d’une fuite. La classification des données conditionne directement ce travail.

Réduire les intégrations et les jetons

• Inventoriez les applications OAuth autorisées sur votre messagerie et vos espaces collaboratifs.
• Supprimez les jetons d’API orphelins et limitez les droits au strict besoin.
• Exigez des comptes nominatifs et une authentification forte pour les accès distants des prestataires.

Vérifier que vos contrôles bloquent ce qui ne doit pas partir

Un flux autorisé vers un tiers ne doit pas devenir un tunnel universel. Si votre DLP laisse passer toute donnée vers le domaine du prestataire, un attaquant qui contrôle un compte chez ce prestataire, ou un domaine proche, profite de la même tolérance. Les mêmes questions se posent pour les contrôles CASB et DLP sur les applications SaaS : la règle couvre-t-elle l’instance d’entreprise seulement, ou toute instance du même éditeur ?

Scénario concret : le prestataire de paie

Une ETI externalise sa paie. Chaque mois, un export RH part vers la plateforme du prestataire. Le contrat est conforme à l’article 28. La DLP autorise le domaine du prestataire pour les fichiers RH.

Trois questions suffisent à mesurer l’exposition réelle. L’export contient-il des colonnes inutiles, comme le numéro de sécurité sociale des ayants droit ? Un fichier RH envoyé vers un autre domaine, ou vers une instance personnelle du même service, est-il bloqué ? Le SOC voit-il un envoi inhabituel par son volume ou son horaire ? Si vous ne pouvez pas répondre avec une preuve, vous ne savez pas. Rejouer ces scénarios avec des données factices en production permet d’obtenir la réponse sans exposer un seul bulletin réel.

Points de contrôle pour votre prochain comité fournisseurs

1. Les sous-traitants qui traitent des données sensibles sont identifiés et classés par criticité.
2. Chaque contrat critique contient un délai de notification chiffré.
3. La liste des sous-traitants ultérieurs a été revue dans l’année.
4. Les flux sortants vers chaque tiers critique sont documentés et minimisés.
5. Les intégrations et jetons inutilisés ont été révoqués.
6. Un test actif a vérifié que les données sensibles ne sortent que vers les destinations prévues.
7. La procédure de réponse à incident prévoit le cas d’une fuite chez un tiers.

Ce dernier point est souvent oublié. Le jour où le prestataire appelle, vous devez savoir qui décide, qui collecte les faits et qui prépare la notification. Voir notre article sur les 24 premières heures de la réponse à incident.

FAQ