Cyberatak nastąpił u dostawcy oprogramowania. System nie należał do lekarza. Zabezpieczenia serwerów również nie były w jego rękach. Można byłoby więc pomyśleć: skoro nie ja dopuściłem do wycieku, to nie mój problem. W ochronie danych osobowych ta logika niestety nie działa. Incydent dotyczący systemów MyDr pokazał, że cyberatak na zewnętrznego dostawcę może w jednej chwili stać się problemem tysięcy lekarzy i placówek medycznych. I to problemem nie tylko technicznym, ale przede wszystkim prawnym.

Skala zdarzenia robi wrażenie. Według informacji przekazanych po ujawnieniu incydentu nieuprawniony dostęp mógł dotyczyć historycznych danych nawet 18,8 mln osób oraz ponad 12 tys. placówek medycznych korzystających z oprogramowania MyDr do prowadzenia elektronicznej dokumentacji medycznej. Sprawa szybko przestała więc być wyłącznie pytaniem o to, co wydarzyło się w MyDr. Pojawiło się inne: co teraz ma zrobić placówka albo lekarz korzystający z tego systemu? I tutaj zaczęło się robić naprawdę interesująco.

Kto właściwie odpowiada?

Pierwsza reakcja wydaje się naturalna: skoro do cyberataku doszło u dostawcy oprogramowania, to właśnie dostawca powinien ponosić odpowiedzialność za jego skutki. Tyle że RODO patrzy na tę sytuację inaczej.

W typowym modelu placówka medyczna albo lekarz prowadzący własną praktykę jest administratorem danych pacjentów.

To on decyduje, w jakim celu i w jaki sposób dane są przetwarzane.

Dostawca systemu informatycznego, któremu dane powierzono, jest natomiast podmiotem przetwarzającym, czyli procesorem.

Powierzenie danych zewnętrznej firmie nie oznacza jednak powierzenia jej całej odpowiedzialności. I właśnie to jest jedna z najważniejszych lekcji płynących z incydentu MyDr. Administrator nie może powiedzieć: „dane były na cudzym serwerze, więc mnie to nie dotyczy”. Nadal ma własne obowiązki wynikające z RODO.

Musi ocenić zdarzenie, ustalić jego zakres, przeanalizować ryzyko dla osób, których dane dotyczą, a następnie zdecydować, czy zachodzą przesłanki do zgłoszenia naruszenia Prezesowi UODO oraz zawiadomienia pacjentów. Procesor ma natomiast obowiązek dostarczyć administratorowi informacji potrzebnych do wykonania tych obowiązków. Powinien więc przekazać między innymi informacje dotyczące charakteru zdarzenia, kategorii danych, liczby osób objętych incydentem oraz podjętych środków zaradczych.

W skrócie – dostawca powinien dostarczyć informacji, ale decyzji za administratora nie podejmie.

„Nie trzeba nic robić”. Czy na pewno?

W przypadku MyDr sytuację dodatkowo skomplikowały komunikaty kierowane do placówek. Z jednej strony UODO przypomniał administratorom korzystającym z usług MyDr o konieczności dokonania analizy ryzyka oraz – jeżeli wystąpią odpowiednie przesłanki – zgłoszenia naruszenia i zawiadomienia osób, których ono dotyczy. Z drugiej strony sam dostawca informował klientów, że na tym etapie nie muszą podejmować działań, a zgłoszenia ze strony placówek nie są wymagane. Zapowiadał jednocześnie indywidualny kontakt z klientami objętymi incydentem. Trudno się dziwić, że lekarze zaczęli zadawać pytania. Jeżeli firma, której powierzono dane i która zna własny system informatyczny, mówi: „na razie nie zgłaszajcie”, to czy lekarz rzeczywiście ma prowadzić własne postępowanie wyjaśniające? Odpowiedź UODO jest istotna nie tylko w sprawie MyDr, ale również na przyszłość. Informacja procesora, że zgłoszenie nie jest potrzebne, nie zwalnia administratora z dokonania własnej analizy zdarzenia. I tutaj pojawia się pewien paradoks. Lekarz ma zajmować się diagnozowaniem i leczeniem pacjentów. Korzysta więc z profesjonalnego systemu właśnie po to, aby nie budować we własnym gabinecie infrastruktury informatycznej i zespołu cyberbezpieczeństwa. Kiedy jednak dochodzi do incydentu, prawo mówi: dostawca dostawcą, ale jako administrator musisz samodzielnie ocenić sytuację. Oczywiście „samodzielnie” nie oznacza „bez informacji od procesora” – bez nich rzetelna analiza może być niemożliwa. Nie oznacza jednak również prawa do biernego oczekiwania.

