L’article 30 du RGPD joue un rôle de pivot dans la conformité des organisations en matière de protection des données. Il impose à chaque responsable de traitement et à chaque sous-traitant de tenir un registre des activités documentant de façon précise le traitement des données personnelles. Ce registre n’est pas un tableau administratif que l’on remplit pour faire joli dans un dossier de conformité.
C’est la cartographie de tout ce qui circule dans ton système d’information : fichiers RH, CRM, outils marketing, logs, IA, vidéosurveillance, tout y passe. Lors d’un contrôle, la CNIL commence presque toujours par demander ce document, justement parce qu’il révèle en quelques minutes la maturité réelle de ton organisation sur le RGPD.
Dans beaucoup de PME, d’associations ou de petites structures très numériques, l’article 30 reste flou. On sait qu’il existe, on a vaguement entendu parler du registre, mais personne n’a eu le temps de s’y mettre sérieusement. Certains se rassurent avec des mentions légales copiées-collées ou une politique de confidentialité générique, alors que le vrai nerf de la guerre est ailleurs : être capable de montrer, preuve à l’appui, ce qui est fait des données.
Entre les obligations théoriques du RGPD, les modèles de registre CNIL, la gestion des sous-traitants et la réalité des contrôles, le terrain est moins abstrait qu’il n’y paraît, surtout si on le regarde avec un œil de tech.
- L’article 30 RGPD impose un registre des activités de traitement à tous les responsables de traitement et sous-traitants.
- Ce registre doit être écrit (papier ou électronique) et présenté sur demande lors des contrôles CNIL.
- Le contenu minimal couvre au moins 8 blocs d’informations : finalités, bases légales, catégories de données, destinataires, transferts, durées, mesures de sécurité, coordonnées.
- Les structures de moins de 250 salariés ne sont que partiellement exemptées, et la CNIL recommande malgré tout un registre allégé.
- Les sanctions en cas de défaut peuvent grimper jusqu’à 10 M€ ou 2 % du CA mondial, avec un impact réputationnel souvent plus lourd que l’amende.
Article 30 RGPD et registre des activités de traitement : comprendre le cadre sans jargon
Pour poser les bases, l’article 30 du RGPD impose un registre des activités de traitement à chaque responsable de traitement et à chaque sous-traitant. En clair, toute entité qui décide du traitement des données (entreprise, association, collectivité) ou qui les manipule pour le compte d’un tiers (prestataire cloud, éditeur SaaS, agence marketing) doit être en mesure de lister ce qu’elle fait avec ces informations.
Le texte prévoit que ce registre soit conservé par écrit, ce qui inclut évidemment un fichier électronique, tant qu’il est exploitable et exportable lors d’un contrôle CNIL.
Ce registre s’inscrit dans la logique de responsabilité posée par le RGPD : il ne suffit plus de dire que la protection des données est respectée, il faut le démontrer. Par exemple, si une plainte arrive chez la CNIL parce qu’un utilisateur n’arrive pas à exercer son droit de suppression, le registre est la première pièce qui permet de vérifier où sont stockées ses données, qui y accède et pendant combien de temps elles sont conservées. Sans ce support, même un système objectivement assez propre peut apparaître comme opaque et peu maîtrisé.
Prenons une petite société de services numériques, appelons-la DataFlow. Elle gère un site web, un CRM, un outil de ticketing support, une paie externalisée et une solution d’envoi d’emailing. Sur le papier, ce n’est rien d’extraordinaire. Mais si DataFlow ne tient aucun inventaire formel de ces traitements, elle est déjà en difficulté face à l’article 30. Chaque flux de données personnelles, du formulaire de contact au suivi des factures, doit être décrit au minimum avec sa finalité, ses destinataires, ses durées de conservation et les mesures de sécurité associées.
Un autre point souvent ignoré concerne la frontière entre données personnelles et données techniques. Beaucoup d’équipes techniques considèrent que les logs, identifiants de session, adresses IP ou données de télémétrie ne relèvent pas vraiment de la vie privée. Pourtant, l’article 30 s’applique dès qu’une information permet d’identifier directement ou indirectement une personne. Un système de vidéosurveillance en entreprise ou un outil de tracking marketing entrent évidemment dans ce périmètre, tout comme certains dispositifs d’IA qui réutilisent des jeux de données clients. Si ce sujet t’intéresse, l’article dédié à la vidéosurveillance et au RGPD en entreprise donne un bon aperçu de l’ampleur réelle du champ couvert.
En arrière-plan, un autre enjeu se dessine : la cohérence entre ce qui est écrit dans les documents publics (politique de confidentialité, mentions cookies) et ce qui figure dans le registre RGPD. La CNIL vérifie très vite si les finalités annoncées aux utilisateurs correspondent aux lignes du registre. Si un traitement apparaît dans le registre mais n’est jamais mentionné dans l’information aux personnes, ou l’inverse, la conformité est déjà fragilisée. Au fond, l’article 30 sert aussi de socle au reste : droits des personnes, documentation des bases légales, analyses d’impact, contrats de sous-traitance.
Une fois ce cadre posé, la vraie question arrive vite : qui doit réellement se plier à ces obligations et dans quelles limites ? C’est là que les choses se corsent pour les petites structures.
Qui est visé par l’article 30 RGPD et comment interpréter les exemptions
L’article 30 vise deux catégories bien identifiées : les responsables de traitement et les sous-traitants. Le premier décide pourquoi et comment les données sont utilisées. Le second exécute un traitement pour le compte du premier. Dans la vraie vie, beaucoup d’acteurs cumulent les deux casquettes : une agence web qui a ses propres salariés (RH, paie, compta) et qui héberge les données de clients sur ses serveurs agit à la fois comme responsable pour ses sujets internes et comme sous-traitant pour les données confiées.
Le RGPD prévoit une exemption partielle pour les organisations de moins de 250 salariés, à condition que leurs traitements soient occasionnels, sans catégories particulières de données (santé, opinions politiques, données biométriques, etc.) et sans risque élevé pour les droits et libertés. Sur le papier, cela semble généreux pour les TPE. Dans la pratique, peu de structures cochent vraiment toutes ces cases à la fois. Dès qu’il y a un CRM, une newsletter régulière ou un suivi RH basique, on peut difficilement parler de traitement occasionnel.
Reprenons l’exemple de DataFlow, 40 salariés. Elle traite les données de ses collaborateurs (paie, congés, entretiens), gère un pipeline de prospects dans un CRM, envoie des campagnes emailing et collecte des statistiques d’usage sur ses produits. Même avec une interprétation très souple, difficile de la considérer comme exemptée d’un registre. D’ailleurs, la CNIL a plusieurs fois rappelé que, même quand l’exemption pourrait théoriquement s’appliquer, elle recommande vivement de tenir au moins un registre simplifié. C’est un peu le même raisonnement que pour les tests automatisés en dev : officiellement facultatifs, mais tout le monde sait que s’en passer augmente le risque de casse.
Côté sous-traitants, il n’y a pas de seuil de salariés. Une micro-entreprise qui gère l’envoi de newsletters pour ses clients, ou une petite structure qui administre un serveur VPS mutualisé, doit tenir un registre spécifique pour les traitements effectués pour le compte de chaque responsable de traitement. Ce registre “sous-traitant” ne contient pas exactement les mêmes informations que celui du responsable, mais l’esprit reste le même : prouver ce qui est fait avec les données confiées et dans quelles conditions techniques.
Pour rendre tout ça plus lisible, un tableau de synthèse aide souvent les équipes à se repérer et à ne pas sur- ou sous-estimer leurs obligations.
| Type d’acteur | Obligations article 30 | Exemples concrets | Exemption possible |
|---|---|---|---|
| Responsable de traitement | Registre complet pour chaque activité de traitement sous sa responsabilité. | PME avec salariés, CRM, facturation, site vitrine, outils d’analytics. | Oui pour moins de 250 salariés, traitements occasionnels et peu risqués, mais rare en pratique. |
| Sous-traitant | Registre listant les catégories de traitements pour chaque client, plus mesures de sécurité. | Hébergeur cloud, agence emailing, prestataire de paie externalisée. | Non, aucune exemption de taille. |
| Micro / TPE “peu data” | Registre allégé conseillé, même si certains traitements sont occasionnels. | Artisan avec simple facturation et fichier clients limité. | Oui sur le papier, mais la CNIL incite à documenter quand même. |
| Startup très numérique | Registre détaillé pour chaque brique produit, surtout si IA, tracking, logs riches. | Plateforme SaaS avec analytics, AB testing, IA intégrée. | Pratiquement aucune exemption réaliste. |
Soit dit en passant, ce flou sur les exemptions explique pourquoi certains se retrouvent en difficulté lors d’un contrôle. Misant sur l’idée “on est petits, ça ne nous concerne pas vraiment”, ils n’ont pas de registre et doivent tout reconstituer en urgence. Autant le dire clairement : miser sur la petite taille pour échapper à l’article 30 est une stratégie fragile. Mieux vaut un registre simple, même partiel, qu’aucun support du tout. La suite logique consiste alors à regarder ce que ce registre doit contenir précisément.
Contenu obligatoire du registre article 30 : les 8 blocs d’informations à maîtriser
Le cœur de l’article 30 RGPD, ce sont les informations minimales à faire figurer dans le registre. Pour chaque traitement des données, il faut documenter un ensemble de champs qui vont permettre à la CNIL de vérifier rapidement la conformité et le niveau de risque. Ce n’est pas qu’un tableau pour faire joli : c’est un outil de diagnostic qui, bien renseigné, aide aussi les équipes techniques et métiers à ne pas perdre le fil des usages.
Un registre complet contient au moins les éléments suivants pour chaque activité de traitement :
Les coordonnées du responsable de traitement (et du DPO s’il y en a un) constituent le point d’entrée. Ensuite viennent les finalités du traitement, qui doivent être concrètes : “gestion des candidatures”, “facturation des clients”, “mesure d’audience du site web”, et non pas des formules vagues. Le registre doit aussi décrire les catégories de personnes concernées (clients, prospects, salariés, candidats, utilisateurs, visiteurs du site) et les catégories de données personnelles associées (identité, coordonnées, données de connexion, données de paiement, données de santé le cas échéant).
Un autre bloc sensible concerne les destinataires des données. Cela inclut les services internes (RH, marketing, support) mais aussi et surtout les sous-traitants : prestataire de paie, plateforme d’emailing, hébergeur, outil d’analytics, fournisseur CRM. Dans un contexte où les stacks techniques se complexifient, ce volet permet de garder une vision claire de qui reçoit quoi. Pour les développeurs, c’est souvent le moment où on réalise que des données passent par plus de briques qu’on ne le croyait.
Les transferts hors Union européenne doivent aussi apparaître clairement. Si le CRM ou l’outil d’analytics est hébergé aux États-Unis, ou si un support technique basé en Inde accède à la base clients, le registre doit en garder une trace, avec les garanties mises en place (clauses contractuelles types, décision d’adéquation, encadrement contractuel renforcé). Ce point revient régulièrement dans les décisions de la CNIL, surtout pour les acteurs qui utilisent massivement des services cloud non européens.
Viennent ensuite les délais de conservation. Le registre doit indiquer pendant combien de temps chaque catégorie de données est conservée, ou selon quels critères ce délai est déterminé. Par exemple, conservation des données de facturation pendant 10 ans pour respecter les obligations comptables, ou conservation des données de candidats non retenus pendant 2 ans avec leur accord. Ce volet rejoint d’ailleurs un autre article du RGPD sur la transparence : si tu veux creuser le lien entre information des personnes et ce qui est déclaré dans le registre, l’analyse de l’article 12 RGPD sur la transparence complète bien le sujet.
Enfin, le registre doit contenir une description générale des mesures de sécurité techniques et organisationnelles. Pas question de lister chaque mot de passe ou chaque règle de firewall, mais de décrire les grandes lignes : chiffrement des données, gestion des habilitations, politique de sauvegarde, journalisation des accès, revue régulière des droits. Quand on travaille déjà sur la cybersécurité, ce bloc fait le lien avec les pratiques habituelles, surtout si on a déjà réfléchi à l’impact direct de la sécurité sur la confiance utilisateur et les ventes.
Pour ne pas se perdre, une petite checklist synthétique reste utile en cours de projet.
- Coordonnées du responsable, des coresponsables éventuels et du DPO.
- Finalités détaillées de chaque traitement (pas de formulations fourre-tout).
- Catégories de personnes (clients, salariés, prospects, etc.).
- Catégories de données (identité, usage, logs, paiement, santé…).
- Destinataires internes et sous-traitants, transferts hors UE et garanties associées.
- Durées de conservation ou critères permettant de les déduire.
- Mesures de sécurité techniques et organisationnelles globales.
Ce schéma doit ensuite être adapté au rôle exact de l’acteur. Un sous-traitant documente les catégories de traitements pour chaque client, tandis qu’un responsable de traitement garde la vision globale par finalité métier. Dans les deux cas, plus les champs sont précis, plus le registre devient un levier concret pour piloter la protection des données, pas seulement une obligation administrative. À partir de là, reste à voir comment construire ce document dans un contexte réel, sans y passer des mois.
Construire un registre article 30 RGPD utile au quotidien : méthode terrain
Monter un registre article 30 RGPD qui tient la route ne demande pas forcément une armée de juristes. Ce qui compte, c’est une méthode claire, un peu de rigueur et un dialogue honnête entre métiers, juridique et technique. En pratique, les structures qui s’en sortent le mieux commencent par cartographier leurs traitements, puis remplissent un modèle de registre outillé, mis à jour au fil des projets.
Revenons sur DataFlow, la PME de services numériques. La direction a nommé un pilote RGPD, qui n’est pas forcément DPO à temps plein, mais qui a l’autorité pour aller interroger chaque service. Première étape : lister toutes les situations où des données personnelles sont collectées, stockées, analysées ou partagées. RH, comptabilité, ventes, marketing, support, produit, sécurité : chacun apporte ses briques. On découvre souvent à cette occasion un outil oublié, un export CSV qui traîne sur un drive partagé ou un vieux système de ticketing encore alimenté en parallèle.
Une fois cette cartographie posée, la deuxième étape consiste à transformer chaque usage en “fiche traitement”. Chaque fiche reprend les champs de l’article 30 : finalité, base légale, catégories de personnes, données, destinataires, transferts éventuels, durées, mesures de sécurité. Pour ne pas réinventer la roue, beaucoup de structures partent d’un modèle de registre RGPD type tableur, compatible avec les recommandations de la CNIL. Si tu veux un exemple prêt à l’emploi, la page dédiée à un exemple de registre RGPD adapté TPE/PME donne une structure simple à reprendre et à personnaliser.
DataFlow commence par un traitement “Recrutement des candidats”. Finalité : gestion des candidatures et organisation des entretiens. Base légale : intérêt légitime de l’employeur, consentement pour la conservation en vivier. Personnes concernées : candidats. Données : identité, coordonnées, CV, lettres, notes d’entretien. Destinataires : équipe RH, managers recruteurs, outil ATS en SaaS. Transferts hors UE : non. Durées : 2 ans pour les candidats avec accord, 6 mois sinon. Mesures de sécurité : accès restreint, authentification forte, purge automatique après délai. Une fiche comme celle-ci, bien rédigée, est déjà très parlante pour un contrôleur.
Reste la question de l’outil. Pour une dizaine ou une vingtaine de traitements, un fichier tableur partagé suffit largement, à condition d’avoir un responsable clair de sa mise à jour. Au-delà, les solutions SaaS spécialisées en privacy management apportent du confort : liaison avec les analyses d’impact, suivi des sous-traitants, journalisation des modifications. En revanche, déléguer la tenue du registre à un outil sans gouvernance claire revient à coller un pansement sur un problème de process. Le vrai sujet est l’organisation interne : qui crée une nouvelle fiche lorsqu’un projet démarre, qui valide les finalités, qui vérifie les durées de conservation.
Un point de vigilance concerne aussi les traitements plus techniques, souvent hors radar des juristes : logs applicatifs, outils de sécurité, monitoring, IA, marketing avancé. Par exemple, un entraînement de modèle d’IA à partir de données clients doit figurer dans le registre, avec une finalité bien distincte, une base légale solide et des mesures de minimisation explicites. Si l’on s’intéresse déjà à l’impact de l’intelligence artificielle sur le marketing, comme détaillé dans l’analyse sur l’impact de l’IA en marketing, il devient naturel de connecter ces usages au registre RGPD pour garder une vue globale des risques.
À la fin de cette démarche, le registre ne doit pas être un fichier figé, rangé dans un dossier “conformité” oublié. Chaque nouveau projet qui touche au traitement des données devrait déclencher une question réflexe : notre registre contient-il déjà ce traitement, ou faut-il créer une nouvelle ligne avec ses spécificités ? Quand cette habitude s’installe, l’article 30 se transforme presque en réflexe de design : avant de lancer un flux de données, on se demande comment il va s’intégrer dans l’inventaire existant.
Une fois le registre en place, reste un volet souvent moins anticipé mais tout aussi décisif : la manière dont la CNIL va s’en servir lors d’un contrôle, et les risques associés en cas d’oubli ou d’imprécision.
Contrôles CNIL, sanctions et risques concrets autour du registre article 30
Du point de vue de la CNIL, le registre des activités est un peu l’équivalent du schéma d’architecture pour un dev senior qui débarque sur un projet inconnu. C’est la première chose que l’on regarde pour jauger la maturité du système. Lors d’un contrôle, qu’il soit sur place, en ligne ou sur pièces, la demande arrive vite : communication du registre prévu par l’article 30 du RGPD. Si la structure répond qu’elle n’en a pas, ou fournit un document manifestement incomplet ou obsolète, le signal d’alerte est immédiat.
Les sanctions prévues par l’article 83 du RGPD peuvent monter très haut sur le papier, jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial pour un registre absent ou lacunaire. En pratique, la CNIL tient compte de la taille, de la bonne foi, de la rapidité des corrections et des antécédents. Une petite association ne paiera pas la même chose qu’un grand groupe coté, mais dans tous les cas, l’absence de registre pèse lourd dans la balance, parce qu’elle révèle souvent d’autres lacunes structurelles : pas de maîtrise des sous-traitants, durées de conservation floues, sécurité inégale.
Ce qui marque le plus, ce n’est pas seulement le montant de l’amende, mais le fait que les décisions sont rendues publiques. Nom de l’organisme, faits reprochés, manquements précis, injonctions de mise en conformité : tout se retrouve noir sur blanc. Certaines sociétés de e-commerce ont dû publier la décision sur leur propre site pendant plusieurs semaines, ce qui fait un peu désordre auprès des clients. Pour une PME déjà sous pression sur son image, voir son nom associé à “absence de registre RGPD et mesures de sécurité jugées insuffisantes” a des effets à long terme sur la confiance.
Les contrôles récents montrent une tendance claire : la CNIL s’intéresse de plus en plus aux acteurs de taille moyenne ou modeste, notamment dans les secteurs très consommateurs de données (marketing, SaaS, santé, éducation, immobilier). Les TPE/PME qui pensaient passer sous les radars découvrent qu’elles sont désormais dans le périmètre des campagnes de contrôle. Le registre article 30 sert alors de révélateur : un document précis, à jour et cohérent avec le terrain peut fortement atténuer la sévérité d’un contrôle, même si tout n’est pas encore parfait.
Au-delà de l’amende, l’impact opérationnel peut aussi être lourd. La CNIL peut ordonner la suspension ou la limitation d’un traitement, par exemple un outil d’analytics ou une plateforme marketing, tant que la conformité n’est pas démontrée. Pour une boîte qui s’appuie fortement sur l’emailing ou le tracking pour ses ventes, se faire couper un levier clé pendant plusieurs semaines peut peser plus lourd que l’amende elle-même. D’où l’intérêt de connecter le registre aux enjeux business, notamment tout ce qui touche à l’expérience client, à la confiance et aux conversions.
Un autre sujet sensible concerne les contrôles ciblant la sécurité. L’absence de registre va souvent de pair avec une vision floue des mesures de chiffrement, de segmentation réseau, de sauvegarde ou de gestion des incidents. Les équipes qui ont déjà travaillé sur la relation entre sécurité des données et performance commerciale savent qu’un socle technique solide peut à la fois réduire le risque CNIL et améliorer la perception utilisateur. Le lien est assez clair dans les analyses sur la façon dont des données sécurisées peuvent booster les ventes : transparence et maîtrise inspirent confiance, ce qui se voit directement dans les métriques.
En résumé, pour la CNIL, le registre article 30 n’est pas un bonus. C’est un indicateur central de conformité. Un registre absent ou purement décoratif ressemble à un repo sans README ni tests : même si le code tourne, on sait déjà que la dette cachée est importante. L’inverse est vrai aussi : un registre propre, mis à jour et relié à des décisions concrètes sur les sous-traitants, les durées de conservation ou les mesures de sécurité pèse en faveur de l’organisation en cas de problème.
Reste une dernière couche, plus transverse : comment faire vivre ce registre dans le temps, et comment l’articuler avec les autres briques RGPD sans se noyer dans la paperasse.
Articuler l’article 30 RGPD avec le reste de la conformité et les pratiques du quotidien
Une fois que le registre article 30 est en place, la tentation est grande de le ranger dans un dossier “mission accomplie” et de passer à autre chose. Sauf que la vie d’un SI n’est jamais figée. Nouveaux outils, nouveaux sous-traitants, projets data, expérimentations IA, fusions applicatives : chaque évolution modifie tôt ou tard une ligne du registre. Le vrai défi n’est donc pas seulement de créer un premier inventaire, mais de l’ancrer dans les réflexes de l’organisation, un peu comme on le ferait pour un schéma d’architecture ou une documentation d’API.
Une bonne approche consiste à relier directement le registre aux autres exigences du RGPD. Quand un nouveau traitement apparaît dans le registre avec un risque potentiellement élevé (géolocalisation fine, scoring automatique, utilisation de données sensibles), cela doit déclencher une réflexion sur l’éventuelle nécessité d’une analyse d’impact (AIPD / DPIA). De la même façon, si une nouvelle finalité marketing est ajoutée pour un usage d’IA, il faut vérifier que les bases légales sont alignées et que l’information donnée aux personnes reste cohérente. Le registre sert alors de point de départ à toutes ces vérifications.
Sur le terrain, certaines équipes product intègrent le RGPD dans leur workflow de lancement de features : lors de la phase de cadrage, une question systématique apparaît dans le template de spec produit ou d’EPIC Jira : ce changement crée-t-il un nouveau traitement ou modifie-t-il un traitement existant dans le registre article 30 ? Si la réponse est oui, la fiche correspondante doit être mise à jour avant la mise en prod. Ce genre de réflexe évite les décalages entre ce qui est réellement en place et ce que le registre déclare.
Autre point de connexion : les droits des personnes. Quand un utilisateur demande l’accès à ses données ou la suppression de certains éléments, le registre aide à identifier rapidement tous les traitements concernés. Un traitement “Support client” qui contient des tickets et des logs d’erreurs n’a pas les mêmes contraintes qu’un traitement “Facturation” basé sur des obligations légales de conservation. Sans ce support, les réponses risquent d’être approximatives ou incomplètes, ce qui peut déclencher derrière des plaintes ou des contrôles ciblés.
Enfin, le registre article 30 peut jouer un rôle pédagogique en interne. Une présentation annuelle du registre aux équipes, avec mise en avant des évolutions majeures, des nouveaux sous-traitants et des traitements les plus sensibles, aide à faire comprendre à chacun où se situent les zones de vigilance. Les développeurs se repèrent mieux sur les données à minimiser, les marketeurs visualisent les limites des bases légales, les RH comprennent pourquoi certaines informations ne peuvent pas être conservées indéfiniment. Le registre cesse alors d’être un simple document de conformité pour devenir une carte vivante de la circulation des données.
Au final, l’article 30 RGPD joue un rôle de colonne vertébrale dans la protection des données. Bien compris et bien utilisé, il structure le dialogue entre métiers, juridique et technique. Maltraité ou ignoré, il devient une source de risques silencieux, qui ressort brutalement lors d’un contrôle CNIL ou d’un incident de sécurité. La question n’est donc pas “faut-il un registre ?”, mais plutôt “comment le rendre vraiment utile pour piloter ses traitements de données au quotidien”.
Le registre article 30 RGPD est-il obligatoire pour une petite startup ?
Oui dans la majorité des cas. L’exemption pour les structures de moins de 250 salariés ne joue que si tous les traitements sont occasionnels, sans données sensibles ni risque particulier pour les personnes. Dès qu’il y a un CRM, une newsletter récurrente ou un suivi RH classique, la tenue d’un registre devient attendue par la CNIL, au moins sous forme simplifiée.
Peut-on se contenter d’un modèle Excel pour le registre des activités ?
Un tableur bien structuré suffit largement pour une TPE ou une PME avec un nombre raisonnable de traitements. L’essentiel est de couvrir les champs exigés par l’article 30 RGPD et de le mettre à jour régulièrement. Les outils SaaS spécialisés deviennent intéressants quand le nombre de traitements explose, que plusieurs pays sont concernés ou que tu veux relier registre, analyses d’impact et gestion des violations.
Comment la CNIL utilise-t-elle le registre lors d’un contrôle ?
Le registre est souvent l’un des premiers documents demandés. Il permet à la CNIL d’identifier rapidement les traitements en place, les sous-traitants, les transferts hors UE, les durées de conservation et les mesures de sécurité. Un registre absent, obsolète ou très incomplet est perçu comme un indicateur de non-maîtrise globale de la protection des données et peut alourdir les sanctions.
Faut-il un registre distinct quand on agit comme responsable et comme sous-traitant ?
Oui. En tant que responsable de traitement, tu documentes toutes les activités que tu décides pour ton propre compte (RH, facturation, marketing, produit). En tant que sous-traitant, tu tiens un registre séparé listant les catégories de traitements réalisés pour chaque client, avec les mesures de sécurité et les éventuels transferts hors UE. Cette séparation reflète les responsabilités différentes prévues par le RGPD.
À quelle fréquence mettre à jour un registre RGPD conforme à l’article 30 ?
Le registre doit être mis à jour à chaque changement significatif : nouvelle finalité, nouveau sous-traitant, nouveau transfert hors UE, modification des durées de conservation, refonte d’un traitement clé. En plus de ces mises à jour ponctuelles, une revue globale au moins annuelle est recommandée pour vérifier que les informations restent en phase avec la réalité du système d’information.
