Incydent MyDr - dlaczego administrator danych nie może zasłonić się procesorem?

W ostatnich dniach doszło do poważnego incydentu cyberbezpieczeństwa dotyczącego systemów firmy MyDr, dostawcy rozwiązań wykorzystywanych przez placówki medyczne do prowadzenia elektronicznej dokumentacji medycznej.

Skala zdarzenia jest szczególnie poważna. Według informacji przekazanych 12 sierpnia przez wicepremiera i ministra cyfryzacji Krzysztofa Gawkowskiego wykradziona baza miała obejmować około 19 mln rekordów i ponad 2 TB danych. System MyDr wykorzystywało około 12 tys. placówek medycznych.

Wcześniejsze informacje wskazywały, że osoby podające się za sprawców twierdziły, iż uzyskały dostęp do systemów MyDr poprzez wykorzystanie podatności w obsłudze certyfikatów, a następnie uzyskały dostęp do kodu źródłowego i danych. Informacje te są obecnie przedmiotem weryfikacji przez odpowiednie służby.

Nie jest jeszcze możliwe przesądzenie o pełnym zakresie danych, które zostały skopiowane lub mogły zostać udostępnione osobom nieuprawnionym. Jednocześnie charakter systemu powoduje, że potencjalnie mogły znajdować się w nim również dane dotyczące zdrowia, a więc dane szczególnie chronione na gruncie RODO. To nie jest jednak wyłącznie problem dostawcy systemu. To także problem każdego administratora danych, który korzystał z usług MyDr.

MyDr był procesorem. Kto więc odpowiada za dane?

W typowym modelu współpracy placówki medycznej z dostawcą systemu informatycznego placówka pozostaje administratorem danych osobowych (ADO), natomiast dostawca systemu, który przetwarza dane w imieniu placówki, jest podmiotem przetwarzającym, czyli procesorem. Taką rolę pełnił MyDr w odniesieniu do danych przetwarzanych w systemie na rzecz korzystających z niego administratorów.

I tutaj pojawia się bardzo ważna zasada RODO: Administrator nie może przenieść na procesora swojej odpowiedzialności za zgodność przetwarzania danych z RODO.

Oczywiście procesor również ma określone obowiązki wynikające z RODO - w szczególności dotyczące bezpieczeństwa przetwarzania oraz zgłaszania administratorowi stwierdzonych naruszeń. Jednak to administrator pozostaje podmiotem odpowiedzialnym za podejmowanie decyzji dotyczących przetwarzania danych i realizację obowiązków wobec Prezesa UODO oraz osób, których dane dotyczą.

UODO wprost wskazał w związku z incydentem MyDr, że obowiązek powiadomienia osób dotkniętych wyciekiem spoczywa na administratorach, którzy korzystali z usług MyDr.

„Mamy umowę powierzenia” - to za mało

Jednym z najczęstszych błędów w podejściu do współpracy z dostawcami IT jest traktowanie umowy powierzenia jako dokumentu, który automatycznie „załatwia” kwestie bezpieczeństwa danych. Tak nie jest.

Podpisanie umowy powierzenia jest oczywiście konieczne, jeżeli spełnione są przesłanki powierzenia danych. Umowa powinna określać m.in. przedmiot i czas trwania przetwarzania, charakter i cel przetwarzania, rodzaj danych oraz obowiązki i prawa administratora. Ale sama umowa nie zwalnia administratora z obowiązku weryfikowania procesora. Administrator powinien m.in.:

• odpowiednio dobierać procesorów, uwzględniając ich zdolność do zapewnienia odpowiednich środków technicznych i organizacyjnych;
• weryfikować, czy procesor zapewnia odpowiedni poziom bezpieczeństwa;
• monitorować sposób wykonywania przez procesora obowiązków;
• reagować na informacje o incydentach i innych nieprawidłowościach;
• w razie potrzeby przeprowadzać audyty lub korzystać z innych mechanizmów weryfikacji;
• odpowiednio zarządzać ryzykiem związanym z dostawcami IT i innymi podmiotami, którym powierzane są dane.

Innymi słowy, administrator powinien nie tylko podpisać umowę z procesorem, ale również wiedzieć, czy procesor rzeczywiście zapewnia bezpieczeństwo powierzonych mu danych.

Co powinien zrobić administrator po incydencie MyDr?

Pierwszym krokiem jest ustalenie, czy dane administratora mogły zostać objęte incydentem oraz jakie kategorie danych i osób mogły być nim dotknięte. Następnie administrator powinien przeprowadzić ocenę naruszenia pod kątem ryzyka dla praw i wolności osób fizycznych.

Jeżeli naruszenie może powodować ryzyko naruszenia praw lub wolności osób fizycznych, administrator powinien zgłosić je Prezesowi UODO bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin od stwierdzenia naruszenia. Jeżeli naruszenie może powodować wysokie ryzyko dla osób, może być również konieczne zawiadomienie osób, których dane dotyczą.

Ważne jest przy tym, że administrator nie musi czekać, aż procesor zakończy całe postępowanie wyjaśniające. Jeżeli w ciągu 72 godzin nie są znane wszystkie informacje, RODO pozwala na przekazywanie informacji sukcesywnie - brakujące informacje należy uzupełnić bez zbędnej zwłoki.

Czy każdy administrator korzystający z MyDr musi zgłosić naruszenie?

