Privacy by design w tworzeniu oprogramowania

Ochronę danych osobowych najskuteczniej buduje się już na etapie projektowania danego systemu. Dopasowywanie zgodności do gotowego produktu jest zdecydowanie bardziej czasochłonne i kosztowne. Art. 25 RODO podnosi zasadę privacy by design do rangi obowiązku prawnego. Ponadto, dla systemów wielkoskalowych lub z wysokim ryzykiem dla danych osobowych dochodzi kolejny obowiązek jakim jest ocena skutków dla ochrony danych (art. 35 RODO).

Dla organizacji tworzących oprogramowanie to nie tylko formalny obowiązek, lecz nieodłączna część inżynierii. To, jak zostaną zaprojektowane model danych, ustawienia domyślne oraz mechanizmy usuwania danych, może przesądzić o zgodności produktu z RODO albo o konieczności wprowadzania kosztownych zmian już po jego wdrożeniu.

W artykule wyjaśniam, jak privacy by design i privacy by default przekładają się na praktykę tworzenia oprogramowania, w jaki sposób uwzględnić te zasady w cyklu SDLC, jaką rolę odgrywa w tym procesie DPIA oraz jakich błędów warto unikać.

Privacy by design i privacy by default — najważniejsze założenia

Artykuł 25 RODO nakłada na administratora dwa kluczowe obowiązki.

Privacy by design (uwzględnianie ochrony danych już na etapie projektowania). Administrator powinien od początku przewidywać i wdrażać odpowiednie środki techniczne i organizacyjne, takie jak pseudonimizacja czy minimalizacja danych, zarówno przy określaniu sposobów przetwarzania, jak i później, w toku jego realizacji. W praktyce oznacza to, że ochrona danych jest elementem projektu systemu od samego początku, a nie elementem fakultatywnym wprowadzanym po jego stworzeniu.

Privacy by default (domyślna ochrona danych). Ustawienia systemu powinny być skonfigurowane w taki sposób, aby bez dodatkowej ingerencji użytkownika przetwarzane były tylko te dane, które są rzeczywiście potrzebne do realizacji określonego celu administratora. Dotyczy to zarówno zakresu zbieranych informacji i sposobu ich wykorzystania, jak i czasu ich przechowywania oraz kręgu osób, które mają do nich dostęp. Prywatność powinna więc być ustawieniem domyślnym.

Praktycznych wskazówek dotyczących stosowania obu zasad dostarczają wytyczne Europejskiej Rady Ochrony Danych (EROD) odnoszące się do art. 25 RODO (Guidelines 4/2019). Wytyczne zakładają, że nie wystarczy formalnie zadeklarować zgodności. Zastosowane rozwiązania muszą faktycznie i skutecznie chronić dane w konkretnym systemie.

Obowiązek administratora, odpowiedzialność całego zespołu

Formalnie obowiązek wynikający z art. 25 RODO spoczywa na administratorze. W praktyce jednak jego realizacja zależy w znacznej mierze od zespołu projektującego i rozwijającego oprogramowanie.  Zespół ten przekłada wymagania prawne na konkretne rozwiązania techniczne — architekturę systemu, model danych, uprawnienia czy ustawienia domyślne. Ma to znaczenie również wtedy, gdy dostawca oprogramowania działa jako podmiot przetwarzający. To sposób zaprojektowania produktu może przecież albo ułatwiać administratorowi zapewnienie zgodności z RODO albo przeciwnie — istotnie ją utrudniać. Z art. 28 RODO wynika również obowiązek podmiotu przetwarzającego do wspierania administratora w wykonywaniu określonych obowiązków, m.in. dotyczących bezpieczeństwa przetwarzania oraz oceny skutków dla ochrony danych.

Dla dostawcy oprogramowania privacy by design ma również wymiar biznesowy. Oprogramowanie, które od początku uwzględnia wymagania RODO, jest łatwiejsze do zaoferowania klientom, sprawniej przechodzi proces wdrożenia i może ograniczać ryzyka pojawiające się przy kontroli lub negocjowaniu warunków umowy.

Jak uwzględnić ochronę danych w cyklu wytwarzania oprogramowania (SDLC)

Najskuteczniej jest traktować ochronę danych jako wymaganie obecne przez cały cykl tworzenia produktu, a nie jako odrębny etap formalno-prawny realizowany dopiero przed jego wdrożeniem.

