Co zrobić, aby mieć cyberbezpieczny szpital w epoce NIS2

Wprowadzenie

Od lat w „Menedżerze Zdrowia” podkreślamy, że zarządzanie szpitalem zaczyna się od danych oraz od rozumienia procesów klinicznych i ekonomicznych. W naszych analizach wielokrotnie pokazywaliśmy, że liczby potrafią zarówno wskazać sukces organizacyjny, jak i obnażyć strukturalne słabości podmiotu leczniczego. Dane nie interpretują rzeczywistości – one ją weryfikują. Analizując ścieżki diagnostyczno-terapeutyczne, strukturę kosztów oraz ekonomię świadczeń, korzystaliśmy z naszego autorskiego narzędzia analitycznego BiSmartHospital.

Wracając do tematu, istnieje jednak warunek brzegowy: analityka funkcjonuje wyłącznie dzięki bazom danych. W ochronie zdrowia są to dane szczególnie wrażliwe – obejmujące informacje o stanie zdrowia, przebiegu terapii i decyzjach klinicznych. Ich ochrona oraz zapewnienie ciągłości działania systemów informatycznych nie są już zagadnieniem technicznym, lecz elementem bezpieczeństwa pacjenta oraz bezpośrednim obszarem odpowiedzialności dyrektora.

Z tej perspektywy analizujemy „Dyrektywę w sprawie bezpieczeństwa sieci i informacji – wersja druga” (Network and Information Security Directive 2 – NIS2) oraz nowelizację ustawy o Krajowym Systemie Cyberbezpieczeństwa.

1. Cyberbezpieczeństwo jako element ładu zarządczego

Cyfryzacja ochrony zdrowia sprawiła, że technologia przestała być wsparciem działalności medycznej – stała się jej warunkiem. Bez dostępu do systemu szpitalnego (Hospital Information System – HIS) placówka nie jest w stanie prowadzić dokumentacji, realizować zleceń ani zapewnić ciągłości procesu diagnostyczno-terapeutycznego.

Niedostępność systemów informatycznych oznacza realne ryzyko kliniczne: opóźnienia w podaniu leków, brak dostępu do wyników badań, problemy z kwalifikacją do zabiegów czy dezorganizację pracy oddziałów. W tym kontekście cyberbezpieczeństwo przestaje być zagadnieniem informatycznym. Staje się elementem bezpieczeństwa pacjenta oraz integralną częścią ładu zarządczego.

2. Dyrektywa NIS2 – system odpowiedzialności

Dyrektywa NIS2 wprowadza spójny system obowiązków obejmujący cztery filary:

1. Zarządzanie ryzykiem (art. 21),
2. Raportowanie incydentów (art. 23),
3. Odpowiedzialność kadry zarządzającej (art. 20),
4. Sankcje administracyjne.
   

2.1. Rozszerzenie zakresu podmiotowego

Obowiązki obejmują wszystkie średnie i duże podmioty w sektorach kluczowych, w tym w ochronie zdrowia. Oznacza to, że większość szpitali publicznych oraz duże podmioty prywatne będą objęte nowym reżimem regulacyjnym.

2.2. Zarządzanie ryzykiem (art. 21 NIS2) – praktyczne wyjaśnienie dla dyrektora szpitala

Dyrektywa NIS2 w art. 21 nakłada na podmioty kluczowe i ważne – w tym szpitale – obowiązek systemowego zarządzania ryzykiem cyberbezpieczeństwa. Nie chodzi o pojedyncze procedury IT, lecz o model zarządczy, w którym bezpieczeństwo informacji i systemów staje się elementem nadzoru kierownictwa, podobnie jak finanse, jakość czy ryzyko kliniczne.

2.2.1. Co to oznacza w praktyce dla szpitala?

To nie jest projekt IT – to odpowiedzialność zarządu.

Art. 21 wymaga, aby:

• środki bezpieczeństwa były adekwatne do ryzyka,
• miały charakter organizacyjny i techniczny,
• były udokumentowane i nadzorowane na poziomie kierownictwa. Odpowiedzialność spoczywa na organie zarządzającym (dyrektor, zarząd spółki).
  

