Realizacja praw podmiotów danych w praktyce – część II

Realizacja żądań z perspektywy systemu IT

Realizacja praw podmiotów danych przysługujących im na gruncie RODO, w zdecydowanej większości przypadków wymaga zaangażowania obszaru IT. Nie istnieje lista wymaganych funkcjonalności (i zabezpieczeń) jakie powinien posiadać system informatyczny, aby był zgodny z RODO. Dlatego jednym z kluczowych etapów wdrożenia RODO jest dostosowanie systemów IT do nowych przepisów w zależności od potrzeb wykorzystania tych systemów.

Część administratorów podjęła się przystosowania systemów samodzielnie, wykonując prace rozwojowe (np. dodając do systemu możliwość wygenerowania raportu z kopią danych z poziomu użytkownika), albo inwestując niemałe kwoty w zlecenie dostawcy systemu wdrożenie odpowiednich zmian. Inni administratorzy postanowili obserwować ilość oraz typy zgłaszanych żądań i realizować je posiłkując się rozwiązaniami „prowizorycznymi” np.  eksportem z bazy danych do pliku o formacie CSV. Każde z tych rozwiązań może być poprawne. W przypadku organizacji, których charakterystyka działalności generuje potencjał dla masowych żądań, warto zainwestować w automatyzację obsługi procesu realizacji żądań (np. poprzez umieszczenie na poziomie interfejsu klienta kilku typów wniosków do wyboru). Zapewni to efektywną, niegenerującą kosztów pracy i terminową obsługę żądań.

Niezależnie od przyjętego sposobu realizacji żądań, przed administratorem danych i jego zespołem IT pozostaje wiele decyzji do podjęcia. O ile żądanie sprostowania czy nawet usunięcia danych nie będzie nastręczało wielu problemów, o tyle żądania otrzymania kopii danych, czy pliku do przeniesienia już tak. Wskazanie formatu pliku czy nośnika, na jakim przekażemy osobie informacje, będzie najprostszą kwestią. Przetwarzając dane w złożonych relacyjnych bazach danych, ilość informacji jaką jesteśmy w stanie połączyć z konkretną osobą jest ogromna. Konieczne jest dokonanie przeglądu tych informacji, wyselekcjonowanie informacji, które nie będą stanowiły danych osobowych i podjęcie decyzji, które informacje powinny ostatecznie znaleźć się w przekazywanym podmiotowi danych pliku. Przykładowo – czy przypisaną do każdego klienta w systemie finansowym informację o terminie płatności lub sposobie przekazania faktury, uznamy za kategorię danych osobowych i włączymy ją do pliku?

Plik do przeniesienie danych nie musi być przejrzysty i zrozumiały dla podmiotu danych, jego format ma przede wszystkim umożliwiać importowanie danych do bazy innego administratora. Kopia danych już zdecydowanie powinna być przejrzysta i zrozumiała. Tworząc kopię danych, korzystając z informacji pochodzących wprost z bazy danych, administratorzy mogą się szybko przekonać, że konieczne jest zaimplementowanie odpowiedniej funkcjonalności w systemie. Jakie mogą być tego powody?

  • Nazwy pól informacyjnych prezentowane z poziomu bazy danych mogą być w dużej mierze niezrozumiałe dla podmiotu danych. Dla zobrazowania problemu kilka oznaczeń pól stosowanych w systemie Płatnik: PRDOEM – prawo do emerytury, IMIEPIERW – pierwsze imię ubezpieczonego, IV_2_SSKLUBR – suma kwot składek na ubezpieczenia rentowe.
  • Nazwy pól informacyjnych mogą być napisane w języku innym niż posługuje się podmiot danych, w praktyce jest to najczęściej angielski. Czy taką kopię danych przekazaną przez polskiego administratora polskiemu podmiotowi danych można uznać za zrozumiałą? Nie.

Rejestr żądań podmiotów danych

Dla spełnienia wymagania rozliczalności nałożonego przez RODO, większość administratorów i procesorów prowadzi rejestry realizacji żądań podmiotów danych. W rejestrze powinny znaleźć się dane podmiotu danych (np. imię, nazwisko, telefon, adres, e-mail), treść lub określenie typu żądania (usunięcie, sprzeciw, itp.), data i kanał komunikacji jakim wpłynęło żądanie, data i sposób zrealizowania żądania. Przydatne mogą okazać się również:

  • Oznaczenie kategorii podmiotu danych.
  • Oznaczenie systemu czy bazy, w której dane są przetwarzane.
  • Wskazanie osoby w organizacji, która realizuje żądanie w bazie.
  • Data przekazania żądania procesorowi.
  • Wskazanie danych, które posłużyły weryfikacji tożsamości podmiotu danych.

