Dane pacjentów u jednego dostawcy. Co ustawa o KSC wymaga od placówki medycznej po MyDr, Medyc, FELG i Enel-Med?

Od sierpnia do października 2026 r. z polskich systemów medycznych wyciekły dane pacjentów pięć razy: MyDr, Medyc, Enel-Med, FELG Dent i IQ Dental. W czterech z pięciu przypadków celem był dostawca oprogramowania, w którym setki albo tysiące placówek trzymały dokumentację pacjentów. Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (ustawa o KSCUstawa o KSC Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych.) obejmuje podmioty lecznicze od wielkości średniego przedsiębiorcy, a dostawca systemu gabinetowego zwykle jest poza nią. Obowiązek zarządzania ryzykiemZarządzanie ryzykiem To, co podmiot robi z oszacowanym ryzykiem: dobiera zabezpieczenia, a ryzyko, którego nie ogranicza, akceptuje świadomie., które taki dostawca wnosi, leży więc po stronie placówki: art. 8 ust. 1 pkt 2 lit. e ustawy o KSC nakazuje jej zapewnić bezpieczeństwo i ciągłość łańcucha dostawŁańcuch dostaw Dostawcy sprzętu, oprogramowania i usług ICT, od których zależy świadczenie usługi. Ich bezpieczeństwo podmiot uwzględnia w swoim zarządzaniu ryzykiem. usług ICT, od których zależy świadczenie usługi. W tym tekście pokazuję, co z tych pięciu incydentów wynika dla kierownika podmiotuKierownik podmiotu Osoba albo organ kierujący podmiotem kluczowym lub ważnym, na przykład zarząd spółki. Odpowiada za cyberbezpieczeństwo podmiotu także wtedy, gdy zadania powierzył innej osobie. leczniczego, dla jego inspektora ochrony danychInspektor ochrony danych Osoba wyznaczona przez administratora lub podmiot przetwarzający do zadań z RODO. Tutaj pojawia się przy incydentach z danymi osobowymi i przy łączeniu tej funkcji z rolą pełnomocnika. (IOD) i dla małej firmy diagnostycznej, która udostępnia wyniki badań online.

Co się stało od sierpnia?

Cztery z pięciu zdarzeń opisałem w aktualnościach, piąte, MyDr, poprzedziło start tej strony, więc streszczam je tu z dokumentów urzędowych.

W sprawie MyDr Prokuratura Okręgowa w Warszawie opisuje przedmiot dochodzenia jako uzyskanie dostępu do systemu „po uprzednim przełamaniu albo ominięciu informatycznych zabezpieczeń” i wymienia zakres danych: imiona, nazwiska, numery PESEL, numery telefonów, adresy e-mail „oraz dane dotyczące stanu zdrowia, jak treść notatek z wizyt lekarskich czy informacji o wystawionych receptach”. Ministerstwo Cyfryzacji w odpowiedzi na interpelację nr 19211 podaje, że zdarzenie dotyczy około 18,8 mln osób i ponad 12 tys. placówek korzystających z MyDr EDM, a pozyskana baza przekracza 2 TB. Centrum e-Zdrowia (CeZ) potwierdziło, że centralne usługi e-zdrowia nie zostały naruszone, a certyfikaty do komunikacji z systemem P1 wymienia zapobiegawczo.

Cztery incydenty u dostawców mają ten sam układ: jedna aplikacja, jedna baza i tysiące administratorów danych, którzy dowiadują się o naruszeniu z komunikatu dostawcy albo z mediów. Skala wycieku zależy wtedy od wielkości dostawcy, a gabinet nie ma na nią żadnego wpływu.

Dlaczego jeden dostawca EDM to inne ryzyko niż jedna placówka?

Dokumentacja medyczna to dane dotyczące zdrowia, czyli szczególna kategoria danych z art. 9 ust. 1 RODO. Pojedyncza przychodnia trzyma je dla swoich kilku tysięcy pacjentów. Dostawca elektronicznej dokumentacji medycznej (EDM) trzyma je dla wszystkich swoich klientów naraz, z rozpoznaniami, receptami, zwolnieniami i notatkami z wizyt. Atak na jedną podatność w jego API daje sprawcy dostęp do całości. W FELG Dent, według relacji sprawcy, wystarczyło założyć konto demo i zwiększać identyfikator w zapytaniu, bo interfejs nie sprawdzał, do czyich danych sięga. W Medyc wystarczyła jedna luka SQL injection. W IQ Dental jedno konto administracyjne.

