Jak zaprojektować aplikację mobilną zgodnie z RODO?

Pierwszym krokiem przy wdrożeniu RODO w aplikacji powinno być zmapowanie przepływów danych, ponieważ sama lista w bazie nie wystarcza. Ważniejsza jest wiedza, skąd dane pochodzą, gdzie trafiają i kto może z nich korzystać. Dla każdej funkcji aplikacji mobilnej trzeba odpowiedzieć przynajmniej na parę podstawowych pytań: jaki jest cel przetwarzania, jakie dane są do niego niezbędne, gdzie będą przechowywane, kto może otrzymać do nich dostęp oraz kiedy zostaną usunięte.

Przykładowo, prosta aplikacja do prowadzenia listy zadań może działać bez konta i przechowywać wszystko na urządzeniu. Dodanie synchronizacji między kilkoma urządzeniami powoduje już potrzebę rozpoznania użytkownika. Dodanie narzędzi analitycznych może wprowadzić kolejnych odbiorców danych. Dodanie logowania przez dostawcę zewnętrznego tworzy kolejny przepływ pomiędzy użytkownikiem, dostawcą tożsamości i wydawcą aplikacji.

Z perspektywy RODO każdą z tych operacji trzeba ocenić osobno.

Uwierzytelnienie użytkownika to nie to samo, co utworzenie konta. Uwierzytelnienie potwierdza, kim jest użytkownik. Konto jest natomiast rekordem i zestawem danych, które aplikacja stale utrzymuje na jego temat.

Takie rozróżnienie jest istotne przy Google Sign-In, Sign in with Apple czy Facebook Login. Dostawca zewnętrzny może potwierdzić tożsamość użytkownika, ale aplikacja nadal może utworzyć we własnej bazie osobne konto zawierające np. identyfikator użytkownika, historię aktywności, ustawienia, zakupione funkcje i dane wygenerowane podczas korzystania z usługi. W takim modelu wydawca aplikacji nie może uznać, że skoro nie przechowuje hasła Google czy Apple, nie odpowiada już za konto w jego aplikacji. Jeżeli ustala cele i sposoby wykorzystania danych znajdujących się w swoim systemie, pozostaje administratorem tych operacji w rozumieniu art. 4 pkt 7 RODO.

Jeśli chodzi o rejestrację i logowanie przez e-mail, to w modelu e-mailowym wydawca aplikacji najczęściej samodzielnie odpowiada za proces tworzenia konta, uwierzytelnienia i dane związane z profilem użytkownika. Nie oznacza to, że potrzebna jest zgoda użytkownika na każdą operację. Jeżeli adres e-mail i dane uwierzytelniające są obiektywnie potrzebne do założenia i prowadzenia konta będącego elementem usługi, podstawą może być art. 6 ust. 1 lit. b RODO – niezbędność przetwarzania do wykonania umowy lub podjęcia działań przed jej zawarciem.

Europejska Rada Ochrony Danych interpretuje „niezbędność” dość restrykcyjnie. Nie wystarczy wpisać tego przetwarzania do regulaminu, lecz operacja musi być obiektywnie potrzebna do wykonania konkretnej usługi. Dlatego przetwarzanie adresu e-mail może być uzasadnione, gdy służy on logowaniu, odzyskaniu dostępu lub do komunikacji związanej z kontem. Znacznie trudniej uzasadnić na tej samej podstawie pobieranie np. daty urodzenia, płci, numeru telefonu albo pełnego imienia i nazwiska, jeżeli żadna funkcja aplikacji takich danych nie potrzebuje.

Hasła należy traktować szczególnie ostrożnie. RODO nie narzuca jednej technologii ich przechowywania, ale art. 32 wymaga zabezpieczeń adekwatnych do ryzyka. W praktyce oznaczać to może m.in. brak przechowywania haseł w postaci jawnej, odpowiednie hashowanie, ochronę procesu resetowania hasła, ograniczenie prób logowania oraz dodatkowe mechanizmy uwierzytelnienia tam, gdzie uzasadnia je ryzyko.