To oznacza:

• konieczność formalnego zatwierdzenia polityk bezpieczeństwa,
• okresowy przegląd ryzyk,
• zapewnienie zasobów (kadrowych i finansowych).
  

Brak nadzoru zarządczego może skutkować sankcjami administracyjnymi.

Szpital powinien:

• Dla najważniejszych systemów (HIS, RIS, LIS, EDM, systemy laboratoryjne, systemy rozliczeń z NFZ) określić zagrożenia (na przykład ransomware, utrata danych, atak na serwerownię, awaria zasilania) oraz skutki dla:

• ciągłości leczenia,
• bezpieczeństwa pacjentów,
• rozliczeń finansowych,
• reputacji.
  

To jest odpowiednik „mapy ryzyka cybernetycznego” – tak jak mamy mapę ryzyka klinicznego.

• Zadbać o bezpieczeństwo łańcucha dostaw.
  

Szpital odpowiada nie tylko za własne systemy, ale również za: 

• dostawców oprogramowania,
• firmy utrzymujące infrastrukturę,
• podmioty przetwarzające dane w chmurze,
• serwis aparatury medycznej z dostępem zdalnym.
  

W praktyce oznacza to:

• weryfikację umów (SLA, klauzule bezpieczeństwa),
• wymóg stosowania określonych standardów przez dostawców,
• kontrolę dostępu serwisowego.
  

• Zapewnić ciągłość działania (Business Continuity).
  

Szpital musi mieć:

• plan ciągłości działania (BCP),
• plan odtwarzania po awarii (DRP),
• regularne testy backupów,
• scenariusze awaryjne (np. praca w trybie papierowym).
  

Z perspektywy dyrektora to zabezpieczenie przed sytuacją, gdy atak cybernetyczny paraliżuje oddziały, blok operacyjny czy SOR.

• Wdrożyć zarządzanie incydentami. Szpital musi mieć:
  

• procedurę wykrywania incydentów,
• system ich klasyfikacji,
• ścieżkę eskalacji,
• gotowość raportową (24 h/72 h/raport końcowy),
• wyznaczone osoby odpowiedzialne,
• współpracę z SOC (wewnętrznym lub zewnętrznym),
• monitoring 24/7.
  

• Zapewnić bezpieczeństwo systemów i sieci, to jest:
  

• segmentację sieci (oddzielenie aparatury medycznej od administracji),
• kontrolę dostępu (role, MFA),
• szyfrowanie danych,
• regularne aktualizacje systemów,
• testy penetracyjne.

• Zapewnić szkolenia personelu, to jest:
  

• regularne szkolenia pracowników,
• budowanie świadomości,
• ćwiczenia symulacyjne.

W praktyce – personel medyczny i administracyjny musi wiedzieć:

• jak rozpoznać podejrzany e-mail,
• komu zgłosić incydent,
• czego nie robić na służbowym sprzęcie.
  

Co to oznacza finansowo i organizacyjnie?

Dla dyrektora – musi wpisać cyberbezpieczeństwa do budżetu nie jako koszt IT, ale jako:

• element zarządzania ryzykiem operacyjnym,
• element bezpieczeństwa pacjenta,
• element zgodności regulacyjnej.
  

Należy zwrócić uwagę na zasadę proporcjonalności – to znaczy, że szpital musi mieć system adekwatny do skali działalności i ryzyk, czyli może, ale nie musi, mieć rozbudowany dział cyberbezpieczeństwa.

Jak dyrektor powinien to uporządkować krok po kroku?

• Powołać osobę odpowiedzialną za cyberbezpieczeństwo.
• Zlecić audyt zgodności z NIS2.
• Zaktualizować rejestr ryzyk.
• Wprowadzić formalny plan ciągłości działania.
• Zweryfikować umowy z dostawcami.
• Wprowadzić cykliczny raport do dyrekcji.