Do tego dochodzi czas. MyDr wyciekły dane historyczne gromadzone do kwietnia 2024 r. Medyc eksportował rekordy od lipca 2024 r. do sierpnia 2026 r., a według Zaufanej Trzeciej Strony kompletna baza sięga siedem lat wstecz. Dostawca, który nie usuwa danych po zakończeniu umowy albo nie ogranicza retencji, zwiększa skalę każdego przyszłego wycieku o pacjentów, których placówka dawno już nie leczy.

Prezes UODO zapowiedział 13 sierpnia 2026 r. kontrolę w MyDr i napisał, co sprawdzi: zastosowane środki techniczne i organizacyjne, to, czy były regularnie testowane pod kątem zmieniających się zagrożeń, i czy analiza ryzyka uwzględniała możliwe zagrożenia dla przetwarzanych danych, a jej wyniki zastosowano w praktyce. Dzień wcześniej Urząd przypomniał, że obowiązek powiadomienia osób dotkniętych wyciekiem spoczywa na administratorach, którzy korzystali z usług spółki. Oba komunikaty opisują ten sam układ: dostawca jest podmiotem przetwarzającym, a każda z 12 tys. placówek osobno odpowiada wobec swoich pacjentów.

Od strony ustawy o KSC układ jest jeszcze mniej wygodny. Ministerstwo Cyfryzacji w odpowiedzi na interpelację nr 19211 stwierdza, że MyDr nie dokonało samoidentyfikacji jako podmiot KSC, nie było wpisane do wykazu podmiotów kluczowych i ważnych i nie złożyło wniosku o wpis, więc incydentu nie zgłoszono przez system S46. Organ właściwy może decyzją z art. 7l uznać za podmiot kluczowy lub ważny firmę, która nie spełnia kryterium wielkości, jeśli między innymi zakłócenie jej usługi spowoduje poważne zagrożenie dla zdrowia publicznego albo jej usługa ma istotne znaczenie na poziomie wojewódzkim lub krajowym. Według tej samej odpowiedzi takiej decyzji wobec MyDr nie wydano. Ministerstwo dodaje, że nawet dostawca, który sam nie jest podmiotem KSC, „powinien podlegać wymaganiom dotyczącym łańcucha dostaw podmiotów kluczowych i podmiotów ważnych”. Obowiązek zostaje więc po stronie placówki, która kupuje usługę.

Nie mam dobrej odpowiedzi na pytanie, czy dostawca EDM z 12 tys. klientów powinien być podmiotem kluczowym z mocy decyzji. Mogę za to powiedzieć, że dopóki nie jest, jego klienci są jedynym miejscem, w którym ustawa o KSC tego dostawcę w ogóle dosięga.

Kto w ochronie zdrowia podlega ustawie o KSC?

Załącznik nr 1 do ustawy o KSC w sektorze ochrona zdrowia wymienia między innymi podmiot leczniczy, o którym mowa w art. 4 ust. 1 ustawy z dnia 15 kwietnia 2011 r. o działalności leczniczej, jednostki publicznej służby krwi, świadczeniodawców posiadających w swojej strukturze szpitalny oddział ratunkowy, centrum urazowe lub centrum urazowe dla dzieci, a także podmioty udzielające świadczeń opieki zdrowotnej będące podwykonawcą dla podmiotów kluczowych lub ważnych w tym sektorze. Wpis do załącznika nie wystarcza; o statusie rozstrzyga wielkość:

• przedsiębiorca z załącznika nr 1, który przewyższa wymogi dla średniego przedsiębiorstwa z załącznika I do rozporządzenia 651/2014/UE, jest podmiotem kluczowym (art. 5 ust. 1 pkt 1 ustawy o KSC);
• przedsiębiorca, który spełnia wymogi średniego przedsiębiorcy, jest podmiotem ważnym (art. 5 ust. 2 pkt 1 ustawy o KSC);
• podmiot leczniczy, który nie jest przedsiębiorcą, jest podmiotem ważnym przy zatrudnieniu od 50 do 249 osób i podmiotem kluczowym od 250 osób (art. 5 ust. 8 ustawy o KSC).

