L’article 33(5) du RGPD impose au responsable de traitement de documenter toute violation de données personnelles — y compris celles qui ne sont pas notifiées à la CNIL : « le responsable du traitement documente toute violation […] en indiquant les faits concernant la violation, ses effets et les mesures prises pour y remédier ». C’est le registre des violations. Sa finalité est explicite dans le texte : permettre à l’autorité de contrôle de vérifier le respect de l’article 33. Un registre vide ne prouve à lui seul ni l’absence d’incident ni une défaillance : l’organisme doit pouvoir expliquer comment il détecte les incidents et documente ceux qui constituent des violations.
Voici le modèle complet, champ par champ, avec deux exemples remplis. Pour la procédure amont (détection, qualification, notification 72 h), voir notre modèle de procédure de violation et notre guide de la notification de violation.
Ce que le registre doit contenir
Le texte impose trois blocs : les faits, les effets, les mesures. Les lignes directrices EDPB 9/2022 recommandent d’y ajouter le raisonnement de notification — c’est la partie que la CNIL scrute : pour chaque violation non notifiée, vous devez pouvoir justifier pourquoi le risque était improbable. Champs recommandés :
- Identification : numéro, dates (survenance, détection, clôture), source de détection
- Faits : nature de la violation (confidentialité / intégrité / disponibilité), description, cause, systèmes concernés
- Données et personnes : catégories et volumes de données, catégories et nombre de personnes, données sensibles ou hautement personnelles
- Effets : conséquences probables pour les personnes, évaluation du risque (improbable / risque / risque élevé) avec justification
- Mesures : confinement, remédiation, prévention de la récurrence
- Décisions : notification CNIL (oui/non + motif + date + référence), communication aux personnes (oui/non + motif + date), sous-traitant impliqué, autres autorités (ANSSI, assureur, plainte pénale)
Modèle de registre des violations (template tableau)
REGISTRE DES VIOLATIONS DE DONNÉES PERSONNELLES — [Société] Tenu par : [DPO / référent RGPD] — conformément à l’article 33(5) RGPD
Champ Violation n° 2026-001 Violation n° 2026-002 Date de survenance 14/03/2026 02/05/2026 (estimée) Date et source de détection 14/03/2026, signalement du salarié 06/05/2026, alerte SOC Nature Confidentialité Confidentialité + disponibilité Description des faits Email RH contenant les bulletins de paie de 12 salariés adressé par erreur à un destinataire externe Compromission d’un compte administrateur par phishing ; chiffrement partiel du serveur de fichiers ; exfiltration suspectée Cause Erreur humaine (autocomplétion) Phishing + absence de MFA sur le compte Systèmes concernés Messagerie Serveur de fichiers, AD Catégories de données Identité, NIR, rémunération Identité, coordonnées, contrats clients Personnes concernées 12 salariés ~3 400 clients Données sensibles / à risque NIR, données financières Non, mais volume significatif Conséquences probables Divulgation limitée à un destinataire identifié Usurpation d’identité, phishing ciblé Évaluation du risque Risque (limité : destinataire identifié, suppression confirmée) Risque élevé Mesures immédiates Demande de suppression confirmée par écrit ; rappel procédure au service RH Isolement du serveur, révocation des comptes, restauration sauvegardes J-1 Mesures correctives Activation du délai d’envoi différé ; formation ciblée MFA généralisé ; EDR déployé ; audit des habilitations Notification CNIL Oui — 16/03/2026 — réf. [n°] Oui — 07/05/2026 (initiale), complément 12/05 — réf. [n°] Si non-notification : justification — — Communication aux personnes Non — risque évalué comme non élevé après confirmation de la suppression par le destinataire ; motif consigné le 15/03 Oui — email du 09/05 + FAQ dédiée Sous-traitant impliqué Non Non Autres démarches — Dépôt de plainte le 07/05 ; assureur cyber notifié Statut / clôture Clôturée le 20/03/2026 Clôturée le 30/06/2026 — REX du 15/06
Un troisième cas type à documenter : la violation non notifiée. Exemple : perte d’un ordinateur portable intégralement chiffré (clé non compromise) → risque improbable, pas de notification, mais ligne au registre avec la justification « chiffrement AES-256, authentification pré-boot, clé non compromise, effacement à distance déclenché » — c’est exactement le cas visé par l’article 33(5).
Comment adapter ce modèle
Reliez chaque violation à votre registre des traitements. La ligne « systèmes concernés » doit renvoyer aux traitements affectés : c’est ce qui permet d’évaluer rapidement les catégories de données et de personnes, et de nourrir la mise à jour de votre analyse de risques article 32.
Documentez le raisonnement, pas seulement la conclusion. « Risque improbable » sans justification ne protège pas ; la grille EDPB/ENISA (nature des données, facilité d’identification, gravité, caractéristiques des personnes) doit transparaître dans le champ évaluation. En cas de désaccord ultérieur de la CNIL, un raisonnement documenté et défendable au moment des faits pèse lourd.
Intégrez les violations chez vos sous-traitants. L’article 33(2) leur impose de vous alerter ; leur violation est la vôtre au regard du registre. Ajoutez le champ sous-traitant et vérifiez que vos DPA prévoient un objectif d’alerte rapide adapté au service et la transmission des éléments de l’article 33(3).
Construire une ligne que l’on peut relire deux ans plus tard
Le minimum juridique de l’article 33(5) tient en trois éléments : faits, effets et mesures correctrices. Une colonne « décision » aide à démontrer comment l’article 33(1) a été appliqué ; les dix-huit champs proposés dans le tableau sont une organisation pratique, pas une liste imposée par le règlement. La CNIL recommande un registre interne de toutes les violations, même lorsqu’elles ne sont pas notifiées. Le modèle peut être un tableur protégé, un dossier structuré ou un outil spécialisé, pourvu que les informations restent compréhensibles, traçables et accessibles aux personnes autorisées.
Inscrivez d’abord ce qui est connu au moment de la découverte : une date de survenance estimée doit être étiquetée comme telle. Ajoutez ensuite chaque élément nouveau avec sa date et sa source. Si un prestataire indique d’abord « dix comptes potentiellement exposés », puis confirme trois accès effectifs, conservez les deux états au lieu d’écraser le premier. Cette chronologie explique pourquoi la décision de notifier a changé. Elle évite aussi de donner l’illusion qu’un analyste disposait dès le départ d’informations apprises une semaine plus tard.
Une ligne ne doit pas contenir de secrets techniques réutilisables ni la copie de toutes les données compromises. Renvoyez vers un dossier de preuve à accès restreint : journaux, messages du prestataire, captures, notification à la CNIL, version de la communication aux personnes. Le dossier doit permettre de vérifier l’heure de prise de connaissance et le raisonnement suivi. Si la preuve contient elle-même des données personnelles, appliquez la minimisation et une règle de conservation distincte. Le responsable peut conserver la description de l’événement sans garder indéfiniment les exports bruts.
Exemple commenté : décision de ne pas notifier
Supposons qu’un ordinateur portable professionnel soit perdu dans un train. Le disque est chiffré avant la perte, la clé est protégée séparément et l’entreprise n’observe aucun accès à distance. Il reste une violation de disponibilité si des données personnelles ne sont plus accessibles localement ; si des copies fiables existent et que les protections sont vérifiées, le risque pour les personnes peut être jugé improbable. La ligne de registre indique le type et les catégories de données, l’heure de la perte et de la découverte, l’état du chiffrement, la disponibilité des sauvegardes et le raisonnement qui conduit à ne pas notifier. « Portable chiffré » seul ne suffit pas si l’on ignore où se trouvait la clé ou si le mot de passe était collé à l’appareil.
Autre hypothèse : une facture part au mauvais client, qui confirme immédiatement sa suppression. La confirmation réduit le risque, mais ne démontre pas mécaniquement qu’il est improbable. Il faut examiner si la facture contient des coordonnées bancaires, des informations de santé, des données d’une personne vulnérable ou des éléments de conflit commercial. Notez l’identité et la fiabilité du destinataire, la possibilité de copie, la réponse obtenue, puis la raison de la décision. La procédure de gestion des violations décrit qui rassemble ces éléments et à quel moment ; le registre en garde la mémoire.
Distinguer trois dates souvent confondues
La date de survenance correspond à l’incident lui-même et peut être inconnue au début. La date de détection correspond au premier signal interne ou externe. La date de prise de connaissance du responsable du traitement suppose, selon les lignes directrices 9/2022 du CEPD, un degré raisonnable de certitude qu’une violation de données personnelles a eu lieu. La troisième importe pour le délai de notification de 72 heures si la violation est susceptible d’engendrer un risque. Écrivez les trois dates et les preuves qui les établissent au lieu de ne garder qu’une date « incident ».
Lorsqu’un sous-traitant découvre la violation, son devoir d’alerte dans les meilleurs délais vient de l’article 33(2). Le responsable du traitement évalue ensuite le risque et décide de la notification ; le fait que le prestataire ait déclaré l’incident à un autre client ne transfère pas cette décision. Faites figurer l’heure du message reçu, les questions posées et les réponses obtenues. Un accord de sous-traitance peut imposer une alerte contractuelle plus rapide, mais ne remplace pas la qualification juridique.
Organiser l’accès et la conservation du registre
Le registre révèle parfois des failles encore exploitables, les identités de victimes et des discussions internes. Donnez un droit d’écriture à un cercle limité, un droit de consultation selon les fonctions, et prévoyez une exportation pour le contrôle. Gardez une trace des rectifications : corriger une erreur de date est normal, effacer l’ancienne décision sans explication nuit à la preuve. Un bilan périodique peut agréger les incidents par cause et vérifier que les actions ont été réalisées ; il ne faut pas transformer chaque incident en indicateur de performance individuel qui dissuaderait le signalement.
Aucun article du RGPD ne fixe « cinq ans » ou « conservation perpétuelle » pour ce registre. Déterminez une durée au regard de la finalité de preuve, des risques, des obligations applicables et des délais de contestation pertinents ; justifiez-la dans votre politique de conservation. Séparez la fiche synthétique des pièces techniques dont l’utilité peut décroître plus vite. Lorsque le dossier est clos, revoyez les accès, les copies et les liens vers les systèmes concernés. Le registre demeure ainsi un outil de responsabilité vérifiable, sans devenir une nouvelle source d’exposition.
Erreurs courantes
- Ne documenter que les violations notifiées : contresens direct sur l’article 33(5), qui vise toutes les violations. Les violations non notifiées doivent aussi laisser une trace permettant de comprendre l’évaluation du risque.
- Confondre registre des violations et registre des traitements : deux documents distincts, deux fondements (articles 33(5) et 30), deux logiques — l’un est événementiel, l’autre structurel.
- Registre reconstruit a posteriori : une reconstitution tardive rend plus difficile la preuve des décisions prises avec les informations disponibles à l’époque. Documentez au fil de l’eau, dans les jours suivant chaque incident.
- Aucune purge ni politique de conservation : le RGPD ne fixe pas une durée universelle pour le registre : définissez une durée justifiée et réévaluez-la, mais les pièces annexes contenant des données personnelles (exports, logs) suivent vos durées de conservation.
- Ne jamais l’exploiter : un registre est aussi un outil de pilotage — trois emails mal adressés au même trimestre justifient une mesure structurelle (envoi différé, DLP), pas trois lignes de plus. Présentez une synthèse annuelle à la direction, comme le fait un DPO dans son rapport.
FAQ
Le registre des violations est-il obligatoire même sans aucune violation ?
L’article 33(5) impose de documenter chaque violation constatée ; il ne présume pas qu’un organisme en subit un nombre donné. Préparez un registre vide et une procédure de gestion des violations afin que le premier événement qualifié puisse être consigné sans délai.
Qui doit tenir le registre : le responsable de traitement ou le sous-traitant ?
L’article 33(5) vise le responsable de traitement. Le sous-traitant a l’obligation d’alerter son client (article 33(2)) et, en pratique, tient son propre registre d’incidents au titre de ses mesures article 32 et de ses engagements contractuels — les obligations du sous-traitant le rendent d’ailleurs directement sanctionnable.
La CNIL peut-elle demander le registre des violations ?
Oui : c’est la finalité même du texte (« permettre à l’autorité de contrôle de vérifier le respect du présent article »), et il figure dans les pièces demandées lors des contrôles. Le refus de communication est un manquement à l’obligation de coopération (article 31).
Que risque-t-on en cas de registre absent ou lacunaire ?
Le manquement à l’article 33 relève du plafond de 10 millions d’euros ou 2 % du chiffre d’affaires mondial (article 83(4)(a)). En pratique, le registre lacunaire aggrave surtout le dossier lors d’une violation notifiée tardivement : impossible de démontrer votre bonne foi sans documentation contemporaine des faits. Voir les lignes directrices EDPB 9/2022 et le téléservice de notification CNIL.
Conclusion
Le registre des violations peut tenir dans un tableau bien conçu : un tableau, dix-huit champs, une discipline de remplissage au fil de l’eau. Copiez le template ci-dessus, créez le registre aujourd’hui même à vide, reliez-le à votre procédure de violation et à votre registre des traitements. Le jour où l’incident sérieux survient — ou celui où la CNIL contrôle — ce tableau aidera à démontrer les décisions et mesures réellement prises.