Inżynierowie szukający kontroli kodu zgodnych z RODO zwykle oczekują jednej rzeczy: krótkiej listy obowiązków prawnych, które mogą zostać naruszone w typowym pull request, a nie pełnego podręcznika programu ochrony prywatności. Rozporządzenie dotyczy głównie procesów, dokumentacji i środków organizacyjnych. Mniejsza, ale stała część obowiązków dotyczy kodu: co jest przechowywane, jak długo, czy ścieżka usuwania dociera do każdej kopii, co jest domyślnie ujawniane, jak zabezpieczone jest przetwarzanie oraz gdzie dane są hostowane.
Ten przewodnik jest taką mapą. Celowo nie jest to opis pojedynczego błędu retencji (znajduje się pod /guides/catching-a-gdpr-retention-bug-in-code-review) ani pogłębiona analiza kontroli (dostępne pod /frameworks/gdpr). To lista kontrolna dla code review: które artykuły wymienić, jak wygląda zmiana i co recenzent może zapytać, nie stając się doradcą prawnym.
Artykuły, które zwykle pojawiają się w diffie
Artykuł 5 ust. 1 lit. c (minimalizacja danych): zmiana zaczyna zbierać lub logować więcej danych osobowych, niż wymaga cel (pełne treści żądań, pełne rekordy tożsamości kopiowane do dodatkowego magazynu). Artykuł 5 ust. 1 lit. e (ograniczenie przechowywania): nowy magazyn lub pamięć podręczna danych osobowych jest wprowadzany bez określenia okresu retencji albo okno czyszczenia jest wydłużane bez uzasadnienia. Artykuł 17 (prawo do usunięcia): ścieżka usuwania nie dociera do pamięci podręcznej, indeksu wyszukiwania, eksportu analitycznego lub kopii przetwarzającej. Artykuł 25 (ochrona danych od samego początku i domyślnie): pole osobowe staje się widoczne lub udostępniane domyślnie wszystkim użytkownikom, albo domyślne zabezpieczenie zostaje wyłączone. Artykuł 32 (bezpieczeństwo przetwarzania): osłabione zostają szyfrowanie, kontrola dostępu lub środki integralności dotyczące danych osobowych (obniżony poziom TLS, magazyn tokenów w postaci jawnej, otwarta ścieżka administracyjna). Artykuł 44 (przenoszenie danych): dane osobowe są przenoszone do nowego regionu lub podmiotu przetwarzającego w państwie trzecim bez uzgodnionej historii transferu w programie ochrony prywatności.
Te opisy są prostym językiem dla inżynierów, a nie dosłownym tekstem Rozporządzenia. Gdy ustalenie odnosi się do konkretnego artykułu, jest to sygnał dla autora i kontaktów ds. prywatności, a nie orzeczenie o niezgodności przetwarzania z prawem.
Przykład praktyczny: ochrona danych domyślnie zmieniona dla „wygody wsparcia”
Zespół wsparcia chce szybszego rozpoznawania zgłoszeń. Inżynier otwiera pull request, który modyfikuje API profilu klienta tak, aby każda uwierzytelniona rola personelu otrzymywała domyślnie pełne imię i nazwisko, adres e-mail, numer telefonu oraz ostatnie cztery cyfry płatności w punkcie końcowym listy, a nie tylko na jawne żądanie „expand=pii”. Zmiana jest niewielka: jedna flaga w serializatorze zmieniona z false na true. Testy są aktualizowane, aby oczekiwać bogatszej ładunku. W code review dyskutuje się o rozmiarze odpowiedzi i nagłówkach pamięci podręcznej. Nic nie wygląda na błąd bezpieczeństwa; uwierzytelnianie nadal działa.
Zmiana dotyczy Artykułu 25 (ochrona danych od samego początku i domyślnie): dane osobowe są teraz domyślnie ujawniane szerszemu gronu wewnętrznych odbiorców niż w poprzednim, bardziej restrykcyjnym modelu. Bezpieczniejsza wersja zachowuje wąskie domyślnie ustawienia i wymaga jawnego, audytowanego rozszerzenia dla narzędzi wsparcia. To inny typ błędu niż błąd retencji (Artykuł 5 ust. 1 lit. e dotyczący nowego magazynu bez czyszczenia) czy czysto minimalizacyjne logowanie (Artykuł 5 ust. 1 lit. c dotyczący treści żądań). Recenzent świadomy zgodności powołuje się na Artykuł 25 (i często na Artykuł 5 ust. 1 lit. c jako zasadę wspierającą) w PR, dopóki flaga jest łatwa do cofnięcia.
Co zapytać w recenzji, nie stając się IOD
Dla każdej zmiany dotyczącej danych osobowych: jakie pola są nowe, kto może je domyślnie widzieć, jak długo istnieją oraz czy ścieżka usuwania lub eksportu nadal do nich dociera. W przypadku zmian regionu lub dostawcy: dokąd trafiają dane i czy ochrona prywatności już śledzi tego podmiotu przetwarzającego lub transfer. W przypadku PR „porządkujących”: czy usunęliśmy szyfrowanie, kontrole dostępu lub linie audytu chroniące dane osobowe (związane z Artykułem 32).
Nie musisz cytować Rozporządzenia. Musisz odmówić scalania, gdy odpowiedź brzmi „nieznane”, dopóki ktoś nie przejmie odpowiedzialności za krok związany z prywatnością, lub przywrócić bezpieczniejsze domyślnie ustawienia.
Rola heygrc i granica odpowiedzialności
heygrc jest zaprojektowany do analizowania każdego pull requesta w oparciu o wybrane frameworki, w tym RODO (jeśli jest włączone), oraz do identyfikowania artykułów, których zmiana może dotyczyć (np. Artykuł 25 w przypadku poszerzonego domyślnego ładunku). Nie decyduje o podstawie prawnej, nie przeprowadza DPIA, nie utrzymuje RoPA, nie zatwierdza transferów ani nie zastępuje IOD. Pozytywna recenzja nie jest równoznaczna z zatwierdzeniem przez organ nadzorczy.
Recenzenci błędów i jakości pozostają w tym samym PR. Pytają, czy kod jest poprawny. Pytania dotyczące RODO sprawdzają, czy obowiązki związane z danymi osobowymi są nadal przestrzegane. Uruchom obie recenzje.