Zasada ograniczenia przechowywania, RODO Art. 5(1)(e), stanowi, że dane osobowe powinny być przechowywane nie dłużej, niż jest to konieczne do realizacji celu, w którym zostały zebrane. Jest to jeden z najłatwiejszych obowiązków do naruszenia przez przypadek, ponieważ dodanie tabeli lub cache jest rutynową czynnością, a dodanie mechanizmu usuwania jest częścią, o której wszyscy zapominają. Oto jak błąd przedostaje się do kodu i jak przegląd go wykrywa.
Jak błąd przedostaje się do kodu
Funkcjonalność wymaga zapamiętania czegoś o użytkowniku: interakcji z obsługą, urządzenia, przesłanego dokumentu. Dodawana jest nowa tabela, funkcjonalność działa, PR jest zatwierdzany. Nic nie wygląda na błędne, ponieważ nic nie jest błędne jako kod. Brakuje czegoś niewidocznego: nie ma określonego limitu retencji, nie ma zadania usuwania po upływie terminu, a często nie ma ścieżki, by istniejący proces usuwania konta dotarł do nowego magazynu danych.
Sześć miesięcy później istnieją dane osobowe bez zdefiniowanego okresu przechowywania, a być może dane, które przetrwają żądanie usunięcia, co staje się również problemem zgodnie z Art. 17.
Na co zwrócić uwagę w diffie
Gdy zmiana wprowadza nowy magazyn danych osobowych, zadaj w przeglądzie trzy pytania: jaki jest limit retencji, co usuwa dane po jego upływie i czy ścieżka usuwania dociera do niego. Jeśli którejkolwiek odpowiedzi brakuje, zmiana jest niekompletna z punktu widzenia ochrony danych, nawet jeśli jest kompletna jako funkcjonalność.
Zazwyczaj sygnałem jest migracja lub model, który dodaje kolumnę z danymi osobowymi bez odpowiedniej zmiany w ścieżce retencji lub usuwania w tym samym PR.
Co sygnalizuje heygrc
heygrc został zaprojektowany, aby rozpoznawać nowy magazyn danych osobowych wprowadzany bez ścieżki retencji lub usuwania i zgłaszać to jako uwagę w przeglądzie, powoływając się na Art. 5(1)(e), z uwzględnieniem Art. 17 tam, gdzie dotyczy to usuwania. Celem jest ujawnienie brakującej części zmiany, gdy autor nadal nad nią pracuje, a nie podejmowanie decyzji prawnych.