Ministerstwo Cyfryzacji w pytaniu 3.23 odpowiedzi do ustawy wyjaśnia, że przy liczeniu zatrudnienia podmiotu leczniczego niebędącego przedsiębiorcą bierze się pod uwagę wszystkie stosunki zatrudnienia, także umowy cywilnoprawne, bez rozróżniania pełnego i niepełnego wymiaru. Dla szpitala z kontraktami lekarskimi to zwykle przesądza o statusie podmiotu kluczowego. Jak sprawdzić wielkość przedsiębiorcy i jakie są wyjątki, opisałem w osobnym tekście.

Sieć medyczna wielkości Enel-Med i duży szpital są więc w ustawie, a gabinet stomatologiczny, mała przychodnia i laboratorium z kilkunastoma osobami zatrudnienia są poza nią, choć to właśnie one trzymają dane u dostawców, którzy wyciekli. Podmioty, które spełniały kryteria 3 kwietnia 2026 r., miały złożyć wniosek o wpis do wykazu do 3 października 2026 r., a obowiązki z rozdziału 3 realizują do 3 kwietnia 2027 r. (art. 33 ust. 1 i 3 ustawy nowelizującej). Pełny harmonogram zebrałem w planie do 3 kwietnia 2027 r..

Czego art. 8 wymaga od placówki, która trzyma dokumentację u dostawcy?

Art. 8 ust. 1 ustawy o KSC nakazuje podmiotowi kluczowemu lub ważnemu wdrożyć system zarządzania bezpieczeństwem informacji (SZBI) w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi. W placówce medycznej ten system informacyjny obejmuje, poza serwerami w piwnicy, szpitalny system informacyjny (HIS) lub system gabinetowy, EDM, portal pacjenta z wynikami online, systemy radiologiczne i laboratoryjne, integrację z P1 przez certyfikaty, e-receptę, e-skierowanie, e-ZLA i eWUŚ. Jeśli którykolwiek z nich jest usługą dostawcy, zasady z art. 8 dotyczą go tak samo jak własnej infrastruktury.

Cztery obowiązki z art. 8 mają w ostatnich incydentach gotowe przykłady.

Szacowanie ryzyka (art. 8 ust. 1 pkt 1) ma objąć scenariusz, który właśnie się zmaterializował pięć razy: dostawca traci całą bazę, a placówka dowiaduje się o tym po tygodniach. Medyc wykrył atak dopiero w nocy z 8 na 9 września, dwa tygodnie po eksporcie. IQ Dental zauważyło ślady po czterech dniach i tylko dlatego, że przejrzało systemy po doniesieniach o innych atakach. Jeśli szacowanie ryzyka w placówce kończy się na „dostawca ma certyfikat ISO”, nie obejmuje tego scenariusza.

Łańcuch dostaw (art. 8 ust. 1 pkt 2 lit. e i ust. 2) wymaga uwzględnienia podatności związanych z dostawcą i ogólnej jakości jego produktów. Ministerstwo w pytaniu 3.22 odpowiedzi do ustawy przypomina, że rejestru bezpiecznych dostawców nie ma i podmiot sam szacuje ryzyko związane z dostawcą. Co wpisać do umowy i jak podejść do umów już zawartych, opisałem w tekście o łańcuchu dostaw. Po FELG i IQ Dental dopisałbym trzy pytania do każdego dostawcy EDM: czy API sprawdza uprawnienia do każdego rekordu, a nie tylko do logowania; czy konta administracyjne i serwisowe mają uwierzytelnianie wieloskładnikowe (MFA); w jakim czasie dostawca powiadamia placówkę o naruszeniu. Na pierwsze pytanie odpowiedź „tak” bez wyniku testu bezpieczeństwa nic nie znaczy, i art. 8 ust. 1 pkt 2 lit. b, który wymaga testowania systemu informacyjnego, dotyczy także systemu kupowanego jako usługa.

Plany ciągłości działania (art. 8 ust. 1 pkt 2 lit. f) w ochronie zdrowia mają jedno konkretne pytanie: jak placówka przyjmuje pacjentów, wystawia recepty i sprawdza uprawnienia w eWUŚ, gdy dostawca wyłączy system na czas analizy. FELG utrzymało system dostępny, Qbusoft rotował hasła i sekrety, ale następny dostawca może wyłączyć system na kilka dni. Plan, który nie przewiduje pracy bez EDM przez ten czas, w takiej sytuacji nie pomoże.

