Natalia Groszyk, Autor w serwisie RODOradar.pl

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.

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

RODO nadaje osobom fizycznym szereg praw związanych z przetwarzaniem ich danych osobowych. Prawa te stanowią jeden z filarów ochrony prywatności osób fizycznych. Największą uwagę poświęcano do tej pory prawu „do bycia zapomnianym” i prawu do przeniesienia danych. Stąd większość organizacji dostosowując się do nowych wymagań, opracowywała lub modyfikowała istniejące procedury realizacja praw podmiotów danych.

Rozwiązania przyjęte w procedurach, jak i poziom ich szczegółowości są różnorodne. Niejednokrotnie procedury implementowane są na poziomie grupy kapitałowej (lokalnie lub globalnie). Wymagają one wdrożenia szczegółowych instrukcji dla pracowników organizacji. Zarówno RODO, jak i Ustawa o ochronie danych osobowych, nie nakładają obowiązku wdrożenia procedury realizacji praw podmiotów danych. RODO wymaga skutecznej i terminowej realizacji żądań podmiotów danych. Czy wdrożone przez administratorów rozwiązania pozwoliły im w praktyce osiągnąć ten cel? Jak należałoby zatem zbudować prawidłowo funkcjonujący proces obsługi żądań podmiotów danych?

Mapowanie dokumentacji i systemów IT

Tworzenie procedury należy zacząć od zidentyfikowania dokumentacji i systemów informatycznych, w których przetwarzane są dane osobowe. Szczególną uwagę należy poświęcić przepływom danych pomiędzy systemami, częstotliwości i kierunkowi przepływu oraz zakresowi wymienianych danych. Poza systemami dziedzinowymi (np. CRM, system kadrowo-płacowy), należy pamiętać o systemach wsparcia (np. helpdesk, system obiegu dokumentów) oraz bazach przechowywanych na dyskach czy zasobach sieciowych. Kolejnym krokiem jest analiza wpływu żądań realizacji każdego z praw przysługujących podmiotom danych na zidentyfikowane zasoby (dokumenty i systemy). Celem analizy jest wskazanie systemów, w których dany typ żądania np. usunięcia danych będzie realizowany. W niektórych przypadkach może to być kilka systemów.

Instrukcja – krok po kroku

Aby procedura była praktyczna, warto precyzyjnie określić w niej kolejne kroki. Zarówno te realizowane dla wszystkich typów żądań, jak i te specyficzne dla danego typu żądania. Dla każdego kroku wymienionego w procedurze powinien zostać wskazany maksymalny czas realizacji. Dzięki temu proces realizacji żądania zostanie zaplanowany tak, aby zrealizować żądanie w terminie 30 dni, a osoby zaangażowane do poszczególnych zadań, będą znały ramy czasowe w jakich się poruszają.

Zdefiniowanie ról

Procedura powinna wskazywać właścicieli biznesowych konkretnych procesów przetwarzania danych i przypisane im role w procesie realizacji żądań. W zależności od wielkości organizacji i złożoności struktury organizacyjnej warto wskazać w procedurach te osoby z imienia i nazwiska wraz z podaniem ich danych kontaktowych. Dzięki temu możliwe będzie sprawne odszukanie właściciela biznesowego danych, pozostawiając zapas czasu na samą realizację żądania.

Wśród administratorów przyjęto różne rozwiązania co do ról w procesie realizacji żądań. Najprostszym rozwiązaniem jest powierzenie całości zadań tj. przyjmowania i obsługi żądań jednej osobie. Może być nią Inspektor Ochrony Danych czy inna osoba wyznaczona w organizacji. Z rozwiązania tego najczęściej korzystają niewielkie organizacje, gdyż wymaga ono, aby osoba realizująca żądania miała dostęp do systemów IT i dokumentacji i mogła samodzielnie dokonać zmian związanych z żądaniem.

Drugi z modeli polega na przyjmowaniu zgłoszeń i koordynacji ich realizacji przez Inspektora Ochrony Danych (czy inną wyznaczoną osobę), natomiast fizycznym zrealizowaniem żądania w dokumentacji i/lub systemie IT zajmują się właściciele biznesowi albo pracownicy IT, wskazani dla poszczególnych systemów.

