MyDr: jak cyberatak na polskie oprogramowanie medyczne może dotyczyć blisko 19 mln pacjentów i co to oznacza dla Twojej firmy?
BLUF (krótka odpowiedź): 17 sierpnia 2026 roku polskie władze potwierdziły cyberatak na MyDr — prywatnego dostawcę oprogramowania, które łączy placówki medyczne z platformą P1 e-zdrowia. Nieuprawniony dostęp do danych historycznych (do kwietnia 2024 r.) może dotyczyć nawet ~19 mln osób i 12 000+ placówek; władze (m.in. minister cyfryzacji i NFZ/CSIRT) badają sprawę, a NFZ ją monitoruje. Brak dowodów publikacji danych. To potencjalnie największy wyciek danych w Polsce i przykład ryzyka łańcucha dostaw oprogramowania, które w świetle NIS2/KSC dotyczy każdej firmy — nie tylko ochrony zdrowia.
Najważniejsze fakty
- MyDr to kluczowy ogniwo cyfrowej opieki zdrowotnej w Polsce — jego oprogramowanie łączy tysiące placówek medycznych z platformą P1 Ministerstwa Zdrowia (e-recepty, e-skierowania), co czyni go elementem krytycznej infrastruktury zdrowotnej kraju [1][2][3].
- Skala: nawet ~19 mln osób i 12 000+ placówek — potwierdzony nieuprawniony dostęp do historycznych danych (do kwietnia 2024 r.); doniesienia mówią nawet o 18,8 mln unikalnych numerów PESEL i danych pacjentów oraz recept [1][4][5].
- Polskie władze badają incydent — zaangażowane są m.in. minister cyfryzacji Krzysztof Gawkowski oraz NFZ/CSIRT; Gawkowski ocenił sprawę jako jeden z największych wycieków danych w historii Polski [2][3][4].
- Na razie brak dowodów publikacji danych — NFZ monitoruje sytuację; nie potwierdzono upublicznienia wykradzionych rekordów [1][2].
- Lekcja NIS2/KSC: sektor opieki zdrowotnej to essential entity; incydent ilustruje ryzyko łańcucha dostaw oprogramowania (art. 21 ust. 2 lit. d NIS2), obowiązki zgłoszeniowe 24h/72h (art. 23) oraz ciągłość działania [1].
Tabela decyzyjna — co to oznacza dla firmy B2B/produkcyjnej
| Obszar | Co wiemy | Co to oznacza dla firmy B2B/produkcji | Zalecane działanie 30/90 dni |
|---|---|---|---|
| Łańcuch dostaw oprogramowania | MyDr to dostawca oprogramowania, przez który mogły wyciec dane medyczne setek placówek | Twoi operatorzy oprogramowania (ERP, CRM, chmura, integratorzy) to ten sam wektor ryzyka | 30 dni: zrób mapę dostawców oprogramowania i poziomu ich dostępu do Twoich danych; 90 dni: wdróż kontrole due diligence i umowy z klauzulami bezpieczeństwa |
| Dane osobowe i wrażliwe | Potencjalnie dane medyczne, PESEL, recepty — do kwietnia 2024 r. | Dane, których nie kontrolujesz bezpośrednio, i tak obciążają Cię odpowiedzialnością | 30 dni: sprawdź, jakie dane przetwarzają Twoi dostawcy i gdzie są przechowywane; 90 dni: zminimalizuj retencję i zaszyfruj dane wrażliwe |
| Zgłaszanie incydentów (NIS2 art. 23) | Healthcare = essential entity; obowiązki zgłoszeniowe 24h/72h | Wszyscy w łańcuchu dostaw powinni mieć jasny proces zgłaszania | 30 dni: wdróż plan reagowania na incydenty i mapę obowiązków zgłoszeniowych; 90 dni: przetestuj proces zgłoszeniowy z zespołem |
| Ciągłość działania (BCP/DR) | Duży wyciek może sparaliżować usługi kluczowego dostawcy | Jeśli kluczowy dostawca upadnie, Twoja produkcja/operacje też stają | 30 dni: zidentyfikuj zależności krytyczne od pojedynczych dostawców; 90 dni: przygotuj plan awaryjny i alternatywnych dostawców |
| Zgodność NIS2/KSC | Incydent u dostawcy może być Twoim incydentem | Ryzyko łańcucha dostaw jest jawnym wymogiem NIS2 (art. 21 ust. 2 lit. d) | 90 dni: wdróż ocenę bezpieczeństwa dostawców i dokumentuj ją |
Perspektywa inż. Marcina Białczyka
Z operacyjnego punktu widzenia MyDr to nie jest historia o „hakerach”, tylko o koncentracji ryzyka. Kiedy jeden dostawca oprogramowania obsługuje tysiące placówek i łączy je z krajową platformą e-zdrowia, tworzy się pojedynczy punkt awarii — i to dokładnie taki, jaki NIS2/KSC nazywa ryzykiem łańcucha dostaw. W firmach produkcyjnych widzę ten sam mechanizm: system ERP, integrator chmury czy dostawca SCADA trzyma dane i dostęp, które decydują o ciągłości działania, a firma nie ma pełnego wglądu w to, jak ten dostawca zabezpiecza te zasoby. Incydent u dostawcy to w praktyce incydent u Ciebie.
Drugi wniosek dotyczy odpowiedzialności i pomiaru. „Nie mieliśmy danych w systemie, bo przechowuje je dostawca” — to nie jest linia obrony, to jest deklaracja braku kontroli. W CHORS.NET podchodzimy do tego przez pomiar ekspozycji i pasywny snapshot, zanim zaproponujemy jakiekolwiek zmiany — bo liczba, a nie słowa, pokazuje realny poziom ryzyka w łańcuchu dostaw. Kluczowe pytanie nie brzmi „czy dostawca ma certyfikat”, ale „co się stanie z moimi danymi i moją ciągłością, gdy dostawca zostanie zaatakowany”.
FAQ
Czy moje dane medyczne są zagrożone, jeśli korzystam z placówki używającej MyDr?
Jeśli Twoja placówka medyczna korzystała z oprogramowania MyDr, Twoje historyczne dane (do kwietnia 2024 r.) mogły zostać objęte nieuprawnionym dostępem. NFZ monitoruje sprawę, a na razie brak dowodów publikacji danych. Sprawdź komunikaty NFZ i swojego świadczeniodawcy oraz rozważ monitoring swoich danych osobowych.
Czy to dotyczy firm spoza ochrony zdrowia?
Tak, pośrednio. MyDr to przykład ryzyka łańcucha dostaw oprogramowania — dokładnie ten sam wektor, który dotyczy każdej firmy B2B/produkcyjnej korzystającej z ERP, chmury, SCADA czy integratorów. NIS2/KSC wprost wymaga zarządzania ryzykiem łańcucha dostaw (art. 21 ust. 2 lit. d).
Jakie są obowiązki zgłoszeniowe w takim przypadku?
W sektorze ochrony zdrowia (essential entity) NIS2 przewiduje zgłoszenie wstępne w 24h i pełne w 72h od incydentu (art. 23). Dokładny zakres obowiązków zależy od statusu podmiotu — szczegółowa interpretacja wymaga konsultacji z kancelarią.
Co zrobić, jeśli nasz dostawca oprogramowania został zaatakowany?
Nie czekaj — uruchom plan reagowania: zidentyfikuj zakres wpływu, zabezpiecz dowody, poinformuj odpowiednie osoby/organy (zgodnie z mapą obowiązków), rozważ monitoring danych i przygotuj komunikację. Kluczowe jest, by nie opierać bezpieczeństwa na deklaracjach dostawcy — weryfikuj fakty.
CTA
Chcesz sprawdzić, jak realnie wygląda ekspozycja Twojej firmy na ryzyko łańcucha dostaw oprogramowania? Zobacz, jak pracuje CHORS.NET i co możemy dla Ciebie zrobić:
- Usługi bezpieczeństwa — pomiar ekspozycji i wsparcie operacyjne: /uslugi/
- NIS2/KSC Readiness — przygotowanie do obowiązków NIS2/KSC z granicami: /nis2-ksc/
- Polityka AI w cyberbezpieczeństwie — jak podchodzimy do automatyzacji: /polityka-ai/
- Jak pracuje CHORS.NET — nasza metodologia i zasady współpracy: /o-nas/jak-pracuje-chors-net/
Granice i założenia
- Nie jesteśmy SOC 24/7 i nie gwarantujemy wykrycia każdego incydentu.
- Nie certyfikujemy zgodności z NIS2/KSC i nie wydajemy samodzielnej opinii prawnej.
- Wyniki i fakty dotyczą stanu na moment artykułu (17.08.2026) i opierają się na publicznych doniesieniach oraz komunikatach NFZ.
- W zakresie interpretacji prawa CHORS współpracuje z kancelariami.
- Materiał ma charakter informacyjny i techniczny; nie stanowi porady prawnej.
Data aktualizacji: 17.08.2026