ChipSoft, holenderskie szpitale i łańcuch dostaw — dlaczego KSC 2.0 miało rację

Co się właściwie stało

Fakty — bez dramatyzacji, bo same mówią za siebie.

• Data: 7 kwietnia 2026
• Cel: ChipSoft — holenderski producent oprogramowania do dokumentacji medycznej pacjentów
• Zasięg: Oprogramowanie ChipSoft obsługuje około 80% szpitali w Holandii
• Mechanizm: Ransomware. Strona WWW ChipSoft niedostępna, poczta działa
• Skutek operacyjny: 11 szpitali wyłączyło oprogramowanie. 9 z nich to placówki, które korzystały z systemu intensywnie
• Grupa odpowiedzialna: Na dzień publikacji — nieznana
• Źródło potwierdzenia: Z-CERT — holenderski zespół reagowania na incydenty w sektorze ochrony zdrowia

Dyrektor Z-CERT, Wim Hafkamp, ujął to w jednym zdaniu, które warto przepisać na ścianę każdej sali zarządu w szpitalu:

„Przestój cyfrowy nie jest abstrakcyjnym problemem IT. Dotyczy ludzi, którzy potrzebują opieki."

Hafkamp przypomniał też świeży precedens. W styczniu 2026 belgijska sieć szpitalna AZ Monica (Antwerpia, Deurne) została sparaliżowana atakiem ransomware. Placówki odsyłały karetki. Pacjentów w stanie krytycznym transportowano do sąsiednich szpitali. System leżał przez kilka dni.

To są fakty. Bez „cyberprzestępcy nie śpią". Bez straszenia. Sama chronologia wystarczy.

To nie był atak na szpital. To był atak na łańcuch dostaw

Uważne czytanie tej sprawy wymaga rozdzielenia dwóch pojęć, które opinia publiczna miesza:

Atak bezpośredni: przestępca włamuje się do sieci szpitala, szyfruje serwery, żąda okupu. Ofiara: szpital. Skala: jedna placówka.

Atak na łańcuch dostaw: przestępca włamuje się do dostawcy, od którego zależy setki organizacji. Ofiara pierwsza: dostawca. Ofiara druga, trzecia i czterdziesta: jego klienci. Skala: cały sektor.

ChipSoft to przypadek drugi. Jeden punkt wejścia. Kilkuset zależnych odbiorców. Szpitale w Holandii nie zostały „zaatakowane" — zostały wyłączone, bo wyłączono oprogramowanie, od którego zależała ich operacyjność. Niektóre wróciły do papierowych kartotek. Inne przełączyły się na ograniczony tryb portali pacjenckich.

Ekonomia ataku jest prosta i dlatego brutalna

Przestępca, który włamie się do jednego dostawcy, zyskuje dźwignię kilkuset organizacji. Koszt pracy jest ten sam. Potencjalny okup rośnie wielokrotnie. To nie jest przyszłość cyberprzestępczości — to jej teraźniejszość:

• Kaseya (2021) — atak na MSP obsługujący tysiące firm
• SolarWinds (2020) — trojanizacja aktualizacji oprogramowania zarządzającego
• MOVEit (2023) — podatność w narzędziu do transferu plików
• Change Healthcare (2024) — paraliż systemu rozliczeń medycznych w USA
• Snowflake (2024) — kradzież danych z instancji chmurowych klientów
• ChipSoft (2026)

I dlatego regulator europejski zmienił reguły.

Art. 8c KSC 2.0 — prawo, które przewidziało ten dzień

Polska nowelizacja ustawy o Krajowym Systemie Cyberbezpieczeństwa weszła w życie 3 kwietnia 2026. Cztery dni później Holandia dostała podręcznikowy przykład tego, po co ten przepis w ogóle powstał.

Art. 8c nakłada na każdy podmiot kluczowy i każdy podmiot ważny obowiązek zarządzania ryzykiem w łańcuchu dostaw. Nie „zachęca". Nie „rekomenduje". Wymaga.

Pięć konkretnych punktów z ustawy

1. Ocena dostawców przed rozpoczęciem współpracy. Nie podpisujesz umowy z dostawcą, dopóki nie przejrzysz jego postawy bezpieczeństwa.
2. Umowy z wymaganiami bezpieczeństwa. Każdy kontrakt musi zawierać konkretne zapisy o obowiązkach bezpieczeństwa dostawcy — nie ogólniki o „najlepszych praktykach".
3. Bieżące monitorowanie zgodności. Ocena dostawcy nie jest wydarzeniem jednorazowym przed podpisem. To proces ciągły.
4. Zarządzanie zagrożeniami od dostawców i outsourcingu. Musisz wiedzieć, jakie ryzyka wnosi każdy podmiot zewnętrzny do Twojej organizacji — i aktywnie je ograniczać.
5. Kontrola dostępu dostawcy. Izolacja środowisk, minimalizacja uprawnień, rejestrowanie każdego zdalnego dostępu.

Sankcja za zaniedbanie? Do 2 mln PLN za naruszenie Art. 8c (taryfikator z załącznika do ustawy).

Sektor ochrony zdrowia w Polsce jest sektorem podmiotów kluczowych. Szpitale, zwłaszcza te o znaczeniu regionalnym, podlegają pełnym wymogom. Pierwsze audyty dla podmiotów kluczowych muszą być zamknięte do 30 czerwca 2027. Za nieco ponad 14 miesięcy.

