RODO w programowaniu, czyli jak wpisać ochronę danych w proces tworzenia narzędzi informatycznych

Poradnik

20.03.2019

11 min. czytania

Tekst

W Polsce 100% dużych i średnich firm zbiera dane, ale nie bardzo wie po co – aż 77,5% nie widzi potrzeby ich wykorzystywania. Na gruncie RODO nie ma miejsca na lekkomyślne podejście do danych, a dbałość o ich ochronę musi na stałe zagościć w checklistach osób tworzących narzędzia, w których dane są przetwarzane. Jak jeszcze RODO wpływa na pracę programistów? Czy mogą być oni „agentami” użytkowników? W tym tekście postaramy się odpowiedzieć na te pytania, rozwiać najważniejsze wątpliwości zgłaszane przez naszych odbiorców i podpowiedzieć, gdzie szukać praktycznych wskazówek.

Co RODO zmieniło w programowaniu?

Głównym powodem, dla którego unijny regulator zdecydował się przyjąć RODO w miejsce obowiązującej od 1995 r. dyrektywy o ochronie danych osobowych, była chęć odpowiedzi na szybko zmieniającą się rzeczywistość, w której nowe technologie są coraz ważniejszą gałęzią gospodarki. Aby uniknąć wprowadzania w RODO ciągłych zmian dostosowujących je do coraz to nowych rozwiązań technicznych, nowe prawo jest neutralne technologicznie – oznacza to, że jego przepisy dotyczą w takim samym stopniu wszystkich procesów przetwarzania danych, niezależnie od tego, czy przetwarzanie odbywa się w papierze, na dysku lokalnym komputera czy w chmurze, ani jakie narzędzia są do tego wykorzystywane.

RODO wprowadza podejście oparte na ryzyku – im więcej danych, tym silniejsze zabezpieczenia.

Logiczną konsekwencją tej koncepcji jest to, że w miejsce szczegółowych wytycznych na temat wdrażanych zabezpieczeń, pojawia się elastyczne podejście oparte na ryzyku – to administrator (w praktyce zarządzający w porozumieniu z działem IT), biorąc pod uwagę charakter swojej działalności i wykorzystywane dane, decyduje o tym, jakie zabezpieczenia zastosować. Zasada jest prosta: im więcej danych i im bardziej są one wrażliwe, tym zabezpieczenia powinny być silniejsze.

Z punktu widzenia branży informatycznej rozporządzenie wprowadza dwie kluczowe zasady: privacy by design i by default (prywatność w fazie projektowania i domyślna ochrona prywatności). Ta pierwsza, privacy by design, wymaga od administratora wpisania zasad ochrony danych w projektowanie danego produktu lub usługi od samego początku oraz wdrożenie tych zasad w postaci konkretnych rozwiązań technicznych i organizacyjnych, np. poprzez zbieranie wyłącznie danych niezbędnych do danego celu, okresowe ich kasowanie, wprowadzenie pseudonimizacji czy poziomów dostępu. Druga zasada, privacy by default, oznacza, że domyślnie powinien być zapewniony maksymalny poziom ochrony prywatności (a więc nawet jeśli sam użytkownik nie podejmie żadnych kroków w tym kierunku, domyślne ustawienia aplikacji mają chronić jego prywatność w najwyższym stopniu).

Zasady privacy by design i privacy by default muszą na stałe trafić do checklisty programistów.

Jakie podejście do danych przeważa w komercyjnych usługach? Z badań przeprowadzonych pod koniec 2018 r. wynika, że 100% dużych i średnich firm w Polsce zbiera dane, ale nie bardzo wie po co – aż 77,5% nie widzi potrzeby ich wykorzystywania. Być może nadal nie zdają sobie sprawy, że za zbieranie danych „na wszelkich wypadek” zgodnie z RODO grożą wysokie kary, a może zmagają się wewnętrznie z przebudowaniem procedur i przełożeniem zasad takich jak privacy by design na codzienną praktykę. Jak się do tego zabrać? Wyobraźmy sobie checklistę wymagań, jakie powinna posiadać dobrze zaprojektowana aplikacja. Załóżmy, że powinna ona być wydajna, możliwie lekka, intuicyjna i responsywna. Do tej listy trzeba dodać standardowe wymaganie, zgodnie z którym aplikacja zbiera tylko te dane, które są niezbędne do jej poprawnego funkcjonowania. W dalszej części piszemy, gdzie znaleźć konkretne przykłady dobrych praktyk.

