Wyciek u dostawcy oprogramowania dla placówek medycznych nie jest tylko incydentem IT. To test modelu, w którym pacjent nie wybiera systemu, a dane zdrowotne koncentrują się u vendora obsługującego tysiące administratorów. Poniżej: co wiadomo, jakie pytania warto zadawać i checklista 72h dla placówek — do swobodnego wykorzystania.
TL;DR
- Rama: problem zaczyna się od zależności od vendora, nie od samego ataku.
- RODO: placówka zwykle nie „zasłania się” procesorem — ma własne obowiązki.
- Publicznie: PESEL pomaga osobie; nie zastępuje standardów ex ante dla vendora skali krajowej.
Co wiemy / czego nie wiemy
| Element | Opis (roboczy) | Źródło / status |
|---|---|---|
| Podmiot | Dostawca oprogramowania dla placówek (MyDr) | komunikaty publiczne MC / media |
| Skala | komunikowana skala rzędu milionów rekordów / osób; tysiące placówek | potwierdzać bieżącymi komunikatami |
| Rodzaj danych | wskazywane m.in. dane identyfikacyjne i informacje związane z opieką medyczną | zakres może być doprecyzowywany |
| Nadzór | kontrola / działania UODO oraz służb | komunikaty UODO |
| Czego nie wiemy | ostateczny zakres per placówka; pełny wektor ataku; finalna lista kategorii danych | oczekiwanie na raporty forensics / komunikaty |
Przesunięcie pytania
Rama: Problem nie zaczyna się w momencie ataku — zaczyna się, gdy milion ludzi jest zależnych od jednego vendora bez równoważnej odpowiedzialności.
Zamiast: „czy zhakowali?” / „czy zastrzec PESEL?”
Lepiej: „jakie obowiązki ex ante powinien mieć vendor EDM o zasięgu krajowym — i jak pacjent ma w praktyce ustalić, czy jest w zakresie?”
5 pytań (do skopiowania)
- Jakie minimum security i testów powinien spełniać vendor EDM działający w skali tysięcy placówek?
- Jak wygląda SLA powiadomienia administratorów o incydencie (treść, zakres, deadline)?
- Jak obywatel ma w praktyce ustalić „czy ja jestem w zakresie” w ciągu dni, nie miesięcy?
- Jakie elementy umowy powierzenia (audyt, podprocesorzy, exit) były realnie egzekwowalne przed incydentem?
- Co z wniosków z tego przypadku wejdzie do standardu ex ante — zanim pojawi się kolejny vendor?
Checklista 72h dla administratora (skrót)
Pełna wersja do skopiowania do memo: Checklista 72h — wyciek u vendora EDM.
- Potwierdź, czy korzystacie z danego vendora i w jakim zakresie (EDM / terminarz / inne).
- Wyślij pisemne zapytanie do procesora: zakres, kategorie danych, timeline, rekomendacje.
- Udokumentuj ocenę ryzyka dla Waszych osób / danych.
- Zdecyduj o zgłoszeniu do UODO (i ewentualnym zawiadomieniu pacjentów).
- Przygotuj komunikację antyphishingową (recepty, wizyty, „dopłaty”).
- Przejrzyj umowę powierzenia: audyt, SLA, podprocesorzy, exit.
FAQ
Kto odpowiada za dane pacjentów, jeśli wyciek nastąpił u dostawcy EDM?
Zazwyczaj placówka pozostaje administratorem, a dostawca działa jako procesor. Administrator ma własne obowiązki oceny ryzyka i zgłoszeń.
Czy zastrzeżenie PESEL rozwiązuje problem wycieku danych medycznych?
Nie. Ogranicza część ryzyk tożsamościowych, ale nie zmienia modelu koncentracji danych u vendora.
Ile czasu ma placówka na zgłoszenie naruszenia do UODO?
Gdy zgłoszenie jest wymagane: bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin od stwierdzenia naruszenia przez administratora.
Czy komunikat medialny wystarczy, by zgłaszać naruszenie?
To sygnał do weryfikacji u procesora. Decyzja powinna wynikać z oceny zakresu i ryzyka dla danych danej placówki.
Jakie pytania warto zadać vendorowi EDM przed kolejnym incydentem?
Baseline security, prawo audytu, podprocesorzy, SLA powiadomień, forensics/logi, exit i eksport danych.
Dlaczego to jest temat publiczny, a nie tylko IT?
Pacjent zwykle nie wybiera systemu, a przy skali krajowej skutki są systemowe.
Czy wystarczy informacja na stronie przychodni?
Przy wysokim ryzyku indywidualne zawiadomienie osób zwykle nie jest zastępowane samym komunikatem na stronie.
Co powinna zawierać checklista 72h?
Zakres, info od procesora, ocena ryzyka, decyzja UODO/osoby, antyphishing, przegląd umowy powierzenia.
Vendor EDM mówi, że ustala zakres wycieku. Czy pacjent ma czekać, aż sam się odezwie?
Nie. Obowiązek wobec osoby, której dane dotyczą, spoczywa na administratorze (placówka), a nie na vendora-procesorze. Ustalanie zakresu nie zawiesza pytania: czy moje dane były w zbiorze, jakiego były charakteru i kiedy dostanę indywidualną informację. Pytaj placówkę na piśmie — nie przyjmuj odesłania „to vendor”.
Dlaczego to problem odpowiedzialności vendora, skoro był atak?
Atak jest zdarzeniem. Problem zaczyna się wcześniej: miliony pacjentów zależą od jednego dostawcy EDM, którego nie wybierali, bez równoważnej odpowiedzialności, audytu i komunikacji. Pacjent nie jest stroną kontraktu z vendorem — dlatego hub trzyma ramę administrator vs procesor vs pacjent.
Czy firma przetwarzająca dane medyczne (np. MyDr) musi poinformować użytkowników o wycieku?
Tak – zgodnie z RODO, podmiot przetwarzający dane (procesor) ma obowiązek natychmiastowego powiadomienia administratora danych, a ten – w razie wysokiego ryzyka dla praw osób – musi poinformować osoby objęte danymi. Brak takiej komunikacji może świadczyć o naruszeniu przepisów.
Czy firma przetwarzająca dane medyczne (np. MyDr) ponosi odpowiedzialność za wyciek?
Tak – jako procesor, firma ma obowiązek bezpieczeństwa zgodnie z RODO. Ale administrator danych (np. NFZ, lekarz) nadal decyduje o legalności przetwarzania. Problem pojawia się, gdy administrator przenosi ryzyko na procesora bez rzeczywistej kontroli nad jego działaniami.
Dlaczego wyciek z MyDr to więcej niż problem techniczny?
To problem systemowy: koncentracja danych blisko 19 mln ludzi w jednym miejscu bez równoległych mechanizmów kontroli, przejrzystości i naprawy. Gdy taki vendor zawodzi, całe społeczeństwo staje się ranne.
Czy jako pacjent mogę sprawdzić, czy moje dane były wycieknięte przez MyDr?
Obecnie nie ma publicznego, wiarygodnego mechanizmu pozwalającego pacjentowi na taką weryfikację. MyDr nie udostępnił narzędzi do indywidualnej weryfikacji, a oficjalne komunikaty są ogólne i opóźnione. To przykład braku odpowiedzialności wobec właściciela danych.
Czy powtarzające się incydenty w MyDr świadczą o czymś więcej niż o pojedynczym błędzie?
Tak. Dwa znaczące wycieki w ciągu kilku lat wskazują na systemowe problemy: niedostateczne inwestycje w cyberbezpieczeństwo, brak skutecznego nadzoru oraz nieproporcjonalną moc rynkową bez równie silnej odpowiedzialności prawnej i operacyjnej.
Jak cytować
Changelog
- 2026-08-21 — Dodano analizę drugiego incydentu w MyDr (13 mln danych sprzed 2 lat) jako dowód na chroniczne problemy bezpieczeństwa.
- 2026-08-21 — Zaktualizowano sekcję o braku przejrzystości dla użytkowników — pacjenci nadal nie wiedzą, czy ich dane zostały naruszone.
- 2026-08-21 — Rozszerzono kontekst bezpieczeństwa narodowego: wyciek danych medycznych to nie tylko prywatna sprawa, ale zagrożenie strategiczne.
- 2026-08-21 — Dodano sekcję analizy przypadku MyDr jako przykładu ekstremalnej koncentracji ryzyka w jednym vendorze EDM.
- 2026-08-21 — Rozszerzono część o odpowiedzialności administratora vs. procesora RODO w kontekście dostępności i integralności danych medycznych.
- 2026-08-21 — Zaktualizowano przykład wycieku o informacje o drugim incydencie z przeszłości (13 mln danych skradzionych 2 lata temu).
- 2026-08-21 — Dodano analizę przypadku MyDr w kontekście braku przejrzystości po incydencie i zależności systemu od jednego dostawcy.
- 2026-08-21 — Zaktualizowano sekcję 'Case lens' o aktualne sygnały dotyczące wycieku danych pacjentów.
- 2026-08-21 — Rozszerzono FAQ o pytanie o obowiązek informowania użytkowników przez platformy EDM po naruszeniu bezpieczeństwa.
- 2026-08-20 — Dodano wątek: brak indywidualnej informacji dla pacjentów przy komunikacie vendora o końcowym etapie ustalania zakresu.
- 2026-08-20 — Wzmocniono rozróżnienie ról: placówka jako administrator, vendor EDM jako procesor, pacjent poza umową z vendorem.
- 2026-08-20 — Zaznaczono, że skala, kategorie danych i status zawiadomień pozostają do potwierdzenia źródłami pierwotnymi — media nie są decyzją.
- 2026-08-20 — v0.1: rama, fakty (robocze), 5 pytań, checklista, FAQ.
Materiał informacyjny. Nie stanowi porady prawnej. Wolno kopiować fragmenty z podaniem źródła.