Trzeci model jest najbardziej złożony, występuje w dużych grupach kapitałowych lub korporacjach międzynarodowych. Rola Inspektora Ochrony Danych ogranicza się tutaj właściwie do udostępnienia „skrzynki podawczej”, do której napływają żądania. Inspektor Ochrony Danych nadzoruje proces i stanowi wsparcie w trudniejszych przypadkach. Większość pracy wykonywana jest przez koordynatorów (nazywanych Privacy Steward albo Privacy Coordinator), którzy rejestrują żądania, a następnie przekazują je do realizacji właścicielom biznesowym czy pracownikom zespołu IT.

Wiele korporacji działających transgranicznie, powołało Privacy Office, którego zadaniem jest m in. przyjmowanie i realizacja żądań kierowanych do wszystkich spółek, oddziałów itp. Rozwiązanie takie okazuje się być nieefektywne czasowo, a główną przyczyną jest język komunikacji. Aby obsłużyć wpływające żądania z wielu krajów, Privacy Office w pierwszej kolejności musi rozpoznać język, w jakim napisane jest żądanie, a następnie przekazać żądanie do tłumaczenia na język angielski do kraju, z którego pochodzi żądanie. Dopiero od tego momentu możliwa jest analiza treści żądania i w zależności od sytuacji, udzielenie odpowiedzi lub złożenie prośby o wyjaśnienie w języku angielskim. W efekcie spora część czasu konsumowana jest na dokonywanie tłumaczeń i związaną z tym korespondencję pomiędzy Privacy Office a Privacy Stewardem.

Ustawa dostosowująca do RODO podpisana

3 kwietnia 2019 roku, Prezydent Andrzej Duda podpisał ustawę z dnia 21 lutego 2019 r. o zmianie niektórych ustaw w związku z zapewnieniem stosowania rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych).

Niemal rok od rozpoczęcia stosowania RODO (25 maja 2018 r.) oraz wejścia w życie nowej, krajowej Ustawy o ochronie danych osobowych (10 maja 2018 r.), doczekaliśmy się dostosowania krajowych przepisów do Rozporządzenia. Zmiany objęły około 170 obowiązujących aktów prawnych.

Na szczególną uwagę zasługują przede wszystkim zmienione przepisy w Kodeksie Pracy (uregulowana została m.in. kwestia kategorii danych osobowych niezbędnych do pozyskania pracownika, pozyskiwania danych wrażliwych pracowników, czy też monitoringu w pomieszczeniach socjalnych), oraz przepisy dotyczące praw pacjenta, a także sektora bankowego i ubezpieczeniowego.

Tak długi termin oczekiwania na ustawę dostosowującą przepisy prawa polskiego do RODO, należy po części tłumaczyć szerokością i złożonością materii, jaką objęły prace nad ustawą. Liczymy, że powód wydłużonego termin postępowania legislacyjnego uchroni nas przed kolejnymi nowelizacjami zmienianych ustaw, a wprowadzone zmiany okażą się adekwatne i stabilne.

Pozostaje mieć także nadzieję, że powstające od tej pory przepisy, zostaną objęte wskazaną w RODO procedurą „privacy by design” i nie nastąpi w przyszłości konieczność uchwalania kolejnego, tak obszernego i rozbudowanego pakietu przepisów.

Ustawa wejdzie w życie po upływie 14 dni od jej ogłoszenia.

Sejm powołał nowego Prezesa Urzędu Ochrony Danych Osobowych

W dniu 4 kwietnia 2019 roku Sejm powołał nowego Prezesa Urzędu Ochrony Danych Osobowych.

Dotychczasową Prezes, Edytę Bielak – Jomaę (wcześniej GIODO, od 25 maja 2018 r. PUODO), zastąpi Jan Nowak, który był jedynym kandydatem na to stanowisko. Wybrany przez Sejm przyszły Prezes to wieloletni pracownik instytucji związanych z ochroną danych osobowych w Polsce – od stycznia 2008 roku pełnił funkcję Dyrektora Biura Generalnego Inspektora Ochrony Danych Osobowych, następnie od 25 maja 2018 roku zajmował stanowisko Dyrektora Urzędu Ochrony Danych Osobowych.

