Dane osobowe, które zapomniały mieć koniec.
Ograniczenie przechowywania, Art. 5(1)(e), stanowi, że dane osobowe powinny być przechowywane w formie umożliwiającej identyfikację osób przez czas nie dłuższy niż jest to konieczne do realizacji celu, w jakim zostały zebrane. Jest to jeden z najłatwiejszych obowiązków do naruszenia nieumyślnie, ponieważ dodanie miejsca do przechowywania czegoś jest rutynowe, a dodanie części, która usunie to później, to część, o której wszyscy zapominają.
The shapes the same control failure takes.
Zmiana prawie nigdy nie polega na celowym przechowywaniu czegoś na zawsze. To zwykle brakująca połowa w innej rozsądnej zmianie. Oto formy, które powtarzają się najczęściej.
Nowe miejsce przechowywania bez określonego terminu usunięcia
Migracja lub model dodaje tabelę, pamięć podręczną lub indeks zawierający dane osobowe, ale nic nie ustala limitu retencji ani terminu ważności, więc dane po prostu się gromadzą.
Zadanie retencji zostało usunięte lub wyłączone
Zaplanowane czyszczenie, TTL w pamięci podręcznej lub zadanie usuwania zostało usunięte podczas refaktoryzacji lub zakomentowane, aby rozwiązać niepowiązany problem, a dane, które wcześniej były usuwane, teraz pozostają.
Okres retencji cicho się wydłuża
Okres retencji został wydłużony (90 dni staje się nieokreślone, lub domyślna konfiguracja ulega zmianie) bez uzasadnionego celu lub udokumentowanego powodu, aby przechowywać dane dłużej.
Miękkie usunięcie zachowuje wszystko
Usunięcie zostało zmienione na flagę (kolumna deleted_at), więc wiersz i zawarte w nim dane osobowe pozostają tam na zawsze, co jest retencją, a nie usunięciem.
Usunięcie nie dotyczy nowej kopii
Nowe miejsce, do którego trafiają dane osobowe (eksport, zlew analityczny, druga baza danych), nie jest powiązane ze ścieżką usuwania konta, więc kopia przetrwa usunięcie. To również problem Art. 17.
Usunięte zadanie czyszczenia, które zachowuje nieaktywnych użytkowników na zawsze.
Zaplanowane zadanie usuwało dane osobowe nieaktywnych użytkowników od dłuższego czasu, ale zostało usunięte, być może było zbyt głośne, a być może wydawało się bezpieczne zachować dane. Efekt jest taki, że dane osobowe nie mają teraz określonego terminu usunięcia.
schedules: reconcile: { cron: "0 2 * * *" }- purge_inactive: { cron: "0 3 * * *", delete: users, older_than: P2Y }To usuwa jedyną rzecz, która usuwała dane osobowe nieaktywnych użytkowników, więc teraz są one przechowywane bez określonego terminu. Art. 5(1)(e) (ograniczenie przechowywania) zakłada, że dane osobowe powinny być przechowywane nie dłużej, niż jest to konieczne do realizacji celu. Jeśli zadanie było zbyt agresywne lub głośne, popraw jego harmonogram lub zakres, ale zachowaj ścieżkę retencji zamiast usuwać ją całkowicie.
Retencja to także problem usuwania.
Ograniczenie przechowywania jest oceniane na podstawie rejestrów przetwarzania i harmonogramu retencji: dane znalezione poza swoim przeznaczonym celem to luka, której szuka przegląd. Jest ono powiązane z prawem do usunięcia, Art. 17, ponieważ każde miejsce, w którym przechowywane są dane osobowe, to miejsce, do którego musi dotrzeć żądanie usunięcia. Nowe miejsce przechowywania bez retencji to zwykle także miejsce, o którym ścieżka usuwania konta nie wie, więc oba obowiązki są często naruszane razem, w tym samym pull request.
Przegląd, a nie porada prawna.
heygrc sygnalizuje zmiany, które dotyczą ograniczenia przechowywania, i cytuje odpowiedni artykuł, aby naprawa nastąpiła w pull request. Nie ustala okresów retencji, nie wydaje orzeczeń prawnych ani nie prowadzi rejestrów przetwarzania. Wykrywa zmianę na wczesnym etapie, aby pytanie o retencję zostało rozwiązane podczas przeglądu, a nie po incydencie.