Risque lié aux tiers au regard du RGPD, de NIS2 et de DORA

Un même fournisseur peut créer des obligations en matière de protection des données, de cybersécurité et de résilience opérationnelle. Un prestataire de paie traite des données personnelles ; un prestataire de services managés détient des accès à privilèges ; une plateforme cloud soutient des applications critiques pour l'activité. Il arrive qu'un seul fournisseur fasse les trois.

Une fiche fournisseur partagée aide les équipes à coordonner l'évaluation, à condition que chaque obligation reste identifiable. Pour un CTO, la difficulté pratique consiste à relier les engagements contractuels à la réalité technique : à quoi le fournisseur peut accéder, comment les défaillances se propagent, quelles mesures sont prouvées et si l'organisation peut se rétablir ou partir.

Établir l'applicabilité avant de combiner les évaluations

Ces textes se recoupent, mais ils ne s'appliquent pas de la même manière à toutes les organisations ni à tous les fournisseurs.

L'article 28 du RGPD impose aux responsables du traitement de faire appel à des sous-traitants présentant des garanties suffisantes. Un contrat au titre de l'article 28 n'est pas approprié au seul motif qu'un fournisseur reçoit des données : établissez d'abord le rôle réel dans le traitement.

Les articles 20 à 23 de NIS2 traitent de la supervision par les organes de direction, des mesures de gestion des risques et de la notification des incidents importants. NIS2 est une directive transposée en droit national ; son champ d'application et ses procédures exigent donc des vérifications propres à chaque juridiction.

DORA s'applique depuis le 17 janvier 2025. Il couvre principalement certaines entités financières ; les prestataires TIC ordinaires peuvent être confrontés à des exigences contractuelles de leurs clients, tandis que les prestataires TIC critiques désignés relèvent d'un régime de supervision distinct. Pour les entités financières couvertes, DORA constitue un droit de l'Union sectoriel spécifique pour les domaines concernés de NIS2. Ne dupliquez pas automatiquement les deux ensembles de mesures.

Construire la fiche autour de la dépendance

Partez du service, et non du questionnaire fournisseur. Un même fournisseur peut fournir plusieurs services impliquant des données, des accès et une importance opérationnelle différents.

En guise de base pratique, consignez :

• Le service, l'entité juridique du fournisseur, le responsable métier, le responsable technique et les relecteurs.
• Les fonctions, systèmes, intégrations et accès à privilèges concernés.
• Les catégories de données personnelles, les finalités de traitement, les lieux et les sous-traitants ultérieurs.
• Les exigences de disponibilité, les objectifs de rétablissement et la perturbation tolérable.
• Les prestataires sous-jacents, les dépendances contractuelles et les alternatives réalistes.
• Les obligations applicables, les dates des preuves, les lacunes non résolues et les décisions.

Identifiez quelles fonctions cesseraient de fonctionner ou se dégraderaient en cas de compromission ou de panne. Un fournisseur qui stocke peu de données sensibles peut tout de même contrôler l'authentification ou les pipelines de déploiement. À l'inverse, un service présentant un faible risque de disponibilité peut exposer des données personnelles très sensibles.

Gardez ces dimensions séparées au lieu de les réduire à un score « risque élevé » inexpliqué. Pour les entités financières couvertes par DORA, reliez cet inventaire opérationnel au registre d'informations requis sur les accords contractuels portant sur des services TIC ; une liste générique de fournisseurs ne suffit pas nécessairement.

Réutiliser les preuves sans réutiliser aveuglément les conclusions

Un rapport de sécurité, une cartographie des flux de données ou un test de rétablissement peut étayer plusieurs revues. Vérifiez son périmètre de service, sa période de référence, ses exclusions, ses exceptions et les responsabilités incombant au client avant de vous y fier.

Par exemple, un rapport couvrant l'infrastructure du fournisseur ne couvre pas nécessairement l'accès de son personnel de support aux données des clients. Une politique de sauvegarde documentée ne montre pas que la restauration satisfait aux exigences de rétablissement de votre application.

Tenez une matrice reliant les preuves aux questions :

Un certificat ISO ou un rapport SOC 2 étaye l'assurance dans les limites de son périmètre ; aucun des deux n'établit la conformité au RGPD ou à NIS2. Conservez le raisonnement du relecteur, et pas seulement le document téléversé. Évaluer l'assurance de sécurité doit être une revue technique reproductible, et non une vérification de badges.

Traduire les exigences en contrats et en mesures

En vertu de l'article 28 du RGPD, les clauses de sous-traitance doivent préciser l'objet, la durée, la nature et la finalité du traitement, le type de données et les catégories de personnes concernées. Elles couvrent aussi les instructions documentées, la confidentialité, la sécurité, les conditions de sous-traitance ultérieure, l'assistance, la suppression ou la restitution, ainsi que les obligations d'information et d'audit. Les transferts internationaux exigent une évaluation distincte au titre du chapitre V ; l'hébergement dans l'UE ne règle pas à lui seul les questions d'accès ou de transfert ultérieur.

L'article 21 de NIS2 inclut la sécurité de la chaîne d'approvisionnement et la prise en compte des vulnérabilités et des pratiques de cybersécurité des fournisseurs directs. Les attentes contractuelles pratiques peuvent porter sur les restrictions d'accès, la gestion des vulnérabilités, la coopération en cas d'incident et la fourniture de preuves. Adaptez-les au service et aux exigences nationales plutôt que de considérer un ensemble universel de clauses comme juridiquement suffisant.