Monitorowanie w trybie ciągłym (art. 8 ust. 1 pkt 2 lit. g) obejmuje także to, co placówka widzi po swojej stronie: logowania do portalu pacjenta, nietypowe godziny pracy kont, eksporty. W IQ Dental nieuprawniony dostęp trwał od około 4:00 do około 12:00 w dzień roboczy. Dostęp, który zaczyna się o czwartej rano, to dokładnie ten rodzaj zdarzenia, które monitoring powinien pokazać.

Za to wszystko odpowiada kierownik podmiotu. Art. 8d ustawy o KSC nakazuje mu podejmować decyzje w sprawie SZBI, planować adekwatne środki finansowe, przydzielać zadania z zakresu cyberbezpieczeństwa i nadzorować ich wykonanie oraz zapewnić, że personel zna swoje obowiązki. W szpitalu to dyrektor, w spółce zarząd, w praktyce lekarskiej jej właściciel. Umowa z dostawcą tej odpowiedzialności nie przenosi.

Incydent: dwa zegary i jeden CSIRT sektorowy

Dla sektora ochrony zdrowia organem właściwym do spraw cyberbezpieczeństwa jest minister właściwy do spraw zdrowia (art. 41 pkt 5 ustawy o KSC), a CSIRT sektorowy z art. 44 działa w Centrum e-Zdrowia jako CSIRT CeZ. Podmiot kluczowy lub ważny klasyfikuje incydent jako poważny według progów i zgłasza do CSIRT sektorowego wczesne ostrzeżenie w ciągu 24 godzin od wykrycia, zgłoszenie incydentu w ciągu 72 godzin i sprawozdanie końcowe w ciągu miesiąca od zgłoszenia (art. 11 ust. 1 pkt 3, 4, 4a i 4c). CSIRT CeZ w swojej instrukcji wymienia kanały: system S46, formularz na cez.gov.pl, a gdy formularz nie działa, pocztę incydent@csirt.cez.gov.pl lub telefon. Jak przebiega klasyfikacja i kto w podmiocie o niej decyduje, opisałem w tekście o incydencie poważnym.

Drugi zegar to RODO: administrator zgłasza naruszenie Prezesowi UODO nie później niż w 72 godziny po jego stwierdzeniu (art. 33 ust. 1), a podmiot przetwarzający zgłasza je administratorowi bez zbędnej zwłoki (art. 33 ust. 2). Oba zegary biegną niezależnie i obsługuje je zwykle kto inny: IOD pilnuje pierwszego, osoba odpowiedzialna za cyberbezpieczeństwo drugiego. W procedurze obsługi incydentu zapisałbym oba z nazwiskami.

Z ostatnich miesięcy wynika, że placówki o CSIRT CeZ zapominają. Minister Gawkowski, cytowany przez Zaufaną Trzecią Stronę, wskazał, że ofiara ataku na Medyc zgłosiła go do CBZC, ale nie przekazała informacji ani do CSIRT CeZ, ani do CERT Polska. Enel-Med z kolei powiadomił CBZC, CSIRT w Centrum e-Zdrowia, Prezesa UODO i CERT Polska naraz. Ten drugi wzór wpisałbym do procedury, niezależnie od tego, czy placówka jest w wykazie: CSIRT CeZ przyjmuje także zgłoszenia o potencjalnych zdarzeniach (art. 44 ust. 1 pkt 2), a jego pomoc jest bezpłatna.

Z raportu rocznego CSIRT CeZ wynika, że w 2025 r. w sektorze zdrowia odnotowano 1441 incydentów bezpieczeństwa, w tym 5 incydentów poważnych i 8 ataków ransomware, o ponad 60 % więcej niż rok wcześniej. Najczęstszą przyczyną był phishing: kampanie podszywające się pod NFZ, Medfile, RPWDL, gabinet.gov.pl, eZUS i usługi CeZ, z wiadomościami o rzekomej utracie możliwości wystawiania e-recept i fałszywymi panelami logowania do systemów EDM. Trzy główne wektory, które zespół wymienia, to oszustwa komputerowe, podatne usługi i wycieki poświadczeń. Dwa z nich, podatne usługi i wycieki poświadczeń, wracają w tegorocznych incydentach.

Małe laboratorium i wyniki online: poza ustawą, w środku ryzyka