Wybór kandydata musi zostać dodatkowo zatwierdzony przez Senat, co zgodnie z terminarzem powinno nastąpić na najbliższym posiedzeniu 11 lub 12 kwietnia. Kadencja obecnej Prezes UODO rozpoczęła się 22 kwietnia 2015 roku i kończy się w kwietniu 2019. Wtedy też na stanowisku zastąpi ją Jan Nowak.

RODO zaczyna zbierać swoje żniwo w Polsce

Po 10 miesiącach od wejścia w życie najsłynniejszego unijnego rozporządzenia 2018 roku, doczekaliśmy się pierwszej kary finansowej w Polsce. Tym samym, po informacjach między innymi z Francji oraz Portugalii, Polska dołączyła do grona państw, które podjęły najostrzejsze kroki w celu zapewnienia przestrzegania przepisów o ochronie danych osobowych.

Jak poinformowała Prezes Urzędu Ochrony Danych Osobowych, zdecydowała ona o nałożeniu relatywnie wysokiej kary w wysokości 943 tysięcy złotych. Zgodnie z informacjami Urzędu, kara została nałożona na spółkę, która w celach zarobkowych przetwarzała dane pochodzące z powszechnie dostępnych źródeł takich jak REGON oraz Centralna Ewidencja i Informacja o Działalności Gospodarczej, bez spełnienia obowiązku informacyjnego. Administrator twierdził, iż nie spełnił obowiązku ze względu na ogromne koszty przeprowadzenia takiej operacji (mowa o ok. 6 milionach osób). Jednak kroki, które Administrator danych podjął tj. wysłanie klauzuli informacyjnej do osób, których adres e-mail posiadał oraz umieszczenie jej na swojej stronie internetowej zostały uznane przez Prezes UODO za niewystarczające.

Jednocześnie podkreślone zostało, iż według UODO naruszenie miało charakter umyślny, a Administrator nie podjął kroków mających na celu usunięcie naruszeń co zdecydowało o nałożeniu na spółkę wysokiej kary finansowej.

Szyfrowanie danych

Mechanizm bezpieczeństwa w postaci szyfrowania danych został wprost wymieniony w art. 32 RODO jako przykład rozwiązania służącego ochronie danych osobowych przed ryzykiem naruszenia praw lub wolności osób fizycznych.

Ustawodawca nie przedstawił jednak bardziej szczegółowych wytycznych wskazujących w jakich sytuacjach oraz przy użyciu jakich metod zabezpieczenia te powinny być implementowane. Administratorowi danych nie pozostaje zatem nic innego, jak odwołać się do „najnowszego stanu wiedzy” w zakresie dostępnych rozwiązań oraz wyniku szacowania ryzyka w celu oceny adekwatności ich stosowania.

Przyjrzyjmy się zatem kilku najczęściej występującym sytuacjom:

Strona www wystawiona do sieci internet. W takim wypadku niewątpliwie należy zastosować ochronę danych w tzw. locie (data in transit), poprzez zastosowanie szyfrowanej transmisji https, wykorzystującej:
1. Protokół tls w wersji co najmniej 1.2.
2. Klucze publiczne wykorzystujące krzywe eliptyczne efemeryczne.
3. Szyfr RSA co najmniej AES128 z GCM.
4. Funkcję skrótu co najmniej SHA256.

Jeśli dostęp do bazy danych możliwy jest bezpośrednio z sieci internet to dane w spoczynku (data in rest) powinny zostać zaszyfrowane w bazie. Rodzaj zastosowanego szyfru zależy tutaj od ważności danych, tj. przykładowo dane zaszyfrowane w 2010 roku AES128 będą narażone na odszyfrowanie w 2030 roku.