A zegar tyka. Tylko od kiedy?

W tym miejscu dochodzimy do słynnych 72 godzin. Zgodnie z art. 33 RODO administrator w przypadku naruszenia ochrony danych osobowych powinien bez zbędnej zwłoki – w miarę możliwości nie później niż w terminie 72 godzin po stwierdzeniu naruszenia – zgłosić je organowi nadzorczemu, chyba że jest mało prawdopodobne, aby naruszenie skutkowało ryzykiem naruszenia praw lub wolności osób fizycznych. Brzmi jasno, dopóki nie spróbujemy zastosować tego przepisu do sytuacji podobnej do MyDr. Od którego momentu liczyć 72 godziny? Od informacji w mediach? Od komunikatu dostawcy, że doszło do cyberataku? Od chwili, kiedy lekarz dowiedział się, że atak mógł dotyczyć systemu, z którego korzysta? A może dopiero od potwierdzenia, że wyciek rzeczywiście objął dane jego pacjentów? Wyjaśnienie UODO ma tutaj ogromne znaczenie praktyczne. Jeżeli administrator wie jedynie, że u procesora doszło do incydentu, ale nie posiada jeszcze informacji pozwalających stwierdzić, że naruszenie dotyczyło powierzonych przez niego danych, nie oznacza to automatycznie rozpoczęcia biegu 72-godzinnego terminu. Nie daje mu to jednak prawa do siedzenia z założonymi rękami. Administrator powinien skontaktować się z procesorem i ustalić, czy zdarzenie objęło jego dane. Innymi słowy: brak wiedzy może powodować, że termin jeszcze nie biegnie, ale nie usprawiedliwia braku działania zmierzającego do zdobycia tej wiedzy. Jeżeli natomiast administrator ma już wystarczające informacje, aby stwierdzić naruszenie, zegar zaczyna tykać. I nie zatrzymuje się tylko dlatego, że nadal czekamy na dodatkowe szczegóły od dostawcy. Co więcej, RODO przewiduje możliwość przekazywania informacji organowi nadzorczemu sukcesywnie, bez zbędnej zwłoki. Nie zawsze trzeba więc czekać, aż wszystkie elementy układanki znajdą się na stole.

Warto podkreślić jeszcze jedną rzecz, bo w praktyce bywa źródłem nieporozumień. Nie każde naruszenie ochrony danych osobowych automatycznie prowadzi do obowiązku zgłoszenia go Prezesowi UODO. RODO wymaga oceny ryzyka naruszenia praw lub wolności osób fizycznych. Ale żeby dojść do wniosku, że zgłoszenie nie jest wymagane, trzeba najpierw tę ocenę rzeczywiście przeprowadzić. W przypadku danych medycznych poprzeczka jest ustawiona szczególnie wysoko. Informacja o stanie zdrowia należy do szczególnych kategorii danych. Jeżeli do tego dochodzą dane identyfikacyjne, w tym numer PESEL, potencjalne konsekwencje naruszenia mogą być bardzo poważne: od prób kradzieży tożsamości i oszustw, przez phishing, po ujawnienie informacji o zdrowiu, które może prowadzić do naruszenia prywatności, dóbr osobistych, dyskryminacji czy stygmatyzacji. Dlatego administrator powinien odpowiedzieć sobie nie tylko na pytanie, czy dane wyciekły, ale również: jakie dane, ilu osób, komu mogły zostać ujawnione, jakie mogą być konsekwencje i jakie środki możemy zastosować, aby je ograniczyć? To właśnie jest analiza ryzyka. Warto przy tym pamiętać, że odpowiedzialność administratora nie zaczyna się dopiero w chwili wycieku. RODO wymaga, aby powierzając dane, korzystał on z usług podmiotów zapewniających wystarczające gwarancje odpowiednich zabezpieczeń. Znaczenie może mieć więc nie tylko sama umowa powierzenia, ale również to, w jaki sposób administrator zweryfikował dostawcę i sprawował nad nim nadzór.

Kiedy trzeba powiedzieć pacjentowi?

Zgłoszenie naruszenia Prezesowi UODO to jeden obowiązek, a zawiadomienie osoby, której dane dotyczą – drugi. Jeżeli naruszenie może powodować wysokie ryzyko naruszenia praw lub wolności osoby fizycznej, administrator powinien bez zbędnej zwłoki zawiadomić o nim pacjenta. I nie chodzi o lakoniczne: „uprzejmie informujemy, że wystąpił incydent”. Pacjent powinien otrzymać informację napisaną jasnym i prostym językiem, z której dowie się, jaki był charakter naruszenia, jakie mogą być jego konsekwencje, gdzie może uzyskać dodatkowe informacje oraz co administrator zrobił albo zamierza zrobić, aby ograniczyć negatywne skutki.