Nie można automatycznie powiedzieć, że każde zdarzenie dotyczące MyDr oznacza obowiązek zgłoszenia przez każdego administratora. Administrator musi samodzielnie ocenić, czy doszło do naruszenia ochrony danych osobowych oraz czy naruszenie powoduje ryzyko dla praw i wolności osób fizycznych.

W przypadku incydentu o takiej skali trudno jednak traktować sprawę jako czysto techniczny problem dostawcy systemu. Administratorzy powinni niezwłocznie ustalić, czy ich dane były przetwarzane w zaatakowanych systemach i czy mogły zostać objęte incydentem, a następnie przeprowadzić i udokumentować ocenę ryzyka.

Administrator powinien monitorować procesora także przed incydentem

Incydent MyDr jest ważnym sygnałem dla wszystkich organizacji korzystających z zewnętrznych systemów IT. Współpraca z dostawcą systemu, chmurą, zewnętrznym centrum medycznym, firmą hostingową, dostawcą oprogramowania czy innym procesorem oznacza, że administrator przekazuje część operacji związanych z przetwarzaniem danych na zewnątrz. Nie oznacza to jednak przekazania odpowiedzialności za dane.

Administrator powinien więc mieć wdrożony proces zarządzania procesorami obejmujący nie tylko podpisanie umowy powierzenia, ale również ich ocenę i okresową weryfikację.

W praktyce warto odpowiedzieć sobie na pytania:

1. Czy wiemy, gdzie faktycznie są przechowywane dane?
2. Czy wiemy, jakie dane przekazujemy procesorowi?
3. Czy procesor korzysta z dalszych podmiotów przetwarzających?
4. Czy mamy prawo do audytu?
5. Czy procesor ma obowiązek niezwłocznego informowania nas o incydentach?
6. Czy wiemy, w jakim czasie musimy otrzymać informację o incydencie, aby realnie zrealizować własny obowiązek 72-godzinny?
7. Czy otrzymujemy informacje o wynikach audytów, testów bezpieczeństwa lub certyfikatach?
8. Czy procesor posiada odpowiednie procedury reagowania na incydenty?
9. Czy po zakończeniu współpracy dane są rzeczywiście usuwane lub zwracane?
10. Czy nasza dokumentacja RODO odzwierciedla rzeczywisty sposób korzystania z usług procesora?

Umowa powierzenia jest punktem wyjścia, a nie końcem procesu nadzoru nad procesorem.

Co grozi administratorowi?

Odpowiedzialność administratora nie znika tylko dlatego, że incydent powstał w systemach zewnętrznego dostawcy.

Prezes UODO, oceniając naruszenie, bierze pod uwagę m.in. charakter, wagę i czas trwania naruszenia, liczbę osób, których dane dotyczą, kategorie danych, rozmiar szkody, a także zachowanie administratora po wystąpieniu incydentu - w tym to, czy administrator sam zgłosił naruszenie i, jeżeli było to wymagane, poinformował osoby, których dane dotyczą. Dlatego znaczenie może mieć nie tylko sam fakt wystąpienia cyberataku, ale również to, jak administrator zarządzał ryzykiem przed incydentem i jak zareagował po jego wystąpieniu.

Za naruszenie art. 33 i 34 RODO (obowiązek zgłoszenia i zawiadomienia) Prezes UODO może nałożyć karę do 10 mln euro lub 2% rocznego światowego obrotu - zastosowanie ma kwota wyższa. Za naruszenie podstawowych zasad przetwarzania danych sankcje są jeszcze wyższe - do 20 mln euro lub 4% obrotu. Do tego dochodzą roszczenia cywilne osób, których dane dotyczą - art. 82 ust. 1 RODO.

Jak możemy pomóc?

Incydent MyDr pokazuje, że zarządzanie ochroną danych osobowych musi obejmować również bezpieczeństwo dostawców i procesorów.

Oferujemy wsparcie dla administratorów zarówno w reakcji na obecny incydent, jak i w przygotowaniu organizacji na podobne zdarzenia w przyszłości.

Możemy pomóc m.in. w:

• opracowaniu procedury zgłaszania i obsługi naruszeń ochrony danych osobowych;
• analizie, czy doszło do naruszenia ochrony danych osobowych;
• przeprowadzeniu i udokumentowaniu oceny ryzyka dla praw i wolności osób, których dane dotyczą;
• przygotowaniu zgłoszenia naruszenia do Prezesa UODO;
• przygotowaniu zawiadomień dla osób, których dane dotyczą, jeżeli będzie ono wymagane;
• analizie możliwości dochodzenia roszczeń wobec procesora, w tym odpowiedzialności kontraktowej i postanowień dotyczących kar umownych lub odszkodowania;
• przeglądzie wszystkich umów powierzenia z dostawcami IT;
• audytowaniu procesu wyboru i monitorowania procesorów;
• przygotowaniu procedury zarządzania procesorami i podprocesorami;
• wsparciu w kontakcie z Prezesem UODO oraz przygotowaniu odpowiedzi na pytania organu;
• przygotowaniu organizacji do kontroli lub postępowania prowadzonego przez UODO.

Incydent MyDr jest dobrym momentem, aby zadać sobie pytanie: Czy gdyby jutro doszło do cyberataku na naszego procesora, bylibyśmy w stanie w ciągu 72 godzin prawidłowo ocenić sytuację, zgłosić naruszenie i odpowiednio poinformować osoby, których dane dotyczą? Jeżeli odpowiedź brzmi „nie” albo „nie wiemy” - warto zająć się tym zanim wydarzy się incydent.