Jest taki rodzaj awarii, którego szpital nie zawinił i któremu nie mógł zapobiec, a mimo to za niego odpowiada. Najsłabsze ogniwo bywa u kogoś, czyjego nazwiska zarząd nie potrafiłby wymienić — a od kogo zależy, czy izba przyjęć widzi historię choroby pacjenta. Jedenastego września próg europejski został przekroczony. Trzeciego października mija polski.
Poranek, którego szpital nie zawinił
Oddział przyjmuje pacjentów jak zwykle, personel loguje się do systemu jak co dnia, serwerownia pracuje bez zarzutu — a mimo to o poranku okazuje się, że zdjęcia z tomografu nie wczytują się do systemu, że wyniki z laboratorium nie spływają, że apteka nie widzi stanów magazynowych. Powód leży poza murem: dostawca oprogramowania, z którego korzysta pół kraju, w nocy padł ofiarą włamania i wyłączył swoje usługi, żeby ograniczyć szkody. Nikt w tym szpitalu nie kliknął w załącznik, nikt nie zgubił hasła, nikt nie zlekceważył procedury. Najsłabsze ogniwo było gdzie indziej.
Ta scena nie jest hipotezą. W marcu 2026 roku działająca globalnie firma Stryker — dostawca sprzętu, technologii i usług dla szpitali — została sparaliżowana atakiem cybernetycznym. Spółka poinformowała o incydencie 11 marca 2026 roku, wskazując, że dotknięte zostało jej środowisko Microsoft, i deklarując, że nie stwierdzono ani oprogramowania szyfrującego, ani złośliwego kodu.1 Amerykańskie Stowarzyszenie Szpitali odnotowało wówczas nie tyle bezpośrednie zakłócenie pracy placówek, ile coś groźniejszego w wymowie: konieczność sprawdzenia przez szpitale, które z ich usług, technologii i elementów łańcucha dostaw są powiązane z zaatakowanym dostawcą, bo dopiero od tego zależał realny wpływ zdarzenia na opiekę.1 Dziewięć dni później amerykańska agencja CISA wydała zalecenia utwardzenia systemów zarządzania punktami końcowymi — narzędzi, które z definicji mają uprawnienia do zdalnej zmiany stanu każdego komputera w organizacji, a więc i do jego zdalnego wymazania.2 To jest właściwa miara zagrożenia: nie „ktoś włamał się do szpitala”, lecz „ktoś przejął narzędzie, któremu szpital z góry ufa”.
Dwa lata wcześniej, w lutym 2024 roku, atak ransomware na amerykański podmiot Change Healthcare — pośrednika rozliczeniowego, przez którego przechodziła znaczna część transakcji między świadczeniodawcami a płatnikami — pokazał pełną skalę zjawiska. Napastnicy weszli do sieci przez serwer zdalnego dostępu Citrix pozbawiony uwierzytelniania wieloskładnikowego, posługując się wykradzionymi danymi logowania pracownika wsparcia; dostęp uzyskali między 12 a 20 lutego, wykrycie nastąpiło 21 lutego.3 Ostateczny bilans to około 192,7 miliona osób, których dane zostały naruszone — największe naruszenie danych zdrowotnych w historii Stanów Zjednoczonych — okup w wysokości 22 milionów dolarów, który zapłacono i po którym przestępcy i tak danych nie usunęli, oraz łączne skutki finansowe ataku szacowane w raporcie rocznym UnitedHealth na około 3,09 miliarda dolarów w samym 2024 roku, z czego mniej więcej 2,2 miliarda to bezpośrednie koszty reakcji.3 Nie padł wtedy żaden szpital z osobna. Padło ogniwo, na którym wisiały tysiące szpitali naraz.
To jest właściwy przedmiot tego tekstu, kolejnego z serii o nośności systemu ochrony zdrowia. Nośność — zdolność systemu do przyjęcia obciążenia bez utraty funkcji — bywa mierzona liczbą łóżek, liczbą lekarzy, wielkością budżetu. Istnieje jednak warstwa nośności, której nie widać w żadnym z tych wskaźników, bo znajduje się poza murem szpitala: w oprogramowaniu, które ktoś inny napisał, w chmurze, którą ktoś inny utrzymuje, w zdalnym serwisie, do którego ktoś inny ma klucze. Dźwignią, o którą chodzi w tej odsłonie, jest odporność — a odporność systemu ochrony zdrowia jest dziś w co najmniej równym stopniu odpornością jego dostawców, co jego własną. Opisywaliśmy w tej serii, jak ransomware odejmuje szpitalowi nośność, co NIS2 zmienia w odpowiedzialności zarządu i dlaczego wspólna osłona jest jedyną realistyczną osłoną. Ten tekst domyka te wątki od strony, która dotąd pozostawała otwarta: od strony podmiotu, który nie jest szpitalem, a bez którego szpital nie działa.
Pomiar: z czego naprawdę jest zbudowany szpital cyfrowy
Zacznijmy od uczciwego rachunku, bo bez pomiaru nie ma decyzji. Współczesny szpital nie jest już budynkiem z serwerownią w piwnicy. Jest węzłem w gęstej sieci zależności. System informacji szpitalnej prowadzi ruch pacjenta, zlecenia i rozliczenia. Systemy obrazowe przechowują i udostępniają badania. System laboratoryjny łączy analizatory z dokumentacją. Nad tym wszystkim rozpościera się chmura, w której coraz częściej leżą kopie zapasowe, moduły analityczne i usługi sztucznej inteligencji. Do tego dochodzi oprogramowanie wbudowane w wyroby medyczne — od tomografu po pompę infuzyjną — oraz cała warstwa integratorów i firm serwisowych mających zdalny dostęp do tych urządzeń, żeby je aktualizować i naprawiać. Każde z tych ogniw jest osobnym podmiotem, z osobnym poziomem dojrzałości, osobną kulturą bezpieczeństwa i osobnym łańcuchem własnych poddostawców. Szpital, który myśli o sobie jak o twierdzy, myli się co do własnej geografii.
Rozróżnienie warstw nie jest ćwiczeniem taksonomicznym. Ma konsekwencję ustrojową: w warstwach od trzeciej w dół szpital nie dysponuje żadnym narzędziem technicznym, którym mógłby wymusić poprawę. Nie może załatać cudzego kodu, nie może zmienić cudzej architektury, nie może nakazać cudzemu poddostawcy wdrożenia uwierzytelniania wieloskładnikowego. Dysponuje wyłącznie umową — a umowa działa tylko wtedy, gdy ktoś ją napisał tak, by działała, i gdy ktoś potrafi jej dotrzymania dochodzić. W tym sensie cyberbezpieczeństwo łańcucha dostaw jest w ochronie zdrowia dziedziną prawa zamówień publicznych w co najmniej takim samym stopniu, w jakim jest dziedziną informatyki.
Cztery liczby i jedna luka w wiedzy
Dane, którymi dysponujemy, są jednoznaczne co do kierunku, choć — jak zawsze w cyberbezpieczeństwie — niepełne co do skali, bo znaczna część incydentów nigdy nie zostaje ujawniona. Pierwsza i, co trzeba powiedzieć wprost, dotąd jedyna całościowa analiza krajobrazu zagrożeń dla sektora zdrowia w Unii Europejskiej została opublikowana przez Agencję Unii Europejskiej do spraw Cyberbezpieczeństwa (ENISA) 5 lipca 2023 roku i obejmowała 215 publicznie zgłoszonych incydentów ze stycznia 2021 – marca 2023. Ransomware odpowiadał w niej za 54 procent incydentów, świadczeniodawcy stanowili 53 procent celów, a same szpitale — 42 procent; najczęściej atakowanym zasobem były dane pacjentów (30 procent), a niemal połowa zdarzeń (46 procent) zmierzała do kradzieży lub wycieku danych.4
Dla naszej sprawy najważniejsze są jednak dwie liczby z tego samego raportu. Pierwsza: ataki na łańcuchy dostaw ochrony zdrowia i na dostawców usług przełożyły się na zakłócenia lub straty organizacji zdrowotnych w 7 procentach przypadków — pozornie niewiele, dopóki nie uświadomimy sobie, że jedno takie ogniwo obsługuje dziesiątki albo setki placówek, więc siedem procent zdarzeń przekłada się na nieproporcjonalnie duży udział w realnym cierpieniu. Druga, jeszcze wymowniejsza: 80 procent ankietowanych organizacji ochrony zdrowia wskazało podatności w oprogramowaniu lub sprzęcie jako przyczynę ponad 61 procent swoich incydentów bezpieczeństwa.4 Innymi słowy — problem nie tkwi głównie w nieostrożnym pracowniku, wbrew popularnej narracji. Tkwi w wadliwych, nieaktualizowanych, źle utrzymanych produktach cyfrowych, które ktoś dostarczył, a ktoś inny wpiął do sieci, w której leży życie ludzi. Medianę kosztu poważnego incydentu w ochronie zdrowia ENISA oszacowała na 300 tysięcy euro — a to tylko koszt policzalny, bez kosztu odroczonego badania, przełożonego zabiegu, utraconego zaufania.4
Trzeba jednak od razu dodać zastrzeżenie, którego nie powinno zabraknąć w żadnym uczciwym opracowaniu: dane sektorowe ENISA mają dziś ponad trzy lata i nie doczekały się aktualizacji. Nowszy, przekrojowy raport ENISA Threat Landscape 2025 przypisuje sektorowi zdrowia 4,2 procent incydentów cyberprzestępczych i nie umieszcza go w pierwszej piątce najczęściej atakowanych sektorów, natomiast ryzykom łańcucha dostaw przyznaje 10,6 procent wszystkich zidentyfikowanych kategorii zagrożeń.5 Zestawienie tych dwóch obrazów prowadzi do wniosku, który jest sednem tego tekstu: udział sektora zdrowia w statystyce ataków maleje, a udział łańcucha dostaw w statystyce ryzyk rośnie. Jeżeli więc szpital chce wiedzieć, gdzie dziś pęka, powinien patrzeć nie na siebie, lecz na tych, od których zależy.
Uzależnienie od dostawcy jako ryzyko nośności
Do tego obrazu trzeba dołożyć problem, o którym w Polsce mówi się zbyt cicho: koncentrację i uzależnienie od dostawcy. Rynek szpitalnych systemów informatycznych nie jest rynkiem dziesiątek równorzędnych graczy; to rynek kilku dominujących platform, w których szpital, raz osadzony, tkwi latami, bo migracja danych, integracji i przyzwyczajeń personelu jest kosztowna, ryzykowna i czasochłonna. Zależność ta ma dwie twarze. Pierwsza jest ekonomiczna: brak realnej możliwości zmiany dostawcy osłabia pozycję negocjacyjną szpitala i spowalnia modernizację. Druga jest systemowa i groźniejsza: jeżeli ten sam produkt, ta sama chmura, ten sam moduł działa w wielu placówkach jednocześnie, to jego pojedyncza podatność staje się podatnością całego regionu. Uzależnienie od dostawcy przestaje być kłopotem zakupowym, a staje się pojedynczym punktem awarii wpisanym w architekturę systemu ochrony zdrowia. Pisałem o tym w tej serii przy okazji interoperacyjności i certyfikacji dokumentacji elektronicznej — tam problem nazywa się „brak wspólnego języka”, tu nazywa się „brak wyjścia”. To dwie strony tej samej monety.
To jest dokładnie to samo zjawisko, które europejska debata rozpoznała już w świecie leków. Nowoczesne łańcuchy dostaw są znacznie bardziej kruche, niż zakładały systemy zdrowia zaprojektowane w innej epoce, a model optymalizowany pod kątem efektywności, a nie odporności — „na czas”, bez zapasu — potrafi sprawić, że lek albo usługa znika z półki nie dlatego, że brak popytu, lecz dlatego, że jedno wąskie ogniwo zawiodło. Skalę zależności dobrze ilustruje często przywoływany szacunek, wedle którego około 80 procent wolumenu substancji czynnych importowanych do Unii pochodzi z pięciu krajów, przy czym na same Chiny przypada około 45 procent.6 Liczba ta wymaga jednak ostrożnej atrybucji: pochodzi z opracowania Institut Jacques Delors powołującego się na dialog strukturalny Komisji z lat 2021–2022, nie zaś z bieżącego dokumentu Komisji, i dziś może wyglądać inaczej. To, co dotyczy insuliny i antybiotyku, dotyczy jednak równie ściśle systemu, który wypisuje na nie receptę — z jedną różnicą na niekorzyść cyfry: zapas leku da się utworzyć, zapasu cudzego oprogramowania nie.
Zapas leku da się utworzyć. Zapasu cudzego oprogramowania — nie. Jedyną rezerwą, jaką szpital może zbudować wobec swojego dostawcy, jest zdolność działania bez niego.
Michał P. Dybowski, „Najsłabsze ogniwo jest u kogoś innego”
Decyzja: Europa przestawia zamówienie z ceny na odporność
Dobra wiadomość jest taka, że pomiar przełożył się wreszcie na decyzje regulacyjne — i to decyzje, których zegar właśnie tyka. Fundamentem jest dyrektywa NIS2, czyli dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555, która po raz pierwszy w prawie unijnym uczyniła z bezpieczeństwa łańcucha dostaw wprost sformułowany obowiązek podmiotów kluczowych i ważnych, a ochronę zdrowia zaliczyła do sektorów krytycznych. Artykuł 21 ustęp 2 litera d nakazuje zapewnić bezpieczeństwo łańcucha dostaw, w tym aspekty relacji między podmiotem a jego bezpośrednimi dostawcami i usługodawcami; artykuł 21 ustęp 3 dopowiada, że podmiot ma uwzględnić podatności każdego bezpośredniego dostawcy oraz ogólną jakość jego produktów i praktyk cyberbezpieczeństwa, w tym bezpieczne procedury rozwoju oprogramowania.7 To ostatnie sformułowanie jest cichym mostem między dwoma aktami: bezpieczne procedury rozwoju to dokładnie ten przedmiot, który reguluje akt o cyberodporności.
Trzeba przy tym zachować precyzję, której publicystyka zwykle nie zachowuje. Po pierwsze, kary — do 10 milionów euro lub 2 procent światowego obrotu dla podmiotów kluczowych oraz do 7 milionów euro lub 1,4 procent dla ważnych — są w dyrektywie określone jako maksima o wartości „co najmniej” takiej, a więc stanowią próg minimalny dla ustawodawcy krajowego, który może pójść wyżej, i dotyczą naruszeń artykułów 21 lub 23, nie każdego przepisu.7 Po drugie, czasowy zakaz pełnienia funkcji zarządczych, chętnie cytowany jako straszak, wynika z artykułu 32 ustęp 5 litera b, dotyczy wyłącznie podmiotów kluczowych, jest środkiem ostatecznym stosowanym dopiero po bezskuteczności innych środków i nie ma zastosowania do podmiotów administracji publicznej.7 Odpowiedzialność organów zarządzających jest natomiast realna i bezwarunkowa: artykuł 20 ustęp 1 czyni je odpowiedzialnymi za zatwierdzenie i nadzór nad środkami zarządzania ryzykiem, a ustęp 2 nakłada na ich członków obowiązek szkolenia.
Po trzecie wreszcie — i to jest obserwacja, którą warto zapamiętać, bo dotyczy ona także Polski — transpozycja idzie wolniej, niż wymagało prawo. Termin upłynął 17 października 2024 roku, a 8 lipca 2026 roku Komisja skierowała do Trybunału Sprawiedliwości sprawy przeciwko Irlandii, Hiszpanii, Francji i Niderlandom, wskazując, że większość państw zgłosiła pełną transpozycję, tych czterech zaś nie.8 Niderlandy uzupełniły zaległość wkrótce potem: tamtejsza ustawa o cyberbezpieczeństwie weszła w życie 15 sierpnia 2026 roku.9 Oznacza to, że we wrześniu 2026 roku wciąż trzy państwa członkowskie — Hiszpania, Francja i Irlandia — nie mają w pełni wdrożonego reżimu, który w zamyśle miał chronić wspólny rynek zdrowia. Dla szpitala, którego dostawca ma siedzibę w jednym z tych państw, jest to informacja operacyjna, nie ciekawostka.
Próg przekroczony: co się stało 11 września
Aktem, który wyznaczył najbliższą twardą datę — i który właśnie ją minął — jest akt o cyberodporności, czyli rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847, znane jako Cyber Resilience Act. Weszło w życie 10 grudnia 2024 roku i po raz pierwszy w Unii nałożyło poziome wymogi cyberbezpieczeństwa na wszystkie „produkty z elementami cyfrowymi”: od zasady projektowania bezpiecznego i domyślnej konfiguracji bezpiecznej, przez obowiązek sporządzenia i utrzymywania wykazu komponentów oprogramowania w powszechnie używanym formacie nadającym się do odczytu maszynowego — obejmującego co najmniej zależności najwyższego poziomu — po zapewnienie okresu wsparcia wynoszącego co najmniej pięć lat, a dłuższego tam, gdzie produkt jest racjonalnie przewidziany do dłuższego użytkowania.10
Kluczowa jest data 11 września 2026 roku. Od tego dnia stosuje się artykuł 14 rozporządzenia, nakładający obowiązek zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów. Na mocy artykułu 69 ustęp 3 obowiązek ten obejmuje wszystkie objęte rozporządzeniem produkty wprowadzone do obrotu przed 11 grudnia 2027 roku — a więc także te, które już dziś pracują w szpitalnych sieciach.10 Terminy są dwutorowe: dla aktywnie wykorzystywanej podatności — wczesne ostrzeżenie w 24 godziny, zgłoszenie w 72 godziny i raport końcowy w 14 dni od udostępnienia środka naprawczego; dla poważnego incydentu — 24 godziny, 72 godziny i raport końcowy w miesiąc od zgłoszenia siedemdziesięciodwugodzinnego. Zgłoszenie trafia jednocześnie do zespołu CSIRT wyznaczonego jako koordynator i do ENISA, za pośrednictwem jednolitej platformy zgłoszeniowej uruchomionej właśnie 11 września 2026 roku.1011
Dwa zastrzeżenia, bez których obraz byłby nieuczciwy. Po pierwsze, wysokie kary przewidziane w akcie — do 15 milionów euro lub 2,5 procent światowego obrotu za naruszenie wymogów załącznika I oraz artykułów 13 i 14 — nie są jeszcze egzekwowalne, ponieważ przepisy o nadzorze rynku i sankcjach stosuje się dopiero od 11 grudnia 2027 roku.10 Obowiązek raportowy istnieje od 11 września 2026, sankcja administracyjna za jego naruszenie — jeszcze nie. Po drugie, mikro- i małe przedsiębiorstwa nie podlegają karom za uchybienie części terminów z artykułu 14, a opiekunowie oprogramowania otwartego nie podlegają karom administracyjnym w ogóle. Kto z tej asymetrii wyciąga wniosek, że można poczekać, myli obowiązek z ryzykiem. Szpital, który dziś nie ma kanału odbioru zgłoszeń od dostawców, nie dostanie kary — dostanie informację o podatności wtedy, gdy będzie już za późno, żeby cokolwiek z nią zrobić.
Wyłączenie, które nie jest osłoną: wyrób medyczny wobec CRA
W dyskusjach branżowych powtarza się uspokajające zdanie: wyroby medyczne są z aktu o cyberodporności wyłączone, więc producentów sprzętu medycznego to nie dotyczy. Zdanie jest prawdziwe w pierwszej połowie i mylące w drugiej. Artykuł 2 ustęp 2 rozporządzenia stanowi, że nie stosuje się go do produktów z elementami cyfrowymi, do których stosuje się rozporządzenia (UE) 2017/745 (MDR), (UE) 2017/746 (IVDR) oraz (UE) 2019/2144; wyłączenie jest przy tym pełne, a nie ograniczone do wymogów produktowych, i obejmuje także obowiązek zgłoszeniowy z artykułu 14.10 Wyroby medyczne mają własny reżim cyberbezpieczeństwa, osadzony w MDR i w wytycznych MDCG, o czym pisałem przy okazji reformy MDR i IVDR.
Rzecz w tym, że wyłączony jest wyrób, a nie jego wnętrze. Artykuł 3 punkt 1 rozporządzenia definiuje produkt z elementami cyfrowymi jako produkt programowy lub sprzętowy wraz z rozwiązaniami zdalnego przetwarzania danych, „w tym komponenty programowe lub sprzętowe wprowadzane do obrotu oddzielnie”. Biblioteka ogólnego przeznaczenia, system operacyjny czasu rzeczywistego czy moduł łączności nie są same w sobie wyrobami medycznymi, więc MDR do nich się nie stosuje, a zatem wyłączenie ich nie obejmuje. Komisja formułuje tę zasadę wprost w odpowiedziach na pytania dotyczące lotnictwa i wyposażenia morskiego, wskazując, że komponenty przeznaczone do integracji z produktami certyfikowanymi na podstawie innych reżimów, lecz same nienależące do tych reżimów, mogą być objęte aktem o cyberodporności.11
Konsekwencja praktyczna jest następująca. Od 11 września 2026 roku dostawca komponentu wbudowanego w certyfikowany wyrób medyczny może być zobowiązany zgłosić aktywnie wykorzystywaną podatność w ciągu 24 godzin. Producent wyrobu i szpital, który tego wyrobu używa, muszą mieć proces, żeby takie zgłoszenie przyjąć, ocenić jego znaczenie dla własnej konfiguracji i podjąć decyzję. Zgłoszenie bez adresata jest hałasem; adresat bez procesu jest pojedynczą osobą, która akurat może być na urlopie. To jest prawdziwa treść zgodności — nie dokument, lecz zdolność.
Zegar polski: 3 października i narzędzie, którego jeszcze nie użyto
Polska wdrożyła NIS2 ustawą z 23 stycznia 2026 roku o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, ogłoszoną w Dzienniku Ustaw pod pozycją 252 i obowiązującą od 3 kwietnia 2026 roku. Nowelizacja zastąpiła dotychczasową kategorię operatorów usług kluczowych podziałem na podmioty kluczowe i ważne, obejmując obowiązkami znacznie szerszy krąg sektorów.12 Dla szpitali istotne są cztery elementy tej reformy — i jeden z nich ma termin za niespełna dwa tygodnie.
Po pierwsze, wpis do wykazu. Samorejestracja ruszyła 7 maja 2026 roku i prowadzona jest przez aplikację Wykaz KSC, stanowiącą element systemu S46; termin na złożenie wniosku upływa 3 października 2026 roku, czyli sześć miesięcy od uzyskania statusu. Wniosek obejmuje między innymi sektor, dane identyfikacyjne, zakresy adresów IP i domeny oraz dane osób kontaktowych, a towarzyszy mu oświadczenie kierownika podmiotu składane pod rygorem odpowiedzialności karnej.12 To jest najbliższa twarda data w kalendarzu polskiego szpitala i najprostszy test tego, czy placówka w ogóle rozpoznała swoją nową sytuację prawną.
Po drugie, trójstopniowy model zgłaszania incydentów: wczesne ostrzeżenie w ciągu maksymalnie 24 godzin od wykrycia poważnego incydentu, pełne zgłoszenie w 72 godziny i sprawozdanie końcowe w ciągu miesiąca, kierowane do zespołu CSIRT sektorowego. Dla ochrony zdrowia zespołem tym jest CSIRT CeZ, który w czerwcu 2026 roku uruchomił własny portal do zgłaszania cyberincydentów wraz z ankietą samooceny, rejestracją osób kontaktowych oraz publikacją ostrzeżeń i rekomendacji.13
Po trzecie — i to jest sedno naszej sprawy — obowiązek aktywnego zarządzania ryzykiem w łańcuchu dostaw ICT, stanowiący element systemu zarządzania bezpieczeństwem informacji. Obejmuje ocenę bezpieczeństwa dostawców sprzętu, oprogramowania, sieci i usług, ich praktyk, podatności i wpływu na ciągłość działania. Towarzyszy mu polska osobliwość: mechanizm dostawcy wysokiego ryzyka. Postępowanie prowadzi Minister Cyfryzacji po zasięgnięciu opinii Kolegium do Spraw Cyberbezpieczeństwa, a decyzja dotyczy konkretnych produktów, usług lub procesów ICT; wycofanie następuje w ciągu siedmiu lat, a w komunikacji elektronicznej w cztery.12 Rzetelność wymaga jednak dopowiedzenia, którego w komentarzach brakuje: na wrzesień 2026 roku nie wszczęto żadnego takiego postępowania i lista dostawców wysokiego ryzyka nie istnieje. Narzędzie jest gotowe i nieużywane — co jest samo w sobie informacją polityczną i o czym piszę niżej.
Po czwarte, nowelizacja przenosi odpowiedzialność na poziom zarządczy. Artykuł 73a przewiduje karę dla kierownika podmiotu do 300 procent wynagrodzenia w podmiocie prywatnym i do 100 procent w podmiocie publicznym, niezależnie od kary nałożonej na sam podmiot; kary dla podmiotów sięgają 10 milionów euro lub 2 procent przychodu dla kluczowych i 7 milionów euro lub 1,4 procent dla ważnych, a w przypadku bezpośredniego poważnego zagrożenia dla obronności, bezpieczeństwa państwa lub zdrowia — do 100 milionów złotych.12 Ministerstwo Cyfryzacji wskazuje przy tym 3 kwietnia 2028 roku jako początek obowiązywania przepisów o karach.12 To ostatnie zastrzeżenie jest w istocie darowanym czasem — oknem na uporządkowanie domu, zanim zacznie się egzekucja. Kto je przeczyta jako zwolnienie z obowiązku, pomyli zawieszenie sankcji z zawieszeniem ryzyka; przestępca nie sprawdza w Dzienniku Ustaw, od kiedy grożą kary.
| Wymiar | Akt o cyberodporności (UE) | Ustawa o KSC (PL) |
|---|---|---|
| Adresat | Producent produktu z elementami cyfrowymi | Podmiot kluczowy i ważny — w tym szpital |
| Przedmiot | Bezpieczeństwo produktu przez cały cykl życia | Bezpieczeństwo organizacji i jej łańcucha dostaw |
| Obowiązek już działa | Zgłaszanie podatności i incydentów od 11.09.2026 | Zgłaszanie incydentów 24 h / 72 h / miesiąc |
| Najbliższy termin | — | Wpis do wykazu do 3.10.2026 |
| Sankcje od | 11.12.2027 | 3.04.2028 |
| Narzędzie szczególne | Wykaz komponentów (SBOM), okres wsparcia min. 5 lat | Dostawca wysokiego ryzyka — dotąd nieużyty |
Co Polska oferuje światu, a co świat oferuje Polsce
Seria o nośności konsekwentnie pyta o wymianę dwustronną, bo polityka zdrowotna, która tylko bierze albo tylko daje, jest niepełna. W kwestii łańcucha dostaw IT ta wymiana jest wyjątkowo konkretna.
Polska ma światu do zaoferowania rzecz nieoczywistą: instytucję dostawcy wysokiego ryzyka wraz z jej proceduralną obudową. Mechanizm ten bywa krytykowany jako nadmiarowy wobec prawa unijnego, w istocie jednak stanowi próbę odpowiedzi na pytanie, na które reszta Europy dopiero szuka odpowiedzi — jak państwo może, w sposób proceduralnie uczciwy, wykluczyć z infrastruktury krytycznej dostawcę, którego produkty zagrażają bezpieczeństwu, nie popadając ani w arbitralność, ani w paraliż. Polski model ma trzy cechy warte eksportu: prowadzi go organ administracji, a nie służba; wymaga opinii ciała kolegialnego; i przewiduje długie, przewidywalne okno wycofania zamiast natychmiastowego odcięcia. Trzeba jednak dodać rzecz, która jest testem wiarygodności całej konstrukcji: narzędzie, którego nigdy nie użyto, nie jest jeszcze modelem — jest hipotezą. Dopiero pierwsze postępowanie pokaże, czy kryteria są jasne, czy dostawca ma realne prawo do obrony i czy ścieżka odwoławcza działa. Do tego czasu ostrożność w chwaleniu się tym rozwiązaniem jest formą uczciwości, a nie słabości.
Drugim polskim wkładem może być model sektorowego, współdzielonego centrum operacji bezpieczeństwa dla ochrony zdrowia — bo w kraju, w którym większość szpitali nigdy nie zbuduje własnego, całodobowego zespołu monitorującego, wspólna tarcza jest jedyną realistyczną tarczą. Poświęciliśmy temu osobną odsłonę serii, ale w kontekście łańcucha dostaw nabiera on nowego sensu: współdzielone centrum widzi wzorzec ataku na dostawcę, zanim uderzy on w dziesiątą placówkę, i może ostrzec pozostałe dziewięć. Pojedynczy szpital widzi wyłącznie siebie — i właśnie dlatego nigdy nie zobaczy ataku na łańcuch dostaw jako ataku na łańcuch dostaw, tylko jako własną, niewytłumaczalną awarię.
Czego nam brakuje
- Aktualnej, sektorowej miary incydentów w łańcuchu dostaw — ostatnia całościowa analiza ENISA pochodzi z 2023 roku
- Praktyki umownej: klauzul bezpieczeństwa, prawa do audytu i obowiązku dostarczenia wykazu komponentów jako standardu, a nie wyjątku
- Realnej możliwości zmiany dostawcy systemu szpitalnego — bez niej zarządzanie ryzykiem koncentracji jest deklaracją
- Pierwszego, przeprowadzonego do końca postępowania w sprawie dostawcy wysokiego ryzyka
Co świat już przygotował
- Zaktualizowane wytyczne zamówieniowe ENISA dla szpitali z 22 lipca 2026 — w układzie planowanie, pozyskanie, zarządzanie
- Europejskie centrum wsparcia cyberbezpieczeństwa przy ENISA, budowane na podstawie trzyletniej umowy o wkładzie na 6 mln euro
- Usługę wczesnego ostrzegania i bony cyberbezpieczeństwa dla mniejszych szpitali z planu działań Komisji ze stycznia 2025
- Gotowy język standardów: SBOM, bezpieczeństwo w projektowaniu, koordynowane ujawnianie podatności, uwierzytelnianie wieloskładnikowe jako norma
Świat oferuje Polsce dojrzały język, którego nie musimy wymyślać od nowa. Najświeższym i najbardziej praktycznym jego wyrazem są wytyczne ENISA dotyczące zamówień na cyberbezpieczeństwo dla szpitali i świadczeniodawców, opublikowane 22 lipca 2026 roku jako jeden z pierwszych produktów europejskiego planu działań. Porządkują one zakup w trzech fazach — planowania, pozyskania i zarządzania — i obejmują systemy informacji klinicznej, wyroby medyczne, chmurę, sprzęt sieciowy oraz produkty wykorzystujące sztuczną inteligencję.14 Sam plan działań, przedstawiony przez Komisję 15 stycznia 2025 roku, przewiduje ponadto europejskie centrum wsparcia cyberbezpieczeństwa dla szpitali przy ENISA, ogólnounijną usługę wczesnego ostrzegania, usługę odzyskiwania po ransomware oraz bony cyberbezpieczeństwa dla mikro-, małych i średnich szpitali; Radę Doradczą do spraw Cyberbezpieczeństwa w Ochronie Zdrowia zwołano po raz pierwszy w listopadzie 2025 roku.15 Precyzja wymaga zaznaczenia, że centrum jest budowane, a nie działa w pełni, a część usług pozostaje na etapie wdrożenia — wskazywanie na nie jako na gotowe wsparcie byłoby przedwczesne.
Jest w tej wymianie jeszcze jeden, głębszy wątek. Polska ma szansę stać się nie tylko konsumentem, ale i producentem zaufanych rozwiązań. Rodzimy sektor technologii medycznych, który nauczy się dostarczać oprogramowanie z gotowym wykazem komponentów, z procesem obsługi podatności i z bezpieczeństwem wpisanym w architekturę, zyskuje przewagę na europejskim rynku zamówień publicznych — bo po 11 września 2026 roku pytanie o cyberbezpieczeństwo przestaje być formalnością. To jest dokładnie ten punkt, w którym odporność przestaje być kosztem, a staje się dźwignią przychodu — i w którym marka „Healthcare Poland” może oznaczać nie tylko dobrze leczonego pacjenta, ale i wiarygodnego dostawcę.
Trzeba wreszcie zauważyć, że decyzje w warstwie cyfrowej mają swój dokładny odpowiednik w warstwie fizycznej. Dwunastego maja 2026 roku Rada i Parlament osiągnęły wstępne porozumienie w sprawie aktu o lekach krytycznych, którego celem jest uodpornienie łańcuchów dostaw leków: dywersyfikacja produkcji, wspólne zamówienia z progiem obniżonym z dziewięciu do pięciu państw i — co najważniejsze doktrynalnie — wpisanie wymogów odporności wprost do procedur zamówień publicznych, tak by bezpieczeństwo dostaw przeważało nad samą ceną.6 Podkreślmy: jest to porozumienie polityczne, a nie akt przyjęty; na wrzesień 2026 roku rozporządzenie nie zostało formalnie przyjęte ani opublikowane w Dzienniku Urzędowym Unii, a wcześniejsze głosowanie Parlamentu ze stycznia 2026 roku było stanowiskiem w pierwszym czytaniu, nie ostatecznym przyjęciem.6 Motyw jest wszakże identyczny jak w cyberbezpieczeństwie: Europa przechodzi od logiki najniższej ceny do logiki odporności. To ta sama decyzja podjęta na dwóch frontach naraz — dowód, że nośność łańcucha dostaw, cyfrowego i materialnego, stała się kategorią polityki publicznej, a nie jedynie zarządzania ryzykiem w pojedynczej firmie.
Wdrożenie: pięć czynności, nie pięć deklaracji
Prawo wskazuje kierunek, ale nośności nie buduje się rozporządzeniem — buduje się ją czynnościami. Ścieżka wdrożenia, choć wymagająca, daje się opisać w kategoriach korzyści, a nie tylko obowiązków, i właśnie tak należy ją przedstawiać kadrom, które słusznie mają dość kolejnych „obowiązków compliance”.
Czynność 1 · Inwentarz i klasyfikacja dostawców
- Spisać wszystkich dostawców ICT i wyrobów z oprogramowaniem, wraz z zakresem ich dostępu zdalnego.
- Uszeregować ich według tego, jak bardzo awaria każdego uderzyłaby w opiekę nad pacjentem, a nie według wartości kontraktu.
- Wskazać dostawców krytycznych — tych, bez których oddział staje. Szpital, który nie wie, od ilu podmiotów zależy jego ciągłość, nie zarządza ryzykiem, lecz złudzeniem.
Czynność 2 · Umowa jako narzędzie, nie formalność
- Wpisać do kontraktów klauzule bezpieczeństwa, obowiązek powiadomienia o incydencie w określonym czasie i prawo do audytu.
- Żądać wykazu komponentów oprogramowania oraz zadeklarowanego okresu wsparcia i aktualizacji — akt o cyberodporności czyni z tego standard rynkowy, nie ekstrawagancję.
- Uregulować okno serwisowe i odpowiedzialność za wdrożenie łaty: to w tym miejscu łańcuch urywa się najczęściej.
Czynność 3 · Kanał odbioru podatności
- Wyznaczyć adresata zgłoszeń od dostawców — funkcję, nie osobę, z zastępstwem i dyżurem.
- Ustalić próg czasowy własnej oceny: ile godzin od zgłoszenia na decyzję „łatamy, obchodzimy czy odłączamy”.
- Połączyć ten kanał ze ścieżką zgłoszenia poważnego incydentu do CSIRT CeZ w 24 godziny.
Czynność 4 · Plan wyjścia i plan bez dostawcy
- Odpowiedzieć na pytanie „co robimy, gdy nasz dostawca systemu zniknie na tydzień”, spisać odpowiedź i przechowywać ją poza systemem, którego dotyczy.
- Zapewnić eksport własnych danych w formacie, który da się odczytać bez tego dostawcy — to warunek brzegowy każdej realnej zmiany platformy.
- Uznać, że awaria dostawcy nastąpi. Plan ciągłości zapisany wyłącznie w systemie, który właśnie padł, jest planem tylko z nazwy.
Czynność 5 · Próba obciążeniowa
- Przeprowadzić ćwiczenie, w którym zespół symuluje odcięcie krytycznego dostawcy — nie prezentację, lecz próbę.
- Zmierzyć, ile z codziennej zdolności leczenia szpital utrzymał w warunkach ćwiczenia.
- Powtórzyć to, co nie zadziałało, i zapisać wniosek tam, gdzie ktoś go przeczyta przed następnym razem.
W każdej z tych czynności kompetencja, którą Fundacja Healthcare Poland rozwija w ramach koalicji CyberC4HE, adresuje problem wprost, bez konieczności, by każdy szpital budował wszystko sam. Sektorowe, współdzielone centrum monitorowania odciąża pojedynczą placówkę od kosztu, którego samodzielnie nie udźwignie, i daje jej to, czego pojedynczy szpital mieć nie może — widok całego sektora. Audyty łańcucha dostaw i wsparcie w konstruowaniu klauzul umownych przekładają wymóg prawny na gotowe narzędzie. Praca nad uwolnieniem szpitali od uzależnienia od dostawcy systemów uderza w źródło ryzyka systemowego, a nie tylko w jego objawy. Szkolenia adresowane do zarządów przekładają nową, osobistą odpowiedzialność kierownictwa na wiedzę, dzięki której odpowiedzialność ta przestaje być pułapką, a staje się narzędziem sprawowania nadzoru. To jest promocja przez użyteczność, nie przez hasło: kompetencja pokazuje swoją wartość, rozwiązując problem, którego termin wpisano do Dziennika Ustaw.
Tarcza dla obywatela i sprawiedliwa kultura zgłaszania
Za każdą z tych procedur stoi ktoś, kto nigdy nie przeczyta rozporządzenia 2024/2847 ani nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa — pacjent. To on jest ostatecznym adresatem całej tej pracy i to on płaci najwyższą cenę, gdy ogniwo pęka: odroczonym badaniem, przełożoną operacją, godzinami spędzonymi na izbie przyjęć, w której lekarz nie widzi jego historii choroby. Narracja tarczy dla obywatela nie jest tu ozdobnikiem — jest właściwym uzasadnieniem. Bezpieczeństwo łańcucha dostaw IT nie służy spokojowi działu informatyki ani unikaniu kary przez zarząd; służy temu, żeby w dniu, w którym u kogoś innego pęknie najsłabsze ogniwo, pacjent tego nie odczuł albo odczuł jak najmniej. Odporność jest formą troski — i tak, a nie jako techniczny obowiązek, powinna być tłumaczona zarówno personelowi, jak i opinii publicznej.
Jest też druga warstwa, bez której cała ta budowla może obrócić się przeciwko własnemu celowi — warstwa kultury. Ataki na łańcuch dostaw mają tę cechę, że rozmywają odpowiedzialność i kuszą do szukania kozła ofiarnego. Szpital, który stanął, bo padł jego dostawca, łatwo obwinić — a przecież często nie zawinił. Dostawcę, który zgłosił podatność, łatwo napiętnować — a przecież to jego zgłoszenie ocaliło innych. Tu wkracza zasada sprawiedliwej kultury, Just Culture, i szerzej doktryna Just Council, którą Fundacja traktuje jako fundament, a nie dodatek. Sprawiedliwa kultura odróżnia błąd systemowy od zaniedbania i uczy się na zdarzeniu, zamiast karać za jego ujawnienie.
W cyberbezpieczeństwie ma to bardzo praktyczny wymiar, i to wymiar świeżo umocowany w prawie. Cały mechanizm zgłaszania, na którym opiera się akt o cyberodporności, działa tylko wtedy, gdy zgłaszający lukę nie jest traktowany jak sprawca, lecz jak sojusznik. Producent, który wie, że po zgłoszeniu aktywnie wykorzystywanej podatności czeka go nagonka, zgłosi ją później, ostrożniej albo wcale — a wtedy 24-godzinny termin z artykułu 14 stanie się przepisem martwym w sensie ścisłym: obowiązującym i nieprzestrzeganym. To samo dotyczy szpitala i jego personelu. Kultura, która „strzela do posłańca”, zabija zgłaszanie, a wraz z nim zabija odporność. Dlatego budowa nośności łańcucha dostaw jest nie tylko projektem technicznym i prawnym, ale i etycznym: wymaga wspólnoty, w której szpital, dostawca i regulator uczą się razem, dzielą się wiedzą o zagrożeniach i traktują incydent u jednego jako lekcję dla wszystkich. To jest przeciwieństwo języka plemiennego „my kontra oni”; to jest język współodpowiedzialności za wspólną tarczę.
Rozliczenie: nośność jako właściwość całego łańcucha
Pomiar prowadzi do decyzji, decyzja do wdrożenia, a wdrożenie — jeśli ma cokolwiek znaczyć — musi prowadzić do rozliczenia. Bez wskaźników i bez wskazanej odpowiedzialności najlepsza nawet regulacja pozostaje intencją. Nośność łańcucha dostaw IT daje się rozliczać całkiem konkretnie.
Ramy prawne dokładają do tego własne, twarde rozliczenie: wpis do wykazu do 3 października 2026 roku, obowiązek zgłoszenia poważnego incydentu w 24 godziny, obowiązek raportowania podatności przez producentów od 11 września 2026 roku, osobista odpowiedzialność kierownictwa. Odpowiedzialność ta, choć bywa odbierana jako groźba, jest w istocie narzędziem rozliczenia we właściwym miejscu — na poziomie, na którym zapadają decyzje o budżecie i priorytetach. Zarząd, który wie, że odpowiada osobiście, przydziela na bezpieczeństwo zasoby, których dział informatyki nigdy sam by nie wywalczył.
Warto na koniec nazwać po imieniu, kto na tej nośności zyskuje, bo korzyść jest rozłożona szeroko i to jej wspólnotowy charakter czyni całą rzecz opłacalną. Pacjent i obywatel zyskują ciągłość i bezpieczeństwo opieki wtedy, gdy najbardziej ich potrzebują — w dniu awarii. Szpitale i ich kadry zyskują mniej gaszenia pożarów, jasny podział odpowiedzialności i partnera, który bierze na siebie część ciężaru nie do udźwignięcia przez pojedynczą placówkę. Regulator i płatnik zyskują system, który nie kładzie się kaskadowo, gdy pada jedno ogniwo, i który potrafi zawczasu ostrzec. Biznes i inwestorzy zyskują przewidywalne reguły oraz rynek, na którym zaufany, bezpieczny produkt wygrywa — a więc zachętę, by taki produkt budować w Polsce. A marka „Healthcare Poland” zyskuje treść, której nie da się kupić za żaden budżet promocyjny: reputację kraju, który traktuje cyfrowy łańcuch dostaw ochrony zdrowia jak zdrowie publiczne, bo nim właśnie jest.
Wróćmy więc do poranka, od którego zaczęliśmy — do szpitala, który zrobił wszystko dobrze i mimo to stanął, bo najsłabsze ogniwo było u kogoś innego. Prawdziwa lekcja tego poranka nie brzmi „zbudujmy wyższy mur”, bo mur nie chroni przed awarią, która nadchodzi z drugiej strony umowy. Brzmi ona inaczej: nośność nie jest właściwością pojedynczego szpitala, lecz właściwością całego łańcucha, a łańcuch jest tak mocny jak jego najsłabsze ogniwo. Europa wpisała tę prawdę do prawa, a jedenasty września 2026 roku był dniem, w którym z deklaracji stała się obowiązkiem. Trzeci października jest dniem, w którym polski szpital musi przynajmniej powiedzieć, że istnieje. Polska ma w tej sprawie coś rzadkiego — nie tylko obowiązek do wypełnienia, ale i własny instrument do wypróbowania, własny model wspólnej tarczy do zbudowania i realną szansę, by z kraju, który dogania, stać się krajem, który pokazuje, jak to się robi. Najsłabsze ogniwo jest u kogoś innego — więc wzmocnienie go jest zadaniem nas wszystkich naraz. To nie jest slogan. To jest definicja odporności.
Granica szpitala nie biegnie po murze, tylko po umowach. Nośność nie jest właściwością pojedynczej placówki, lecz właściwością całego łańcucha — a łańcuch jest tak mocny jak jego najsłabsze ogniwo.
Michał P. Dybowski, „Najsłabsze ogniwo jest u kogoś innego”
Przypisy i źródła
Wszystkie źródła zweryfikowano niezależnie; data dostępu: 21 września 2026. Przy twierdzeniach, dla których nie istnieje źródło urzędowe odnoszące się wprost do sytuacji opisywanej w tekście, zaznaczono charakter wykładni.
- American Hospital Association, „Medical technology company Stryker disrupted globally by cyberattack”, AHA News, 12 marca 2026 — spółka poinformowała o incydencie 11 marca 2026, dotknięte zostało jej środowisko Microsoft, brak wskazań na ransomware i złośliwe oprogramowanie; komentarz Johna Riggiego o konieczności oceny przez szpitale powiązań własnych usług, technologii i łańcucha dostaw z zaatakowanym dostawcą. aha.org
- American Hospital Association, „CISA urges organizations to harden endpoint management systems following Stryker cyberattack”, AHA News, 20 marca 2026 — zalecenia utwardzenia systemów zarządzania punktami końcowymi, wydane po incydencie. aha.org
- HIPAA Journal, „Change Healthcare responding to cyberattack” (aktualizowane zestawienie) oraz raport roczny UnitedHealth Group za 2024 r. — 192,7 mln osób objętych naruszeniem; wejście przez serwer zdalnego dostępu Citrix bez uwierzytelniania wieloskładnikowego, skradzione dane logowania pracownika wsparcia, dostęp 12–20 lutego 2024, wykrycie 21 lutego 2024, sprawca: afiliant BlackCat/ALPHV; okup 22 mln USD zapłacony, dane nieusunięte; łączne skutki ataku w 2024 r. ok. 3,09 mld USD, w tym ok. 2,2 mld USD bezpośrednich kosztów reakcji; największe naruszenie danych zdrowotnych w historii USA (poprzedni rekord: Anthem 2015, 78,8 mln). hipaajournal.com
- ENISA, „Health Threat Landscape”, 5 lipca 2023 — 215 publicznie zgłoszonych incydentów ze stycznia 2021 – marca 2023: ransomware 54% incydentów, świadczeniodawcy 53% celów, szpitale 42%, dane pacjentów najczęściej atakowanym zasobem (30%), 46% incydentów nakierowanych na kradzież lub wyciek danych, ataki na łańcuchy dostaw i dostawców usług skutkujące zakłóceniami lub stratami — 7%; 80% respondentów wskazuje podatności jako przyczynę ponad 61% incydentów (dane ankietowe HIMSS/ENISA cytowane w raporcie, nie z analizy 215 incydentów); mediana kosztu poważnego incydentu 300 tys. euro. enisa.europa.eu
- ENISA, „ENISA Threat Landscape 2025” (wyd. 1.2, styczeń 2026) — sektor zdrowia 4,2% incydentów cyberprzestępczych, poza pierwszą piątką najczęściej atakowanych sektorów; ryzyka łańcucha dostaw 10,6% wszystkich zidentyfikowanych kategorii zagrożeń. Raport ma charakter przekrojowy; ENISA nie opublikowała dotąd aktualizacji sektorowego „Health Threat Landscape” z 2023 r. enisa.europa.eu (PDF)
- Rada Unii Europejskiej, „Critical Medicines Act: Council and Parliament reach provisional deal”, komunikat prasowy z 12 maja 2026 — wstępne porozumienie, obowiązkowe wymogi odporności w zamówieniach publicznych na leki krytyczne, obniżenie progu wspólnych zamówień z dziewięciu do pięciu państw. Na 21 września 2026 r. akt nie został formalnie przyjęty ani opublikowany w Dz.U. UE; głosowanie Parlamentu z 20 stycznia 2026 r. stanowiło stanowisko w pierwszym czytaniu przed rozmowami trójstronnymi. Szacunek udziału importu substancji czynnych (ok. 80% z pięciu krajów, Chiny ok. 45%) — za: Institut Jacques Delors, Policy Paper 288 (2025), powołujący się na dialog strukturalny Komisji z lat 2021–2022; nie jest to bieżąca dana Komisji. consilium.europa.eu · institutdelors.eu (PDF)
- Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2) — art. 20 ust. 1 i 2 (odpowiedzialność i szkolenia organów zarządzających), art. 21 ust. 2 lit. d oraz ust. 3 (bezpieczeństwo łańcucha dostaw, podatności bezpośrednich dostawców, bezpieczne procedury rozwoju), art. 32 ust. 5 lit. b (czasowy zakaz pełnienia funkcji — wyłącznie podmioty kluczowe, środek ostateczny, bez zastosowania do administracji publicznej), art. 34 ust. 4 i 5 (kary: „maximum of at least” 10 mln EUR / 2% oraz 7 mln EUR / 1,4%, za naruszenia art. 21 lub 23), art. 41 ust. 1 (transpozycja do 17.10.2024, stosowanie od 18.10.2024). eur-lex.europa.eu
- Komisja Europejska, „Commission refers Ireland, Spain, France and the Netherlands to the Court of Justice for failing to transpose rules”, 8 lipca 2026 — większość państw notyfikowała pełną transpozycję NIS2; Hiszpania, Francja, Irlandia i Niderlandy nie. digital-strategy.ec.europa.eu
- NL Digital Government, „NIS2 Directive / Cyberbeveiligingswet (Cbw)” — niderlandzka ustawa o cyberbezpieczeństwie weszła w życie 15 sierpnia 2026 r. nldigitalgovernment.nl
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847 (Cyber Resilience Act) — art. 2 ust. 2 (wyłączenie produktów objętych rozporządzeniami 2017/745, 2017/746 i 2019/2144, wraz z motywem 25), art. 3 pkt 1 (definicja obejmująca komponenty wprowadzane do obrotu oddzielnie), art. 13 (projektowanie bezpieczne, należyta staranność wobec komponentów stron trzecich, okres wsparcia co najmniej 5 lat), art. 14 (zgłaszanie: 24 h / 72 h oraz raport końcowy — 14 dni dla podatności, 1 miesiąc dla incydentów), art. 16 (jednolita platforma zgłoszeniowa), art. 64 (kary: 15 mln EUR / 2,5% za naruszenia zał. I oraz art. 13 i 14; wyłączenia dla mikro- i małych przedsiębiorstw oraz opiekunów oprogramowania otwartego), art. 69 ust. 3 (stosowanie art. 14 do produktów wprowadzonych do obrotu przed 11.12.2027), art. 71 (wejście w życie 10.12.2024; rozdz. IV od 11.06.2026; art. 14 od 11.09.2026; pełne stosowanie, w tym nadzór rynku i kary, od 11.12.2027), zał. I cz. I pkt 2 lit. b (domyślna konfiguracja bezpieczna) i cz. II pkt 1 (wykaz komponentów oprogramowania — SBOM, co najmniej zależności najwyższego poziomu). eur-lex.europa.eu
- Komisja Europejska, „Cyber Resilience Act implementation — frequently asked questions” oraz ENISA, „The CRA Single Reporting Platform is launched” — uruchomienie jednolitej platformy zgłoszeniowej 11 września 2026, zgłoszenie jednocześnie do CSIRT wyznaczonego jako koordynator i do ENISA; wyjaśnienie, że komponenty nieobjęte innym reżimem certyfikacyjnym mogą podlegać CRA (FAQ formułuje tę zasadę wprost dla lotnictwa i wyposażenia morskiego; brak odrębnego wyjaśnienia Komisji ani wytycznych MDCG dla styku CRA z MDR i IVDR — odniesienie do wyrobów medycznych jest w tym tekście wykładnią, nie stanowiskiem urzędowym); zawieszenie stosowania przepisów o karach do 11.12.2027. digital-strategy.ec.europa.eu · enisa.europa.eu
- Ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252) wraz z komunikatami Ministerstwa Cyfryzacji „Nowelizacja ustawy o KSC — najważniejsze terminy” i „Procedura dot. listy dostawców wysokiego ryzyka” — wejście w życie 3 kwietnia 2026; podmioty kluczowe i ważne (art. 5 ust. 1 i 2 wraz z załącznikami); wykaz uruchomiony 13 kwietnia 2026, samorejestracja od 7 maja 2026 przez aplikację Wykaz KSC (element systemu S46), termin złożenia wniosku 3 października 2026, oświadczenie kierownika pod rygorem odpowiedzialności karnej; wdrożenie SZBI do 3 kwietnia 2027; pierwszy audyt do 3 kwietnia 2028, następnie co najmniej raz na 3 lata; zgłaszanie incydentów 24 h / 72 h / miesiąc; mechanizm dostawcy wysokiego ryzyka prowadzony przez Ministra Cyfryzacji po opinii Kolegium, wycofanie w 7 lat (4 lata w komunikacji elektronicznej) — na wrzesień 2026 nie wszczęto żadnego postępowania i lista nie istnieje; kary: art. 73 ust. 3–5 (10 mln EUR / 2%, 7 mln EUR / 1,4%, do 100 mln zł przy bezpośrednim poważnym zagrożeniu), art. 73a (do 300% wynagrodzenia kierownika w podmiocie prywatnym, do 100% w publicznym); początek obowiązywania przepisów o karach — 3 kwietnia 2028. isap.sejm.gov.pl · samorzad.gov.pl
- Centrum e-Zdrowia, komunikat o uruchomieniu portalu CSIRT CeZ (czerwiec 2026) oraz „Sposób zgłaszania incydentów” — portal csirt.cez.gov.pl: formularz zgłoszenia z załącznikami, ankieta samooceny statusu podmiotu, rejestracja osób kontaktowych, ostrzeżenia i rekomendacje; wstępne zgłoszenie w 24 h od wykrycia; kanały: S46, formularz, e-mail i telefon. cez.gov.pl
- ENISA, „Procurement guidelines for the cybersecurity of hospitals and healthcare providers”, 22 lipca 2026 — aktualizacja wytycznych z 2020 r., powstała jako jeden z pierwszych produktów europejskiego planu działań; struktura Plan / Source / Manage; zakres obejmuje systemy informacji klinicznej, wyroby medyczne, chmurę, sprzęt sieciowy i produkty z elementami sztucznej inteligencji. enisa.europa.eu (PDF)
- Komisja Europejska, „European action plan on the cybersecurity of hospitals and healthcare providers”, 15 stycznia 2025 — europejskie centrum wsparcia cyberbezpieczeństwa przy ENISA (budowane na podstawie trzyletniej umowy o wkładzie na 6 mln euro), ogólnounijna usługa wczesnego ostrzegania, usługa odzyskiwania po ransomware, bony cyberbezpieczeństwa dla mikro-, małych i średnich szpitali, Rada Doradcza ds. Cyberbezpieczeństwa w Ochronie Zdrowia (pierwsze posiedzenie: listopad 2025). Stan na wrzesień 2026: centrum w budowie, część usług na etapie wdrożenia. digital-strategy.ec.europa.eu

Dodaj komentarz