2.3. Obowiązki raportowe (art. 23 NIS2)

Zgodnie z art. 23 dyrektywy NIS2 podmiot objęty regulacją ma obowiązek nie tylko zarządzać ryzykiem, ale również raportować poważne incydenty bezpieczeństwa w ściśle określonych ramach czasowych. W realiach szpitala oznacza to konieczność posiadania sprawnego, całodobowego mechanizmu wykrywania, klasyfikowania i dokumentowania zdarzeń. Nie jest to obowiązek formalny. To obowiązek operacyjny.

• Wstępne ostrzeżenie – do 24 godzin. Pierwszy próg raportowy ma charakter sygnalny.
  

W ciągu 24 godzin od wykrycia incydentu szpital powinien przekazać wstępne ostrzeżenie zawierające:

• informację o wystąpieniu incydentu,
• jego wstępną klasyfikację (np. podejrzenie ransomware, naruszenie poufności danych),
• wstępny zakres oddziaływania (czy dotyczy systemów klinicznych, administracyjnych, infrastruktury),
• informację, czy incydent może mieć charakter transgraniczny,
• pierwsze działania podjęte w celu ograniczenia skutków.
  

Kluczowe jest pojęcie „moment wykrycia”. Dlatego bez stałego monitoringu (SOC 24/7) organizacja często nie jest w stanie jednoznacznie wskazać, kiedy incydent się rozpoczął ani kiedy został zauważony.

24 godziny to bardzo krótki czas – w praktyce oznacza to konieczność:

• natychmiastowej eskalacji incydentu do kierownictwa,
• uruchomienia procedury kryzysowej,
• zabezpieczenia materiału dowodowego (logi, kopie systemów),
• podjęcia decyzji o zgłoszeniu.

• Zgłoszenie właściwe – do 72 godzin
  

Drugi etap raportowania ma charakter pogłębiony. W ciągu 72 godzin od wykrycia incydentu należy przekazać bardziej szczegółowe informacje, w tym:

• potwierdzoną klasyfikację incydentu,
• opis jego przyczyn (jeśli są znane),
• szacunkową skalę naruszenia (liczba systemów, potencjalnie objęte dane),
• wpływ na działalność operacyjną (np. wstrzymanie przyjęć, opóźnienia zabiegów),
• podjęte środki naprawcze,
• wstępną ocenę skutków dla pacjentów i interesariuszy.
  

Na tym etapie konieczna jest współpraca:

• zespołu IT/SOC,
• kierownictwa medycznego,
• działu prawnego,
• osoby odpowiedzialnej za ochronę danych (jeśli dotyczy danych osobowych).
  

To moment, w którym raport przestaje być techniczny, a staje się dokumentem zarządczym.

• Raport końcowy – do miesiąca. Raport końcowy ma charakter analityczny i naprawczy.
  

Powinien zawierać:

• pełny opis przebiegu incydentu (oś czasu),
• potwierdzoną przyczynę źródłową,
• rzeczywistą skalę naruszenia,
• skutki operacyjne i finansowe,
• ocenę wpływu na bezpieczeństwo pacjentów,
• wdrożone działania korygujące,
• plan zapobiegania podobnym zdarzeniom w przyszłości.
  

To dokument, który w praktyce staje się elementem:

• audytu wewnętrznego,
• przeglądu systemu zarządzania ryzykiem,
• raportowania do organu tworzącego lub rady nadzorczej.
  

• Co oznacza „incydent podlegający raportowaniu”? Nie każde zdarzenie wymaga zgłoszenia.
  

Raportowaniu podlegają incydenty mające istotny wpływ na:

• świadczenie usług zdrowotnych,
• poufność, integralność lub dostępność danych,
• stabilność infrastruktury krytycznej.

W szpitalu mogą to być między innymi:

• zablokowanie systemu HIS,
• utrata dostępu do EDM,
• wyciek danych medycznych,
• sparaliżowanie systemu laboratoryjnego,
• długotrwała niedostępność systemu rejestracji.
  