Z mojego doświadczenia wynika, że niewielkie firmy diagnostyczne, które udostępniają wyniki badań online, inwestowały w cyberbezpieczeństwo w stopniu nieproporcjonalnym do danych, które trzymają. Portal z wynikami to publicznie dostępna aplikacja, w której po zalogowaniu pacjent widzi swoje wyniki, a lekarz wyniki swoich pacjentów. Błąd uprawnień w takim portalu działa dokładnie jak w FELG Dent: kto umie zmienić numer w adresie, czyta cudze wyniki. Taka firma rzadko spełnia wymogi średniego przedsiębiorcy, więc ustawa o KSC jej wprost nie obejmuje. Obejmuje ją natomiast RODO, a jeśli pracuje jako podwykonawca szpitala, który jest podmiotem kluczowym, to ten szpital ma ją ująć w swoim łańcuchu dostaw.

Pełnomocnik Rządu do Spraw Cyberbezpieczeństwa opublikował 23 marca 2026 r. komunikat z zaleceniami dla podmiotów KSC ze szczególnym uwzględnieniem sektora ochrony zdrowia, po serii ataków jednej grupy na placówki. To komunikat, nie rekomendacja z numerem, i jego zalecenia nie są obowiązkiem z ustawy, ale czytam go jako listę tego, co atakujący sprawdzają najpierw. Dla usług publikowanych, w tym telemedycyny i portali pacjenta, komunikat zaleca monitorowanie logów, wykrywanie i blokowanie ataków brute force, możliwość wdrożenia aktualizacji w 24 godziny od wykrycia krytycznej podatności i maksymalną izolację od systemów wewnętrznych. Dla dostępu zdalnego: brak RDP wystawionego do sieci publicznej, MFA dla wszystkich połączeń VPN i RDP. Dla kopii zapasowych: osobny segment sieci, konta niedomenowe, kopie w trybie WORM z ustaloną retencją. Dla dostawców zewnętrznych: uprawnienia czasowe, tylko do niezbędnych zasobów, z regularną weryfikacją kont serwisowych.

Gdybym miał w takim laboratorium jeden dzień i mały budżet, zrobiłbym trzy rzeczy. Test uprawnień w portalu wyników, ręczny albo zlecony, z pytaniem „czy zalogowany użytkownik może odczytać wynik, który nie jest jego”. MFA na każdym koncie administracyjnym i serwisowym, także u dostawcy hostingu. Spis danych z datami: jak daleko wstecz sięgają wyniki w portalu i czy ktokolwiek je kiedykolwiek usunął. Po MyDr wiadomo, że dane sprzed dwóch lat wyciekają tak samo jak wczorajsze.

Co sprawdziłbym w placówce w tym tygodniu?

1. Status w ustawie o KSC: podmiot leczniczy, wielkość przedsiębiorcy albo liczba zatrudnionych, podwykonawstwo dla podmiotu kluczowego. Jeśli wniosek o wpis do wykazu powinien był pójść do 3 października 2026 r., a nie poszedł, to pierwsza decyzja kierownika.
2. Lista dostawców, u których leżą dane pacjentów: EDM, system gabinetowy, portal pacjenta, laboratorium, radiologia, hosting, poczta. Przy każdym: czy jest umowa powierzenia z art. 28 ust. 3 RODO, czy zobowiązuje dostawcę do pomocy przy obowiązkach z art. 32 do 36 (lit. f) i do poddania się audytowi (lit. h), i w jakim terminie dostawca ma zgłosić naruszenie.
3. Pytanie do każdego dostawcy EDM, zadane na piśmie: kiedy ostatnio testował API pod kątem uprawnień do rekordów, czy konta administracyjne mają MFA, jaką retencję stosuje dla danych zakończonych umów.
4. Procedura incydentu z dwoma zegarami i czterema adresatami: CSIRT CeZ, właściwy CSIRT poziomu krajowego, Prezes UODO, CBZC. Z nazwiskami i numerami, przetestowana na sucho.
5. Tryb pracy bez EDM przez trzy dni: rejestracja, recepty, eWUŚ, wyniki. Spisany, a nie zakładany.
6. Przegląd kont u dostawców i w portalach: byli pracownicy, konta demo i testowe, konta serwisowe firm zewnętrznych. Po FELG konto demo z dostępem do danych produkcyjnych powinno być pierwszym pytaniem.