Wymagania. Na początku trzeba określić, jakie dane osobowe będą przetwarzane, w jakich celach i na jakiej podstawie prawnej. Należy też zidentyfikować mapy danych oraz ich odbiorców. Bez tego trudno później zastosować zasadę minimalizacji.

Projekt i architektura. Na etapie projektowania wszystkie wymagania dotyczące ochrony danych powinny zostać przełożone na konkretne rozwiązania techniczne. Model danych powinien więc obejmować wyłącznie informacje niezbędne do realizacji określonych celów. W zależności od ryzyka dla danych osobowych należy przewidzieć m.in. pseudonimizację, szyfrowanie, odpowiedni model uprawnień, rejestrowanie dostępu do danych, a także mechanizmy pozwalające realizować prawa osób, których dane dotyczą. Już na tym etapie trzeba także uwzględnić retencję i automatyczne usuwanie danych po upływie ustalonego okresu.

Analiza ryzyka i DPIA. Zgodnie z regulacjami RODO w tym samym czasie należy ocenić, jakie zagrożenia dla praw i wolności osób wiążą się z planowanym w nowym produkcie/ oprogramowaniu przetwarzaniem. Jeżeli może ono powodować wysokie ryzyko dla praw i wolności osób, przed rozpoczęciem przetwarzania, konieczne jest przeprowadzenie oceny skutków dla ochrony danych (DPIA).

Budowa i testy. Ochrona danych osobowych musi być widoczna także na poziomie konfiguracji systemu. Ustawienia domyślne, zgodnie z zasadą privacy by default, powinny zapewniać możliwie wysoki poziom prywatności. Ostrożności wymagają również środowiska deweloperskie i testowe. Wykorzystywanie w nich rzeczywistych danych produkcyjnych powinno być ograniczone do sytuacji, w których jest to konieczne i odpowiednio zabezpieczone.

Wdrożenie i utrzymanie. Zgodność produktu z RODO nie kończy się w momencie jego uruchomienia. System powinien być aktualizowany, monitorowany i okresowo oceniany pod kątem bezpieczeństwa oraz ochrony danych. Każda istotna zmiana funkcjonalności, zakresu danych lub sposobu ich wykorzystywania może wpływać na wcześniej przeprowadzoną ocenę ryzyka.

Trzeba pamiętać o tym, żeby najważniejsze decyzje dotyczące ochrony danych odpowiednio dokumentować. Pozwala to nie tylko uporządkować proces projektowy, ale również wykazać przestrzeganie zasady rozliczalności wynikającej z art. 5 ust. 2 RODO.

Privacy by default w praktyce

Zasadę privacy by default najłatwiej pokazać na konkretnych ustawieniach, które system powinien stosować od momentu uruchomienia:

• zbieranie wyłącznie danych rzeczywiście potrzebnych do realizacji określonego celu, bez tworzenia dodatkowych pól „na przyszłość”,
• pozyskiwanie zgody poprzez aktywne działanie użytkownika (opt-in), a nie za pomocą domyślnie zaznaczonych checkboxów,
• brak automatycznego publicznego udostępniania profilu, aktywności czy innych danych użytkownika,
• przyjęcie możliwie krótkiego, uzasadnionego celu przetwarzania okresu retencji,
• ograniczenie dostępu i widoczności danych do osób, które rzeczywiście potrzebują ich do wykonywania swoich zadań.

Jeżeli użytkownik musi samodzielnie zmieniać ustawienia po to, aby ograniczyć zbędne przetwarzanie swoich danych, trudno mówić o rzeczywistej realizacji zasady privacy by default z art. 25 RODO.

Privacy by design a DPIA

Ocena skutków dla ochrony danych (DPIA) jest naturalnym uzupełnieniem zasady privacy by design. DPIA to proces sformalizowanej analizy ryzyka, który należy przeprowadzić, gdy planowane przetwarzanie może powodować wysokie ryzyko naruszenia praw lub wolności osób fizycznych. Zgodnie z art. 35 ust. 3 RODO DPIA jest wymagana w szczególności w przypadku:

• systematycznej i kompleksowej oceny czynników osobowych, opartej na zautomatyzowanym przetwarzaniu, w tym profilowaniu, jeżeli na jej podstawie podejmowane są decyzje wywołujące skutki prawne lub w podobny sposób istotnie wpływające na daną osobę,
• przetwarzania na dużą skalę szczególnych kategorii danych, o których mowa w art. 9 RODO, lub danych dotyczących wyroków skazujących i czynów zabronionych z art. 10 RODO,
• systematycznego monitorowania na dużą skalę miejsc dostępnych publicznie.