• Gotowość organizacyjna – warunek realnego spełnienia art. 23, aby zmieścić się w ustawowych terminach.
  

Szpital musi posiadać:

• Jasną strukturę odpowiedzialności, to jest:
  

• kto wykrywa incydent,
• kto go klasyfikuje,
• kto podejmuje decyzję o zgłoszeniu,
• kto podpisuje raport.
  

• Całodobowy monitoring (SOC 24/7). Bez 24/7:

• incydent może zostać zauważony po wielu godzinach,
• moment wykrycia stanie się niejednoznaczny,
• raport będzie oparty na domysłach.
  

• Procedurę eskalacji:
  

• ścieżka powiadamiania kierownictwa,
• tryb pracy zespołu kryzysowego,
• wzór komunikatu wewnętrznego.
  

• Dokumentowanie zdarzeń:
  

• archiwizacja logów,
• zabezpieczenie nośników,
• odtworzenie osi czasu.
  

6. Perspektywa zarządcza

Art. 23 nie jest przepisem informatycznym, to przepis o odpowiedzialności organizacyjnej. Jeżeli incydent trwał kilka dni, a szpital dowiedział się o nim dopiero po paraliżu systemu, regulator może uznać, że problemem nie był wyłącznie atak, lecz brak adekwatnego nadzoru. W tym sensie obowiązki raportowe są testem dojrzałości systemu zarządzania ryzykiem.

Podmiot objęty regulacją ma obowiązek:

• przekazać wstępne ostrzeżenie w ciągu 24 godzin,
• dokonać zgłoszenia w ciągu 72 godzin,
• przedłożyć raport końcowy w ciągu miesiąca.
  

Wymaga to gotowości organizacyjnej, jasno określonych ról oraz całodobowego monitorowania.

2.4. Odpowiedzialność kierownictwa (art. 20 NIS2)

Art. 20 dyrektywy NIS2 wprowadza jedną z najistotniejszych zmian systemowych: odpowiedzialność za cyberbezpieczeństwo spoczywa na organie zarządzającym. Nie jest to już wyłącznie domena działu IT ani informatyka szpitalnego. To element nadzoru menedżerskiego.

W praktyce oznacza to, że dyrektor – jako osoba zarządzająca podmiotem leczniczym – musi wykazać, że system bezpieczeństwa jest:

• świadomie zaprojektowany,
• formalnie zatwierdzony,
• realnie nadzorowany,
• okresowo oceniany.
  

Nie chodzi o wiedzę techniczną. Chodzi o nadzór organizacyjny.

• „Zna kluczowe ryzyka” – co to znaczy w praktyce? Dyrektor nie musi znać konfiguracji zapory sieciowej.
  

Powinien natomiast wiedzieć:

• które systemy są krytyczne dla funkcjonowania szpitala (HIS, EDM, laboratorium, blok operacyjny),
• jakie są najpoważniejsze scenariusze zagrożeń (na przykład ransomware, utrata dostępu do danych, wyciek dokumentacji),
• jak długo szpital może funkcjonować w trybie awaryjnym,
• jakie byłyby skutki dla pacjentów i kontraktu z NFZ.
  

• „Zatwierdził adekwatne środki” – czyli decyzja zarządcza.
  

Art. 20 wymaga, aby środki zarządzania ryzykiem były formalnie zatwierdzone przez kierownictwo.

W praktyce oznacza to:

• przyjęcie polityki bezpieczeństwa informacji,
• zatwierdzenie planu ciągłości działania,
• decyzję o wdrożeniu monitoringu (na przykład SOC 24/7),
• zapewnienie budżetu na zabezpieczenia,
• akceptację poziomu ryzyka resztkowego.
  

Z perspektywy kontroli oznacza to możliwość wykazania:

• zarządzenia,
• protokołu narady,
• zatwierdzonego planu działania.

• „Nadzorował wdrożenie” – czyli kontrola, nie tylko podpis. Zatwierdzenie dokumentu to dopiero początek.
  