Kto ma dbać o prywatność użytkowników?

Tworzenie oprogramowania może być złożonym procesem z wieloma zaangażowanymi stronami albo jednoosobową inicjatywą. Z punktu widzenia RODO kluczowe jest ustalenie, kto podejmuje decyzje o celach i sposobach przetwarzania danych, bo to ten podmiot (czasem osoba fizyczna, czasem spółka) jest ich administratorem.

Jeśli programista pracuje na własny rachunek (np. z własnej inicjatywy tworzy aplikację i udostępnia ją szerszej publiczności), to odpowiedzialność za ochronę prywatności użytkowników spoczywa w całości na nim. Jeśli pracuje na zlecenie klienta, odpowiedzialność za to, by dane użytkowników były jak najlepiej chronione, ciąży na zleceniodawcy.

Z rozmów z praktykami wiemy jednak, że rola programisty bywa różna w zależności od projektu – czasem ma więcej swobody w podejmowaniu decyzji co do projektowanych funkcjonalności, czasem musi „dowieźć” projekt, który spełnia precyzyjnie określone kryteria. Zachęcamy programistów, by w relacjach, w których mają większą samodzielność, wybierali rozwiązania sprzyjające prywatności. W ramach tego, czego oczekuje klient, zwykle można zasugerować coś, co rzeczywiście zwiększa bezpieczeństwo danych albo daje większą kontrolę użytkownikowi.

Programista może przyjąć rolę „anioła stróża” prywatności i sugerować rozwiązania, które zwiększają bezpieczeństwo.

Bywa, że klienci nie zdają sobie nawet sprawy z zagrożeń, które może wygenerować tworzony produkt. Programista jest wówczas w uprzywilejowanej pozycji, bo – konfrontując klienta z tymi zagrożeniami – może przyjąć rolę „anioła stróża” prywatności, a jednocześnie zdobyć szacunek w relacji biznesowej. A co z klientami, którzy twierdzą, że prywatność użytkowników ich nie obchodzi? W swoim webinarze Beata Marek z cyberlaw.pl podpowiada sprytną reakcję na takie podejście: warto zapytać, czy nie obchodziłoby go też, gdyby ktoś wziął jego bazę danych i wystawił w sieci na sprzedaż (i publiczną krytykę).

Czy można korzystać z gotowych komponentów?

To normalne i zrozumiałe, że programiści, szukając oszczędności czasu i pieniędzy, sięgają po open source’owe czy inne stworzone przez osoby trzecie komponenty. Taka decyzja nie zwalnia jednak z przestrzegania zasad ochrony danych osobowych. Zanim programista zdecyduje się skorzystać z zewnętrznego rozwiązania, powinien upewnić się, że zostało ono zaprojektowane zgodnie z RODO. Dlaczego ta kwestia miałaby być mniej ważna niż to, czy zewnętrzny komponent nie ma błędów w kodzie?

Zgodność z RODO przewagą konkurencyjną

RODO napędza innowację, bo daje mocne (również finansowe!) argumenty, żeby tworzyć bezpieczne, bardziej dopracowane pod kątem UX i przemyślane programy. Będą one co prawda droższe, ale – ze względu na wysoki standard ochrony prywatności i zabezpieczenia danych – mogą się okazać atrakcyjniejsze zarówno dla inwestorów, jak i samych użytkowników. Dla porównania: dziurawy i niedopracowany produkt to nie tylko realne ryzyko kar ze strony organu nadzorczego, ale też utraty zaufania po stronie użytkowników i – co za tym idzie – niskich przychodów.

W sytuacji, gdy klient zamówi „produkt zgodny z RODO” warto – jeśli wykonawca ma odpowiednie kompetencje – osobno wycenić audyt narzędzia. Taką usługę można też zlecić osobnemu podmiotowi i uwzględnić ten koszt w zamówieniu.

Kto ponosi odpowiedzialność za wyciek?

W sytuacji wycieku lub innego naruszenia bezpieczeństwa danych odpowiedzialność programisty będzie zależała od tego, jaka była jego rola w budowaniu i utrzymywaniu tego konkretnego systemu. Jeśli programista po prostu napisał kawałek kodu lub zaprojektował cały system na czyjeś zlecenie i zgodnie z przekazanymi mu wytycznymi, to klient – jako administrator danych – musi się liczyć z potencjalną karą nałożoną przez Prezesa UODO czy pozwem ze strony użytkownika, który poniósł szkodę w związku z naruszeniem jego praw.