Natomiast co z logowaniem przez Google, Apple lub Facebooka? Social login nie powoduje automatycznie, że Google, Apple albo Meta stają się procesorem wydawcy aplikacji. Role trzeba ustalać dla konkretnych operacji. Administrator to podmiot rzeczywiście decydujący o celach i zasadniczych sposobach przetwarzania. Procesorem jest natomiast podmiot przetwarzający dane w imieniu administratora oraz na jego zlecenie. Jedna relacja biznesowa może obejmować kilka operacji o różnych kwalifikacjach.

Dostawca może jednak wykonywać równolegle własne operacje, a w określonych konfiguracjach może również wystąpić współadministrowanie. Dla przykładu, TSUE w sprawie C-40/17, Fashion ID, wydanym jeszcze na podstawie przepisów dyrektywy 95/46 obowiązującej przed wejście w życie RODO uznał, że operator strony integrujący wtyczkę społecznościową mógł być wspólnie odpowiedzialny z Facebookiem za etap zbierania i przekazywania danych, mimo że sam nie miał do nich dostępu. Wyrok nie dotyczył wprawdzie logowania za pomocą Facebooka, ale dobrze pokazuje istotną zasadę: sam fakt, że dane są technicznie zbierane i przekazywane przez rozwiązanie dostarczone przez zewnętrznego dostawcę (Software Development Kit – SDK), nie wyłącza odpowiedzialności podmiotu, który zdecydował o jego wykorzystaniu w swojej aplikacji lub na swojej stronie.

RODO nie wymaga checkboxa „akceptuję politykę prywatności”. Polityka prywatności lub klauzula informacyjna służy poinformowaniu użytkownika, a nie uzyskaniu jego zgody na każde przetwarzanie.

Jeżeli prowadzenie konta opiera się na art. 6 ust. 1 lit. b RODO, czyli niezbędności przetwarzania do zawarcia umowy lub podjęcia działań przed jej zawarciem – tworzenie takiej sztucznej zgody na „przetwarzanie danych w celu realizacji usług” ukrywa właściwą podstawę prawną. Zgoda jest potrzebna wtedy, gdy administrator rzeczywiście wybiera art. 6 ust. 1 lit. a jako podstawę konkretnego, opcjonalnego celu. Musi ona wtedy być dobrowolna, konkretna, świadoma, jednoznaczna i możliwa do wycofania w dowolnym momencie, o czym użytkownika należy uprzednio poinformować.

Osobną kwestią jest akceptacja regulaminu serwisu. Regulamin opisuje zasady umowy i świadczenia usługi. Art. 8 ustawy o świadczeniu usług drogą elektroniczną wymaga udostępnienia go przed zawarciem umowy. Checkbox może być przydatnym dowodem jako potwierdzenie akceptacji regulaminu, ale nie należy łączyć go ze zgodą marketingową czy zgodą na opcjonalną analitykę.

Klauzulę informacyjną najlepiej udostępniać warstwowo: krótka informacja przy rejestracji lub social loginie, zawierająca link do pełnej polityki prywatności, oraz zapewnienie stałego dostępu do dokumentu w ustawieniach aplikacji lub na stronie internetowej. Warstwowe przekazywanie informacji jest dozwolone, o ile użytkownik może łatwo dotrzeć do informacji wymaganych przez RODO.

Zakres danych powinien wynikać z dostępnych funkcji, a nie z gotowego szablonu formularza rejestracyjnego. Art. 5 ust. 1 lit. c RODO wymaga, aby dane były adekwatne, stosowne i ograniczone do tego, co niezbędne. W praktyce najprostsze pytanie produktowe brzmi: co przestanie działać, jeżeli tych danych nie zbierzemy? Jeżeli odpowiedź brzmi „nic”, warto przemyśleć rzeczywistą konieczność ich zbierania. Rodzaj aplikacji zmienia skalę ryzyka – aplikacja sklepu internetowego może potrzebować danych kontaktowych oraz, przy realizacji dostawy, danych adresowych. Aplikacja narzędziowa działająca offline może nie potrzebować żadnego konta. Aplikacja zdrowotna może wejść bezpośrednio w obszar szczególnych kategorii danych.

Dane dotyczące zdrowia wymagają osobnej analizy. Nie każdy parametr z aplikacji dotyczącej zdrowia jest automatycznie daną szczególnej kategorii, ale dane ujawniające informacje o stanie zdrowia są danymi dotyczącymi zdrowia w rozumieniu RODO.