Dyrektor musi wykazać, że system rzeczywiście funkcjonuje. Oznacza to między innymi:

• sprawdzenie, czy kopie zapasowe są testowane,
• czy przeprowadzono szkolenia personelu,
• czy monitoring działa 24/7,
• czy przeprowadzono testy awaryjne,
• czy zidentyfikowane luki zostały usunięte.
  

Nadzór może przybrać formę:

• kwartalnego przeglądu bezpieczeństwa,
• raportu od osoby odpowiedzialnej za cyberbezpieczeństwo,
• prezentacji wyników audytu.
  

Kluczowe jest to, że kierownictwo nie może pozostawać bierne.

• „Otrzymuje cykliczne raporty” – system informacji zarządczej.
  

Cyberbezpieczeństwo powinno być włączone do systemu raportowania tak samo jak:

• wynik finansowy,
• realizacja kontraktu,
• wskaźniki jakości.

Raport dla dyrektora powinien zawierać między innymi:

• liczbę incydentów w danym okresie,
• poziom ryzyka w obszarach krytycznych,
• status wdrażanych działań naprawczych,
• wyniki testów bezpieczeństwa,
• poziom zgodności z NIS2.

To pozwala dyrektorowi wykazać, że:

• monitoruje sytuację,
• podejmuje decyzje,
• reaguje na nieprawidłowości.

• Czego nie wolno robić?
  

Delegować odpowiedzialności na pracownika IT. Dyrektywa jednoznacznie wskazuje, że odpowiedzialność organu zarządzającego nie może zostać przeniesiona wyłącznie na dział IT.

• Co powinien mieć dyrektor „w teczce”?
  

Aby wykazać zgodność z art. 20, warto posiadać:

• zatwierdzoną politykę bezpieczeństwa informacji,
• rejestr ryzyk cybernetycznych,
• plan ciągłości działania,
• procedurę reagowania na incydenty,
• dowody przeglądu i nadzoru (protokoły, raporty kwartalne),
• dokument potwierdzający wyznaczenie osoby odpowiedzialnej.
  

2.5. Sankcje

System sankcyjny wynikający z dyrektywy NIS2 ma charakter dwuetapowy: obejmuje zarówno podmiot (szpital), jak i – w określonych sytuacjach – kierownictwo.

Kluczowe jest rozróżnienie: sankcja nie jest nakładana za sam fakt wystąpienia incydentu, lecz za brak wdrożenia adekwatnych środków zarządzania ryzykiem lub niewykonanie obowiązków raportowych i nadzorczych.

Sankcje wobec podmiotu (szpitala)

W sektorach kluczowych kara administracyjna może sięgać do 10 mln euro lub do 2 proc. całkowitego rocznego światowego obrotu. W sektorach ważnych – do 7 mln euro lub do 1,4 proc. obrotu.

Sankcje mogą być stosowane między innymi, gdy:

• nie wdrożono środków zarządzania ryzykiem (art. 21),
• nie dopełniono obowiązków raportowych (art. 23),
• nie zapewniono nadzoru kierownictwa (art. 20),
• nie wykonano zaleceń organu nadzorczego.
  

W praktyce organ nadzorczy najpierw może wydać zalecenia lub nakaz usunięcia nieprawidłowości. Kara finansowa jest środkiem ostatecznym – stosowanym przy poważnych lub uporczywych naruszeniach.

Sankcja osobista – do 600 proc. wynagrodzenia

Polskie przepisy wdrażające NIS2 przewidują możliwość nałożenia administracyjnej kary pieniężnej bezpośrednio na kierownika podmiotu. Maksymalna wysokość kary może wynieść do 600 proc. miesięcznego wynagrodzenia brutto tej osoby. Oznacza to, że przy wynagrodzeniu np. 30 000 zł brutto miesięcznie kara może sięgnąć do 180 000 zł. To odrębny mechanizm od sankcji wobec szpitala.

Kiedy dyrektor może zostać ukarany osobiście?

Kara osobista nie jest nakładana za incydent.

