MyDr — wyciek danych medycznych: odpowiedzialność vendora EDM

← Hub odpowiedzialności · Stan na 02.10.2026 · materiał publiczny · Checklista 72h dla placówki

Wyciek danych medycznych MyDr to nie tylko incydent IT — to test modelu, w którym placówka (administrator) i vendor EDM (procesor) mają różne obowiązki, a pacjent nie wybiera systemu. Poniżej: co wiadomo o wycieku MyDr, kiedy liczy się 72h na zgłoszenie do UODO, jakie pytania zadać vendorowi i checklista 72h dla placówki.

Co wiemy / czego nie wiemy

Weryfikuj daty i źródła przed cytowaniem. Liczby bywają aktualizowane w toku śledztwa.

Przesunięcie pytania

5 pytań (do skopiowania)

1. Jakie minimum security i testów powinien spełniać vendor EDM działający w skali tysięcy placówek?
2. Jak wygląda SLA powiadomienia administratorów o incydencie (treść, zakres, deadline)?
3. Jak obywatel ma w praktyce ustalić „czy ja jestem w zakresie” w ciągu dni, nie miesięcy?
4. Jakie elementy umowy powierzenia (audyt, podprocesorzy, exit) były realnie egzekwowalne przed incydentem?
5. 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.

1. Potwierdź, czy korzystacie z danego vendora i w jakim zakresie (EDM / terminarz / inne).
2. Wyślij pisemne zapytanie do procesora: zakres, kategorie danych, timeline, rekomendacje.
3. Udokumentuj ocenę ryzyka dla Waszych osób / danych.
4. Zdecyduj o zgłoszeniu do UODO (i ewentualnym zawiadomieniu pacjentów).
5. Przygotuj komunikację antyphishingową (recepty, wizyty, „dopłaty”).
6. 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.

Czy firma przetwarzająca moje dane medyczne (np. MyDr) ponosi odpowiedzialność za ich bezpieczeństwo?

Tak, jako procesor danych musi zapewnić odpowiedni poziom ochrony. Jednak w praktyce kontrola nad tym, jak to robi, często jest niewystarczająca, a skutki naruszeń są powszechne i trudne do naprawienia. Odpowiedzialność formalna nie zawsze idzie w parze z rzeczywistą przejrzystością i konsekwencjami.

Dlaczego wyciek z MyDr dotyczy aż 19 mln osób?

To skutek centralizacji danych medycznych u jednego dostawcy technologicznego. Gdy taki vendor staje się krytyczny dla działania systemu zdrowia, każdy incydent ma skalę systemową — dokładnie to, co opisuje rama 'zależność miliona ludzi od jednego podmiotu'.

Czy firma przetwarzająca dane medyczne online może uniknąć odpowiedzialności po wycieku?

Nie powinna, ale często to robi. RODO nakłada obowiązki na administratora i procesora danych, jednak brakuje skutecznych narzędzi egzekwowania przejrzystości i naprawy szkód, gdy w grę wchodzą miliony osób. Przypadek MyDr pokazuje luki w tym systemie.

Dlaczego wyciek z MyDr jest przykładem problemu z vendor EDM?

Ponieważ platforma stała się krytycznym elementem infrastruktury zdrowotnej bez bycia traktowaną jak taka. Brak jawnych zobowiązań, audytów i mechanizmów reakcji po incydencie ujawnia nierównoważność: ogromna skala przetwarzania vs zerowa rozliczalność.

Czy wyciek z MyDr oznacza, że vendor systemu powinien ponosić odpowiedzialność za naruszenie RODO?

Tak – jeśli vendor działa jako procesor danych, ma obowiązki wynikające z art. 28 RODO. Jednak w praktyce pacjent trudno może dochodzić roszczeń bezpośrednio od niego. Problem tkwi w tym, że mimo zależności milionów użytkowników, odpowiedzialność pozostaje rozmyta.

Czy państwo powinno tworzyć własne systemy (jak eDziennik), by uniknąć zależności od prywatnych vendorów?

Niekoniecznie. Kluczowe nie jest to, kto buduje system, ale kto i jak ponosi odpowiedzialność za jego działanie i bezpieczeństwo. Publiczny vendor też może być niewystarczająco odpowiedzialny – chyba że mechanizmy kontroli będą rzeczywiste.

Czy firma obsługująca system EDM (np. MyDr) jest odpowiedzialna za bezpieczeństwo danych pacjentów?

