Uwzględnianie ochrony prywatności w fazie projektowania zgodnie z art. 25 RODO: Przewodnik wdrażania dla zespołów produktowych i inżynieryjnych

Artykuł 25 RODO ustanawia dwa uzupełniające się obowiązki: ochronę danych w fazie projektowania i domyślną ochronę danych. Nie są to cele aspiracyjne. Są to prawnie wiążące wymogi, które mają zastosowanie do każdego administratora, podlegające karze grzywny w wysokości do 10 mln EUR lub 2% rocznego światowego obrotu na mocy art. 83 ust. 4. Jednak dla wielu zespołów produktowych i inżynieryjnych przełożenie tych zobowiązań prawnych na praktyczne procesy rozwoju pozostaje wyzwaniem.

Niniejszy przewodnik wypełnia lukę między tekstem regulacyjnym a codziennym tworzeniem oprogramowania. Zapewnia on praktyczne ramy dla włączenia prywatności do cyklu życia produktu, od początkowego projektu po wdrożenie i nie tylko.

Zrozumienie artykułu 25

Art. 25 ust. 1 wymaga od administratora wdrożenia odpowiednich środków technicznych i organizacyjnych w celu skutecznego wdrożenia zasad ochrony danych oraz zintegrowania niezbędnych zabezpieczeń z przetwarzaniem. Obowiązek ten ma zastosowanie w momencie określania środków przetwarzania oraz w momencie samego przetwarzania.

Art. 25 ust. 2 wymaga, aby domyślnie przetwarzane były tylko te dane osobowe, które są niezbędne do każdego konkretnego celu przetwarzania. Dotyczy to ilości gromadzonych danych, zakresu przetwarzania, okresu przechowywania i dostępności. Domyślnie dane osobowe nie mogą być udostępniane bez indywidualnej interwencji nieokreślonej liczbie osób fizycznych.

Wytyczne EROD 4/2019 w sprawie art. 25 wyjaśniają, że obowiązek wdrożenia ochrony danych w fazie projektowania jest stałym, dynamicznym wymogiem, który musi być oceniany w sposób ciągły przez cały cykl życia przetwarzania.

7 podstawowych zasad

Fundamentalne ramy Privacy by Design Ann Cavoukian, pierwotnie opracowane w latach 90-tych XX wieku, pozostają najczęściej przywoływanym modelem koncepcyjnym. Te siedem zasad stanowi filozoficzną podstawę artykułu 25:

1. Proaktywne, a nie reaktywne; zapobiegawcze, a nie naprawcze. Proszę przewidywać i zapobiegać zdarzeniom naruszającym prywatność, zanim do nich dojdzie. Proszę nie czekać, aż zagrożenia dla prywatności się zmaterializują.
2. Prywatność jako ustawienie domyślne. Proszę upewnić się, że dane osobowe są automatycznie chronione w każdym systemie. Osoba fizyczna nie powinna podejmować żadnych działań w celu ochrony swojej prywatności.
3. Prywatność wbudowana w projekt. Proszę wbudować prywatność w projekt i architekturę systemów informatycznych i praktyk biznesowych. Prywatność nie jest dodatkiem.
4. Pełna funkcjonalność: suma dodatnia, a nie zerowa. Proszę uwzględnić wszystkie uzasadnione interesy i cele. Prywatność nie powinna odbywać się kosztem funkcjonalności, a funkcjonalność nie powinna odbywać się kosztem prywatności.
5. Kompleksowe bezpieczeństwo: pełna ochrona cyklu życia. Zapewnienie środków bezpieczeństwa adekwatnych do danych w całym cyklu ich życia, od gromadzenia po usuwanie.
6. Widoczność i przejrzystość: proszę zachować otwartość. Proszę zapewnić wszystkich interesariuszy, że procesy obejmujące dane osobowe działają zgodnie z deklarowanymi obietnicami i celami, z zastrzeżeniem niezależnej weryfikacji.
7. Poszanowanie prywatności użytkownika: proszę skupić się na użytkowniku. Architekci i operatorzy muszą dbać o interesy poszczególnych osób, oferując silne domyślne ustawienia prywatności, odpowiednie powiadomienia i przyjazne dla użytkownika opcje.

Włączanie ochrony prywatności w fazie projektowania do zwinnych przepływów pracy

Privacy by Design jest często postrzegane jako niekompatybilne ze zwinnym rozwojem. W praktyce, przy odpowiednim podejściu, w naturalny sposób integruje się z przepływami pracy opartymi na sprintach.

Planowanie sprintu

Podczas planowania sprintu każda historia użytkownika, która dotyczy danych osobowych, powinna wywołać ocenę prywatności. Proszę dodać listę kontrolną prywatności do szablonu historii:

• Czy ta funkcja gromadzi nowe dane osobowe?
• Czy ta funkcja zmienia sposób przetwarzania istniejących danych osobowych?
• Czy ta funkcja udostępnia dane osobowe nowym odbiorcom?
• Czy ta funkcja obejmuje zautomatyzowane podejmowanie decyzji lub profilowanie?
• Czy funkcję można wdrożyć przy użyciu mniejszej ilości danych osobowych (minimalizacja danych)?