Może zostać zastosowana, gdy organ stwierdzi, że kierownik:

• nie zapewnił wdrożenia wymaganych środków bezpieczeństwa,
• nie nadzorował ich realizacji,
• nie zgłosił incydentu mimo obowiązku,
• ignorował zalecenia pokontrolne,
• dopuścił się rażącego niedbalstwa w zakresie nadzoru.

Ważne jest wykazanie zawinionego zaniechania.

Jeżeli dyrektor potrafi udokumentować, że:

• znał kluczowe ryzyka,
• zatwierdził adekwatne środki,
• otrzymywał raporty,
• reagował na nieprawidłowości, ryzyko osobistej sankcji znacząco maleje – nawet w przypadku poważnego incydentu.
  

Najczęstsze złudzenie: „kupiliśmy system”

W praktyce często obserwujemy schemat: pozyskano finansowanie, zakupiono system zarządzania zdarzeniami bezpieczeństwa (Security Information and Event Management – SIEM), podpisano umowę na Centrum Operacji Bezpieczeństwa (Security Operations Center – SOC), a następnie uznano temat za zakończony. Technologia bez procesu nie zapewnia bezpieczeństwa.

Cyberodporność wymaga:

• stałego monitorowania,
• reagowania w czasie rzeczywistym,
• testów odtworzeniowych,
• ćwiczeń symulacyjnych,
• raportowania do zarządu.
  

Przepisy wdrażające dyrektywę NIS2 przewidują możliwość nałożenia na kierownika podmiotu administracyjnej kary pieniężnej do 600 proc. miesięcznego wynagrodzenia brutto, jeżeli nie dopełni obowiązków nadzorczych. Odpowiedzialność dotyczy braku systemu i braku nadzoru – nie samego incydentu.
Przygotowaliśmy krótką listę pytań, które powinien zadać sobie dyrektor. Jeżeli na większość poniższych pytań odpowiedź brzmi „nie”, należy pilnie pogłębić nadzór.

Dziesięć pytań kontrolnych:

1. Czy posiadam aktualny i formalnie zatwierdzony rejestr ryzyk cybernetycznych?
2. Czy wiem, które trzy systemy są krytyczne dla ciągłości leczenia (HIS, EDM, laboratorium, blok operacyjny)?
3. Czy zatwierdziłem politykę bezpieczeństwa oraz plan ciągłości działania (BCP/DRP)?
4. Czy funkcjonuje całodobowy monitoring bezpieczeństwa (SOC 24/7 – wewnętrzny lub zewnętrzny)?
5. Czy mam pewność, że incydenty są wykrywane w czasie rzeczywistym, a nie dopiero po paraliżu systemu?
6. Czy istnieje jasna procedura raportowania incydentów w terminach 24 h/72 h/30 dni?
7. Czy w ostatnich 12 miesiącach przetestowano odtworzenie systemów z kopii zapasowych?
8. Czy personel był szkolony z zakresu phishingu i podstaw cyberbezpieczeństwa?
9. Czy umowy z dostawcami IT zawierają zapisy o odpowiedzialności i reagowaniu na incydenty?
10. Czy otrzymuję cykliczne raporty dotyczące poziomu cyberbezpieczeństwa i statusu działań naprawczych?
    

Jeśli na większość pytań odpowiemy „tak” – system nadzoru prawdopodobnie funkcjonuje prawidłowo.

Większość odpowiedzi „nie” – istnieje istotne ryzyko regulacyjne i osobiste.

Szczególnie alarmujące są odpowiedzi „nie” przy pytaniach dotyczących:

• SOC 24/7,
• testów kopii zapasowych,
• raportowania do dyrektora.
  

Brak monitoringu całodobowego w realiach NIS2 może zostać uznany za brak adekwatnych środków zarządzania ryzykiem.

Podsumowanie

Realizacja procesu cyberbezpieczeństwa w szpitalu nie jest wyłącznie wypełnianiem obowiązków, jakie narzucają dyrektywa NIS2 oraz przepisy krajowe. Nie jest też jedynie próbą uniknięcia sankcji – nawet tak dotkliwych jak kara do 600 proc. wynagrodzenia kierownika podmiotu.