Żadna z tych pozycji nie wymaga nowego sprzętu. Wymaga za to decyzji kierownika, że dane pacjentów u dostawcy są jego ryzykiem. Tak stawia to art. 8 ustawy o KSC i tak samo w sprawie MyDr postawił to Prezes UODO.

Pojęcia w tym tekście (28)

Ustawa o KSC

Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych.

Zarządzanie ryzykiem

To, co podmiot robi z oszacowanym ryzykiem: dobiera zabezpieczenia, a ryzyko, którego nie ogranicza, akceptuje świadomie.

Łańcuch dostaw

Dostawcy sprzętu, oprogramowania i usług ICT, od których zależy świadczenie usługi. Ich bezpieczeństwo podmiot uwzględnia w swoim zarządzaniu ryzykiem.

Incydent

Zdarzenie, które szkodzi albo może zaszkodzić bezpieczeństwu systemów informacyjnych. Zgłaszać trzeba nie każdy incydent, tylko incydent poważny.

Kierownik podmiotu

Osoba albo organ kierujący podmiotem kluczowym lub ważnym, na przykład zarząd spółki. Odpowiada za cyberbezpieczeństwo podmiotu także wtedy, gdy zadania powierzył innej osobie.

Inspektor ochrony danych

Osoba wyznaczona przez administratora lub podmiot przetwarzający do zadań z RODO. Tutaj pojawia się przy incydentach z danymi osobowymi i przy łączeniu tej funkcji z rolą pełnomocnika.

Elektroniczna dokumentacja medyczna

Dokumentacja pacjenta prowadzona w postaci elektronicznej: recepty, skierowania, karty i wyniki, zwykle w systemie dostawcy, który obsługuje wiele placówek naraz. Stąd skala wycieków u takich dostawców.

Centralne Biuro Zwalczania Cyberprzestępczości

Jednostka Policji powołana do zwalczania cyberprzestępczości. W aktualnościach pojawia się jako adresat zawiadomień o włamaniach i wyciekach, obok CSIRT i Prezesa UODO.

SQL injection

Podatność, która pozwala wstrzyknąć do bazy danych własne zapytania, w opisanym przypadku bez uwierzytelnienia.

IDOR

Podatność aplikacji, która nie sprawdza, czy użytkownik ma prawo do wskazanego obiektu. Po zmianie identyfikatora w adresie lub parametrze atakujący dostaje cudze dane.

RODO

Rozporządzenie (UE) 2016/679 o ochronie danych osobowych. Tematy RODO omawiam na pawel.rosol.pl; tutaj pojawia się przy incydentach, które są też naruszeniem ochrony danych.

Podatność

Słabość produktu lub usługi ICT, którą można wykorzystać do ataku. Znane podatności dostają identyfikatory CVE, a te wykorzystywane w atakach trafiają do katalogu KEV.

Urząd Ochrony Danych Osobowych

Urząd obsługujący Prezesa UODO, który jest organem nadzorczym w rozumieniu RODO. Tutaj pojawia się przy incydentach, które są też naruszeniem ochrony danych osobowych.

Szacowanie ryzyka

Proces, w którym podmiot ustala, co może zagrozić jego systemom, jak bardzo jest to prawdopodobne i jakie byłyby skutki. W praktyce mówi się też „analiza ryzyka”.

Wykaz podmiotów kluczowych i ważnych

Rejestr podmiotów kluczowych i ważnych prowadzony w systemie S46. Służy ich identyfikacji, wymianie informacji o incydentach i nadzorowi.

System S46

System teleinformatyczny ministra właściwego do spraw informatyzacji, przez który zgłasza się incydenty i prowadzi wykaz podmiotów. Nazwa S46 jest potoczna, od numeru artykułu.

Podmiot kluczowy

Podmiot z sektorów ustawy o KSC, który ze względu na wielkość albo rodzaj działalności ma najszersze obowiązki, w tym audyt bezpieczeństwa co najmniej raz na trzy lata.

Podmiot ważny

Podmiot z sektorów ustawy o KSC, który spełnia jej kryteria, ale nie jest podmiotem kluczowym. Wdraża SZBI i zgłasza incydenty poważne tak jak podmiot kluczowy.

System zarządzania bezpieczeństwem informacji

