Réponse succincte
Les sous-traitements ne constituent pas une catégorie à part entière du RGPD. Ce terme désigne ici un principe structurel organisationnel et technique dans le registre des activités de traitement : un traitement de base central constitue le cœur commun d’un processus. Les variantes locales ou spécifiques à un cas d’utilisation sont répertoriées comme des déclinaisons subordonnées de ce traitement de base.
Un tel modèle peut s'avérer particulièrement pertinent pour les groupes. De nombreux processus sont mis en œuvre de manière similaire dans plusieurs sociétés, pays ou sites, mais présentent toutefois des différences sur certains points. Dans ces conditions, des copies non reliées entre elles peuvent entraîner des incohérences. Un traitement de base associé à des sous-traitements permet en revanche de relier entre eux les normes communes, les écarts locaux, les responsabilités, les validations, les versions, les statuts et la mise hors service des variantes qui ne sont plus nécessaires.
Écarts locaux dans le RoPA du groupe
Au sein des groupes, de nombreuses activités de traitement sont menées de manière similaire dans plusieurs sociétés ou sur plusieurs sites. Cela concerne par exemple les processus RH, la gestion des candidatures, la gestion de la relation client (CRM), la communication avec les locataires, les processus liés aux installations, la gestion des fournisseurs, l'enregistrement des visiteurs, la gestion des formations, l'assistance informatique, la gestion du parc automobile, les systèmes d'alerte et les processus marketing.
Le cœur commun des processus est souvent similaire. Toutefois, un examen plus approfondi peut révéler des différences considérables. Une entreprise fait appel à un prestataire local, tandis qu’une autre recourt à un prestataire utilisé à l’échelle du groupe. Sur certains sites, des données supplémentaires sont traitées ou d’autres destinataires sont impliqués. Les délais de conservation peuvent varier d’une société à l’autre en fonction des exigences locales. De même, la définition des finalités, les applications utilisées, les bases juridiques ou les processus de validation internes ne sont pas nécessairement identiques dans toutes les sociétés.
Chacune de ces dérogations n'implique pas nécessairement une activité de traitement totalement distincte. Elle doit toutefois être documentée de manière structurée, afin que la norme commune et la spécificité locale correspondante restent compréhensibles.
Dans la pratique, on copie souvent un traitement existant, puis on l'adapte à la société ou au site concerné. Cette approche permet dans un premier temps de réduire la charge de travail liée à la documentation. Cependant, à mesure que le nombre de copies augmente, il devient plus difficile d'identifier le lien entre le processus d'origine et les variantes locales, et de les gérer à long terme.
Risques liés aux copies RoPA non associées
Il est généralement possible de créer rapidement une copie d'une activité de traitement existante. L'entrée existante est reprise et adaptée aux spécificités locales dans certains champs. Cette procédure peut toutefois poser problème dès lors que la description centrale ou une autre spécification commune est modifiée.
Une copie non liée ne contient généralement aucune information fiable permettant de déterminer sur quel processus de base elle repose. Si, par exemple, une catégorie de données centrale est modifiée, il faut d’abord déterminer quelles entrées locales sont concernées par cette modification. Il en va de même en cas de changement de prestataire de services, d’ajustement d’un délai de suppression, de modifications apportées aux mesures techniques et organisationnelles ou de révision d’une description de processus central.
Lorsqu'il existe de nombreuses copies similaires, il peut devenir difficile, avec le temps, de déterminer quelle entrée correspond à la norme à l'échelle du groupe et quelles entrées ne contiennent que des écarts locaux. Cela ne pose pas seulement un problème de documentation. Le pilotage, la mise à jour, le reporting et la conservation des justificatifs sont notamment concernés.
Conformément à l'article 30 du RGPD, le registre des activités de traitement doit notamment contenir des informations sur les finalités du traitement, les catégories de personnes concernées et de données à caractère personnel, les destinataires, les transferts éventuels vers des pays tiers, les délais d’effacement prévus et, dans la mesure du possible, une description générale des mesures techniques et organisationnelles. Le registre doit être tenu par écrit, un format électronique étant également autorisé, et mis à la disposition de l’autorité de contrôle compétente sur demande.
Dans ce contexte, ce n’est pas seulement l’exhaustivité des différentes entrées qui importe, mais aussi la structure du répertoire. Si plusieurs copies décrivent le même processus de manière divergente, il peut s’avérer difficile de présenter de manière claire et compréhensible l’état actuel des choses à la direction, aux délégués à la protection des données ou aux autorités de contrôle.
Notion de « sous-traitance » dans le RoPA
Dans cet article, le terme „ sous-traitance “ est délibérément utilisé dans un sens opérationnel. Il ne s’agit ni d’une sous-traitance confiée à un autre sous-traitant, ni d’une nouvelle catégorie juridique du RGPD.
Un « sous-traitement » désigne plutôt une variante subordonnée d'un traitement principal au sein du répertoire des activités de traitement.
Le traitement des données de base décrit notamment le cœur commun du processus :
- l'objectif général,
- le processus principal,
- les groupes de personnes régulièrement concernés,
- catégories de données typiques,
- systèmes centraux,
- Destinataire par défaut,
- prestataires de services typiques,
- mesures techniques et organisationnelles fondamentales,
- la logique de suppression par défaut,
- risques principaux,
- les responsabilités principales ainsi que
- tests standard prévus et validations.
Le sous-traitement, en revanche, correspond à un écart contrôlé par rapport à la norme commune. Il peut notamment concerner :
- une société locale,
- un site,
- un pays donné,
- un département,
- un cas d'utilisation supplémentaire,
- un autre prestataire,
- une catégorie de données supplémentaire,
- une autre durée de conservation locale,
- un destinataire supplémentaire,
- une étape locale du processus,
- un statut différent,
- un partage local ou
- une mesure locale complémentaire.
Au lieu de disposer de plusieurs copies indépendantes les unes des autres, on obtient ainsi un traitement de référence auquel sont associées, de manière traçable, les variantes locales ou spécifiques à chaque cas d'utilisation.
Exemple : gestion des candidatures au sein d'un groupe
En matière de gestion des candidatures, le cœur du processus est similaire dans de nombreuses entreprises. Les candidatures sont reçues, examinées, validées avec les services concernés, documentées, puis supprimées à l'expiration des délais applicables. Les candidats sont concernés par ce processus. Les données généralement traitées comprennent les coordonnées, les informations issues des CV, les justificatifs de qualification, les notes d’entretien et les données de communication. Ce processus implique généralement un système de gestion des candidatures, le service des ressources humaines, les services opérationnels concernés et, le cas échéant, des prestataires externes.
Ce tronc commun peut être documenté dans un traitement de base. Sa mise en œuvre concrète peut toutefois varier d'une société à l'autre.
Ainsi, une société allemande peut utiliser le système central de gestion des candidatures, tandis qu'en France, un prestataire local est également impliqué. Aux États-Unis, une autre plateforme d'entretien peut être utilisée. Une société conserve certains documents plus longtemps en raison des exigences locales en matière de droit du travail. Une unité opérationnelle collecte des documents supplémentaires relatifs au portefeuille. Sur un site donné, des contrôles de sécurité sont effectués pour certains postes. Dans un pays, les obligations d’information sont différentes, tandis que dans une autre entreprise, une procédure impliquant le comité d’entreprise est également prévue.
Ces différences ne justifient pas systématiquement la mise en place de dix opérations de traitement totalement distinctes. Dans la mesure où le cœur commun du processus reste valable, elles peuvent être gérées comme des variantes du traitement de base. Le fait de les classer comme sous-opérations de traitement permet de distinguer clairement les informations applicables à l’ensemble du groupe et les points sur lesquels il existe des écarts locaux.
| Question d'évaluation | Copie non associée | Traitement de base avec sous-traitement |
|---|---|---|
| Noyau commun du processus | C'est décrit à plusieurs reprises. | Cette donnée est gérée une seule fois dans le traitement des données de base. |
| Écart local | Souvent, cela n'est visible que sur la copie. | Elle est expressément documentée en tant que variante. |
| Modifications apportées à la norme | Ils doivent être répercutés individuellement dans les copies concernées. | Ils peuvent être gérés de manière centralisée et vérifiés pour les différentes variantes. |
| Responsabilité locale | Cette information est souvent imprécise ou ne figure que dans des champs de texte libre. | Peut être attribué à un rôle local spécifique ou à un propriétaire. |
| Rapports | Cela nécessite la consolidation a posteriori de plusieurs entrées. | Les variantes restent associées au processus de base correspondant. |
| aptitude à l'audit | L'historique et les décisions sont répartis sur plusieurs entrées. | Les écarts, les contrôles et les validations restent liés les uns aux autres. |
| Désactivation et archivage | Il arrive souvent que des copies qui ne sont plus utilisées subsistent. | Les variantes peuvent être désactivées ou archivées de manière ciblée. |
| point de vue de la direction | Affiche de nombreuses entrées similaires sans classification supérieure. | Représente un processus commun avec des caractéristiques contrôlées. |
Les sous-traitements ne visent donc pas à réduire le volume de documentation requis. Ils ont pour but de structurer la documentation de manière à ce que les normes communes et les particularités locales restent gérables.
Héritage et gestion locale des champs
Il n'est pas nécessaire de saisir à nouveau toutes les données relatives à une activité de traitement dans chaque variante locale. Lorsque les processus sont comparables à l'échelle du groupe, il peut s'avérer judicieux de reprendre certaines informations issues du traitement des données de base. D'autres données devraient pouvoir être complétées, vérifiées ou remplacées au niveau local.
| Groupe de champs | Traitement classique | Exposé des motifs |
|---|---|---|
| Nom du processus et objectif principal | Héritage centralisé | Favorise une structure homogène et une meilleure reconnaissance. |
| Description du processus standard | Héritage centralisé | Évite les copies divergentes d'une même description. |
| Catégories de données standard | Hériter et compléter localement | Les catégories de données locales supplémentaires doivent rester identifiables. |
| Groupes concernés | Hériter et compléter localement | Ces groupes sont souvent comparables, mais pas nécessairement tout à fait identiques. |
| Système centralisé | Héritage centralisé | Les systèmes utilisés à l'échelle du groupe n'ont pas besoin d'être mis à jour plusieurs fois. |
| Systèmes locaux | Compléter localement | Toute utilisation différente doit être expressément documentée. |
| prestataire de services standard | Héritage centralisé | Évite la saisie multiple des mêmes informations concernant le prestataire. |
| Prestataires de services locaux | Compléter localement | Cela peut avoir une incidence sur le traitement des commandes, les transferts vers des pays tiers et les risques. |
| Bases juridiques | Reprendre partiellement et vérifier localement | Certaines particularités locales peuvent nécessiter une évaluation distincte. |
| Délais de suppression | Hériter et permettre la réécriture locale | Il doit être possible de refléter les différences nationales ou organisationnelles. |
| Mesures techniques et organisationnelles | Hériter et compléter localement | Les mesures prises au niveau central peuvent être complétées par des dispositions locales. |
| Risques | Associer les risques centraux et locaux | Il convient de distinguer les situations de risque à l'échelle du groupe de celles au niveau local. |
| Propriétaire | Attribuer localement | La responsabilité opérationnelle doit être clairement définie pour chaque variante. |
| Validation | Au niveau local ou central, selon le processus | Le statut de validation peut varier d'une variante à l'autre. |
| Statut | Gérer localement | Une variante peut être active, planifiée, désactivée ou archivée. |
| Date de révision | Définir localement ou de manière centralisée | Les compétences dépendent du profil de risque et du modèle organisationnel. |
L'important n'est pas de centraliser le plus grand nombre possible de champs. Il s'agit plutôt de déterminer quelles données constituent réellement une norme contraignante et quelles informations nécessitent un contrôle et une gestion au niveau local.
Exigences relatives aux variantes locales
Les variantes locales ne doivent pas être gérées comme des copies librement modifiables. Il faut plutôt mettre en place une structure permettant de retracer le lien avec le traitement de base, la divergence concrète et la responsabilité qui en découle.
Un traitement secondaire devrait donc au moins permettre de mettre en évidence :
- sur quelle mise en œuvre de base elle repose,
- quelle que soit la société, le site ou le département concerné,
- quels champs s'écartent de la norme applicable à l'ensemble du groupe,
- la raison pour laquelle cette dérogation est nécessaire,
- celui qui a vérifié l'écart,
- qui a donné son accord,
- quels risques supplémentaires peuvent découler de cet écart,
- quelles mesures locales sont prévues,
- à quel moment un nouveau réexamen doit avoir lieu et
- que la variante soit planifiée, en cours d'examen, active, désactivée ou archivée.
Sans ces informations, on court le risque de se retrouver simplement avec une copie supplémentaire portant une désignation différente. Ce n’est qu’une fois l’affectation, la justification et la validation documentées que cette divergence locale devient un objet de gouvernance pouvant être piloté.
Écarts spécifiques à chaque cas d'utilisation
Toutes les variantes ne sont pas nécessairement liées à un pays, une entreprise ou un site en particulier. Des différences peuvent également résulter d'un cas d'utilisation spécifique.
Un processus CRM peut, par exemple, servir de référence pour le service client. Une unité opérationnelle utilise ce même processus pour un programme d'événements, tandis qu'une autre unité s'en sert pour communiquer avec ses partenaires. Sur un site donné, une source de données supplémentaire peut être exploitée. Une équipe de projet peut compléter le processus existant par des fonctions d'analyse.
Dans de tels cas, il convient de vérifier s’il s’agit toujours d’une composante du processus de base existant ou s’il y a lieu de documenter une activité de traitement distincte. Les éléments déterminants sont notamment la finalité, les données traitées, les destinataires, le niveau de risque et la responsabilité organisationnelle.
Il ne serait donc ni approprié de classer automatiquement chaque divergence comme un sous-traitement, ni de reproduire chaque particularité à l'aide d'une copie entièrement nouvelle et sans lien avec le processus initial. Ce qui est déterminant, c'est de savoir si le noyau commun du processus reste valable et si la divergence peut être décrite, vérifiée et validée de manière suffisamment précise.
Distinction par rapport à l'activité de transformation indépendante
Les sous-traitements ne doivent pas avoir pour effet de masquer des différences substantielles entre les activités de traitement. Un traitement autonome peut notamment être envisagé lorsque :
- si l'objectif diffère sensiblement,
- que d'autres groupes concernés soient associés,
- des catégories de données supplémentaires présentant un risque plus élevé soient traitées,
- si un autre système ou un autre prestataire modifie considérablement la situation en matière de risques,
- d'autres destinataires soient intégrés ou
- la variante locale constitue, sur le plan organisationnel, un processus à part entière.
Si un système RH standard est utilisé pour la gestion des candidatures, mais qu’une société locale l’utilise en outre pour effectuer des évaluations automatisées de l’aptitude à l’aide de l’IA, cela peut, selon la configuration concrète, aller au-delà d’une simple divergence mineure. Dans un tel cas, une activité de traitement autonome ou, à tout le moins, un sous-traitement clairement délimité, assorti d’une évaluation des risques distincte et d’une autorisation spécifique, peut s’avérer nécessaire.
C'est donc la délimitation technique qui est déterminante. La simplification administrative ne peut à elle seule être déterminante pour décider s'il s'agit d'une variante ou d'une activité de traitement autonome.
Validation des écarts locaux
Une variante locale ne doit pas être mise en production sans avoir fait l'objet d'un contrôle documenté. Le processus de validation requis ne doit pas nécessairement être très complexe, mais il doit prévoir des responsabilités et des étapes de contrôle clairement définies.
Un déroulement type peut comporter les étapes suivantes :
- C'est le propriétaire local qui demande la dérogation.
- Le système indique les champs qui s'écartent de la configuration standard.
- Le responsable de la protection des données compétent vérifie la pertinence au regard de la législation sur la protection des données.
- Si nécessaire, le service juridique, le service de sécurité informatique, le délégué à la protection des données ou d'autres services compétents seront associés.
- Les risques identifiés et les mesures à prendre sont consignés par écrit.
- La variante est validée, validée sous certaines conditions ou renvoyée pour révision.
- Un statut et une date de révision sont attribués à la variante.
- L'écart reste lié au traitement de base correspondant.
De cette manière, on ne se contente pas de documenter une modification apportée à l'enregistrement. On peut également retracer sur quelle base l'écart a été vérifié et validé.
Modèle d'état pour les sous-traitements
Les sous-traitements devraient disposer de leur propre statut. Sans un tel modèle de statut, il est impossible de déterminer de manière fiable si une variante est simplement en cours de préparation, si elle a déjà été vérifiée, si elle est utilisée en production ou si elle n'est plus utilisée.
| Statut | Signification |
|---|---|
| Projet | La variante est en cours de préparation et n'est pas encore valide. |
| En cours d'examen | Protection des données, le service juridique ou d'autres services compétents examinent l'écart. |
| Retourné | Certaines informations manquent ou la divergence n'est pas suffisamment justifiée. |
| Validé | Cette variante est active et peut être utilisée. |
| Approuvé sous certaines conditions | Cette variante est active, mais elle est soumise à certaines mesures ou à certains délais. |
| En cours de révision | La variante est réévaluée. |
| Désactivé | Cette variante n'est plus utilisée, mais reste compréhensible. |
| Archivé | Cette variante présente un intérêt historique, mais n'est plus utilisée dans la pratique. |
| Supprimé | Cette variante peut être supprimée, à condition qu'aucune obligation légale ou technique de justification ne s'y oppose. |
Un RoPA de groupe peut perdre en clarté non seulement en raison de l'ajout continu de nouvelles entrées, mais aussi à cause des variantes qui ne sont plus nécessaires sur le plan opérationnel et dont le statut n'a pas été mis à jour. Un modèle de statut clair est donc indispensable pour la mise à jour régulière du répertoire.
Désactivation, archivage et suppression
Les variantes qui ne sont plus d'actualité ne devraient pas être conservées indéfiniment en tant qu'opérations de traitement actives. Toutefois, leur suppression immédiate n'est pas non plus toujours appropriée.
Il convient tout d'abord de vérifier si la variante en question a effectivement été utilisée dans le cadre de l'exploitation. Si elle n'a jamais été utilisée, sa suppression peut être envisagée, à condition qu'il n'existe ni obligation légale de conservation ni raison interne justifiant de la conserver plus longtemps.
En revanche, si la variante a été utilisée en production, il est généralement préférable de la désactiver ou de l'archiver. De cette manière, il est possible de retracer si la variante a existé et pendant quelle période, quand elle a été supprimée, quelles données étaient concernées, quels délais de suppression doivent encore être pris en compte et quelles décisions ont été prises concernant son traitement.
Il convient notamment d'envisager un contrôle du traitement en sous-traitance lorsque :
- si la société en question n'utilise plus le processus,
- le système utilisé a été mis hors service,
- lorsqu'un prestataire a été changé,
- l'objet n'existant plus,
- le cas d'utilisation sous-jacent a été clôturé,
- une dérogation jusqu'alors locale a été intégrée dans la norme applicable à l'ensemble du groupe,
- la variante a été remplacée par une nouvelle variante ou
- une structure obsolète a été constatée dans le cadre d'un audit.
La désactivation s'inscrit donc dans le cadre de la gouvernance et ne constitue pas simplement une mesure visant à mettre de l'ordre dans le répertoire d'un point de vue formel.
Exigences en matière de reporting
Pour un délégué à la protection des données du groupe ou une fonction centrale chargée de la protection des données, une liste répertoriant de nombreuses activités de traitement quasi identiques n’a généralement qu’une valeur informative limitée. Il est au contraire nécessaire de disposer d’une analyse qui mette en évidence :
- quels sont les processus standardisés à l'échelle du groupe,
- quelles sociétés ou quels sites s'écartent de la norme,
- quels écarts présentent un risque accru,
- les variantes qui n'ont pas encore été validées,
- pour quelles variantes des mesures locales s'imposent depuis longtemps,
- quelles entrées sont obsolètes et
- quelles divergences locales devraient, le cas échéant, être intégrées dans la norme applicable à l'ensemble du groupe.
Un rapport sur la gestion des candidats ne devrait donc pas se contenter de présenter côte à côte plusieurs opérations de traitement sans lien entre elles. Il devrait présenter le processus de base, les variantes actives, les écarts respectifs, le statut de risque et de validation, les révisions en retard, les mesures en suspens, les variantes expirées et les sociétés ne faisant pas l'objet d'un contrôle en cours.
Un tel reporting suppose que le traitement des données de base et celui des variantes soient reliés de manière structurée. Ce n'est qu'alors que le RoPA peut être utilisé comme outil de pilotage, au-delà de la simple documentation.
Lien avec l'article 30 du RGPD
L'article 30 du RGPD impose aux responsables du traitement de tenir un registre des activités de traitement relevant de leur responsabilité. Les sous-traitants doivent tenir un registre des catégories d'activités de traitement qu'ils effectuent pour le compte d'un responsable du traitement. Chaque registre doit être mis à la disposition de l'autorité de contrôle sur demande.
Le RGPD n'impose toutefois aucun modèle technique de données particulier. En particulier, il ne ressort pas de l'article 30 du RGPD que chaque divergence locale doive impérativement être consignée sous la forme d'une entrée totalement isolée. De même, la réglementation n'exige pas que des processus similaires soient documentés au moyen de copies sans lien entre elles.
Il est essentiel que les informations réellement pertinentes soient exactes, compréhensibles et disponibles. L'EDPB décrit le registre comme un inventaire des opérations de traitement, permettant d'identifier les responsabilités et les risques potentiels. Parmi les informations essentielles figurent notamment la finalité, les catégories de données, les destinataires, les transferts éventuels, les délais de conservation ou de suppression et les mesures de sécurité prévues.
Les sous-traitances ne remplacent donc pas les exigences de l’article 30 du RGPD. Elles constituent plutôt un modèle organisationnel possible permettant de présenter de manière structurée les informations requises au sein de structures de groupe complexes.
Soutien apporté par Ailance RoPA
Ailance RoPA peut représenter les processus du groupe sous forme de traitements de données de base interconnectés et de variantes locales ou spécifiques à des cas d'utilisation. Le traitement central des données de base décrit ici la norme commune. Des sous-traitements subordonnés prennent en compte les particularités respectives.
Les champs peuvent être repris depuis le traitement des données de base, complétés localement ou remplacés de manière contrôlée. Les écarts restent ainsi identifiables. Les responsabilités, les validations, les mesures, les informations de statut et les dates de révision peuvent être affectées à la variante correspondante.
En matière de pilotage, il convient notamment de distinguer trois niveaux :
Par défaut
Quelles sont les informations applicables à l'échelle du groupe pour ce processus commun ?
Variante
Quelles sont les informations qui diffèrent pour une société donnée, un site ou un cas d'utilisation particulier ?
Justificatif
Qui a vérifié, validé, modifié, réévalué ou désactivé cet écart ?
Cette distinction est particulièrement importante pour les grandes organisations comptant de nombreux processus similaires. Les problèmes rencontrés dans le RoPA ne sont souvent pas uniquement dus à des entrées manquantes, mais aussi à l'absence de structure claire entre des entrées similaires.
Exemple : communication avec les locataires
Un groupe immobilier mène une opération de traitement des données à des fins de communication avec les locataires. Le traitement des données de base peut notamment contenir les informations suivantes :
- Communication avec les locataires,
- Données de base,
- Coordonnées,
- Référence au contrat,
- Traitement des demandes,
- Utilisation d'un système CRM centralisé,
- un délai d'effacement standard,
- Destinataires par défaut et
- mesures techniques et organisationnelles centrales.
Au niveau local, il peut exister différentes variantes. Une société fait également appel à un centre de services local. Sur un site donné, un autre outil de communication est utilisé. Dans une région, des informations spécifiques relatives aux sinistres sont traitées. Une société fait appel à un prestataire d'impression externe, tandis qu'une autre exploite sa propre application destinée aux locataires.
Ces particularités peuvent être documentées soit en tant qu’opérations de traitement autonomes, soit en tant que sous-opérations de traitement clairement délimitées. Dans la mesure où le cœur commun du processus subsiste, le rattachement au traitement de base permet une présentation plus claire de la norme à l’échelle du groupe et des écarts locaux respectifs.
Exemple : processus liés aux installations
En raison de leur nature spécifique à chaque site, les processus de gestion des installations sont particulièrement susceptibles de générer de nombreuses entrées similaires. Il s'agit notamment de l'enregistrement des visiteurs, du contrôle d'accès, de la vidéosurveillance, de la gestion des clés, de la gestion des parkings, de la coordination du nettoyage et des demandes de réparation.
De nombreux sites mettent en œuvre ces processus de manière similaire. Leur organisation concrète peut toutefois varier considérablement d'un site à l'autre. Un site utilise la vidéosurveillance, un autre non. Certains sites font appel à des prestataires locaux, traitent les numéros d'immatriculation, tiennent des registres d'accès supplémentaires ou utilisent une application spécifique. D'autres sites continuent de travailler avec des listes manuelles.
Les sous-traitements peuvent contribuer à mettre en évidence ces variantes de site, sans pour autant fragmenter le processus commun de gestion des installations en une multitude d'enregistrements sans lien entre eux. Le pilotage central peut ainsi identifier clairement quelles directives font partie du processus standard et sur quels sites des écarts par rapport à celui-ci sont constatés, ainsi que les raisons de ces écarts.
Exemple : CRM
Les processus CRM s'appliquent généralement à l'échelle du groupe. Le traitement des données de base peut désigner la gestion des clients et des prospects. Les variantes locales peuvent notamment refléter différentes autorisations de marketing, des campagnes locales, des sources de données supplémentaires, des destinataires spécifiques, des logiques de suppression différentes ou diverses formes d'utilisation du système.
Dans le cadre des processus CRM notamment, l'existence de copies non reliées entre elles comporte le risque de données contradictoires concernant les finalités, les destinataires, les bases juridiques et les délais de suppression. En revanche, un traitement principal associé à des sous-traitements permet d’identifier quelles informations s’appliquent à l’échelle du groupe et quelles particularités locales ou spécifiques à un cas d’utilisation ont été vérifiées et validées.
Questions de vérification concernant les RoPA existants du groupe
Pour dresser un premier état des lieux, on peut choisir un processus présent dans plusieurs sociétés ou sur plusieurs sites. On peut citer, par exemple, la gestion des candidatures, la gestion de la relation client (CRM), la communication avec les locataires, la gestion des installations, la gestion des fournisseurs, l'enregistrement des visiteurs, la gestion des formations ou l'assistance informatique.
Il convient ensuite d'examiner en particulier les questions suivantes :
- Existe-t-il un processus de base clairement défini ?
- Quelles sont les variantes locales ou spécifiques à certains cas d'utilisation ?
- Ces divergences sont-elles expressément consignées ou figurent-elles simplement dans des copies indépendantes les unes des autres ?
- Qui a vérifié et validé ces écarts ?
- Quelles variantes ne sont plus utilisées sur le plan opérationnel ?
Si ces questions ne trouvent pas de réponse évidente, cela ne signifie généralement pas que le nombre d'opérations de traitement est trop faible. Il peut plutôt s'agir d'un manque de cohérence entre les entrées existantes.
Conclusion
Les sous-traitements peuvent constituer un modèle structurel adapté aux RoPA du groupe lorsque des processus comparables sont mis en œuvre dans plusieurs sociétés, pays ou sites, sans pour autant être identiques dans tous leurs détails.
Les copies non reliées peuvent dans un premier temps être créées sans trop d'efforts. Cependant, à mesure que leur nombre augmente, elles peuvent entraîner des informations contradictoires, un flou quant aux responsabilités, des mises à jour plus difficiles et une capacité d'analyse limitée. En revanche, un traitement des données de référence, avec des variantes locales ou spécifiques à des cas d’utilisation, permet de mettre en évidence les informations qui constituent la norme commune et les points où il existe des écarts vérifiés.
Une telle structure facilite les processus de validation, le reporting, les révisions ainsi que la désactivation et l'archivage des variantes qui ne sont plus nécessaires. Il est essentiel que chaque écart puisse être attribué à un processus traçable, à un service responsable et à un statut documenté.
Questions et réponses
Que sont les sous-traitances dans le registre des activités de traitement ?
Les sous-traitements sont des variantes subordonnées d'un traitement principal. Ils reflètent des écarts locaux ou spécifiques à un cas d'utilisation par rapport au cœur commun du processus. Ce terme ne désigne pas une catégorie autonome du RGPD, mais un modèle structurel possible pour les RoPA au sein d'un groupe.
Le « traitement secondaire » correspond-il au « traitement en sous-traitance » ?
Non. Dans cet article, le terme « sous-traitements » ne désigne ni les sous-traitants ni les sous-traitants de données. Ce terme désigne les variantes d’une activité de traitement au sein d’un modèle RoPA structuré.
Pourquoi le sous-traitement peut-il être utile aux grands groupes ?
Dans les grands groupes, de nombreux processus sont mis en œuvre sous une forme similaire, mais pas tout à fait identique. Les sous-processus permettent de combiner un processus de base commun et des variations locales contrôlées, sans avoir à créer une copie indépendante pour chaque variante.
Dans quels cas faut-il privilégier le traitement partiel plutôt qu'une copie ?
Un sous-traitement peut être envisagé lorsque le cœur commun du processus est conservé et que seules certaines informations divergent au niveau local ou en fonction d'un cas d'utilisation spécifique. Cela peut concerner, par exemple, des prestataires locaux, des catégories de données supplémentaires, des délais différents, des systèmes locaux ou des autorisations particulières.
Dans quels cas vaut-il mieux effectuer soi-même le traitement plutôt que de le sous-traiter ?
Un traitement autonome peut s'avérer nécessaire lorsque, notamment, la finalité, le niveau de risque, le système utilisé, les catégories de données, les destinataires ou la responsabilité organisationnelle diffèrent à tel point que le cœur du processus initial n'est plus viable.
Quels champs doivent être repris à partir du traitement des données de base ?
En règle générale, il est possible de reprendre le nom du processus, l'objectif principal, la description standard, les systèmes centraux, les catégories de données standard, les prestataires de services standard, les mesures techniques et organisationnelles centrales ainsi que la logique de suppression standard. Il convient de vérifier, pour chaque groupe de champs, si cette reprise est appropriée.
Quelles informations doivent figurer dans une variante locale ?
Une variante locale doit notamment mentionner la société concernée, le site ou le cas d'utilisation, les champs divergents, la raison de la divergence, les personnes responsables, les risques, les mesures, les validations, les informations sur le statut et la date de révision prévue.
Comment les écarts locaux devraient-ils être validés ?
Toute dérogation locale doit faire l'objet d'une demande, être examinée par des experts, documentée et approuvée. En fonction de la nature et du risque lié à la dérogation, il peut être nécessaire d'impliquer les services chargés de la protection des données, du service juridique, de la sécurité informatique, le délégué à la protection des données ou d'autres instances compétentes. La variante doit rester associée au traitement de base sur lequel elle repose.
Dans quels cas faut-il désactiver les sous-traitements ?
Il convient notamment d'envisager une désactivation lorsque la variante locale n'est plus utilisée, qu'elle a perdu sa raison d'être, qu'un système a été mis hors service, qu'il y a eu changement de prestataire ou que la dérogation existante a été intégrée dans la norme applicable à l'ensemble du groupe.
Faut-il supprimer ou archiver les sous-traitements ?
Si une variante a été utilisée en production, il est généralement préférable de l'archiver ou de la désactiver plutôt que de la supprimer immédiatement. Cela permet de garantir la traçabilité des décisions antérieures, des délais de suppression et des autres justificatifs. Une suppression peut notamment être envisagée lorsque la variante n’a jamais été mise en production et qu’il n’existe aucune obligation légale ou technique de conservation.
Comment Ailance RoPA peut-il faciliter les traitements secondaires ?
Ailance RoPA permet de relier entre eux le traitement des données de base, les variantes locales, les champs repris, les écarts, les responsabilités, les validations, les mesures, les informations de statut et les révisions. Cela permet de représenter de manière structurée les normes communes et les spécificités locales au sein du RoPA du groupe.
Quel est le principal avantage de la sous-traitance ?
L'avantage principal réside dans le lien clair entre la norme et la dérogation. Le RoPA ne se contente donc pas de présenter plusieurs processus similaires, mais indique également en quoi chaque variante s'écarte de la norme, pour quelle raison, et qui a vérifié et validé cette dérogation.
German 
English 
Italian 
French