Odpowiedzialność programisty za wyciek zależy od tego, jaką rolę pełnił w budowaniu i utrzymywaniu konkretnego systemu.

Trochę inaczej będzie w sytuacji, w której programista jest odpowiedzialny za utrzymywanie produktu, który stworzył. Jeśli ma dostęp do przetwarzanych danych osobowych, administrator powinien zawrzeć z nim (jeśli jest samozatrudniony) lub z jego pracodawcą (jeśli pracuje na etacie) umowę powierzenia. Taka umowa daje większe podstawy do odpowiedzialności – RODO przewiduje, że kara może zostać nałożona nie tylko na administratora, ale też na podmiot przetwarzający dane. W tym układzie użytkownik, który poniósł szkodę w związku z naruszeniem jego praw, może pozwać także procesora, jeśli ten źle realizował swoje obowiązki.

W obu wyżej opisanych scenariuszach wykonawca może ponieść odpowiedzialność cywilną wobec klienta na zasadach ogólnych (tzn. niezależnie od umowy między stronami), jeśli przyczyną wycieku będzie źle wykonany program. Zdarza się też, że klienci – chcąc się jeszcze bardziej zabezpieczyć – wprowadzają do umowy postanowienia zobowiązujące wykonawcę do zwrócenia administratorowi równowartości nałożonej kary lub odszkodowania, niezależnie od tego, czy wyciek nastąpił z jego winy. Takie praktyki, co do zasady, nie są zabronione, ale w konkretnych sprawach mogą zostać uznane za nieważne przez sąd (np. jeśli sąd dojdzie do wniosku, że klient wykorzystał słabszą pozycję wykonawcy). Morał jest prosty: warto dokładnie czytać umowy i dbać o swoje interesy, np. wpisując do umowy maksymalną kwotę, do wysokości której odpowiada programista. To szczególnie ważne, jeśli programista jest freelancerem – wtedy za zobowiązania odpowiada całym swoim majątkiem.

Czy zabezpieczenie danych może utrudnić realizowanie praw użytkowników?

Szukając sposobów na lepsze zabezpieczenie danych administratorzy korzystają np. z systemów rozproszonych czy pseudonimizacji. Idąc w tym (skądinąd wysoce rekomendowanym!) kierunku, trzeba pamiętać, że ten sam administrator ma też obowiązek realizować prawa użytkowników. A więc np. potrzebuje narzędzi, żeby w rozproszonych systemach odnaleźć wszystkie dane konkretnego użytkownika, który korzysta z prawa dostępu albo żąda ich usunięcia.

Niestety, zdarza się, że takie zabezpieczenia są wykorzystywane jako wymówka i powód, żeby nie realizować uprawnień użytkownika. Przykład z rynku reklamy internetowej: wiele firm, które pytaliśmy o nasze cyfrowe profile, twierdzi, że nic o nas nie wie – tylko dlatego, że identyfikatory z plików cookies zostały spseudonimizowane. Tymczasem pseudonimizacja to proces w pełni odwracalny, a dane wywnioskowane z analizy behawioralnej czy w inny sposób wygenerowane przez administratora to też dane osobowe, które na prośbę użytkownika należy udostępnić w przejrzystej i zrozumiałej formie. Przeciętnego użytkownika interesują konkrety (np. kategorie marketingowe, do których został przypisany), a nie tajemnicze ciągi cyfr i liter.

Kopie zapasowe a prawo do bycia zapomnianym

Swego czasu GIODO wywołał burzę w branży informatycznej, uznając, że żądanie usunięcia danych dotyczy też kopii zapasowych (backupów). To jednak nie oznacza, że pojedyncze dane należy kasować nawet kosztem integralności backupów. Jak poradzić sobie z trudnościami związanymi z wyłuskiwaniem pojedynczych logów z ogromu danych przechowywanych w kopiach zapasowych? Znów kłania się zasada privacy by design – najlepiej tak zaprojektować system, by segregował dane i okresowo je kasował. Przykładowo, z komputera można kasować dane starsze niż 5 lat, a backupy przechowywać tylko przez miesiąc. W takiej sytuacji usunięcie danych z komputera oznacza, że po miesiącu znikną również z kopii zapasowych.