Registre RGPD rempli : un exemple à adapter
Un exemple de fiche registre RGPD rempli et une trame à copier pour documenter finalités, données, destinataires, durées et sécurité.
Un registre utile permet de retrouver une activité, son objectif et les règles qui s’appliquent à ses données. Voici un exemple rempli, puis une trame à copier. Il s’agit d’un cas entièrement fictif, à adapter aux traitements réellement mis en œuvre dans votre organisation.
Ce que le registre doit contenir
Pour un responsable de traitement, l’Art. 30(1)(a) à (g) du RGPD prévoit l’identité et les coordonnées des acteurs concernés, les finalités, les catégories de personnes et de données, les catégories de destinataires, les transferts éventuels, puis, dans la mesure du possible, les délais d’effacement et une description générale des mesures de sécurité. Source : RGPD, Art. 30(1).
La base légale, le propriétaire interne, les applications et la date de révision sont des compléments utiles. Ils ne figurent pas tous dans la liste des mentions imposées par l’Art. 30(1). Les ajouter facilite les contrôles croisés sans transformer le registre en inventaire de chaque ligne de données.
Les catégories du registre d’un sous-traitant diffèrent : l’Art. 30(2) vise notamment les responsables pour lesquels il agit et les catégories de traitements réalisés pour chacun. Notre analyse de l’article 30 détaille cette distinction.
Exemple rempli : assistance liée à une prestation
Hypothèses du cas : une entreprise fictive installe des équipements de rangement et répond aux demandes techniques de ses clients particuliers. L’outil de tickets, ses sauvegardes et sa messagerie sont exploités en interne ; aucun prestataire n’accède aux données de cette activité et aucun transfert vers un pays tiers n’intervient. Ces hypothèses simplificatrices doivent être vérifiées, et non copiées, dans un cas réel. Les noms et coordonnées qui suivent sont inventés pour remplir entièrement la fiche.
| Rubrique | Exemple de contenu |
|---|---|
| Référence et activité | SUP-01 — Assistance aux clients sur la prestation en cours |
| Responsable de traitement | Société Exemple Assistance ; adresse fictive : 12 rue Exemple, 00000 Ville-Exemple ; contact : donnees@example.invalid |
| Autres acteurs Art. 30(1)(a) | Aucun responsable conjoint ni représentant dans ce cas fictif ; aucun DPO désigné dans l’hypothèse retenue |
| Finalités | Recevoir la demande, diagnostiquer la difficulté, apporter une réponse et suivre sa résolution |
| Personnes concernées | Clients particuliers titulaires de la prestation |
| Catégories de données | Identifiant client, coordonnées de réponse, référence du contrat, description technique utile, dates et contenu des échanges nécessaires |
| Catégories de destinataires | Équipe support habilitée ; équipe technique pour les seuls éléments nécessaires au diagnostic |
| Transferts | Aucun dans les hypothèses de cet exemple ; contrôle à reprendre si l’hébergement ou l’assistance change |
| Effacement | Ticket accessible pendant sa résolution, puis pendant trois mois pour gérer une réouverture ; purge quotidienne à échéance, contrôlée par le responsable du support |
| Justification de la durée | Hypothèse opérationnelle d’un délai de réouverture de trois mois ; choix illustratif à justifier dans le cas réel, aucune durée légale générale de trois mois |
| Sécurité générale | Comptes individuels, habilitations par fonction, accès administrateur renforcé, sauvegardes internes protégées renouvelées sur trente jours, journal des accès utiles et revue des habilitations |
| Base légale, complément | Art. 6(1)(b), pour les opérations effectivement nécessaires à l’assistance contractuelle du client personne physique |
| Pilotage, complément | Responsable du support ; outil Assistance-01 et messagerie interne ; version 2 validée le 27 septembre 2026 ; réexamen avant ajout d’un prestataire ou changement de finalité |
Cette fiche reste un modèle pédagogique : remplacez les coordonnées fictives et décrivez les mesures réellement appliquées. Une archive destinée à défendre un droit en justice demande une justification, un périmètre et une durée propres ; elle ne permet pas de garder tous les tickets sans limite. De même, les données des interlocuteurs d’une entreprise cliente ne relèvent pas automatiquement du contrat au sens de l’Art. 6(1)(b), puisqu’ils ne sont pas nécessairement parties au contrat.
Suivre un ticket de l’ouverture à l’effacement
Le 3 mars 2026, une cliente signale qu’une porte de rangement se ferme mal. Le support ouvre le ticket SUP-184 avec son identifiant client, sa référence de prestation, ses coordonnées de réponse et la description du défaut. Il n’a pas besoin de recopier les données de facturation ni l’ensemble de son historique d’achats. Une photographie du mécanisme suffit au diagnostic ; l’équipe demande d’éviter d’y inclure les personnes présentes au domicile.
Le technicien reçoit la référence de l’intervention et les éléments utiles, sans accès général aux autres tickets. Le problème est résolu le 10 mars. Selon la règle choisie dans cet exemple, le ticket devient éligible à l’effacement le 10 juin. Une réouverture liée à la même difficulté doit être traitée et documentée ; elle ne justifie pas de repousser artificiellement l’échéance par un simple envoi automatique.
La durée de trois mois et le cycle de sauvegarde de trente jours sont des choix illustratifs à justifier par les besoins et les risques. Les sauvegardes restent isolées des usages courants. Une restauration doit réappliquer les suppressions déjà décidées avant la remise en service : décrire seulement la purge de l’outil principal laisserait une partie du traitement sans règle.
La trace de contrôle renseignée
| Point contrôlé | Résultat dans le cas | Suite donnée |
|---|---|---|
| Périmètre du ticket | Identifiant, référence de prestation et description utiles | Champs retenus dans la fiche SUP-01 |
| Pièce jointe | Photo du mécanisme, sans personne visible | Pièce admise pour le diagnostic, même échéance que le ticket |
| Accès technique | Intervention affectée au technicien concerné | Accès limité au dossier utile, retiré à la fin du besoin |
| Échéance | Résolution le 10 mars ; purge prévue le 10 juin | Date de résolution utilisée comme événement de départ |
| Copies | Ticket principal et pièce jointe ; une copie dans la messagerie de support | Messagerie ajoutée au périmètre de suppression avant validation |
| Sauvegardes | Cycle isolé de trente jours | Règle de réapplication des effacements dans la procédure de restauration |
Cette trace n’a pas à transformer le registre en journal de tous les tickets. Elle montre comment contrôler une fiche sur un échantillon pertinent et conserver la preuve du contrôle dans un dossier lié. Les données individuelles de la cliente ne sont pas ajoutées à la fiche générale du registre.
Quand le contrôle contredit le registre
Dans le premier essai de purge, le ticket disparaît de l’outil, mais la photographie reste accessible dans la messagerie du support. La fiche indiquait uniquement Assistance-01. Le responsable ne déclare pas la mesure opérationnelle : il documente cet écart, identifie les copies de messagerie concernées et organise leur suppression selon la même règle, sous réserve des justifications distinctes réellement applicables.
Il corrige ensuite la fiche et la procédure, puis rejoue le contrôle avec un ticket fictif dont l’échéance est atteinte. Le résultat attendu comprend la pièce jointe, le message associé et la bonne application des restrictions sur les sauvegardes. Si l’outil ne permet pas cette opération, une procédure manuelle peut être retenue seulement si ses moyens et son contrôle rendent la règle applicable ; sinon, il faut modifier le dispositif.
Autre situation : un responsable découvre qu’un prestataire intervient à distance sur la base. La ligne « aucun prestataire » devient inexacte, même si celui-ci est déjà connu du service informatique. Il faut qualifier son rôle, vérifier ses accès, son contrat et les transferts éventuels, puis mettre le registre à jour. Une information manquante appelle une investigation ; elle n’autorise pas à inscrire « aucun » pour terminer le tableau.
Le registre distingue donc le fonctionnement constaté et les corrections décidées. Les mesures projetées ne doivent pas être présentées comme réalisées. Un renvoi vers un plan d’action daté permet de conserver une fiche lisible tout en gardant visibles les écarts.
Une activité n’est pas nécessairement une application
Un logiciel peut gérer plusieurs finalités avec des données et des durées différentes. À l’inverse, une activité peut mobiliser un formulaire, une boîte de réception et un outil métier. Évitez une fiche « logiciel clients » qui empêche de distinguer support, facturation et prospection.
Pour choisir le bon découpage, demandez si les catégories de personnes, les destinataires, les durées et les garanties restent suffisamment homogènes pour être compréhensibles dans une même fiche. La méthode pour rapprocher applications et traitements du registre aide à identifier les oublis.
Dans un groupe, un outil commun ne rend pas toutes les sociétés responsables de toutes les activités. Identifiez l’entité compétente pour chaque périmètre avec le registre RGPD d’un groupe et de ses filiales.
Trame à copier et circuit de validation
Référence / nom de l'activité :
Responsable de traitement et coordonnées :
Responsables conjoints / représentant / DPO, le cas échéant :
Finalités :
Catégories de personnes :
Catégories de données :
Catégories de destinataires :
Transferts : pays ou organisation et documentation applicable :
Délais prévus d'effacement par catégorie :
Description générale des mesures techniques et organisationnelles :
Compléments utiles : base légale, outil, référent métier, version :
Points à vérifier / responsable / échéance :
Le référent métier décrit l’activité, l’équipe technique vérifie les flux et les accès, puis le responsable valide les choix avec le conseil du DPO s’il existe. Une case « à vérifier » accompagnée d’une action est préférable à un « aucun transfert » non contrôlé, mais elle ne dispense pas de terminer la vérification.
À l’arrêt d’une activité, conservez la trace de sa fermeture et de la destination des données. Notre procédure pour fermer un traitement dans le registre traite cette étape.
Ce qu’il faut retenir
- Remplissez les rubriques de l’Art. 30 à partir des flux réels.
- Distinguez les mentions obligatoires des compléments de pilotage.
- Les durées et les mesures d’un exemple ne deviennent pas vos règles par simple copie.
- Un registre peut prendre la forme d’un tableur correctement tenu et accessible.
FAQ
Une PME de moins de 250 salariés est-elle dispensée ?
Pas de manière générale. L’Art. 30(5) maintient l’obligation pour les traitements non occasionnels, susceptibles de comporter un risque, ou portant sur les données particulières de l’Art. 9(1) ou les données pénales de l’Art. 10. Ces critères sont alternatifs.
Faut-il acheter un logiciel ou transmettre le registre à la CNIL ?
L’Art. 30(3) impose une forme écrite, y compris électronique, sans logiciel obligatoire. Le registre doit être mis à la disposition de l’autorité sur demande selon l’Art. 30(4), et non transmis systématiquement. La fiche CNIL sur le registre propose également des supports officiels.
Le registre suffit-il pour être conforme ?
Non. Décrire une durée ou une restriction d’accès ne démontre pas qu’elle est appliquée. Le registre doit permettre de retrouver les décisions et les preuves de leur mise en œuvre.
Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.
Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.