Przy ocenie, czy DPIA jest konieczna, warto również sięgnąć do wytycznych organów ochrony danych oraz do wykazu rodzajów operacji przetwarzania podlegających obowiązkowi przeprowadzenia DPIA, opublikowanego przez Prezesa UODO.

Istotne są przy tym dwie kwestie. Po pierwsze, DPIA przeprowadza się przed rozpoczęciem przetwarzania, najlepiej jeszcze na etapie projektowania rozwiązania. Po drugie, jeżeli mimo zastosowania planowanych środków ograniczających ryzyko pozostaje ono wysokie, administrator powinien skonsultować się z organem nadzorczym przed rozpoczęciem przetwarzania, zgodnie z art. 36 RODO.

DPIA nie powinna więc być traktowana jako formalność. Prawidłowo przeprowadzona ocena powinna realnie wpływać na projekt systemu, jego architekturę, zakres przetwarzanych danych oraz zastosowane zabezpieczenia.

Dane produkcyjne w środowiskach testowych — ryzyko, o którym łatwo zapomnieć

Na uwagę zasługuje też częsty błąd popełniany w procesie tworzenia oprogramowania, polegający na wykorzystywaniu rzeczywistych danych osobowych pochodzących ze środowiska produkcyjnego do testów, prac deweloperskich czy szkoleń. Takie rozwiązanie może istotnie zwiększać ryzyko naruszenia ochrony danych, ponieważ środowiska nieprodukcyjne często mają słabsze zabezpieczenia, a dostęp do nich bywa przyznany szerszemu gronu użytkowników.

W miarę możliwości należy więc korzystać z danych syntetycznych albo skutecznie zanonimizowanych. Jeżeli zastosowanie takich danych nie jest możliwe, można rozważyć pseudonimizację, pamiętając jednak, że dane pseudonimizowane nadal pozostają danymi osobowymi i podlegają przepisom RODO. Odpowiednie podejście do danych testowych jest jednym z praktycznych przejawów privacy by design, a jednocześnie elementem realizacji wymogów bezpieczeństwa wynikających z art. 32 RODO.

Najczęstsze błędy przy wdrażaniu privacy by design

„RODO na końcu”. Próba dostosowania gotowego oprogramowania do wymogów ochrony danych osobowych jest bardziej kosztowna i mniej skuteczna niż uwzględnienie ich już na etapie projektowania.

Zbyt szerokie ustawienia domyślne. Jeżeli system od początku zbiera, udostępnia lub przechowuje więcej danych, niż jest to konieczne, trudno mówić o realizacji zasady privacy by default.

Dane produkcyjne w środowiskach testowych. Wykorzystywanie rzeczywistych danych osobowych w środowiskach deweloperskich i testowych niepotrzebnie zwiększa ryzyko naruszenia ochrony danych osobowych, zwłaszcza gdy środowiska te są słabiej zabezpieczone lub dostęp do nich ma większa liczba osób.

Brak DPIA albo przeprowadzenie jej zbyt późno. Ocena skutków nie spełni swojej funkcji, jeśli zostanie wykonana dopiero po wdrożeniu systemu. W przypadku przetwarzania mogącego powodować wysokie ryzyko dla praw lub wolności osób fizycznych powinna wpływać na produkt jeszcze przed rozpoczęciem przetwarzania.

Zbieranie danych „na zapas”. Dodawanie pól tylko dlatego, że informacje mogą kiedyś okazać się przydatne, pozostaje w sprzeczności z zasadą minimalizacji danych. Każda kategoria danych powinna mieć konkretny i uzasadniony cel.

Brak przemyślanej retencji. Częstym problemem jest zaprojektowanie mechanizmu gromadzenia danych bez równoczesnego określenia, kiedy i w jaki sposób mają zostać usunięte. Retencja powinna być już elementem projektu.

Zbyt szerokie uprawnienia. Dostęp do danych nadawany całym zespołom zwiększa ryzyko nieuprawnionego dostępu. Uprawnienia powinny odpowiadać rzeczywistym potrzebom wynikającym z pełnionej roli.

Traktowanie pseudonimizacji jak anonimizacji. Pseudonimizacja jest ważnym środkiem ograniczającym ryzyko, ale nie powoduje, że dane przestają być danymi osobowymi. Nadal podlegają one przepisom RODO.