Praktyczne problemy realizacji żądań

Z perspektywy niemal roku od wejścia w życie RODO, okazuje się, że bardzo często trudności w realizacji żądań są bardziej prozaiczne niż brak funkcjonalności w systemie IT. Około 30% żądań zawiera braki uniemożliwiające realizację żądania.

W większości przypadków podmioty danych nie posługują się w treści żądań nomenklaturą RODO lub mylą pojęcia. W efekcie z treści żądania nie wynika czego oczekuje podmiot danych. Żąda usunięcia danych? Zgłasza sprzeciw na nasze działania marketingowe? A może jednak wycofuje zgodę na przetwarzanie danych? Administrator danych może próbować skontaktować się podmiotem danych celem doprecyzowania żądania lub samodzielnie podjąć decyzję o zakwalifikowaniu żądania do określonego typu. Może zdarzyć się również, że mimo precyzyjnego zdefiniowania żądania przez podmiot danych, administrator zakwalifikuje je jako inne. Przykładem może być żądanie zaprzestanie przetwarzania danych w celach marketingowych od konsumenta, którego dane są przetwarzane w bazie marketingowej. W takim przypadku większość administratorów podejmie decyzję o usunięciu danych konsumenta z bazy, gdyż przy takim jej charakterze utrzymanie rekordu, którego nie można wykorzystać w celu marketingowym, jest bezcelowe.

Bardzo często żądania nie zawierają wystarczającej ilości informacji o podmiocie danych, aby administrator był w stanie go zidentyfikować czy zweryfikować. Na przykład – korzystając z adresu mailowego wskazanego do kontaktu z Inspektorem Ochrony Danych, podmiot danych wysyła żądanie nie podając swojego imienia i nazwiska. Jedyną daną osobową podaną w treści żądania jest adres mailowy, natomiast administrator przetwarza w bazie jedynie imię, nazwisko, adres zamieszkania i telefon. Zdarzają się również zgłoszenia telefonicznie z ukrytego numeru, gdzie osoba odmawia podania jakichkolwiek informacji o sobie, żądając jednocześnie usunięcia jej danych osobowych.

W obu przypadkach opisanych powyżej, metodą na rozwiązanie problemu jest skontaktowanie się z podmiotem danych w celu uzupełnienia danych, wyjaśnienia przedmiotu żądania czy weryfikacji tożsamości podmiotu danych.  Niestety, zadanie to okazuje się być niezwykle trudne do wykonania, gdyż reakcja osób jest zwykle emocjonalna, zdarza się, że odmawiają udzielania informacji, czy też nie reagują na mailowe prośby o uzupełnienie danych. W takich przypadkach, po stronie administratora istotne jest zachowanie np. historii korespondencji mailowej, na wypadek złożenia przez podmiot danych skargi do Prezesa Urzędu Ochrony Danych Osobowych (PUODO).

Częstą przyczyną skarg do PUODO są niezrealizowane przez administratora żądania usunięcia danych. Zdarza się, że żądania usunięcia danych są realizowane jedynie częściowo, z uwagi na ograniczenia prawne. Przykładowo żądanie usunięcia danych wniesione przez klienta, który dokonał zakupu w sklepie internetowym 3 lata temu, zostanie zrealizowane tylko w zakresie jego profilu użytkownika w sklepie, czy listy subskrypcyjnej newslettera. Dane w dokumentacji księgowej będą wciąż przetwarzane przez administratora ze względu na ciążące na nim obowiązki rachunkowe. Przeciętny „Kowalski” nie rozumie tej konstrukcji, zwłaszcza w towarzystwie komunikatów medialnych mówiących, że RODO zapewnia mu prawo do bycia zapomnianym i jego dane zostaną całkowicie usunięte na jego żądanie.

doradczymi w obszarze ochrony danych

Autor

Daria Worgut-Jagnieża

Od kilkunastu lat kieruje projektami audytowymi i doradczymi w obszarze ochrony danych osobowych oraz bezpieczeństwa informacji. Pełni funkcję Inspektora Ochrony Danych w wielu międzynarodowych korporacjach m.in. z branży farmaceutycznej.