Aplikacja działająca wewnątrz sieci lokalnej wykorzystująca bazę SQL. Ze względu na to to, że ryzyko włamania do bazy jest tutaj minimalne, szyfrowanie danych w samej bazie na ogół jest zbędne.
Poczta email. Powszechnie stosowane są dwa standardy bezpiecznej wymiany poczty email. Pierwszy oparty jest na mechanizmie certyfikatów x.509. Drugi wykorzystuje rozwiązanie PGP (Pretty Good Privacy) lub jego otwartą implementację GPG (GNU Privacy Guard). W obu przypadkach, aby wysłać bezpieczny email do odbiorcy, należy znać jego klucz publiczny, co czyni rozwiązanie mało elastycznym. Alternatywą może być wykorzystanie do ochrony zawartości poczty email za pomocą serwera, praw dostępu RMS (Rights Management System), którego zadaniem jest zarządzanie prawami dostępu do określonych dokumentów. Dzięki temu rozwiązaniu mamy możliwość nie tylko określania praw dostępu do poszczególnych dokumentów, ale również okresu ich ważności.
Urządzenia mobilne. Ze względu na wysokie ryzyko zgubienia lub kradzieży urządzeń, pamięć wewnętrzna powinna być szyfrowana za pomocą co najmniej AES128.

Strona trzecia

Zgodnie z art. 4 ust. 10 RODO: „strona trzecia” oznacza osobę fizyczną lub prawną, organ publiczny, jednostkę lub podmiot inny niż:

Osoba, której dane dotyczą.
Administrator.
Podmiot przetwarzający.
Osoby, które z upoważnienia administratora lub podmiotu przetwarzającego mogą przetwarzać dane osobowe.

Z powyższej definicji wynika, że strona trzecia nie jest: podmiotem danych, administratorem ani procesorem, nie jest też osobą, która mogłaby ich reprezentować czyli działać na podstawie upoważnienia do przetwarzania danych. Stroną trzecią nie jest osoba, której dane są przetwarzane, nie decyduje ona o celach i środkach przetwarzania, nie zleca przetwarzania zewnętrznym podmiotom, nie przetwarza danych na polecenie administratora, nie reprezentuje także żadnego z tych podmiotów.

Jednocześnie pojęcie strony trzeciej pojawia się w RODO w definicji „odbiorcy”, gdyż „Odbiorcą jest (…) podmiot, któremu ujawnia się dane osobowe, niezależnie od tego czy jest stroną trzecią”.

Kiedy strona trzecia zostanie w pewnym momencie włączona w proces przetwarzania danych i będzie decydować o celach i środkach przetwarzania, stanie się samodzielnym administratorem lub współadministratorem. Kiedy strona trzecia otrzyma dostęp do danych i będzie działać na zlecenie administratora, będzie w procesie przetwarzania danych pełnić rolę podmiotu przetwarzającego, czy też osoby upoważnionej do przetwarzania, w zależności od relacji jaka łączy ją ze zlecającym przetwarzanie.

Strona trzecia może także reprezentować osobę, której dane są przetwarzane w momencie kiedy są to informacje nie wchodzące w materialny zakres stosowania RODO, np. gdy dotyczą codziennych spraw życia codziennego.

Analizując dokładnie definicję strony trzeciej możemy dojść do wniosku, iż stroną trzecią wg RODO mogą być np. organy publiczne czy też służby mundurowe, które realizując swoje obowiązki, stosują zgodnie z art. 2 ust. 2 lit. d RODO inne przepisy niż RODO, choć mogą wykonywać czynności identyfikowane jako przetwarzanie danych osobowych.

Podsumowując, w procesie przetwarzania danych strona trzecia pojawia się w praktyce rzadko i niejednokrotnie przypisanie podmiotowi takiej roli na pierwszy rzut oka nie jest łatwe. W interpretacji definicji strony trzeciej pomocny okazuje się art. 2 RODO.

Sytuacja byłaby bardziej klarowna, gdyby w polskim tłumaczeniu RODO, użyto pojęcia „osoba trzecia”, które było już znane z dyrektywy 95/46/WE oraz występuje w kodeksie cywilnym.