Art. 9 ust. 1 RODO ustanawia zasadniczy zakaz przetwarzania szczególnych kategorii danych, w tym danych dotyczących zdrowia, i przewiduje wyjątki w ust. 2. Jeżeli aplikacja rzeczywiście przetwarza takie informacje, sama ogólna podstawa z art. 6 RODO nie kończy analizy, bo potrzebna jest również właściwa dodatkowa przesłanka pozwalająca na przetwarzanie danych szczególnej kategorii. Przykładowo zapis „przebiegnięto 5 km” nie musi sam w sobie ujawniać stanu zdrowia. Zestaw danych obejmujący tętno spoczynkowe, nieprawidłowości rytmu serca, wyniki badań i informacje o chorobach może już wyraźnie dotyczyć zdrowia.

Przy rozwiązaniach wysokiego ryzyka trzeba także ocenić obowiązek przeprowadzenia DPIA, czyli oceny skutków dla ochrony danych. Prezes UODO w jednym z poradników dostępnych na stronie UODO przypomina, że art. 35 RODO wymaga jej przeprowadzenia, jeżeli planowane przetwarzanie może z dużym prawdopodobieństwem powodować wysokie ryzyko dla praw lub wolności osób.

Imię i nazwisko nie są domyślnie potrzebne do konta, które może działać bez znajomości rzeczywistego imienia i nazwiska użytkownika.

Jeżeli jedynym celem jest rozpoznanie konta, często wystarczy techniczny identyfikator. Jeżeli potrzebny jest sposób zwracania się do użytkownika, może wystarczyć nick albo inna dobrowolna nazwa wyświetlana. Pełne dane mogą być potrzebne dopiero w innej funkcji, np. wystawieniu dokumentu, dostawie albo realizacji obowiązku wynikającego z konkretnych przepisów. Projekt formularza powinien odzwierciedlać to rozróżnienie. Dane, które mogą zostać zebrane dopiero przy zakupie, nie muszą być zbierane już w formularzu rejestracyjnym.

Opcja notatek w aplikacji może otworzyć nieplanowany kanał zbierania danych. Administrator odpowiada za rzeczywiste przetwarzanie, a nie tylko za dane, które zamierzał otrzymać.

Użytkownik może wpisać w wolnym polu tekstowym dowolne informacje o chorobie, religii, sytuacji rodzinnej albo dane innej osoby. Jeżeli taka treść trafia do infrastruktury administratora, stanie się częścią jego procesów przetwarzania. Problem najlepiej ograniczać na poziomie projektu. Zamiast jednego pola „inne informacje” można zastosować pola strukturalne odpowiadające celowi funkcji. Tam, gdzie wolny tekst jest potrzebny, pomocne mogą być jasne instrukcje, ograniczenie zakresu, ostrzeżenie przed wpisywaniem niepotrzebnych danych osób trzecich oraz mechanizmy automatycznego usuwania określonych treści, o ile ich zastosowanie jest proporcjonalne do ryzyka.

Privacy by design nie polega w tym przypadku na dopisaniu do regulaminu zakazu wprowadzania dowolnych treści. Polega przede wszystkim na nietworzeniu funkcjonalności, która zachęca użytkownika do przekazywania danych bez realnej potrzeby.

Architektura lokalna może istotnie ograniczyć zakres obowiązków i ryzyko, ale samo przechowywanie danych na telefonie nie oznacza automatycznie, że RODO nie ma zastosowania.

• Model całkowicie lokalny

Francuski organ ochrony danych CNIL w rekomendacji dotyczącej aplikacji mobilnych przyjmuje, że w określonych przypadkach aplikacja może jedynie dostarczać użytkownikowi narzędzie do przetwarzania objętego wyjątkiem osobistym lub domowym. Organ wskazuje m.in. na sytuacje, w których przetwarzanie odbywa się z inicjatywy użytkownika, pozostaje pod jego kontrolą, służy wyłącznie jemu i odbywa się w odseparowanym środowisku bez możliwości ingerencji podmiotu trzeciego. Jako przykład CNIL wskazuje określone aplikacje zdrowotne zapisujące dane wyłącznie lokalnie, bez zewnętrznego połączenia i bez zdalnej usługi.