Uporządkowany sposób, w jaki podmiot kluczowy lub ważny zarządza bezpieczeństwem systemu używanego do świadczenia usługi, od szacowania ryzyka po obsługę incydentów.

Uwierzytelnianie wieloskładnikowe

Logowanie, które wymaga więcej niż jednego składnika, na przykład hasła i kodu z aplikacji. Ustawa o KSC wymienia je wśród środków bezpieczeństwa.

Ciągłość działania

Zdolność podmiotu do świadczenia usługi mimo awarii albo ataku. Ustawa wymaga planów ciągłości działania, które są dokumentowane, testowane i utrzymywane.

CSIRT sektorowy

Zespół reagowania na incydenty dla jednego sektora lub podsektora, ustanowiony przez organ właściwy. To do niego podmiot kluczowy lub ważny zgłasza incydent poważny.

CSIRT

Zespół reagowania na incydenty bezpieczeństwa komputerowego. Na poziomie krajowym działają trzy: CSIRT GOV (Szef ABW), CSIRT MON (Minister Obrony Narodowej) i CSIRT NASK (NASK-PIB).

Wczesne ostrzeżenie

Pierwsze zgłoszenie incydentu poważnego do CSIRT sektorowego, niezwłocznie i najpóźniej w ciągu 24 godzin od wykrycia. Pełne zgłoszenie idzie w ciągu 72 godzin.

CERT Polska

Zespół reagowania na incydenty prowadzony przez NASK, źródło ostrzeżeń i analiz, które cytuję w aktualnościach. Ustawa tej nazwy nie zna; ustawowym zespołem jest CSIRT NASK.

Incydent poważny

Incydent, który poważnie zakłóca usługę, przynosi podmiotowi straty finansowe albo wyrządza poważną szkodę innym. Podmiot kluczowy lub ważny zgłasza go do CSIRT sektorowego.

Ransomware

Złośliwe oprogramowanie, które szyfruje dane i żąda okupu za ich odszyfrowanie. Coraz częściej sprawcy także wykradają dane i grożą ich upublicznieniem.

Wirtualna sieć prywatna

Virtual Private Network: szyfrowany tunel, którym pracownik albo oddział łączy się z siecią firmy przez internet. Brama VPN wystawiona do internetu to częsty cel ataków.

Najczęściej zadawane pytania

Czy prywatna przychodnia albo laboratorium podlega ustawie o KSC?

Podmiot leczniczy w rozumieniu art. 4 ust. 1 ustawy o działalności leczniczej jest wymieniony w załączniku nr 1 do ustawy o KSC, ale status zależy od wielkości. Przedsiębiorca, który spełnia wymogi średniego przedsiębiorcy z załącznika I do rozporządzenia 651/2014/UE, jest podmiotem ważnym (art. 5 ust. 2 pkt 1 ustawy o KSC), a ten, który je przewyższa, podmiotem kluczowym (art. 5 ust. 1 pkt 1 ustawy o KSC). Mikro- i mały przedsiębiorca jest poza ustawą, chyba że organ właściwy uzna go za podmiot kluczowy lub ważny decyzją z art. 7l ustawy o KSC.

Czy dostawca oprogramowania gabinetowego lub EDM jest podmiotem kluczowym?

Nie z samego faktu, że obsługuje placówki. Ministerstwo Cyfryzacji odpowiedziało w sprawie MyDr, że spółka nie dokonała samoidentyfikacji jako podmiot KSC, nie była wpisana do wykazu i nie wydano wobec niej decyzji z art. 7l. Ministerstwo wskazało zarazem, że taki dostawca powinien podlegać wymaganiom łańcucha dostaw swoich klientów, bo art. 8 ust. 1 pkt 2 lit. e ustawy o KSC nakazuje podmiotowi kluczowemu lub ważnemu zapewnić bezpieczeństwo i ciągłość łańcucha dostaw produktów, usług i procesów ICT.

Komu i w jakim terminie placówka zgłasza incydent poważny?