Ochrona medycznych danych osobowych – wywołanie pacjenta

Omawiając temat danych osobowych w służbie zdrowia, należy zwrócić uwagę, że w motywach RODO dokładnie opisano, czym są dane osobowe dotyczące zdrowia.

Zgodnie z motywem 35 preambuły do danych osobowych dotyczących zdrowia należy zaliczyć wszystkie dane o stanie zdrowia osoby, której dane dotyczą, ujawniające informacje o przeszłym, obecnym lub przyszłym stanie fizycznego lub psychicznego zdrowia osoby, której dane dotyczą. Do danych takich należą:

Informacje o danej osobie fizycznej zbierane podczas jej rejestracji do usług opieki zdrowotnej lub podczas świadczenia jej usług opieki zdrowotnej, jak to określa dyrektywa Parlamentu Europejskiego i Rady 2011/24/UE (9); numer, symbol lub oznaczenie przypisane danej osobie fizycznej w celu jednoznacznego zidentyfikowania tej osoby fizycznej do celów zdrowotnych.
Informacje pochodzące z badań laboratoryjnych lub lekarskich części ciała lub płynów ustrojowych, w tym danych genetycznych i próbek biologicznych.
Wszelkie informacje, na przykład o chorobie, niepełnosprawności, ryzyku choroby, historii medycznej, leczeniu klinicznym lub stanie fizjologicznym lub biomedycznym osoby, której dane dotyczą, niezależnie od ich źródła, którym może być na przykład lekarz lub inny pracownik służby zdrowia, szpital, urządzenie medyczne lub badanie diagnostyczne in vitro.

Powołując się na „Przewodnik po RODO w służbie zdrowia” wydany przez Ministerstwo Cyfryzacji w nawiązaniu do motywu 35, należy rozważyć możliwe przykładowe metody wywołania pacjenta zgodne z RODO w pomiocie leczniczym, a mianowicie:

Wezwanie z wykorzystaniem numeru identyfikacyjnego, nadanego zgodnie z wskazaniami art. 36 ust. 5 ustawy o działalności leczniczej znaku/pseudonimu numerycznego. Wpisywanie tych numerów do dokumentacji medycznej następuję z jednoczesnym przekazaniem ich pacjentowi. Pacjent jest wzywany wówczas do gabinetu po tym unikalnym numerze.
Wezwanie po numerze nadanym podczas rejestracji. Takie rozwiązanie nie wymaga dużych kosztów finansowych, a jest związane z nadawaniem unikalnego numeru podczas rejestracji w sposób zapewniający przekazanie numeru lekarzowi w gabinecie oraz pacjentowi. (np. wpisany w dokumentację w systemie, dopięty do karty).
Wezwanie po godzinie wizyty, wizyty są umawiane na konkretną godzinę, w sposób uniemożliwiający pokrywanie się tych godzin.
Wezwanie po imieniu, gdy jest to wystarczające (np. w kolejce jest tylko jedna osoba o takim imieniu).
Rozwiązania mieszane:
1. Wezwanie z użyciem imienia i godziny wizyty np. Pan Marcin z godziny 12:15.
2. Wezwanie z dodaniem numeru gabinetu np. Pan Adam z godziny 12:00 proszony jest do gabinetu nr 5.
3. Wezwanie za pomocą elektronicznego systemu identyfikacji pacjentów (numerki wyświetlane nad gabinetami).
W przypadku gdy jest kilka kategorii pacjentów lub rodzajów poradni, możliwe jest przydzielanie numerków o różnych kolorach (np. czerwona jedynka).

Jeżeli jest to możliwe, w szczególności gdy osoba wykonująca zawód medyczny zna pacjenta, może zrezygnować z wskazanych wyżej sposobów wezwań.

Należy zaznaczyć, że niezależnie od powyższego, możliwe jest zastosowanie metody identyfikacji tożsamości z wykorzystaniem nazwiska bądź imienia i nazwiska oraz innych niezbędnych danych osobowych pacjenta w przypadku zaistnienia zagrożenia zdrowia bądź życia, a nie jest jednocześnie możliwe wykorzystanie wyżej wymienionych metod.