Gdyby scenariusz ChipSoft wydarzył się w Polsce, pytanie kontrolne brzmiałoby: „Kiedy ostatnio oceniliście dostawcę systemu HIS pod kątem bezpieczeństwa? Pokażcie dokumentację." I to pytanie nie padłoby od dziennikarza. Padłoby od organu właściwego do spraw cyberbezpieczeństwa.

Cztery pytania, które zarząd powinien zadać w poniedziałek

Nie w przyszłym kwartale. W poniedziałek. Niezależnie od sektora, w którym działasz — jeśli jesteś podmiotem kluczowym lub ważnym w rozumieniu KSC 2.0, licznik już bije.

1. Ilu mamy dostawców, których wyłączenie sparaliżuje naszą operacyjność w ciągu 24 godzin?

To nie jest pytanie o listę kontraktów z działu zakupów. To pytanie o zależności. System ERP. System HIS. Operator chmury. Operator łączy telekomunikacyjnych. Dostawca MDM/EDR. Integrator, który ma zdalny dostęp do serwerów. Policz. Zwykle wychodzi 8–15.

2. Co każdy z tych dostawców faktycznie robi z naszym bezpieczeństwem — czy tylko podpisał oświadczenie?

Oświadczenie to nie jest kontrola. Raport SOC 2 sprzed dwóch lat to nie jest monitoring. Art. 8c wymaga oceny ciągłej — a ciągłość oznacza proces, nie dokument w szufladzie.

3. Jaki dostęp do naszych systemów ma każdy z nich i kto tego dostępu pilnuje?

Zdalny dostęp dostawcy to najczęstszy wektor kompromitacji w atakach na łańcuch dostaw. Jeżeli dostawca ma konto z uprawnieniami administratora, które nie jest objęte MFA, rotacją haseł i logowaniem sesji — to jest podatność, nie umowa serwisowa.

4. Co się dzieje, jeśli jeden z tych dostawców zostanie zaszyfrowany dziś o 14:00?

Plan ciągłości działania dla zależności zewnętrznej. Nie dla własnej serwerowni — dla cudzej. Czy wiesz, jak pracujesz, gdy Twój system HIS nie odpowiada? Jak długo możesz tak działać? Kto podejmuje decyzję o przełączeniu na tryb awaryjny?

Jeśli na którekolwiek z tych pytań odpowiedź brzmi „nie wiem", masz konkretną, nazwaną lukę w zgodności z Art. 8c.

Co na to SecIQ

Zarządzanie łańcuchem dostaw w rozumieniu KSC 2.0 jest żmudne. Nie jest widowiskowe. Nie jest też zadaniem, które robi się raz. Jest procesem — i na tym polega problem dla zespołów IT, które już dziś są obciążone.

Model SecIQ został pomyślany właśnie pod to obciążenie. Zamiast dokładać firmie kolejne narzędzie, dajemy zespół, który ten proces prowadzi operacyjnie:

• vCISO SecIQ — przygotowuje rejestr dostawców krytycznych, katalog wymagań bezpieczeństwa do umów, prowadzi ocenę wstępną i okresową, przygotowuje dokumentację pod audyt Art. 8c. Robi to jako ekspert zgodności w imieniu klienta — nie jako zewnętrzny konsultant, który zostawia raport i wychodzi.
• Twój opiekun bezpieczeństwa — monitoruje dostęp dostawców do Twojego środowiska w ramach SOC. Zdalne sesje serwisowe, nietypowe logowania konta integratora, skoki ruchu z adresów dostawców — to sygnały, które musi ktoś widzieć na żywo.
• Ekspert edukacji SecIQ — szkoli Twoich ludzi, żeby rozumieli, czego wymaga Art. 8c i jak rozmawiać z dostawcami o bezpieczeństwie. Bez tego każda polityka jest martwa.

W tle cały czas pracuje AI-powered SOC, który automatyzuje triaż alertów, obsługę powtarzalnych zgłoszeń i korelację sygnałów z wielu źródeł. Dzięki temu analityk nie zajmuje się odsiewaniem szumu — tylko tym, co wymaga realnej oceny człowieka.

Puenta spokojnie

Atak na ChipSoft nie jest wyjątkiem. Jest statystyką, która w końcu trafiła na Holandię. Następnym razem trafi gdzie indziej — być może na polskiego dostawcę systemów dla sektora zdrowia, finansów, energetyki albo administracji publicznej. Ekonomia takich ataków się opłaca, więc będą się powtarzać.

Dobra wiadomość jest taka, że regulator tym razem nie spóźnił się o dekadę. Art. 8c KSC 2.0 istnieje właśnie po to, żeby zmusić organizacje do sprawdzenia, co się dzieje poza ich własną serwerownią. Prawo jest. Deadline audytowy jest. Instrumenty są.

Pytanie, które warto zadać dzisiaj, nie brzmi „czy ChipSoft mogło się wydarzyć u nas". Brzmi: „kiedy ostatnio ktoś u nas przeszedł listę naszych dostawców z listą wymagań z Art. 8c, punkt po punkcie — i co z tego wyszło".

Jeśli na to pytanie nie masz odpowiedzi, wiemy, od czego zacząć.

Źródła

• The Register — „Dutch healthcare software vendor goes dark after ransomware attack" (2026-04-08)
• Z-CERT Netherlands Healthcare CERT — komunikat z 2026-04-08
• Ustawa o Krajowym Systemie Cyberbezpieczeństwa — nowelizacja 2026, Art. 8c (Bezpieczeństwo Łańcucha Dostaw)