Wczesne ostrzeżenie trafia do właściwego CSIRT sektorowego nie później niż w ciągu 24 godzin od wykrycia, zgłoszenie incydentu w ciągu 72 godzin, a sprawozdanie końcowe w ciągu miesiąca od zgłoszenia (art. 11 ust. 1 pkt 4, 4a i 4c ustawy o KSC). Dla sektora ochrony zdrowia organem właściwym jest minister właściwy do spraw zdrowia (art. 41 pkt 5), a CSIRT sektorowy działa w Centrum e-Zdrowia jako CSIRT CeZ. Zgłoszenie naruszenia do Prezesa UODO z art. 33 ust. 1 RODO biegnie osobno, w 72 godziny od stwierdzenia naruszenia przez administratora.

Dostawca prosi, żeby nie zgłaszać naruszenia do UODO, dopóki nie potwierdzi, że dotyczy mojej placówki. Co robić?

Termin 72 godzin z art. 33 ust. 1 RODO biegnie od stwierdzenia naruszenia przez administratora, a prośba dostawcy tego terminu nie zmienia. Podmiot przetwarzający ma obowiązek zgłosić naruszenie administratorowi bez zbędnej zwłoki (art. 33 ust. 2). Zapisałbym zdarzenie w dokumentacji naruszeń z art. 33 ust. 5 razem z powodem, dla którego jeszcze nie zgłaszam, i zażądał od dostawcy potwierdzenia na piśmie w konkretnym terminie.

Źródła

1. Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa, tekst jednolity Dz.U. 2026 poz. 20, ze zmianami
2. Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, Dz.U. 2026 poz. 252
3. Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), art. 9, 28, 32 i 33
4. Ministerstwo Cyfryzacji, odpowiedź na interpelację nr 19211 w sprawie cyberataku na systemy firmy MyDr (8 września 2026 r.)
5. Ministerstwo Cyfryzacji, odpowiedź na interpelację nr 19215 w sprawie cyberataku i wycieku danych zdrowotnych (7 września 2026 r.)
6. Prokuratura Okręgowa w Warszawie, komunikat o dochodzeniu w sprawie danych z systemu MyDr (13 sierpnia 2026 r.)
7. UODO, Wyciek danych - co dalej? (12 sierpnia 2026 r.)
8. UODO, Prezes UODO skontroluje spółkę MyDr (13 sierpnia 2026 r.)
9. Centrum e-Zdrowia, Działania prewencyjne po incydencie dotyczącym firmy MyDr (14 sierpnia 2026 r.)
10. NFZ za Centrum e-Zdrowia, Informacja w związku z incydentem dotyczącym firmy MyDr (12 sierpnia 2026 r.)
11. CBZC, Komunikat dot. wycieku danych pacjentów z systemu informatycznego (18 sierpnia 2026 r.)
12. CSIRT CeZ, Raport roczny 2025 (czerwiec 2026 r.)
13. CSIRT CeZ, Sposoby zgłaszania incydentów bezpieczeństwa (maj 2025 r.)
14. Komunikat Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa z zaleceniami dla podmiotów KSC, ze szczególnym uwzględnieniem sektora ochrony zdrowia (23 marca 2026 r.)
15. Ministerstwo Cyfryzacji, pytania i odpowiedzi do ustawy o KSC, pkt 3.22 i 3.23 (aktualizacja z czerwca 2026 r.)

Stan prawny sprawdzony: 20.10.2026. Wpis jest informacją ogólną, nie poradą prawną (zasady publikacji).

Powiązane artykuły

• 19.10.202615 min czytania

  Plan do 3 kwietnia 2027 r. dla zarządu. Co wynika z rekomendacji Pełnomocnika rządu ds. cyberbezpieczeństwa?

  Rekomendacja 2026-67a-9 to katalog środków. Które z nich są obowiązkiem z ustawy o KSC, co musi istnieć 3 kwietnia 2027 r. i jak ułożyć pięć miesięcy pracy?

• 14.10.202612 min czytania

  Szkoła w ustawie o KSC. Co musi zrobić dyrektor i jak ująć e-dziennik i Classroom w SZBI?

  Publiczna szkoła samorządowa jest podmiotem ważnym. Co z tego wynika dla dyrektora do 3 kwietnia 2027 r. i co zrobić z e-dziennikiem i platformą w chmurze.

• 09.10.20267 min czytania

  Których dostawców wpisać do wykazu KSC jako dostawcę usług zarządzanych w zakresie cyberbezpieczeństwa?

  Dostawcę w wykazie KSC wpisuje się tylko przy umowie na zadania z art. 8 lub art. 11. Helpdesk, serwerownia, pentest, audyt, kancelaria, spółka z grupy: kogo?