Każdy z nas jest chodzącym zbiorem danych osobowych. Mamy imiona i nazwiska, numery pesel, linie papilarne, a niektórzy z nas mają tatuaże. To są wszystko informacje, które spełniają definicję danych osobowych zawartą w RODO:
„dane osobowe – wszelkie informacje o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej”.
Zidentyfikowanie o którym mówi ten przepis to coś innego niż ustalenie tożsamości. Identyfikujemy osobę, kiedy jesteśmy w stanie wyizolować ją z większej grupy.
To powoduje, że przykładowe dane osobowe, które mogą być zbierane w tworzonej przez Ciebie aplikacji albo z którymi będziesz mieć do czynienia robiąc np. system e-commerce klienta to nie tylko imię i nazwisko, adres czy numer karty płatniczej. Dane takie jak login i hasło do systemu, geolokalizacja, a nawet szlaki zachowań osoby na stronie internetowej (ustalone dzięki cookie-ID) – również uznamy za dane osobowe.
To już całkiem duża ilość informacji o danej osobie, których bezpieczeństwo powinna zapewniać projektowana przez Ciebie aplikacja.
RODO wprowadza też pojęcie danych szczególnych kategorii, tzw. danych wrażliwych.
Wymienia je artykuł 9 RODO:
- dane ujawniające pochodzenie rasowe lub etniczne,
- dane ujawniające poglądy polityczne,
- dane ujawniające przekonania religijne lub światopoglądowe,
- dane ujawniające przynależność do związków zawodowych,
- dane genetyczne,
- dane biometryczne (wykorzystywane w celu jednoznacznego zidentyfikowania osoby fizycznej),
- dane dotyczące zdrowia,
- dane dotyczące seksualności lub orientacji seksualnej.
Kiedy więc aplikacja randkowa zbiera od Ciebie informacje o orientacji seksualnej czy poglądach religijnych – gromadzi dane wrażliwe, na co musisz wydać wyraźną zgodę – w przeciwnym wypadku użycie tych danych będzie nielegalne. Podobnie w przypadku siłowni – jeśli używa czytników linii papilarnych – powinna pobrać od Ciebie udokumentowaną zgodę na takie działanie.
Zgoda jest jedyną podstawą przetwarzania danych wrażliwych, ale w przypadku większości danych podmioty je przetwarzające mają do dyspozycji również inne podstawy prawne:
Poza podstawą prawną w postaci zgody, zgodnie z art. 6 ust. 1 RODO przetwarzanie DO jest zgodne z prawem wówczas, gdy spełniony jest jeden z poniższych warunków:
* przetwarzanie jest niezbędne do wykonania umowy, której stroną jest osoba, której dane dotyczą, lub do podjęcia działań na żądanie tej osoby przed zawarciem umowy
np. Aplikacja pyszne.pl w pierwszej kolejności, zanim zaczniesz z niej korzystać, wymaga podania adresu zamieszkania, żeby wygenerować listę dostępnych restauracji.
Albo, weźmy rejestrację użytkowników.
To przetwarzanie wymaga zwykle zbierania nazwisk i e-maili. Celem tego zbierania jest umożliwienie użytkownikom korzystania z dostępnych funkcji poprzez konto użytkownika. A podstawą prawną jest wykonanie umowy, która jest realizowana poprzez akceptację Regulaminu aplikacji.
* przetwarzanie jest niezbędne do wypełnienia obowiązku prawnego ciążącego na administratorze
np. Każdy pracodawca zobowiązany jest prawnie odprowadzić składki i zaliczki na poczet podatków i ubezpieczeń społecznych.
* przetwarzanie jest niezbędne do ochrony żywotnych interesów osoby
np.: Jeżeli jesteś uczestnikiem wypadku, szpital identyfikuje Cię na podstawie dokumentów, które znajdzie w aucie.
* przetwarzanie jest niezbędne do celów wynikających z prawnie uzasadnionych interesów realizowanych przez administratora lub stronę trzecią z wyjątkiem sytuacji, w których nadrzędny charakter wobec tych interesów mają interesy lub podstawowe prawa i wolności osoby, której dane dotyczą, wymagające ochrony danych osobowych, w szczególności gdy osoba, której dane dotyczą jest dzieckiem.
Ta podstawa uzasadnionego interesu wymaga trochę szerszego omówienia. Chodzi tutaj o takie sytuacje, w których podejmujemy określone działania, wiążące się z przetwarzaniem danych osobowych, by osiągnąć cele np. gospodarcze, przy czym w inny sposób tych celów nie osiągniemy. Przykładowo, żeby prowadzić biznes, niezbędne jest komunikowanie się z pracownikami kontrahentów. Jakbyśmy nie mieli z nimi kontaktu, nie prowadzili z nimi korespondencji mailowej, to nie bylibyśmy w stanie zrealizować żadnej umowy, poprowadzić negocjacji itd.
Poza tym, RODO wskazuje, że prawnie uzasadniony interes może być podstawą przetwarzania danych, o ile w świetle rozsądnych oczekiwań osób, których dane dotyczą, opartych na ich powiązaniach z podmiotem, mogą założyć, że ich dane będą przez ten podmiot przetwarzane.
Takim ekstremalnym przykładem np. w handlu elektronicznym celu wynikającego z prawnie uzasadnionego interesu mogą być działania remarketingowe podejmowane w celu przeciwdziałania porzucaniu koszyka zakupowego. Skoro osoba wrzuciła do koszyka produkty, to znaczy że jest nimi zainteresowana. Skoro tak, to w dzisiejszym świecie może się spodziewać, że sprzedający skieruje do niej reklamę z produktami, które ją zainteresowały. Sprzedający ma podstawę, aby skontaktować się z tą osobą, bo ona już wykonała pierwszy krok, a jego prawnie uzasadniony interes to zatrzymać klienta i jest to zgodne z praktyką rynkową.
Żeby skorzystać z prawnie uzasadnionego interesu warto sobie odpowiedzieć na 3 pytania:
1) po co ja chcę przetwarzać te dane, czy to będzie zgodne z praktyką rynkową?
2) czy naruszę prywatność tej osoby w sposób szkodliwy dla niej?
3) czy jestem w stanie swój cel zrealizować bez przetwarzania tych danych?
ZAPAMIĘTAJ
Dla każdej czynności przetwarzania danych musi istnieć cel. Każdy cel musi być uzasadniony odpowiednią podstawą prawną.
Tip dla developera: W aplikacjach podstawą prawną przetwarzania danych najczęściej będzie zgoda albo niezbędność do wykonania umowy, której stroną jest osoba, której dane dotyczą, lub do podjęcia działań na żądanie tej osoby przed zawarciem umowy. W pierwszym przypadku aplikacja powinna zawierać checkbox, umożliwiający łatwe wyrażenie zgody, w drugim przypadku powinna informować użytkownika, że przetwarzanie jest niezbędne do skorzystania z funkcji.
Zasady przetwarzania danych osobowych i ich implementacja w oprogramowaniu
Jeśli mamy już podstawę prawną do przetwarzania danych to teraz musimy przy przetwarzaniu tych legalnie pozyskanych danych kierować się kilkoma zasadami:
Zgodność z prawem, rzetelność i przejrzystość – (art. 5 ust. 1 lit. a) RODO);
Ograniczenie do celu (art. 5 ust. 1 lit. b) RODO);
Minimalizacja danych (art. 5 ust. 1 lit. c) RODO);
Prawidłowość (art. 5 ust. 1 lit. d) RODO);
Ograniczenie przechowywania (art. 5 ust. 1 lit. e) RODO);
Integralność i poufność (art. 5 ust. 1 lit. f) RODO);
Rozliczalność (art. 5 ust. 2 RODO)
Obowiązkiem administratora DO jest spełnianie oczywiście wszystkich wymienionych na slajdzie zasad, jednak w kontekście przetwarzania danych osobowych w systemach informatycznych czy aplikacjach kilka z tych zasad jest kluczowe.
Zgodność z prawem, rzetelność i przejrzystość
Przejrzystość osiąga się poprzez dostarczenie wszystkich informacji, jakie osoba, której dane dotyczą, musi wiedzieć o przetwarzaniu przez aplikację danych. Odpowiedzi na poniższe pytania muszą być udostępnione osobie, której dane dotyczą, najpóźniej w momencie zbierania od niej danych:
Kto
– kim jest administrator danych i jak można się z nim skontaktować;
– kim jest wyznaczony przez niego inspektor ochrony danych (jeśli został wyznaczony) i jak można się z nim skontaktować,
– jakich kategorii osób dane są zbierane (osoby odwiedzające stronę internetową, osoby zakładające konto, kandydaci do pracy, dostawcy, …)
Co
– jakie dane zbierasz od osób, których dane dotyczą;
– jakie są cele zbierania danych oraz jakie podstawy prawne legitymizują te działania;
– jakie zobowiązania prawne wymagają zbierania lub zatrzymywania określonych danych (jeśli takie istnieją);
– jakie prawa przysługują osobom, których dane dotyczą, i np.: dlaczego nie wszystkie z nich są dostępne
Czy
– dane osobowe są dostępne dla stron trzecich, na których Twoja firma polega; (Mailchimp, Zoom, GSuite, …)
– czy dane osobowe opuszczają UE i pod jakimi zabezpieczeniami technicznymi i umownymi;
– czy przetwarzasz dane w celu zautomatyzowanego podejmowania decyzji lub profilowania
Jak
– jak długo dane są przechowywane przez; (czas trwania umowy, 2 lata, 1 miesiąc, 3 milisekundy, …)
– w jaki sposób osoba, której dane dotyczą, może wykonywać swoje prawa w odniesieniu do każdej czynności przetwarzania;
– w jaki sposób osoby, których dane dotyczą, mogą złożyć skargę do organu nadzorczego (dane kontaktowe organu).
Tip dla developera: techniki projektowania mające na celu zwiększenie przejrzystości to m.in:
– Wykorzystanie hoverów i opartych na input-field disclaimerów just-in-time.
– UX z dobrze widocznym linkiem do polityki prywatności.
– Proaktywna informacja, gdy użytkownicy aktywują swoje podłączone urządzenie / tworzą konto / za każdym razem, gdy się logują.
– Informacje audio/wizualne wspierające użytkowników niedosłyszących lub niedowidzących.
– Łatwy dostęp do informacji o prywatności powinien być widoczny przez cały czas.
– Opcja ustawień plików cookies przejrzyście wbudowana w UX.
Minimalizacja danych osobowych i ograniczenie do celu
Minimalizacja danych osobowych i ograniczenie do celu oznacza przetwarzanie danych w zakresie niezbędnym do osiągnięcia celów przetwarzania. W praktyce chodzi o to, aby zbierać tylko te dane, których przetwarzanie jest absolutnie konieczne do realizacji zaplanowanego procesu. Występuje tu duże powiązanie z zasadami privacy by design oraz privacy by default, o których obszerniej wypowiem w dalszej części tego artykułu. Póki co, warto byś wiedział, że o pierwszej z tych zasad nie wolno zapominać podczas planowania nowych sposobów przetwarzania danych. Już w początkowej fazie prac należy uwzględniać zakres danych osobowych, jaki będzie potrzebny do osiągnięcia założonego celu. Druga z zasad stanowi o tym, iż domyślne ustawienia systemu IT powinny zapewniać, że dane osobowe są przetwarzane w zakresie niezbędnym do osiągnięcia konkretnego celu. Bardzo często dane osobowe są zbierane przy użyciu systemów IT, np. wpisanie danych na landing page skutkuje przerzuceniem ich do systemu oraz dalszym przetwarzaniem. Należy pamiętać o tym, aby formularze służące do zbierania danych zawierały pola do wpisania tylko niezbędnych danych. Jeśli więc do realizacji celu przetwarzania niezbędne będą: imię, nazwisko, numer telefonu oraz adres e-mail to na landing page umieszczamy tylko pola służące do zbierania tylko tych danych, a nie dodatkowe pola, w których osoba będzie musiała wpisać np. adres zamieszkania. Jeśli z kolei formularz do zbierania danych zawiera więcej pól, które są jednak opcjonalne, należy w czytelny sposób zaznaczyć, w których polach uzupełnienie danych jest obowiązkowe, a w których nie.
Tipy dla developera: W trakcie tworzenia formularzy, deweloper powinien zadawać sobie i zespołowi np. takie pytania :
- Dlaczego zbieramy pełną datę urodzenia, skoro sama wiedza o tym, że osoba, której dane dotyczą, ma >= do 18 lat, jest wystarczająca do określenia uprawnień do założenia konta?
- Po co nasza aplikacja mobilna zaprojektowana do sprzedaży detalicznej odzieży online miałaby mieć dostęp do mikrofonu osoby, której dane dotyczą?
- Jaki wpływ będzie miało wdrożenie tego konkretnego SDK na poufność danych? Jakie strony trzecie będą miały dostęp do danych?
- Dlaczego zbieramy adresy domowe osób, których dane dotyczą, w celu zarejestrowania ich do newslettera wysyłanego drogą elektroniczną?
Jeśli takie pytania pozostaną bez odpowiedzi, to jest to wskazówka, że warto zmienić projekt, bo zasady ochrony danych osobowych nie zostały jeszcze wplecione w biznesplan. Nie jest jeszcze za późno na dopracowanie produktu w celu zwiększenia jego zgodności z przepisami.
Integralność i poufność
Te dwie powiązane ze sobą zasady oznaczają tyle, że dane powinny być chronione przed zmianami i nieautoryzowanym dostępem.
Poufność związana jest z dwoma mechanizmami, które należy zaimplementować w procesie projektowania aplikacji – privacy by design oraz privacy by default.
Obowiązkiem firmy jest wdrożenie środków spełniających zasady RODO na wczesnym etapie projektowania oraz zapewnić, że opcje i funkcje, które mają wpływ na prywatność osoby, której dane dotyczą, są domyślnie wyłączone przy tworzeniu konta lub pierwszym użyciu aplikacji.
Żeby spełnić wymogi zasady poufności musisz budując aplikację np.: określić dla kogo określone dane są dostępne, ponieważ ma to wpływ na współczynnik ryzyka prowadzący do skompromitowania danych, tj.: np. wycieku, dostępu osób nieuprawnionych.
Zilustruję to na podstawie case study. W naszym case study będziemy tworzyć aplikację bazodanową, która umożliwia udostępnienie danych przez operatora telekomunikacyjnego firmie dokonującej montażu np. modemów w domach klientów.
Czyli mamy sobie firmę telekomunikacyjną, która jest administratorem DO, tj.: takim podmiotem, który decyduje o celach i sposobach przetwarzania zebranych przez niego danych klientów. I mamy firmę zewnętrzną, która na zlecenie administratora przetwarza DO klientów administratora w celu realizacji usługi instalacji internetu w domach klientów, czyli jest tzw. procesorem. Tak to profesjonalnie nazywamy.
Do tej pory umowa z klientem na dostawę internetu była podpisywana w salonie i przesyłano ją do centrali, skąd kopie były przesyłane do firmy instalującej modemy. Postanowiono ten proces zdigitalizować.
W zdigitalizowanej wersji proces przekazywania informacji pomiędzy firmami byłby taki, że tworzone jest konto klienta w systemie Administratora, gdzie gromadzi się dane oraz skan podpisanej umowy. Dane gromadzone w systemie to w tym case study wszystkie dane pozyskane od klienta w trakcie zawierania umowy na dostawę internetu, czyli dane identyfikacyjne jak imię nazwisko czy numer dowodu tożsamości, dane adresowe, potwierdzenie przelewu numer konta bankowego itp.
I teraz – w tworzonej aplikacji, na podstawie zlecenia Administratora Procesor otrzymuje zdalny dostęp do konta klienta tak, żeby po instalacji odnotować, że została ona wykonana. Czyli po prostu pracownik salonu wypełnia zlecenie dla firmy dokonującej instalacji, że w terminie X u klienta Y ma się dokonać instalacja modemu, a dane klienta Y są dostępne dla instalatora w aplikacji, w bazie danych.
Pierwsze pytanie, które sobie tutaj zadamy, to pytanie jak dalece procesor powinien mieć dostęp do informacji na temat klienta?
Gdybyśmy w ogóle nie znali zasady privacy by design moglibyśmy tak zaprojektować dostępność w aplikacji, że technik miałby:
– pełny dostęp do całej bazy danych wszystkich klientów, z których technik musi sobie wyfiltrować zlecenia, do jakich jest przypisany
– pełny dostęp do konta klienta (włącznie ze skanem umów)
– w aplikacji brak polityki retencji, czyli dane są dostępne przez cały czas
Jak w takiej sytuacji wyglądałaby uproszczona ocena ryzyka? Jakiego rodzaju ryzyko pojawi się przy takim podejściu, w momencie skompromitowania danych klientów albo utraty dostępu do bazy danych (bo np. technikowi ukradziono tablet, na którym korzystał z aplikacji)?
Podstawmy sobie tutaj jakieś parametry, żeby wyliczyć ryzyko.
Powiedzmy, że cała baza danych = 10 000 klientów.
W bazie jest 9 różnych kategorii danych osobowych opisujących każdego klienta (imię nazwisko, adres, PESEL, nr tel, email, itd.)
Firma procesora ma 10 techników i każdy z nich ma dostęp do pełnej bazy danych.
Łącznie:
(10 tyś profili x 9 kategorii danych) x 10 techników = 900 000 pkt
To jest bardzo duże ryzyko.
Ale, znając zasadę privacy by design wiemy, że powinniśmy:
– ograniczyć dostęp technika wyłącznie do profili, na których jest aktywne wystawione przez pracownika salonu zlecenie,
– ograniczyć dostęp wyłącznie do zleceń przypisanych do konkretnego technika
– ograniczyć dane do tych niezbędnych, do wykonania zlecenia czyli np. tylko imię i nazwisko oraz adres zamieszkania
Jak w takiej sytuacji wyglądałaby uproszczona ocena ryzyka? Po zmianie zasad działania aplikacji, po tym, jak wdrożyliśmy do funkcji aplikacji zasadę privacy by design.
Podstawimy sobie takie parametry:
30 profili klientów, bo każdy technik widzi profile tylko tych klientów, u których sam wykonuje instalację modemu
3 kategorie danych, czyli dane ograniczone do niezbędnych dla wykonania zlecenia
10 techników, z których każdy ma dostęp tylko do swoich zleceń
(30 profili x 3 kategorie) x 10 techników = 900 pkt.
Spójrz teraz – zastosowanie zasady privacy by design pozwoliło, w uproszczeniu, obniżyć wskaźnik zagrożenia o 99,9% w stosunku do pierwotnej wielkości!
Tipy dla developera: W trakcie tworzenia aplikacji, deweloper, oprócz ww. wskazówek powinien zadawać sobie i zespołowi np. takie pytania :
- Jaki wpływ będzie miało wdrożenie tego konkretnego SDK na poufność danych? Które strony trzecie będą miały dostęp do danych?
- Dlaczego np. dane dotyczące zdrowia są wysyłane do tego dostawcy chmury w sposób jawny, a nie zaszyfrowany?
Jeśli takie pytania pozostają bez odpowiedzi, to jest to wskazówka, że – ponownie – warto zmienić projekt.
Dodatkowo, pamiętaj, że biblioteki i zestawy SDK firm trzecich często dostarczane są z domyślnymi plikami konfiguracyjnymi, które z braku czasu rzadko są zmieniane, co powoduje wiele luk w zabezpieczeniach. Przeczytaj dokumentację i zmień domyślne konfiguracje, aby wdrożyć zasadę poufności. Dla software developera ważne jest zidentyfikowanie tych elementów aplikacji, które mogą być narażone na ryzyka związane z naruszeniem ochrony danych osobowych. Na przykład błąd ludzki po stronie backendu – implementacja zewnętrznego kodu który może być podatny na przeciek danych.
Rozliczalność
Ciężar dowodu, że dane były przetwarzane zgodnie z wszystkimi zasadami spoczywa na firmie, więc obowiązkiem organizacji jest:
- Prowadzić dokumentację tego, co robi z danymi osobowymi (np. logi dostępu, logi odczytu/zapisu/usunięcia, …);
- Dokumentować środki (techniczne i organizacyjne), które wdraża w celu zabezpieczenia tych danych (kontrole bezpieczeństwa informacji, protokoły QA, ścieżki audytu, …);
- Udokumentować umowy zawarte z dostawcami usług i odbiorcami w celu prawnego zabezpieczenia przetwarzania danych i przekazywania ich za granicę (np. właściwe i wyczerpujące zapisy w Regulaminie aplikacji oraz dowody akceptacji przez użytkownika warunków użytkowania aplikacji).
Projekt aplikacji powinien wspierać organizację w realizacji zasady rozliczalności.
Prawa podmiotów danych, czyli co musisz zapewnić użytkownikom
Mamy 6 najważniejszych praw podmiotów danych. Pokażę Ci jak implementować je w aplikacjach na przykładach:
- Prawo dostępu do danych
- Prawo do poprawienia danych i ograniczenia przetwarzania
- Prawo do bycia zapomnianym, tj. usunięcia danych z systemu
- Prawo do przenoszenia danych
- Prawo do sprzeciwu wobec przetwarzania oraz do niepodlegania decyzji opartych na zautomatyzowanym przetwarzaniu
Mimo, że RODO określa te prawa, nie zawsze są one możliwe do wykonania. Na przykład jeśli podmiot danych chce skorzystać z prawa do bycia zapomnianym, Twój system powinien sprawdzić jakie są warunki wykonania tego prawa – np. może dojść do braku integralności danych, co samo w sobie może być uznane za naruszenie ochrony DO.
Pytania, które trzeba sobie zadać projektując system/aplikację w celu zapewnienia mechanizmów wykonania praw podmiotów danych to:
1) czy jesteśmy w stanie zidentyfikować usera? Wiele firm nie weryfikuje użytkowników.
2) czy system zapewnia możliwość kontroli przez usera procesów przetwarzania?
3) czy system umożliwia usunięcie zestawu danych?
4) Czy system chroni przed usunięciem dane, które są przechowywane ze względu na wymogi prawa – np. rekordy zamówień ? Firma powinna poinformować podmiot danych, jakie dane i z jakiego powodu nie mogą być na jego żądanie usunięte oraz jak długo będą przechowywane.
Podsumowanie
Omówiliśmy kilka istotnych zagadnień związanych z projektowaniem aplikacji w zgodzie z RODO. Jak widzisz, prywatność jest prawem podstawowym, ale nie absolutnym. Prawo do prywatności nie zawsze przeważa nad interesami, jakie może mieć strona trzecia (firma) w dostępie do informacji o użytkowniku. Aby jednak firma mogła legalnie przekroczyć granicę prywatności, musi mieć solidną legitymację. Jest to ścisły obowiązek firmy, aby zapewnić, że ta legitymizacja jest odpowiednia, udokumentowana i zakomunikowana, a twórcy oprogramowania mogą bez wątpienia wspierać ten proces.
Disclaimer: Treści umieszczone na stronie są treściami edukacyjnymi lub poglądami jej twórczyni, w związku z czym nie stanowią porad prawnych. Pamiętaj, że każdy problem prawny ma swoje zmienne ze względu na indywidualny charakter, a wszelkie decyzje finansowe, podatkowe czy inwestycyjne podejmujesz na własną odpowiedzialność.