Jeżeli ujawnione zostały na przykład imię, nazwisko i numer PESEL, jednym z zaleceń może być zastrzeżenie numeru PESEL.

Jeżeli incydent dotyczył danych zdrowotnych, trzeba uwzględnić również zupełnie inny rodzaj ryzyka – naruszenie prywatności, dóbr osobistych, dyskryminację czy stres związany z ujawnieniem informacji, które z natury rzeczy należą do najbardziej intymnej sfery życia człowieka. Zawiadomienie nie powinno więc służyć przede wszystkim zabezpieczeniu administratora. Ma pozwolić pacjentowi zabezpieczyć siebie.

UODO przyjrzy się ochronie zdrowia dokładniej

Incydent MyDr ma jeszcze jeden skutek, który może dotyczyć także placówek niemających bezpośredniego związku z tym systemem. Prezes UODO zdecydował o rozszerzeniu kontroli w sektorze ochrony zdrowia. Do końca 2026 r. dodatkowe, zintensyfikowane kontrole mają objąć kolejne podmioty, a jednym z najważniejszych obszarów będzie sposób zabezpieczenia danych pacjentów. To dobry moment, aby nie czekać na pismo z Urzędu.

Warto sprawdzić, jakie systemy wykorzystujemy, komu powierzamy dane, czy posiadamy aktualne umowy powierzenia, jakie mamy dowody weryfikacji dostawców, kto ma dostęp do dokumentacji, jak zarządzamy uprawnieniami, jak reagujemy na incydenty, czy personel wie, komu i w jakim czasie powinien je zgłosić oraz czy procedura istniejąca w dokumentacji rzeczywiście działa w praktyce. Bo procedura bezpieczeństwa, której nikt nigdy nie przeczytał, zapewnia mniej więcej tyle bezpieczeństwa, ile gaśnica zamknięta w szafie, do której w czasie pożaru nikt nie może znaleźć klucza.

Czy każdy lekarz jest administratorem?

Na szczęście – nie. I to rozróżnienie jest niezwykle ważne, bo po informacji o incydencie wielu lekarzy mogło odnieść wrażenie, że każdy, kto kiedykolwiek wprowadzał dane pacjentów do systemu, powinien teraz analizować, zgłaszać i zawiadamiać. Tak nie jest. Lekarz zatrudniony w szpitalu czy przychodni zasadniczo nie staje się przez sam fakt wykonywania zawodu administratorem danych znajdujących się w systemie placówki. Dotyczy to również lekarzy współpracujących na podstawie umów cywilnoprawnych, jeżeli przetwarzają dane w ramach organizacji administratora, na jego polecenie i z jego upoważnienia. Wówczas obowiązki administratora spoczywają na placówce. Inaczej może wyglądać sytuacja lekarza prowadzącego indywidualną praktykę lekarską, który sam decyduje o celach i sposobach przetwarzania danych swoich pacjentów. W zależności od konkretnego modelu współpracy z inną placówką może on występować jako samodzielny administrator albo – w określonych sytuacjach – współadministrator. Dlatego samo stwierdzenie „jestem na kontrakcie” nie rozstrzyga jeszcze sprawy. Trzeba odpowiedzieć na pytanie: czyje cele przetwarzania są realizowane, kto decyduje o zasadach prowadzenia dokumentacji, w czyim imieniu lekarz działa i czy dane przetwarza wyłącznie w ramach udzielonego mu upoważnienia, czy także we własnym celu związanym z prowadzoną działalnością leczniczą? Dopiero odpowiedź na te pytania pozwala ustalić zakres odpowiedzialności.

A jeśli pacjent zażąda odszkodowania?

Kary administracyjne to niejedyny finansowy skutek naruszenia. Art. 82 RODO przewiduje prawo do odszkodowania za szkodę majątkową lub niemajątkową poniesioną wskutek naruszenia przepisów rozporządzenia. Nie oznacza to, że każdy wyciek danych automatycznie daje każdemu pacjentowi prawo do określonej kwoty. Samo naruszenie RODO nie wystarcza. Muszą wystąpić szkoda oraz związek przyczynowy między naruszeniem a tą szkodą. Jednocześnie prawo unijne nie ustanawia minimalnego progu powagi szkody niemajątkowej. W określonych okolicznościach znaczenie może mieć także realna obawa przed potencjalnym wykorzystaniem danych. W przypadku danych medycznych nie jest to problem abstrakcyjny. Informacja o diagnozie, leczeniu, przyjmowanych lekach czy wystawionych receptach ma zupełnie inny ciężar niż ujawnienie samego adresu e-mail. Połączenie informacji zdrowotnych z danymi pozwalającymi jednoznacznie zidentyfikować człowieka zwiększa potencjalne konsekwencje incydentu. Dla pojedynczego gabinetu nawet kilka roszczeń może być problemem. Jeżeli natomiast naruszenie dotyczy dużej liczby pacjentów, suma potencjalnych roszczeń może stać się istotnym ryzykiem finansowym. Cyberatak może więc skończyć się nie tylko zmianą haseł i korespondencją z UODO.

