Collecter plus que nécessaire pour la finalité.
La minimisation des données, Art. 5(1)(c), stipule que vous devez collecter et conserver uniquement les données personnelles strictement nécessaires à une finalité, et rien de plus. Dans le code, cette règle est violée dès qu'une modification commence à capturer, journaliser ou envoyer plus de données personnelles que ce que la fonctionnalité exige réellement, ce qui est facile à faire car envoyer l'objet entier demande généralement moins de travail que de sélectionner les champs nécessaires.
The shapes the same control failure takes.
La minimisation est rarement violée intentionnellement. Elle l'est parce que la solution pratique transporte plus que le strict nécessaire. Les formes récurrentes :
Une charge utile s'élargit à l'objet complet
Un événement, une requête ou un message est modifié pour envoyer un objet utilisateur ou client complet alors qu'un identifiant et un ou deux champs auraient suffi.
Un nouveau champ capture plus que nécessaire
Un formulaire, un modèle ou une importation commence à collecter des données personnelles que la fonctionnalité n'utilise pas, simplement parce qu'elles étaient disponibles.
Une ligne de journal contient des données personnelles
Un journal de débogage enregistre une requête ou un enregistrement complet, plaçant des données personnelles dans un stockage de logs qui n'en avait pas besoin.
Un tiers reçoit plus que nécessaire
Une intégration d'analyse, de support ou de marketing commence à recevoir des champs qu'elle n'utilise pas, élargissant ainsi les détenteurs des données.
Un texte libre est transmis sans rédactions
Un champ pouvant contenir des données personnelles (une note, un message) est transmis ou stocké sans être réduit à ce que la finalité exige.
Un événement d'analyse qui envoie l'utilisateur complet.
Un produit souhaite suivre les inscriptions dans son outil d'analyse. L'appel le plus rapide envoie l'objet utilisateur entier comme propriétés d'événement, y compris l'email, le nom et l'adresse, alors que l'analyse n'a besoin que d'un identifiant et d'un plan.
analytics.track("signup", {- userId: user.id, plan: user.plan,+ ...user, // send everything, filter later})Envoyer l'objet utilisateur complet transmet l'email, le nom et l'adresse au fournisseur d'analyse, soit plus de données personnelles que nécessaire pour suivre une inscription, et à un nouveau sous-traitant. L'Art. 5(1)(c) (minimisation des données) exige qu'une modification ne transporte que les données personnelles strictement nécessaires à la finalité. Envoyez l'identifiant et les champs spécifiques réellement utilisés par l'analyse, et non l'enregistrement complet.
La minimisation est vérifiée à chaque flux.
Une revue de protection des données examine quelles données personnelles chaque activité de traitement collecte et envoie, et les compare à la finalité déclarée : tout ce qui dépasse le nécessaire constitue un constat. Les nouveaux flux de données vers des tiers font l'objet d'une attention particulière, car ils élargissent les détenteurs des données et peuvent soulever des questions de transfert. Ces flux sont créés dans le code, une intégration ou un événement à la fois, c'est là que la décision de minimisation est effectivement prise.
Une revue, pas un avis juridique.
heygrc signale les modifications qui concernent la minimisation des données et cite l'article afin que la correction ait lieu dans la pull request. Il ne détermine pas votre base légale ni ne tient à jour vos registres de traitement. Il détecte le moment où une modification commence à transporter plus de données personnelles que nécessaire, directement dans le diff.