Jeśli którakolwiek z odpowiedzi jest twierdząca, historia wymaga przeglądu prywatności przed rozpoczęciem wdrażania. Przegląd ten może zostać przeprowadzony przez inspektora ochrony danych, inżyniera ds. prywatności lub przeszkolonego członka zespołu, w zależności od złożoności.

Historie użytkownika z wymaganiami dotyczącymi prywatności

Wymagania dotyczące prywatności powinny być wyraźnie określone w historiach użytkownika. Na przykład:

Standardowa historia użytkownika: "Jako użytkownik chcę wyświetlić historię moich zamówień, aby móc śledzić moje zakupy".

Zwiększona prywatność: "Jako użytkownik chcę wyświetlić historię moich zamówień, aby móc śledzić moje zakupy". Kryteria akceptacji: (1) Wyświetlane są tylko zamówienia należące do uwierzytelnionego użytkownika. (2) Dane zamówienia są pobierane z minimalnymi polami niezbędnymi do wyświetlenia. (3) Adresy dostawy są domyślnie częściowo maskowane. (4) Dostęp jest rejestrowany do celów audytu."

Definicja Done

Państwa definicja zespołu powinna obejmować kryteria prywatności:

• Sprawdzona i wypełniona lista kontrolna dotycząca prywatności
• Potwierdzono minimalizację danych (brak niepotrzebnego gromadzenia lub przechowywania danych)
• Wdrożone i przetestowane kontrole dostępu
• Informacja o ochronie prywatności jest aktualizowana w przypadku wprowadzenia nowego sposobu gromadzenia danych
• Przechowywanie danych zgodne z udokumentowaną polityką przechowywania danych
• DPIA aktualizowana, jeśli funkcja zmienia profil ryzyka

Wzorce minimalizacji danych

Minimalizacja danych (art. 5 ust. 1 lit. c)) jest najbardziej praktycznym wyrazem zasady uwzględniania ochrony prywatności w fazie projektowania. Wymaga, aby dane osobowe były adekwatne, istotne i ograniczone do tego, co jest niezbędne do celów przetwarzania. Skuteczne wzorce minimalizacji danych obejmują:

Minimalizacja kolekcji:

• Proszę zbierać tylko pola wymagane do określonego celu
• Proszę stosować progresywne ujawnianie danych: początkowo proszę zbierać minimalną ilość danych, a o dodatkowe dane prosić tylko wtedy, gdy jest to konieczne.
• Proszę unikać pól typu "miło mieć": jeśli dane nie są wymagane do przetwarzania, proszę ich nie gromadzić.

Minimalizacja przetwarzania:

• Przetwarzanie danych na najwyższym poziomie agregacji, który służy celowi
• Proszę stosować pseudonimizację, gdy do przetwarzania nie jest wymagana indywidualna identyfikacja.
• Wdrożenie separacji danych: przechowywanie identyfikatorów oddzielnie od danych behawioralnych

Minimalizacja retencji:

• Określenie i egzekwowanie okresów przechowywania dla każdej kategorii danych.
• Wdrożenie automatycznego usuwania lub anonimizacji na koniec okresu przechowywania danych
• Coroczny przegląd okresów przechowywania i skracanie ich tam, gdzie to możliwe.

Minimalizacja dostępu:

• Zastosowanie kontroli dostępu opartej na rolach: użytkownicy powinni mieć dostęp tylko do danych, których potrzebują do pełnienia swojej roli.
• Wdrożenie dostępu czasowego: tymczasowy dostęp do określonych zadań, automatycznie odwoływany
• Rejestrowanie i audytowanie całego dostępu do danych osobowych

Technologie zwiększające prywatność

Artykuł 25 i motyw 78 RODO wyraźnie odnoszą się do środków technicznych, w tym pseudonimizacji i szyfrowania. Szerszy zestaw technologii zwiększających prywatność (PET) może wzmocnić Państwa wdrożenie Privacy by Design:

Pseudonimizacja (art. 4 ust. 5):

Proszę zastąpić dane bezpośrednio identyfikujące (imiona i nazwiska, adresy e-mail) identyfikatorami pseudonimowymi. Mapowanie między pseudonimami a tożsamościami jest przechowywane oddzielnie z zachowaniem ścisłej kontroli dostępu. Pseudonimizacja zmniejsza ryzyko w przypadku naruszenia, jednocześnie umożliwiając ponowną identyfikację danych, gdy jest to konieczne do zgodnego z prawem przetwarzania.

Szyfrowanie:

Proszę wdrożyć szyfrowanie w spoczynku (AES-256 lub równoważne) dla przechowywanych danych osobowych i szyfrowanie w tranzycie (TLS 1.3) dla wszystkich transmisji danych. Szyfrowanie sprawia, że dane są niezrozumiałe dla nieupoważnionych stron i jest wyraźnie uznane w art. 34 ust. 3 lit. a) za czynnik, który może wyeliminować obowiązek powiadamiania osób, których dane dotyczą, o naruszeniu.