Firma ta działa najczęściej jako procesor danych – technicznie przetwarza informacje na rzecz administratora (np. NFZ lub szpitala). Choć ma obowiązki bezpieczeństwa wynikające z RODO, ostateczna odpowiedzialność prawna spoczywa na administratorze. Jednak w praktyce pacjent nie ma dostępu do umów ani mechanizmów kontroli procesora, co tworzy lukę w ochronie.

Dlaczego wyciek u jednego vendora może zagrozić milionom pacjentów?

Gdy pojedynczy vendor obsługuje infrastrukturę dla wielu instytucji medycznych, staje się centralnym punktem awarii. Brak standardów wymuszających redundancję, audyty i transparentność zobowiązań powoduje, że miliony osób stają się zależne od jednej struktury technicznej bez możliwości wyboru czy wpływu.

Czy pacjent może żądać informacji o wycieku danych bezpośrednio od MyDr?

Nie wprost. MyDr działa jako procesor danych dla administratorów (np. NFZ, szpitale). Prawo do informacji przysługuje pacjentowi wobec administratora, który powinien monitorować procesora. Brak reakcji administratora to również naruszenie jego obowiązków RODO.

Dlaczego wyciek danych z jednego providera może dotyczyć 19 mln osób?

To efekt scentralizowanej infrastruktury – gdy jeden vendor obsługuje krytyczne funkcje dla wielu podmiotów administracyjnych, staje się punktem pojedynczego zawodzenia. Bez wymogu równoważnej odpowiedzialności ryzyko systemowe rośnie wykładniczo.

Czy firma obsługująca dane medyczne online może być jedynym punktem awarii dla milionów?

Tak — jak pokazuje przypadek MyDr. Gdy jeden vendor obsługuje dostęp do danych dla większości obywateli, jego błędy stają się kryzysem ogólnopaństwowym. To nie jest pytanie techniczne, ale kwestia architektury odpowiedzialności.

Kto ponosi winę, gdy dane z e-usługi trafiają do sieci?

Administrator danych (np. NFZ) ma ostatnią odpowiedzialność, ale jeśli powierzył infrastrukturę firmie bez skutecznych wymogów audytu i reakcji na incydenty, to współtworzy ryzyko. Procesor (vendor) musi działać transparentnie — dziś często tego nie robi.

Czy dostawca systemu e-recept lub e-skierowań może być administratorem danych?

Nie – zgodnie z RODO, administratorem danych jest podmiot decydujący o celu i sposobie przetwarzania, np. NFZ lub szpital. Vendor (np. EDM) działa jako procesor i odpowiada tylko za bezpieczeństwo techniczne i organizacyjne, nie za decyzje o udostępnianiu czy przechowywaniu.

Co jeśli wyciek danych wynika z podatności w systemie trzeciego dostawcy?

Odpowiedzialność administracyjna i przed organami RODO spoczywa nadal na administratorze (np. NFZ). Jednak może on dochodzić roszczeń cywilnych od procesora. Kluczowe jest, by umowy z vendorami zawierały jasne mechanizmy raportowania incydentów i współpracy po wycieku.

Czy dostawca systemu medycznego (np. MyDr) ponosi odpowiedzialność za naruszenie danych?

Tak – jeśli przetwarza dane w imieniu administratora, jest procesorem RODO i musi zapewnić bezpieczeństwo. Brak takiego zapewnienia może skutkować sankcjami i obowiązkiem naprawy szkody. Szczegóły w analizie na stronie.

Jakie konsekwencje ma dla placówki lekarskiej użycie niesprawnego systemu EDM?

Placówka pozostaje administratorem danych i ponosi pierwotną odpowiedzialność przed UODO, ale może dochodzić roszczeń od procesora (vendora). Kluczowe znaczenie ma umowa i dokumentacja ryzyka.

Czy każdy wyciek danych medycznych to powtórka scenariusza MyDr?

Nie. Kluczowe jest, kto odpowiada za bezpieczeństwo danych: lekarz (administrator) czy dostawca oprogramowania (procesor). Problem pojawia się, gdy miliony pacjentów są zależne od jednego systemu, a odpowiedzialność pozostaje niejasna. Wtedy awaria u vendora staje się kryzysem publicznym.

Jak cytować

Changelog