Formularz kontaktowy a RODO

W celu ułatwienia kontaktu z przedsiębiorcą, powszechnie stosowanym narzędziem udostępnianym użytkownikom stron internetowych jest formularz kontaktowy. Umożliwia on zadanie pytania niezależnie od pory dnia i nie wymaga od użytkownika opuszczania strony w celu wysłania maila za pośrednictwem własnego konta poczty elektronicznej.

Aby móc ustosunkować się do pytania przesłanego przez formularz kontaktowy, administrator serwisu musi uzyskać od użytkownika konkretne informacje umożliwiające mu kontakt zwrotny. W zależności od charakteru formularza, zakres danych, które trzeba w tym celu zamieścić, może ograniczać się do adresu e-mail bądź zawierać szereg dodatkowych informacji. W większości przypadków administrator serwisu stanie się więc administratorem danych osobowych, co wiąże się z koniecznością spełnienia wymagań określonych przepisami RODO.

O czym trzeba pamiętać przed umieszczeniem formularza

Przy konstruowaniu formularza kontaktowego zgodnego z RODO, administrator powinien wyznaczyć cele w jakich będzie przetwarzał dane użytkowników. Zazwyczaj jest nim udzielenie odpowiedzi na zadane pytanie, lecz czasem dane z formularzy wykorzystywane są w celach marketingowych lub dla usprawnienia wykonania umowy pomiędzy użytkownikiem i administratorem serwisu.

Po wyznaczeniu celu, konieczne jest wdrożenie środków zapewniających realizację podstawowych zasad przetwarzania danych. Szczególną wagę należy przywiązać do realizacji zasad minimalizacji i celowości, a więc należy zadbać aby nie wymagać od użytkownika serwisu danych, które nie będą konieczne do osiągnięcia celu przetwarzania wskazanego przez administratora. Często więc wystarczające jest, aby użytkownik wpisał do formularza adres poczty internetowej lub numer telefonu, choć w niektórych przypadkach niezbędne mogą okazać się inne informacje jak np. numer umowy, do której odwołuje się użytkownik, numer klienta, imię i nazwisko.

Kolejną kwestią, o której należy pamiętać w przypadku umieszczenia na stronie formularza kontaktowego, jest konieczność spełnienia obowiązku informacyjnego względem użytkowników. Można w tym celu zamieścić klauzulę informacyjną pod formularzem, bądź odwołać się do polityki prywatności. Przepisy nie wskazują dokładnie w jakiej formie należy spełnić wspomniany obowiązek, ważne jest, aby informacja przekazywana była w chwili zbierania danych i spełniała wymogi przejrzystości tj. by była zwięzła, łatwo dostępna i zrozumiała. Szczegółowy zakres informacji, których należy udzielić zamieszczony został w art. 13 RODO.

Zgoda na przetwarzanie danych

Podstawą przetwarzania danych w ramach formularza kontaktowego nie zawsze będzie zgoda osoby, której dane dotyczą. Administrator danych w zależności od celu w jakim prowadzi komunikację za pomocą formularza, sam musi zdecydować na jakiej podstawie będzie przetwarzał dane osobowe. Dla przykładu, jeżeli formularz prowadzony jest w celu obsługi kontrahentów umowy, właściwą przesłanką może być „niezbędność do wykonania umowy” (art. 6 ust. 1 lit. b RODO) z kolei, gdy jego główną funkcją jest zbieranie opinii użytkowników dotyczących korzystania z serwisu podstawą może być uzasadniony interes administratora (art. 6 ust. 1 lit. f RODO).

W przypadku gdy administrator serwisu zdecyduje się na przetwarzanie danych osobowych za pomocą zgody, należy pamiętać że powinna ona być dobrowolna, konkretna, świadoma i jednoznaczna. Oznacza to, że aby była ona ważna wymagane jest:

– aktywne działanie użytkownika serwisu przy jej wyrażeniu,

– aby nie była wymuszona i została wyrażona w konkretnym celu,