W dobie cyfryzacji ochrony zdrowia cyberbezpieczeństwo staje się fundamentem funkcjonowania szpitala – na równi z bezpieczną i jakościową realizacją procesów leczenia pacjentów. Jeżeli systemy informatyczne przestają działać, przestaje działać również organizacja kliniczna. Jeżeli dane nie są chronione, zagrożone jest zaufanie, ciągłość świadczeń i stabilność finansowa. Dyrektywa wprowadza procedury, których należy przestrzegać: analizę ryzyka, nadzór kierownictwa, raportowanie incydentów, zapewnienie ciągłości działania. Jednak regulacja nie rozwiązuje najtrudniejszego problemu – jak zbudować i utrzymać realny, trwały model cyberbezpieczeństwa w warunkach ograniczonych zasobów. Na pierwszym etapie transformacji można spodziewać się wsparcia finansowego – na przykład z funduszy takich jak Krajowy Plan Odbudowy. Pozwoli to wdrożyć infrastrukturę, przeprowadzić audyty, zakupić narzędzia, uruchomić monitoring. Finansowanie projektowe ma jednak charakter czasowy.

System musi działać również po zakończeniu programów wsparcia, a to oznacza konieczność:

• utrzymania wysoko wyspecjalizowanych kompetencji,
• finansowania szkoleń i certyfikacji,
• zapewnienia ciągłego rozwoju kadry,
• konkurowania o specjalistów z rynkiem komercyjnym.

Powstają więc pytania zasadnicze:

• Skąd pozyskać wykwalifikowanych specjalistów cyberbezpieczeństwa w realiach niedoboru kadr?
• Jak finansować ich rozwój, certyfikację i utrzymanie kompetencji?
• Jak budować trwały model bezpieczeństwa po zakończeniu środków projektowych?
• Czy w warunkach rosnącej presji kosztowej i wykluczenia części personelu medycznego z systemu podwyżek płac realne jest równoległe zwiększanie nakładów na wysoko wyspecjalizowane zespoły IT?
• Jak utrzymać równowagę między bezpieczeństwem cyfrowym a stabilnością organizacyjną całej kadry?
  

Nie ma jednej odpowiedzi.

Każdy podmiot będzie musiał podjąć decyzję strategiczną: czy buduje kompetencje wewnętrznie (make), czy korzysta z wyspecjalizowanych usług zewnętrznych (buy) – szczególnie w obszarach takich jak monitoring 24/7, analiza incydentów czy testy penetracyjne.

To nie jest decyzja techniczna. To decyzja zarządcza, która determinuje strukturę kosztów, odpowiedzialność oraz poziom kontroli nad ryzykiem.

Naszą intencją było pokazanie procesu zabezpieczania danych nie jako obowiązku regulacyjnego, lecz jako elementu jakości zarządzania. Od jakości zarządzania cyberbezpieczeństwem coraz częściej zależy zdolność szpitala do realizacji swojej podstawowej misji. Odejście od wąsko rozumianej perspektywy prawnej było świadome. W obecnym momencie sektor ochrony zdrowia potrzebuje nie tylko interpretacji przepisów, lecz także refleksji strategicznej.

Każdy szpital będzie musiał się z tym zmierzyć. Nie dlatego, że wymaga tego dyrektywa. Dlatego, że bez odporności cyfrowej nie ma dziś bezpiecznego i stabilnego leczenia.

Tekst Jarosława Kozery, właściciela firmy JS Konsulting Jarosław Kozera i byłego prezesa Stowarzyszenia Menedżerów Opieki Zdrowotnej STOMOZ, oraz Magdaleny Kozery, analityka biznesowego z JS Konsulting, pochodzi z „Menedżera Zdrowia” 1/2026.

Przeczytaj także: „KSC – kogo obejmuje?” i „Dlaczego lokalne lecznice przegrywają finansowo?”.