Lekarz ma leczyć. I jeszcze skontrolować cyberbezpieczeństwo?

W całej tej historii trudno nie dostrzec pewnej systemowej sprzeczności. Od lekarza oczekujemy, że będzie lekarzem. Ma diagnozować, leczyć, prowadzić dokumentację, wystawiać recepty, realizować obowiązki wobec NFZ, znać kolejne zmieniające się regulacje, przestrzegać praw pacjenta, zasad wykonywania zawodu, przepisów podatkowych, pracowniczych i oczywiście RODO.

A teraz powinien jeszcze wiedzieć, czy jego dostawca oprogramowania właściwie zabezpiecza serwery, jak wygląda hosting, jakie są procedury reagowania na incydenty i czy gwarancje procesora są rzeczywiście „wystarczające” w rozumieniu art. 28 RODO. W dużej placówce zajmują się tym inspektor ochrony danych, informatyk, dział bezpieczeństwa i prawnik. W indywidualnej praktyce bardzo często wszystkie te osoby mają jedno nazwisko – nazwisko lekarza. Nie zmienia to obowiązującego prawa. Powinno jednak skłaniać do refleksji nad tym, czy wraz z nakładaniem kolejnych obowiązków na najmniejsze podmioty zapewniamy im realne narzędzia pozwalające te obowiązki wykonywać. Bo wymaganie od lekarza, aby samodzielnie przeprowadził profesjonalny audyt cyberbezpieczeństwa dużej firmy technologicznej, byłoby fikcją.

Co więc zrobić po takim komunikacie? Przede wszystkim nie panikować. Ale też nie odkładać wiadomości do folderu „później”.

Trzeba ustalić, czy incydent rzeczywiście objął dane naszych pacjentów i jaki był jego zakres. Wystąpić do procesora o potrzebne informacje. Udokumentować podjęte działania. Przeprowadzić analizę ryzyka. Ocenić obowiązek zgłoszenia naruszenia Prezesowi UODO i – odrębnie – obowiązek zawiadomienia pacjentów. Jeżeli stwierdziliśmy naruszenie, pamiętać o terminie 72 godzin. Warto także wrócić do umowy z dostawcą, dokumentacji dotyczącej jego wyboru i zasad nadzoru nad procesorem. A przyszłość, jak pokazała zapowiedź zintensyfikowanych kontroli UODO w sektorze medycznym, może nadejść szybciej, niż się spodziewamy.

Cudzy atak, własna odpowiedzialność

Najważniejszy wniosek z historii MyDr jest mało komfortowy, ale prosty: w ochronie danych nie wystarczy ustalić, kto został zaatakowany. Trzeba jeszcze ustalić, kto był administratorem danych.

Cyberprzestępca może zaatakować serwer dostawcy, ale skutki prawne tego ataku nie zatrzymują się na drzwiach jego firmy. Nie oznacza to oczywiście, że każda placówka korzystająca z zewnętrznego systemu automatycznie ponosi odpowiedzialność za cudze błędy. Oznacza natomiast, że administrator ma własne obowiązki, których nie może przenieść na procesora jednym podpisem pod umową powierzenia. I być może właśnie to jest najważniejsza lekcja tego incydentu. W medycynie od dawna wiadomo, że profilaktyka jest łatwiejsza i tańsza niż leczenie skutków choroby. W ochronie danych zasada okazuje się zaskakująco podobna. Dopóki wszystko działa, umowa z dostawcą, analiza ryzyka, procedura naruszeń i dokumentacja nadzoru nad procesorem mogą wyglądać jak kolejna porcja „administracyjnej papierologii”. Dopiero kiedy dane prawie 19 milionów osób mogą znaleźć się poza kontrolą, okazuje się, że RODO – podobnie jak gaśnica – najbardziej potrzebne jest właśnie wtedy, kiedy wolelibyśmy z niego nie korzystać.

Ewa Urbanowicz

redaktor naczelny
radca prawny