Brak ponownej oceny po zmianach w systemie. Nowa funkcjonalność, dodatkowe źródło danych czy zmiana sposobu ich wykorzystywania mogą istotnie zmienić profil ryzyka. Privacy by design nie jest więc jednorazowym zadaniem wykonywanym przed pierwszym wdrożeniem danego produktu.

Brak dokumentowania decyzji na etapie projektowania. Nawet dobre rozwiązania trudno później wykazać, jeżeli nie wiadomo, dlaczego zostały przyjęte. Dokumentowanie kluczowych decyzji dotyczących zakresu danych, retencji, dostępu czy zabezpieczeń jest niezwykle istotnym elementem zasady rozliczalności.

Privacy by design w projekcie IT — praktyczna checklista

• Zmapuj dane, cele i podstawy prawne przetwarzania danych osobowych już na etapie definiowania wymagań.
• Ogranicz zakres danych osobowych do niezbędnego minimum — każde pole powinno mieć konkretny cel i uzasadnienie.
• Zaprojektuj odpowiednie zabezpieczenia, w tym pseudonimizację, szyfrowanie oraz kontrolę dostępu zgodną z zasadą need-to-know.
• Ustaw prywatność jako stan domyślny — stosuj opt-in, ograniczoną widoczność danych i możliwie krótkie, uzasadnione okresy retencji.
• Zaplanuj realizację praw osób, w tym dostęp do danych, ich sprostowanie, usunięcie, ograniczenie przetwarzania i przenoszenie, jeśli mają zastosowanie.
• Zaprojektuj retencję i usuwanie danych — najlepiej w sposób zautomatyzowany i możliwy do zweryfikowania.
• Przeprowadź analizę ryzyka, a jeżeli przetwarzanie może powodować wysokie ryzyko — wykonaj DPIA przed jego rozpoczęciem.
• Nie wykorzystuj danych produkcyjnych w testach, jeżeli ten sam cel można osiągnąć przy użyciu danych syntetycznych lub skutecznie zanonimizowanych.
• Uwzględnij bezpieczeństwo środowisk nieprodukcyjnych, w szczególności zakres dostępu, logowanie operacji i sposób przechowywania danych.
• Sprawdź dostawców i komponenty zewnętrzne — biblioteki, usługi chmurowe, API i podwykonawcy również mogą wpływać na zakres i ryzyko przetwarzania.
• Włącz IOD odpowiednio wcześnie, jeżeli został wyznaczony, zwłaszcza przy projektach bardziej złożonych lub wysokiego ryzyka.
• Dokumentuj najważniejsze decyzje projektowe dotyczące danych, retencji, dostępu, zabezpieczeń i oceny ryzyka — zgodnie z zasadą rozliczalności.
• Testuj nie tylko funkcjonalność, ale również mechanizmy ochrony danych, np. uprawnienia, usuwanie danych, retencję i ustawienia domyślne.
• Ponownie oceniaj ryzyko po istotnych zmianach w funkcjonalności, architekturze lub sposobie wykorzystywania danych.
• Po wdrożeniu zapewnij monitoring, aktualizacje i okresowe przeglądy, ponieważ privacy by design jest procesem ciągłym, a nie jednorazowym zadaniem przed uruchomieniem systemu.

Potrzebujesz wsparcia w privacy by design lub DPIA?

Uwzględnienie ochrony danych już na etapie projektowania oprogramowania pozwala ograniczyć ryzyko, uniknąć kosztownych zmian po wdrożeniu i od początku budować rozwiązanie zgodne z wymaganiami RODO.

W Kancelarii Radcowskiej dr Joanny Maniszewskiej-Ejsmont wspieramy organizacje tworzące i wdrażające rozwiązania IT w praktycznym stosowaniu zasad privacy by design i privacy by default, przeprowadzaniu ocen skutków dla ochrony danych (DPIA), a także w określaniu ról stron i przygotowywaniu odpowiednich umów dotyczących przetwarzania danych.

Jeżeli tworzysz nowy system, rozwijasz istniejący produkt albo chcesz sprawdzić, czy przyjęte rozwiązania spełniają wymagania RODO, sprawdź ofertę wdrożenia RODO lub skontaktuj się z nami. Pomożemy uwzględnić ochronę danych w projekcie, zanim stanie się ona problemem na etapie wdrożenia danego produktu.