Réponse succincte
Les sous-traitements ne constituent pas une catégorie à part entière de la RGPD. Ce terme désigne ici un principe de structure organisationnelle et technique dans le Répertoire 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 géré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 assorti de sous-traitements associés permet en revanche de relier entre eux les normes communes, les écarts locaux, les responsabilités, les validations, les versions, les informations de statut 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 sous une forme similaire dans plusieurs sociétés ou sur plusieurs sites. Cela concerne par exemple les processus RH, la gestion des candidatures, le CRM, la communication avec les locataires, les processus de gestion des 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. À y regarder de plus près, il peut toutefois exister des différences considérables. Une entreprise fait appel à un prestataire local, tandis qu’une autre s’appuie sur 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’un site à l’autre en fonction des exigences locales. De même, la finalité, les applications utilisées, les Bases juridiques ou bien les processus de validation internes ne doivent pas nécessairement être identiques dans toutes les sociétés.
Chacune de ces dérogations n'implique pas nécessairement une activité de traitement entièrement distincte. Elle doit toutefois être documentée de manière structurée, afin que la norme commune et la spécificité locale concernée 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 d'en assurer le suivi à 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 consigne commune venait à changer.
Une copie non liée ne contient généralement aucune information fiable sur le processus principal dont elle est issue. 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 reflète 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. Cela affecte notamment le pilotage, la mise à jour, le reporting et la conservation des justificatifs.
Conformément à l'article 30 RGPD il faut que Répertoire des activités de traitement notamment des informations sur les finalités de la Traitement, les catégories de personnes concernées et de données à caractère personnel, les destinataires, les éventuels transferts vers des pays tiers, les délais de suppression 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 la autorité de contrôle à mettre à disposition 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
Le terme „ sous-Traitement“ » est utilisé ici délibérément dans un sens opérationnel. Il ne s'agit ni d'un sous-traitement effectué par un autre sous-traitant, ni d'une nouvelle catégorie juridique de RGPD.
Une sous-Traitement désigne plutôt une variante subordonnée d'un traitement de base au sein du registre 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,
- fondamentale mesures techniques et organisationnelles,
- la logique de suppression par défaut,
- risques principaux,
- les responsabilités principales ainsi que
- tests standard prévus et validations.
La sous-Traitement représente, en revanche, l'écart contrôlé par rapport à la norme commune. Elle peut notamment porter sur :
- 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 en concertation avec les services concernés, documentées, puis supprimées à l'expiration des délais applicables. Les personnes concernées sont les candidats et candidates. 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 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, des règles différentes s’appliquent Obligations d'information, tandis que dans une autre entreprise, une procédure devant 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 indépendantes. 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 en tant que sous-traitements permet de distinguer clairement les informations applicables à l'échelle du groupe et les points sur lesquels il existe des écarts locaux.
| Question d'évaluation | Copie non associée | Traitement des fiches 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 un par un 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 floue 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 n'ont donc pas pour but de réduire le volume de documentation requis. Ils visent à Documentation la structurer de manière à ce que les normes communes et les spécificité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 être judicieux de reprendre certaines informations issues du traitement des données de base. Il devrait être possible de compléter, de vérifier ou de remplacer localement d'autres données.
| 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 consigné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 | Peut être utilisé pour Traitement des commandes, les transferts vers des pays tiers et les risques peuvent être pris en compte. |
| 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 obligatoire 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, l'écart concret et la responsabilité qui en découle.
Une sous-Traitement devrait donc au moins permettre de voir :
- 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 nouvel examen doit avoir lieu et
- que la variante soit en cours de planification, en cours d'examen, active, désactivée ou archivée.
Sans ces informations, on court le risque de ne créer qu’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 contrôlable.
É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 dans le cadre standard du 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 manifestation du cœur de processus 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 pas approprié de considérer automatiquement chaque écart comme un sous-Traitement ni de classer chaque particularité, ni de la reproduire à l'aide d'une copie entièrement nouvelle et sans lien avec l'original. Ce qui est déterminant, c'est de savoir si le cœur commun du processus reste valable et si la divergence peut être décrite de manière suffisamment précise, vérifiée et validée.
Distinction par rapport à une activité de transformation indépendante
Les sous-traitances ne doivent pas servir à masquer des différences substantielles entre les activités de traitement. Une activité autonome Traitement peut notamment être envisagée 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é sont 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 des aptitudes à l’aide de l’IA, cela peut, selon la configuration concrète, aller au-delà d’un écart mineur. Dans un tel cas, il peut s’agir d’une activité de traitement autonome ou, à tout le moins, d’une sous-activité clairement délimitéeTraitement pouvant nécessiter une évaluation des risques spécifique et une autorisation distincte.
C'est donc la délimitation technique qui est déterminante. La simplification administrative ne saurait à 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 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 sont associés.
- Les risques identifiés et les mesures nécessaires sont consignés.
- 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 en raison des variantes qui ne sont plus nécessaires sur le plan opérationnel et dont le statut n'a toutefois pas été mis à jour. Un modèle de statut clair est donc une condition préalable à 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 de manière permanente en tant qu'activités de traitement actives. Une Suppression ce n'est toutefois pas non plus la solution appropriée dans tous les cas.
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é mise en service, une Suppression peuvent être pris en considération, pour autant qu’il n’existe ni obligation légale de justification ni raisons internes justifiant une Rangement existent.
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. Cela permet de garder une trace de l’existence de la variante, de la période durant laquelle elle a été active, de la date à laquelle elle a été supprimée, des données concernées, des délais de suppression à respecter et des décisions prises en lien avec la Traitement ont été prises.
Un examen des sous-Traitement peut notamment être envisagé 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 de nombreuses activités de traitement quasi identiques n’a généralement qu’une valeur informative limitée. Il est bien plus 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 liés de manière structurée. Ce n'est qu'alors que le RoPA peut aller au-delà de la simple Documentation mais aussi comme outil de pilotage.
Lien avec l'article 30 du RGPD
Art. 30 RGPD exige des responsables du traitement qu’ils tiennent un registre des activités de traitement relevant de leur compétence. 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. Ce registre est le autorité de contrôle à mettre à disposition sur demande.
Le site RGPD ne prescrit toutefois aucun modèle de données technique particulier. Il ressort notamment de l'article 30 RGPD Cela ne signifie pas pour autant que chaque écart local doive impérativement être consigné sous la forme d'une entrée totalement isolée. De même, la règle n'exige pas que des processus similaires soient documentés par des 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 éventuels. 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 prévues à l'article 30 RGPD. Elles constituent plutôt un modèle d'organisation possible permettant de représenter de manière structurée les informations nécessaires 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 pertinente 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 au fait qu’il n’existe pas 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
- centrale mesures techniques et organisationnelles.
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 comme des opérations de traitement autonomes, soit comme des 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 applicable à 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 liés aux installations sont particulièrement susceptibles de donner lieu à la création de nombreuses entrées similaires. Il s’agit notamment de l’enregistrement des visiteurs, Contrôle d’accès physique, Vidéosurveillance, gestion des clés, gestion des places de parking, coordination du nettoyage et signalement des réparations.
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. Sur un site, on Vidéosurveillance utilisé dans certains sites, mais pas dans d'autres. 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 fragmenter le processus commun de gestion des installations en de nombreuses entrées sans lien entre elles. 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 concerner 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 un risque de contradictions concernant les finalités, les destinataires, Bases juridiques et les délais de suppression. En revanche, un traitement de base associé à des sous-traitements permet de distinguer les informations applicables à l'échelle du groupe de celles qui relèvent de spécificités locales ou propres à un cas d'utilisation et qui 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, le 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 immédiate, cela ne signifie généralement pas que le nombre d’opérations de traitement est insuffisant. 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 de 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 liées peuvent être créées dans un premier temps sans grand effort. Cependant, à mesure que leur nombre augmente, elles peuvent entraîner des informations contradictoires, un flou au niveau des responsabilités, des mises à jour plus difficiles et une capacité d'analyse limitée. En revanche, un traitement des données de base 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 revues, 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 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 de base. 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 distincte de la RGPD, mais un modèle structurel possible pour les RoPA des groupes.
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 la sous-traitance peut-elle ê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 distincte pour chaque variante.
Dans quels cas faut-il privilégier le traitement partiel plutôt qu'une copie ?
Une sous-Traitement Cette option peut être envisagée lorsque le cœur du processus commun 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 de services 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 ?
Une entreprise indépendante Traitement Cela peut s'avérer nécessaire notamment lorsque l'objectif, la situation en matière de risques, le système utilisé, les catégories de données, les destinataires ou la responsabilité organisationnelle présentent des différences si importantes 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, 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 systèmes centraux mesures techniques et organisationnelles ainsi que la logique de suppression par défaut. 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 devrait notamment permettre de concernés la société, le site ou le cas d'utilisation, les champs présentant des écarts, la raison de ces écarts, 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és à la dérogation, il peut être nécessaire d'impliquer les services chargés de la protection des données, les services juridiques, 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 correspondant.
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 n'a plus de 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 de manière opérationnelle, il est généralement préférable de l'archiver ou de la désactiver plutôt que de procéder immédiatement à une Suppression. Cela permet de garantir la traçabilité des décisions antérieures, des délais de suppression et des autres justificatifs. Une Suppression Cette option 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 justifiant sa conservation.
Comment Ailance RoPA peut-il faciliter les sous-traitances ?
Ailance RoPA permet de relier entre eux les traitements 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 établi 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