– udzielenie podmiotowi danych wyczerpujących informacji dotyczących przetwarzania.

Rozwiązaniem pozwalającym na uzyskanie zgody jest zastosowanie w formularzu pól wyboru (tzw. checkbox), które użytkownik strony musi zaznaczyć aby przesłać informację przez formularz kontaktowy. W przypadku zastosowania takiego elementu należy jednak pamiętać, aby pole wyboru nie było domyślnie zaznaczone, co podważałoby wyraźność zgody.

Outsourcing IOD – sprawdź naszą usługę

120 000 funtów kary za zgubionego pendrive’a

Brytyjski organ nadzoru nad przestrzeganiem przepisów o ochronie danych osobowych (Information Commissioner’s Office) nałożył na lotnisko Heathrow w Londynie karę w związku z wyciekiem danych osobowych.

Zdarzenie, które było przedmiotem postępowania miało miejsce w październiku 2017 roku, a więc pod rządami poprzednich przepisów. Data jego wystąpienia jest na tyle istotna, iż w brytyjskich mediach można spotkać się ze sformułowaniem, że port lotniczy „uciekł” przed wysokimi karami RODO. Na tle obecnie grożących kar administracyjnych (nawet 20 mln euro) 120 tysięcy funtów można faktycznie odbierać jako niski koszt (maksymalnie w ówczesnym stanie prawnym administratorom danych groziła kara w wysokości 500 tysięcy funtów).

Incydent polegał na zgubieniu przez pracownika lotniska pendrive’a, na którym znajdowało się 2,5 gigabajtów poufnych informacji. Osoba, która znalazła urządzenie, przejrzała jego zawartość przy użyciu komputera dostępnego w publicznej bibliotece, a następnie przekazała ją do lokalnej gazety, która po skopiowaniu danych, przekazała pendrive z powrotem lotnisku.

Dysk zawierał ponad 1000 plików i nie był w żaden sposób zabezpieczony (brak hasła, brak szyfrowania).

O ile liczba plików zawierających dane osobowe była stosunkowo niewielka, to jednak ich „ciężar gatunkowy” był dosyć duży – jeden z nich zawierał np. wideo szkoleniowe, które ujawniało dane dziesięciu osób, w tym nazwiska, daty urodzenia, numery paszportów, a także inne informacje na temat blisko 50 członków personelu ochrony lotniska.

Brytyjski organ nadzorczy w toku dochodzenia stwierdził również, że tylko 2% z 6500 pracowników zatrudnionych przez lotnisko Heathrow zostało przeszkolony w zakresie ochrony danych. Ponadto, powszechne korzystanie z przenośnych nośników było sprzeczne z wewnętrzną polityką portu lotniczego, a środki zapobiegające pobieraniu danych osobowych na nieautoryzowane lub nieszyfrowane nośniki były nieefektywne.

Poza danymi osobowymi pendrive zawierał również inne poufne informacje, w tym m.in.:

Informacje o dokładnej trasie, którą Elżbieta II przemieszcza się podczas korzystania z lotniska oraz środki bezpieczeństwa stosowane w celu jej ochrony;
Harmonogram patroli ochraniających teren lotniska przed zamachowcami-samobójcami i atakami terrorystycznymi;
Mapy wskazujące rozmieszczenie kamer CCTV oraz sieć tuneli i szybów ewakuacyjnych połączonych z Heathrow Express;
Drogi i zabezpieczenia dla ministrów i zagranicznych dygnitarzy;
Szczegóły systemu radarowego ultradźwięków stosowanego do skanowania dróg startowych i ogrodzenia lotniska.

Źródła:

https://securityboulevard.com/2018/10/heathrow-airport-escapes-hefty-gdpr-fine-gets-only-120000-under-1998-dpa-for-2017-privacy-breach-incident/

https://www.telegraph.co.uk/technology/2018/10/08/heathrow-airport-fined-120000-serious-data-breach/

Potrzebujesz oferty na wdrożenie RODO?

Potrzebujesz usługi Outsourcingu IOD?

Potrzebujesz oferty na audyt RODO?