W konkretnej aplikacji trzeba ustalić, czy wydawca rzeczywiście jest wyłącznie dostawcą oprogramowania. Telemetria, zdalna synchronizacja, dostęp supportu albo zewnętrzne SDK mogą zmienić ocenę.

Trzeba również pamiętać o Prawie komunikacji elektronicznej. Art. 399 PKE reguluje przechowywanie informacji na urządzeniu końcowym i dostęp do informacji już tam zapisanej. Co do zasady przewiduje uprzednie poinformowanie i konieczność wyrażenia zgody, ale ust. 3 wyłącza te warunki, jeżeli operacja jest konieczna do transmisji albo dostarczenia usługi wyraźnie żądanej przez użytkownika.

Dlatego zapis ustawienia koniecznego do działania funkcji i zapis identyfikatora reklamowego wymagają odrębnych analiz. Nie można przyjąć reguły, że każda operacja lokalna potrzebuje zgody albo że żadna jej nie potrzebuje.

• Backend i chmura

Jeżeli dane trafiają na backend wydawcy, wydawca zwykle wchodzi bezpośrednio w rolę administratora w zakresie, w jakim ustala cele i sposoby ich wykorzystania.

Dostawca chmury może być podmiotem przetwarzającym, jeżeli działa na udokumentowane polecenie administratora. Wtedy współpraca powinna przebiegać zgodnie z wymogami art. 28 RODO. Jeżeli dostawca wykorzystuje określone dane do własnych, samodzielnie ustalanych przez niego celów, sama etykieta „procesor” w umowie nie przesądza o kwalifikacji procesu przetwarzania.

Przed wdrożeniem backendu trzeba ustalić również lokalizację danych, podwykonawców i dostęp administracyjny.

Jeśli chodzi o bezpieczeństwo, retencja, usuwanie i kopie zapasowe, to art. 32 RODO nie daje programiście zamkniętej checklisty zabezpieczeń. Wymaga dostosowania przyjętych środków odpowiednio do ryzyka.

W praktyce w aplikacji serwerowej oznacza to m.in. ochronę transmisji, ograniczanie uprawnień, bezpieczne przechowywanie tokenów, właściwe zarządzanie sekretami, oddzielenie środowisk, kontrolę dostępu oraz mechanizmy ograniczające nadużycia przy logowaniu. Retencja nie powinna być określana jednym zdaniem „przechowujemy dane do usunięcia konta”. Poszczególne kategorie danych czy procesy przetwarzania mogą mieć różne cele i okresy. Dane niepotrzebne po usunięciu funkcji powinny być usuwane wcześniej, jeżeli nie istnieje odrębna podstawa do ich dalszego przechowywania. Kopie zapasowe również zawierają dane osobowe. Proces usuwania powinien więc określać czas ich rotacji oraz sposób postępowania przy odtworzeniu backupu, aby usunięte dane nie wróciły bez kontroli do aktywnej bazy oraz aby nie ulegały żadnym modyfikacjom.

Przed wysłaniem aplikacji do App Store albo Google Play dobrze jest wykonać przynajmniej następujące czynności:

1. sporządzić mapę danych i odbiorców dla każdej funkcji;
2. usunąć pola, których nie da się powiązać z konkretnym celem;
3. ustalić podstawę przetwarzania z art. 6 RODO dla każdego celu, a przy danych szczególnych także dodatkowo przesłankę z art. 9;
4. rozdzielić uwierzytelnienie od danych rzeczywiście potrzebnych w profilu aplikacji;
5. zweryfikować każdy SDK i jego ruch sieciowy;
6. rozdzielić regulamin, obowiązek informacyjny i opcjonalne zgody;
7. ustalić retencję, procedurę usunięcia konta i zachowanie backupów;
8. sprawdzić umowy z hostingiem, chmurą i innymi procesorami;
9. przeprowadzić analizę konieczności DPIA przed uruchomieniem funkcji wiążących się z wysokim ryzykiem.

Najdroższe problemy z prywatnością powstają zwykle wtedy, gdy architektura została już zamknięta i administrator zleca „jedynie napisanie polityki prywatności”. W aplikacji projektowanej zgodnie z RODO dokumentacja opisuje istniejącą architekturę, a nie próbuje jej naprawiać po czasie.