Kontrola dostępu:

Wdrożenie szczegółowej, opartej na rolach kontroli dostępu z zasadą najmniejszych uprawnień. Połączenie z uwierzytelnianiem wieloskładnikowym w celu uzyskania dostępu do wrażliwych danych. Monitorowanie i rejestrowanie całego dostępu na potrzeby audytu i wykrywania anomalii.

Anonimizacja:

W przypadku, gdy dane osobowe nie są już potrzebne do pierwotnego celu, ale podstawowe wzorce są cenne (np. analityka), należy zastosować techniki anonimizacji, które uniemożliwiają ponowną identyfikację. Prawdziwie zanonimizowane dane całkowicie wykraczają poza zakres RODO. Proszę jednak zachować ostrożność: Opinia Grupy Roboczej Art. 29 05/2014 ostrzega, że wiele rzekomych technik anonimizacji można odwrócić za pomocą danych pomocniczych.

Prywatność różnicowa:

W przypadku zastosowań analitycznych i uczenia maszynowego, prywatność różnicowa dodaje skalibrowany szum do zbiorów danych, aby zapobiec wywnioskowaniu poszczególnych rekordów. Technika ta umożliwia analizę statystyczną, zapewniając jednocześnie matematyczne gwarancje przed ponowną identyfikacją.

Integracja DPIA

Privacy by Design i ocena skutków dla ochrony danych (art. 35) są procesami uzupełniającymi się. W przypadku, gdy nowa funkcja lub system uruchamia wymóg DPIA, analiza Privacy by Design jest bezpośrednio włączana do DPIA:

• Ocena minimalizacji danych stanowi podstawę analizy konieczności i proporcjonalności DPIA
• Wybór PET informuje o sekcji dotyczącej ograniczania ryzyka DPIA
• Projekt kontroli dostępu informuje o sekcji środków bezpieczeństwa DPIA
• Polityka przechowywania informuje o analizie ograniczeń przechowywania DPIA

Proszę zintegrować przeglądy DPIA z cyklem sprintu dla funkcji, które obejmują przetwarzanie wysokiego ryzyka. Pozwala to uniknąć powszechnego anty-wzoru przeprowadzania DPIA retrospektywnie, po tym jak system został już zbudowany i wdrożony.

Pomiar dojrzałości uwzględniania ochrony prywatności w fazie projektowania

Aby wyjść poza doraźną integrację prywatności, należy ustanowić wskaźniki, które śledzą dojrzałość Państwa organizacji w zakresie ochrony prywatności w fazie projektowania:

• Odsetek historyjek użytkownika z wypełnionymi listami kontrolnymi prywatności
• Liczba funkcji wdrożonych bez przeglądu prywatności (cel: zero)
• Średni czas rozwiązywania problemów związanych z prywatnością wynikających z przeglądu kodu
• Różnica w gromadzeniu danych: liczba nowych pól danych osobowych dodawanych i usuwanych kwartalnie
• Wskaźnik zgodności przechowywania: procent kategorii danych w określonym okresie przechowywania
• Wskaźnik ukończenia DPIA: odsetek cech wysokiego ryzyka z ukończonymi DPIA przed wdrożeniem

Budowanie kultury inżynierii prywatności

Privacy by Design ostatecznie odnosi sukces lub porażkę w oparciu o to, czy zespoły inżynierów internalizują prywatność jako ograniczenie projektowe. Wymaga to:

• Szkolenia: Regularne szkolenia z zakresu inżynierii prywatności dla programistów, QA i menedżerów produktu.
• Narzędzia: Narzędzia do lintingu prywatności, integracje mapowania przepływu danych i zautomatyzowane wyzwalacze PIA w Państwa potoku CI/CD.
• Mistrzowie: Proszę wyznaczyć osoby odpowiedzialne za ochronę prywatności w każdym zespole inżynieryjnym, które będą służyć jako pierwszy punkt kontaktowy w przypadku pytań dotyczących prywatności.
• Zachęty: Proszę uznawać i nagradzać decyzje projektowe chroniące prywatność. Prywatność powinna być atrybutem jakości, a nie biurokratyczną przeszkodą.
• Pętle sprzężenia zwrotnego: Proszę dzielić się działaniami w zakresie egzekwowania prawa, analizami przypadków naruszeń i wynikami audytów z zespołami inżynierów, aby zachować świadomość rzeczywistych konsekwencji.

Artykuł 25 nie jest ćwiczeniem polegającym na zaznaczaniu pola wyboru. Jest to ciągłe zobowiązanie do budowania systemów, które szanują prywatność osób fizycznych już na etapie projektowania i domyślnie. Organizacje, które włączą to zobowiązanie do swojej kultury inżynieryjnej, przekonają się, że prywatność staje się czynnikiem umożliwiającym, a nie ograniczającym: budując zaufanie użytkowników, zmniejszając ryzyko naruszenia i wykazując odpowiedzialność, której wymaga RODO.