Persoonsgegevens die vergeten zijn een eind te hebben.
Opslagbeperking, Art. 5(1)(e), stelt dat persoonsgegevens in een vorm die personen identificeert niet langer mogen worden bewaard dan noodzakelijk is voor het doel waarvoor ze zijn verzameld. Het is een van de plichten die het gemakkelijkst per ongeluk worden geschonden, omdat het toevoegen van een opslaglocatie routine is, en het toevoegen van het deel dat de gegevens later verwijdert het deel is dat iedereen vergeet.
The shapes the same control failure takes.
De wijziging is bijna nooit 'bewaar dit voor altijd met opzet'. Het is een ontbrekend deel van een verder redelijke wijziging. Dit zijn de terugkerende patronen.
Een nieuwe opslaglocatie zonder einddatum
Een migratie of model voegt een tabel, cache of index toe die persoonsgegevens bevat, en er wordt geen bewartermijn of vervaldatum ingesteld, waardoor de gegevens eenvoudigweg blijven ophopen.
Een bewartermijn-taak wordt verwijderd of uitgeschakeld
Een geplande verwijdering, een TTL op een cache of een opschoningstaak wordt tijdens een refactor verwijderd of uitgeschakeld om een niet-gerelateerd probleem op te lossen, en de gegevens die voorheen werden verwijderd, blijven nu bewaard.
Een termijn wordt stilletjes verlengd
Een bewartermijn wordt verlengd (90 dagen wordt onbepaald, of een standaardconfiguratie verandert) zonder een doel of gedocumenteerde reden om de gegevens langer te bewaren.
Een soft delete bewaart alles
Een verwijdering wordt gewijzigd in een vlag (een deleted_at-kolom), zodat de rij en de persoonsgegevens daarin onbepaald bewaard blijven, wat neerkomt op bewaring, niet op verwijdering.
Verwijdering bereikt de nieuwe kopie niet
Een nieuwe locatie waar persoonsgegevens terechtkomen (een export, een analytics-sink, een tweede database) is niet gekoppeld aan het pad voor 'verwijder mijn account', waardoor een kopie de verwijdering overleeft. Dit is ook een probleem met Art. 17.
Een verwijderde opschoningstaak die inactieve gebruikers voor altijd bewaart.
Een geplande taak die de persoonsgegevens van lang inactieve gebruikers verwijderde, is verwijderd, misschien was deze luidruchtig, misschien leek het veilig om de gegevens te bewaren. Het gevolg is dat persoonsgegevens nu geen gedefinieerde einddatum meer hebben.
schedules: reconcile: { cron: "0 2 * * *" }- purge_inactive: { cron: "0 3 * * *", delete: users, older_than: P2Y }Dit verwijdert het enige wat persoonsgegevens van inactieve gebruikers verwijderde, waardoor deze nu zonder einddatum worden bewaard. Art. 5(1)(e) (opslagbeperking) verwacht dat persoonsgegevens niet langer worden bewaard dan nodig is voor het doel. Als de taak te agressief of luidruchtig was, pas dan de planning of reikwijdte aan, maar behoud een bewartermijnpad in plaats van deze volledig te verwijderen.
Bewaring is ook een verwijderingsprobleem.
Opslagbeperking wordt beoordeeld aan de hand van uw verwerkingsregisters en uw bewartermijnschema: gegevens die langer worden bewaard dan het gestelde doel, zijn de hiaten waar een review naar zoekt. Het is verbonden met het recht op vergetelheid, Art. 17, omdat elke locatie waar persoonsgegevens worden bewaard een locatie is die een verwijderingsverzoek moet bereiken. Een nieuwe opslaglocatie zonder bewartermijn is meestal ook een locatie die het pad voor 'verwijder mijn account' niet kent, waardoor beide plichten vaak in dezelfde pull request worden geschonden.
Een review, geen juridisch advies.
heygrc markeert wijzigingen die opslagbeperking raken en verwijst naar het artikel, zodat de oplossing in de pull request wordt doorgevoerd. Het stelt uw bewartermijnen niet in, doet geen juridische beoordeling of onderhoudt uw verwerkingsregisters. Het detecteert de wijziging vroeg, zodat een bewartermijnvraag tijdens de review wordt beantwoord in plaats van na een incident.