Incydent MyDR
Wyciek danych MyDR — co się wydarzyło?
Najważniejsze informacje dotyczące incydentu, możliwego zakresu naruszenia oraz znaczenia sprawy dla placówek medycznych.
Obsługa IT dla firm • Bydgoszcz i okolice
Stała opieka informatyczna
Jeden kontakt do wszystkich spraw IT, zakres dobrany do liczby stanowisk.
Konfiguracja pod zadanie
Doradzamy podzespoły, składamy, testujemy pod obciążeniem i dajemy gwarancję na całość.
Strony, które pozyskują klientów
Projekt, wdrożenie i optymalizacja pod Google. Wycena po krótkiej rozmowie.
Znamy Wasze programy
Systemy księgowe, medyczne i CAD — wiemy, co nie może przestać działać.
Zgodność bez paniki
Dokumentacja, audyt i funkcja IOD prowadzone razem z obsługą IT — jeden wykonawca, spójne procedury.
Poradniki dla firm
Praktyczne teksty o opiece IT, bezpieczeństwie danych i widoczności w Google.
RODO
Naruszenie wystąpiło u dostawcy oprogramowania, a obowiązki spoczywają na placówce. Wyjaśniamy, dlaczego RODO rozkłada odpowiedzialność właśnie w ten sposób.
To pytanie wraca w każdej rozmowie o incydencie MyDR: skoro atak dotyczył systemów dostawcy, dlaczego to placówka ma cokolwiek zgłaszać? Odpowiedź wynika z konstrukcji RODO, która rozdziela dwie role — administratora danych i podmiotu przetwarzającego — i przypisuje im różne obowiązki.
Rozróżnienie nie jest formalnością. Decyduje o tym, kto ocenia ryzyko, kto zawiadamia organ nadzorczy, kto informuje pacjentów i kto odpowiada, jeżeli te obowiązki nie zostaną wykonane.
Administrator to podmiot, który decyduje o celach i sposobach przetwarzania danych. W przypadku dokumentacji medycznej jest to placówka: podmiot leczniczy, praktyka lekarska, gabinet. To ona przyjmuje pacjenta, zbiera dane, decyduje, w jakim systemie będą przechowywane i jak długo.
Podmiot przetwarzający działa na zlecenie administratora i w zakresie, który administrator określił. Dostawca systemu do prowadzenia elektronicznej dokumentacji medycznej jest klasycznym przykładem: przetwarza dane pacjentów, ale nie decyduje, po co i dlaczego. W sprawie MyDR to właśnie ten układ — placówki występują jako administratorzy, spółka jako procesor.
Umowa powierzenia przetwarzania danych określa przedmiot i czas przetwarzania, rodzaj danych i kategorie osób, obowiązki dostawcy w zakresie bezpieczeństwa, zasady korzystania z podwykonawców oraz sposób wspierania administratora w realizacji jego obowiązków. Powinna też opisywać, jak i w jakim terminie dostawca informuje o naruszeniach.
W sprawie MyDR treść tej umowy zyskała praktyczne znaczenie. Prawnicy komentujący sprawę zwracali uwagę, że od zapisów dokumentu zależy, jakich informacji placówka może żądać i w jakim terminie — a także jaka jest jej pozycja w razie ewentualnych roszczeń.
Nie przenosi obowiązków administratora na dostawcę. Art. 33 i art. 34 RODO adresowane są do administratora i żadna umowa tego nie zmienia. Umowa może zobowiązać dostawcę do przekazania informacji i do współpracy, ale nie może przenieść na niego decyzji o zgłoszeniu naruszenia.
Szerzej o konstrukcji takiej umowy pisaliśmy w materiale Umowa powierzenia danych — kiedy jest potrzebna.
Podmiot przetwarzający ma po stwierdzeniu naruszenia jeden zasadniczy obowiązek: bez zbędnej zwłoki zgłosić je administratorowi. W praktyce oznacza to przekazanie informacji pozwalających administratorowi ocenić sytuację — charakteru naruszenia, kategorii i przybliżonej liczby osób oraz rekordów, możliwych konsekwencji i podjętych działań zaradczych.
Dostawca nie zgłasza naruszenia organowi nadzorczemu w imieniu administratora i nie zawiadamia pacjentów. Nie ma też kompetencji, by rozstrzygnąć, że zgłoszenie nie jest potrzebne — może przedstawić swoją ocenę, ale nie jest ona wiążąca dla administratora.
Odpowiadając na wystąpienie samorządu lekarskiego, Prezes UODO wskazał, że z komunikatów nie wynika automatyczny obowiązek zgłoszenia naruszenia przez każdego administratora korzystającego z systemu — ale też że administrator nie może oprzeć się wyłącznie na stanowisku procesora o braku takiej konieczności.
Ścieżka jest więc następująca: ustalić, czy zdarzenie dotyczy danych, które placówka powierzyła do przetwarzania, a następnie samodzielnie ocenić, czy w jej sytuacji zachodzą obowiązki z art. 33 lub 34 RODO. Jeżeli placówka nie ma do tego wystarczających informacji, powinna zwrócić się o nie do dostawcy — aktywnie, a nie biernie czekając na rozwój sytuacji.
Organ nadzorczy podkreślił również, że termin 72 godzin biegnie od chwili stwierdzenia naruszenia, rozumianej jako uzyskanie dostatecznego stopnia pewności, że doszło do incydentu prowadzącego do naruszenia ochrony danych. Po tym momencie oczekiwanie na dodatkowe informacje od procesora nie wstrzymuje biegu terminu. Zagadnienie omawiamy szczegółowo w artykule Czy trzeba zgłosić wyciek MyDR do UODO.
Jeżeli któryś z tych punktów okaże się nieuregulowany, to informacja na przyszłość — nie na dziś. Na dziś liczy się ustalenie faktów i terminowa ocena obowiązków. Przegląd umów jest naturalnym elementem wniosków po zakończeniu sprawy.
Wspieramy placówki medyczne w analizie technicznej incydentu, weryfikacji bezpieczeństwa infrastruktury IT oraz przygotowaniu informacji i dokumentacji potrzebnych do dalszej obsługi sprawy. ITCOMPUTEX nie świadczy usług prawnych i nie wydaje ocen prawnych — pracujemy po stronie technicznej i organizacyjnej.
Incydent MyDR
Najważniejsze informacje dotyczące incydentu, możliwego zakresu naruszenia oraz znaczenia sprawy dla placówek medycznych.
UODO
Kiedy powstaje obowiązek zgłoszenia, od czego liczy się termin 72 godzin i jak udokumentować decyzję administratora.
Dokumentacja
Rejestr naruszeń, chronologia zdarzeń, źródła informacji, korespondencja z dostawcą i zapis decyzji administratora.
Wszystkie materiały dotyczące incydentu zebrane są w sekcji Wyciek danych MyDR.