L'article 30 de DORA précise les dispositions contractuelles relatives aux services TIC, avec des exigences supplémentaires pour les services qui soutiennent des fonctions critiques ou importantes. Examinez la description des services, les lieux, la protection et la récupération des données, l'assistance, la résiliation et les droits de supervision pertinents. Ces fonctions critiques ou importantes exigent une attention particulière aux niveaux de service, au reporting, aux mesures d'urgence, à la coopération aux tests, aux droits d'audit et aux modalités de transition.

Vérifiez ensuite la mise en œuvre. Si un contrat promet un accès d'administration restreint, obtenez la preuve de la séparation des rôles, de l'authentification, de l'approbation et de la journalisation. S'il promet la suppression, établissez ce qu'il advient des sauvegardes et des données conservées. Attribuez les lacunes juridiques et les lacunes techniques aux relecteurs appropriés.

Concevoir les passages de relais en cas d'incident avant l'incident

La politique de réponse aux incidents d'un fournisseur peut étayer une évaluation de sécurité tout en laissant les obligations de notification non résolues. Précisez les canaux de contact, la couverture de l'escalade, les informations initiales, les attentes en matière de mises à jour et la responsabilité de la préservation des preuves.

En vertu des articles 33 et 34 du RGPD, le sous-traitant informe le responsable du traitement dans les meilleurs délais. Le responsable du traitement évalue la notification à l'autorité de contrôle dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, à moins que la violation ne soit pas susceptible d'engendrer un risque pour les droits et libertés des personnes. Un risque élevé peut imposer une communication aux personnes concernées, sous réserve d'exceptions. Consignez le raisonnement lorsque la notification n'est pas requise.

Les étapes de notification prévues par NIS2 au niveau de l'Union pour les incidents importants comprennent une alerte précoce sous 24 heures, une notification sous 72 heures et, en général, un rapport final dans un délai d'un mois après la notification ; vérifiez les règles nationales et sectorielles. DORA dispose de son propre cadre de notification des incidents majeurs liés aux TIC. Ne remplacez pas ces évaluations par un simple indicateur « violation » au niveau du fournisseur.

Recommandation pratique : exercez-vous sur un incident fournisseur avec des informations incomplètes. Vérifiez si les équipes peuvent établir les services touchés, l'exposition, l'impact opérationnel et les décisions de notification sans attendre un rapport définitif sur la cause première.

Exemple détaillé : un service, trois circuits de revue

Supposons, à titre d'illustration, qu'une entité financière couverte utilise une plateforme de support client hébergée qui traite des données personnelles et soutient une fonction qu'elle a classée comme critique ou importante au titre de DORA.

Le fournisseur fournit un rapport d'assurance, une politique de gestion des incidents et une synthèse de test de rétablissement. La sécurité constate que les contrôles des accès d'administration sont prouvés, mais que le test de rétablissement exclut l'intégration du client.

La protection des données relève, de son côté, un processus de changement de sous-traitants ultérieurs peu clair et des dispositifs de transfert non résolus pour les accès à distance. La revue DORA conclut que l'assistance à la transition et les clauses d'audit pertinentes doivent être revues.

Le plan d'action qui en résulte est précis :

• Le responsable technique teste le rétablissement de l'intégration et documente le résultat.
• Le relecteur protection des données résout les questions de sous-traitance ultérieure et de transferts.
• Le service juridique et les achats traitent les lacunes contractuelles.
• Le responsable désigné décide si un usage temporaire est acceptable, avec des conditions et une date de réexamen.

Les preuves sont réutilisées, mais aucune des trois conclusions n'est déduite d'une autre. Une revue de sécurité réussie ne referme pas les lacunes en matière de protection des données ou de résilience.

Surveiller les changements, la concentration et la faisabilité de la sortie

Fixez la fréquence des revues en fonction de la dépendance et du risque. Déclenchez une revue supplémentaire après des incidents, des changements majeurs du service, de nouveaux sous-traitants ultérieurs, des changements de localisation des données, des changements d'actionnariat ou un renouvellement de contrat.

Regardez au-delà des noms des fournisseurs : plusieurs services peuvent dépendre de la même région cloud, du même fournisseur d'identité ou du même sous-traitant. Évaluez les perturbations corrélées et si l'alternative proposée partage cette dépendance. L'article 29 de DORA traite explicitement de l'évaluation du risque de concentration lié aux TIC.

Tenez un plan de sortie proportionné couvrant l'export des données, la migration, la continuité, la révocation des accès et les preuves de suppression. Testez l'exploitabilité de l'export et identifiez qui peut exploiter la solution de remplacement. Un droit de résiliation est plus utile lorsque l'organisation est en mesure de l'exercer.

Les conséquences diffèrent également. Le RGPD prévoit des plafonds de sanction selon le type de manquement ; NIS2 impose des régimes de sanctions nationaux avec des plafonds différents pour les entités essentielles et les entités importantes. Les sanctions prévues par DORA pour les entités financières dépendent des dispositifs applicables, tandis que les sanctions liées à la supervision des prestataires critiques sont distinctes. Ne modélisez pas l'exposition à partir d'une prétendue amende universelle.

Commencer par une dépendance lourde de conséquences

Choisissez un fournisseur qui soutient une fonction importante. Rapprochez son inventaire de services, ses contrats, ses preuves, ses risques ouverts et ses hypothèses de sortie. Terminez avec des responsables désignés et des conclusions distinctes et datées pour chaque obligation applicable.

Dans Secani, les équipes peuvent modéliser le service et le prestataire externe, relier les exigences et les mesures aux preuves, et suivre les lacunes sous forme de tâches assorties de responsables. Les décisions examinées par des personnes, les liens vers les sources, les commentaires et les horodatages préservent le raisonnement. Cela permet un contexte fournisseur partagé sans masquer les jugements distincts en matière de protection des données, de sécurité et de résilience.