• 2026-10-02 — Kontekst medialny (2026-10-02): nasilenie sygnałów pod case mydr (m.in. Niebezpiecznik: „Kolejny wyciek danych, tym razem 2 500 000 pacjentów”) — dopięcie do ramy administrator vs procesor / zależność od vendora EDM; to tło, nie ustalenie faktów.
• 2026-09-21 — Odnotowano sygnał: Wyciek danych nauczycieli. Faktury do badań medycznych w sieci
• 2026-09-17 — Dodano analizę przypadku MyDr jako przykładu krytycznego ryzyka vendor lock-in w sektorze publicznym.
• 2026-09-17 — Rozszerzono sekcję o odpowiedzialności procesora RODO w kontekście cyberincydentów w dostawcach trzecich.
• 2026-09-17 — Zaktualizowano dane dotyczące liczby dotkniętych placówek (ok. 15 tys.) i skali wycieku (ponad 18 mln pacjentów).
• 2026-09-07 — Odnotowano sygnał: Wciąż nie wiesz, czy Twoje dane wyciekły z MyDr. Czas zadawać pytania [OPINIA]
• 2026-09-07 — Dodano kontekst wycieku MyDr jako przykład skalowanego ryzyka w modelu jednego dostawcy dla sektora publicznego.
• 2026-09-07 — Rozszerzono sekcję o procesorach danych o przykład incydentu w przychodni w Warszawie – wpływ na wybór i kontrolę vendorów EDM.
• 2026-09-07 — Zaktualizowano linki do analiz zewnętrznych (ZTS, CyberDefence24) w sekcji przypadków.
• 2026-09-07 — Dodano sekcję analizy przypadku MyDr: skalę wycieku, rolę vendora EDM, brak mechanizmów ograniczających dostęp.
• 2026-09-07 — Rozszerzono model odpowiedzialności: admin vs procesor w kontekście incydentów w służbie zdrowia.
• 2026-09-07 — Zaktualizowano przykładami ryzyka scentralizowanych platform zdrowotnych bez równoległych zabezpieczeń lokalnych.
• 2026-09-07 — Dodano kontekst wycieku MyDr (2026) jako przypadek braku accountability procesora danych medycznych.
• 2026-09-07 — Zaktualizowano sekcję 'Case lens' o analizę roli admin vs procesor w świetle dwóch incydentów MyDr.
• 2026-09-07 — Rozszerzono perspektywę historyczną: drugi duży wyciek z MyDr w ciągu kilku lat.
• 2026-09-07 — Dodano analizę przypadku MyDr jako przykład krytycznego wycieku danych medycznych przetwarzanych przez vendorów systemów EDM.
• 2026-09-07 — Rozszerzono sekcję o odpowiedzialności procesora vs administratora w świetle RODO i faktycznej ochrony pacjenta.
• 2026-09-07 — Zaktualizowano ramę 'Problem nie zaczyna się w momencie ataku' o aspekt zależności systemowej od jednego punktu awarii – tutaj: vendor bez pełnej przejrzystości i odpowiedzialności.
• 2026-09-01 — Dodano analizę przypadku wycieku danych z MyDr jako przykład braku równoważnej odpowiedzialności vendorów systemów medycznych
• 2026-09-01 — Rozszerzono sekcję o rolę administratora vs procesora danych w kontekście systemów typu EDM
• 2026-09-01 — Zaktualizowano kontekst polityczny: propozycja 'Cyber Piątki' i weto dla eDziennika jako sygnały zmieniającego się podejścia do centralizacji cyfrowej
• 2026-08-24 — Dodano analizę przypadku MyDr jako przykład braku odpowiedzialności vendora EDM przy systemowym wycieku danych medycznych.
• 2026-08-24 — Rozszerzono sekcję o rolę procesora danych w RODO, z naciskiem na brak mechanizmów egzekwowania przejrzystości po incydencie.
• 2026-08-24 — Zaktualizowano kontekst publicznego zaufania: zależność milionów od jednej platformy bez możliwości wyboru lub kontroli.
• 2026-08-23 — Dodano sekcję analizującą wyciek danych z MyDr jako przykład ekstremalnej zależności publicznej od jednego vendora EDM.
• 2026-08-23 — Rozszerzono kontekst o ryzyko bezpieczeństwa narodowego i brak komunikacji wobec pacjentów.
• 2026-08-23 — Zaktualizowano przykłady dotyczące braku równoważnej odpowiedzialności podmiotów przetwarzających dane medyczne.
• 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.