KSC w placówce medycznej: co zrobić do 3 kwietnia 2027 i jak to utrzymać po tej dacie

Szpital powiatowy, początek października 2026. Kierownik IT melduje dyrektorowi, że wniosek o wpis do wykazu podmiotów kluczowych i ważnych jest złożony, więc sprawa załatwiona. Na biurku leży segregator z polityką bezpieczeństwa sprzed kilku lat. W sieci pracują analizatory i aparatura, o których dział IT nie wie, jaki mają system i kto łączy się z nimi zdalnie. Dostawca systemu szpitalnego loguje się do serwera kontem „serwis”, które od lat zna kilku jego techników. Kopia bazy robi się co noc, ale nikt nie pamięta, kiedy ktoś ostatnio coś z niej odtworzył. W czwartek o 23:40 program antywirusowy wysyła alarm na skrzynkę informatyka, który o tej porze śpi.

Wpis do wykazu niczego w tym obrazku nie zmienił. Obowiązki z ustawy o krajowym systemie cyberbezpieczeństwa powstają z mocy prawa, a wykaz tylko potwierdza, że placówka im podlega. Papier przyjmie wszystko. Atak nie.

Dla kogo i jak czytać. Poradnik jest dla szpitali, sieci przychodni i dużych przychodni objętych ustawą oraz dla placówek, które nie wiedzą, czy ustawa je obejmuje. Dyrektor i zarząd spółki zaczynają od kalendarza, statusu i rozdziału o kierowniku, a rozdziały od spisu systemów do monitoringu przekazują działowi IT. Kierownik IT czyta całość po kolei, bo każdy rozdział korzysta ze spisu. Przychodnia, która po rozdziale o statusie wie, że jest poza ustawą, bierze rozdziały o dostawcach, kontach i kopiach danych poza produkcją, bo te obowiązki wynikają też z RODO. Gabinet ma swoją część w rozdziale o skali. Przed rozdziałem o skali jest test w dziesięciu pytaniach na jedno spotkanie dyrekcji z działem IT. Stan prawny na 29.09.2026.

Kalendarz: 3 października 2026, 3 kwietnia 2027, 3 kwietnia 2028

Ustawa z 23 stycznia 2026 o zmianie ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252) weszła w życie 3 kwietnia 2026. Terminy wynikają z jej przepisów przejściowych i z harmonogramu Ministerstwa Cyfryzacji na gov.pl.

Termin 3 kwietnia 2027 dotyczy podmiotów, które spełniały przesłanki podmiotu kluczowego albo ważnego w dniu wejścia nowelizacji w życie. Placówka, która spełni je później, na przykład po przekroczeniu 50 zatrudnionych, składa wniosek o wpis w 6 miesięcy (art. 7c ust. 1 ustawy o KSC), wdraża obowiązki w 12 miesięcy, a podmiot kluczowy robi pierwszy audyt w 24 miesiące od tego dnia (art. 16). S46 to system, przez który przekazuje się wczesne ostrzeżenia, zgłoszenia i sprawozdania o incydentach (art. 11 ust. 2 ustawy o KSC).

Szpital, który przed nowelizacją był operatorem usługi kluczowej, z dniem jej wejścia w życie stał się podmiotem kluczowym (art. 22 ust. 1 nowelizacji) i minister wpisał go do wykazu z urzędu (art. 34 ust. 2), więc samorejestracja go nie dotyczy; dane we wpisie sprawdza sam. Ma też inny kalendarz w dwóch sprawach. Incydenty poważne zgłasza według nowych zasad w terminie 6 miesięcy od wejścia nowelizacji w życie, czyli najpóźniej od 3 października 2026 (art. 33 ust. 4 nowelizacji). Audyt robi w swoim dotychczasowym cyklu, co najmniej raz na 3 lata licząc od raportu z ostatniego audytu, a nie dopiero do 3 kwietnia 2028 (art. 15 ust. 1 ustawy o KSC). Harmonogram Ministerstwa Cyfryzacji podaje termin 3 kwietnia 2028 tylko dla podmiotów kluczowych, które nie były operatorami, a art. 25 nowelizacji wyłącza wobec operatorów, którzy wykonali audyt, termin pierwszego audytu z art. 16 pkt 2 ustawy o KSC. Do czasu wdrożenia nowego systemu zarządzania bezpieczeństwem stosuje dotychczasowy (art. 33 ust. 6 nowelizacji).

Brak wpisu nie zwalnia z obowiązków. Jeśli placówka spełnia przesłanki, a nie ma jej w wykazie, wniosek składa się także po 3 października 2026, przed wszystkimi innymi krokami. Rok od 3 kwietnia 2027 do 3 kwietnia 2028 nie jest przedłużeniem okresu dostosowawczego: obowiązki już działają, a w tym roku powstają protokoły, które obejrzy audytor i organ.

Plan na sześć miesięcy

Tabela zakłada start w październiku 2026. Kto zaczyna później, robi te same kroki w tej samej kolejności, w krótszych odstępach, bo każdy krok korzysta z poprzedniego.

Dokumenty są w styczniu, a nie w październiku. Polityka pisana przed spisem i testem opisuje placówkę, której nie ma. Po trzech miesiącach pracy jest krótka, bo zapisuje to, co już ustaliliście i sprawdziliście. Tę samą kolejność ma Lista kontrolna KSC: gotowość szpitala na 3 kwietnia 2027 (PDF), 24 punkty z opisem dowodu przy każdym.

Po 3 kwietnia 2027: rytm, który utrzymuje obowiązki

Ustawa wymaga dokumentacji operacyjnej, czyli zapisów, które potwierdzają, że czynności opisane w dokumentach faktycznie się wykonuje (art. 10 ust. 4). Protokoły z tej tabeli są takimi zapisami. Polityka z 2027 roku bez protokołów z 2028 roku niczego nie dowodzi.

Czy ustawa was obejmuje: podmiot kluczowy, ważny czy poza ustawą

Załącznik nr 1 do ustawy, w sektorze ochrony zdrowia, wymienia podmiot leczniczy w rozumieniu art. 4 ust. 1 ustawy o działalności leczniczej. O statusie decydują forma prawna i wielkość (art. 5 ustawy o KSC), liczone dla całego podmiotu, który prowadzi placówki, a nie dla jednej lokalizacji.

Progi przedsiębiorcy pochodzą z załącznika I do rozporządzenia Komisji (UE) nr 651/2014. Mały przedsiębiorca zatrudnia mniej niż 50 osób, a jego roczny obrót albo suma bilansowa nie przekracza 10 mln euro. Średni zatrudnia mniej niż 250 osób, a jego obrót nie przekracza 50 mln euro albo suma bilansowa 43 mln euro. SPZOZ liczy samo zatrudnienie. Przesłanki bada się według stanu na dzień sporządzenia sprawozdania finansowego (art. 5 ust. 5).

Mikro i mały przedsiębiorca oraz SPZOZ zatrudniający mniej niż 50 osób co do zasady są poza ustawą. „Co do zasady”, bo organ może decyzją uznać mniejszy podmiot z załącznika za podmiot kluczowy, na przykład gdy jako jedyny świadczy usługę o kluczowym znaczeniu (art. 7l ust. 1 i ust. 2 pkt 1; ochrona zdrowia jest w załączniku nr 1). Indywidualna praktyka lekarska nie jest podmiotem leczniczym (art. 2 ust. 1 pkt 5 ustawy o działalności leczniczej). Załącznik wymienia wprawdzie także podmioty udzielające świadczeń jako podwykonawcy podmiotów kluczowych i ważnych, ale i wtedy o statusie decyduje wielkość, więc praktyka lekarska jako mikroprzedsiębiorca co do zasady pozostaje poza ustawą.

Do progów spółki wlicza się co do zasady przedsiębiorstwa powiązane i partnerskie (art. 6 ust. 2 do 4 załącznika I do rozporządzenia 651/2014), więc mała przychodnia w dużej grupie może być podmiotem ważnym albo kluczowym. Wyjątek: spółka, której system informacyjny jest niezależny od systemów spółek powiązanych albo która nie świadczy z nimi usług wspólnie, nie staje się z powodu tego doliczenia podmiotem ważnym ani kluczowym (art. 5 ust. 6 i 7 ustawy o KSC).

Instytut badawczy, który prowadzi szpital, wymaga oceny indywidualnej z prawnikiem: instytuty badawcze należą do sektora podmiotów publicznych w załączniku nr 1, a taki podmiot publiczny jest podmiotem kluczowym bez względu na wielkość (art. 5 ust. 1 pkt 4 lit. d). Samorządowa jednostka budżetowa i spółka gminy albo powiatu wykonująca zadania o charakterze użyteczności publicznej może być podmiotem ważnym bez względu na wielkość, jeśli realizuje zadanie publiczne z użyciem systemów informacyjnych (art. 5 ust. 2 pkt 8 i załącznik nr 2). Placówka w takiej formie wymaga oceny indywidualnej z prawnikiem. SPZOZ nie jest podmiotem publicznym w rozumieniu ustawy o KSC, bo definicja z art. 2 pkt 11b go nie obejmuje. Szpital prowadzony jako SPZOZ stosuje więc pełny system zarządzania bezpieczeństwem z art. 8 ust. 1 i pełny tryb zgłaszania incydentów, a nie rozwiązania dla podmiotu ważnego będącego podmiotem publicznym (art. 8 ust. 3, art. 12c).

Od statusu zależą dwie rzeczy. Audyt co najmniej raz na 3 lata robi tylko podmiot kluczowy; podmiotowi ważnemu organ może go nakazać decyzją po incydencie poważnym albo innym naruszeniu ustawy, a kluczowemu w każdym czasie (art. 15 ust. 1 i 1b). Od statusu zależy też górna granica kar dla podmiotu (art. 73 ust. 3 i 4). System zarządzania bezpieczeństwem, zgłaszanie incydentów, szkolenie kierownika i jego odpowiedzialność są dla obu takie same.

We wpisie do wykazu są między innymi osoby do kontaktu i informacja o umowie z dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa (art. 7 ust. 2 pkt 11 i 16). Zmianę zgłasza się w 14 dni (art. 7c ust. 3), więc zmiana dyrekcji, informatyka albo firmy monitorującej to także zmiana wpisu.

Dowodem statusu jest notatka z wyliczeniem: forma prawna, zatrudnienie, w spółce obrót i suma bilansowa razem z grupą, data sprawozdania finansowego, wynik i podpis kierownika. Wyliczenie robią kadry i księgowość.

Spis systemów z właścicielem: pierwszy dokument, nie ostatni

Na pytanie, kto poza własnym informatykiem ma dostęp do serwera laboratorium, w placówce bez spisu każdy zna swój kawałek, a nikt całości. Audytor zacznie od całości.

System zarządzania bezpieczeństwem informacji ma zapewniać szacowanie ryzyka (art. 8 ust. 1 pkt 1 ustawy o KSC), zarządzanie aktywami (pkt 2 lit. m), polityki kontroli dostępu (lit. n) i bezpieczeństwo łańcucha dostaw (lit. e). Żadnego z tych punktów nie da się wykonać bez listy tego, co placówka ma. Spis jest też surowcem dokumentacji normatywnej z charakterystyką usługi i infrastruktury (art. 10 ust. 3 pkt 2 lit. a i pkt 4).

Audytu nie może przeprowadzić osoba, która realizuje w podmiocie zadania z art. 8 albo art. 9 do 13 albo robiła to w roku przed audytem (art. 15 ust. 2a). Spis obroni się więc tylko wtedy, gdy obca osoba zrozumie go bez tłumaczenia: z datami weryfikacji, nazwiskami i bez skrótów znanych tylko w dziale IT. Wzoru spisu przepisy nie podają, a rozporządzenie z art. 8a ze szczegółowymi wymaganiami nie zostało wydane (stan na 29.09.2026). Pięć arkuszy poniżej to praktyka.

Co wchodzi do spisu

Każdy wiersz ma datę ostatniej weryfikacji i nazwisko osoby, która ją zrobiła.

1. Systemy: nazwa, proces, który obsługuje, właściciel po stronie placówki, dostawca, wersja, gdzie działa, z czym wymienia dane i jak placówka wyciąga z niego swoje dane.
2. Infrastruktura: serwery i maszyny wirtualne, system operacyjny i baza danych z wersjami, data końca wsparcia producenta, kopia zapasowa: gdzie leży i kiedy ostatnio ktoś z niej odtworzył system.
3. Konta i dostępy: konta administracyjne, serwisowe i techniczne, czy są imienne, czy mają uwierzytelnianie wieloskładnikowe (MFA); drogi zdalnego wejścia (VPN, programy do zdalnego pulpitu, łącza serwisowe aparatury); konta i certyfikaty do P1, portali NFZ i ZUS, banku, z datą ważności i osobą, która je odnawia.
4. Dostawcy i umowy: zakres, numer umowy, umowa powierzenia, sposób dostępu zdalnego, termin zgłoszenia placówce incydentu, kontakt awaryjny osiągalny w nocy, data końca umowy.
5. Urządzenia w sieci poza IT: aparatura, analizatory, monitoring wizyjny, system kolejkowy, kontrola dostępu do budynku, sterowanie wentylacją; przy każdym: kto serwisuje, czy ma zdalny dostęp, w jakiej części sieci pracuje, czy producent pozwala na aktualizacje.

Kolumna o danych w arkuszu systemów ma cel. Dane wprowadzone do systemu i w nim wytworzone należą do placówki, oprogramowanie jest na licencji. Jeśli przy którymś systemie nikt nie potrafi wpisać, jak wyciągnąć z niego dane, to pierwsze ryzyko do analizy; jak zapisać wyjście w umowie, opisuje poradnik o umowie z dostawcą. Właścicielem systemu nie jest „dział IT”. Informatyk utrzymuje serwer, ale o tym, ile godzin przestoju laboratorium jest do przyjęcia, decyduje kierownik laboratorium z dyrektorem.

Tydzień pracy

Pierwsza wersja spisu wymaga tygodnia, w którym kierownik IT ma zgodę dyrektora na odmawianie drobnych zleceń, i jednej osoby do pomocy, choćby z działu aparatury. Po tygodniu spis będzie miał wiersze ze znakami zapytania i nazwiska osób, które mają je wyjaśnić. To wystarczy do analizy ryzyka.

W poniedziałek procesy: każda komórka mówi, z jakich programów korzysta. Wyjdzie więcej systemów, niż zna dział IT, a arkusz z makrami, bez którego rozliczenia nie zamkną miesiąca, też dostaje wiersz. We wtorek infrastruktura z sieci, nie z faktur: konsola wirtualizacji, serwer DHCP, skan adresów; podsieci z aparaturą skanujecie po uzgodnieniu z działem aparatury i poza godzinami badań, bo starsze urządzenie potrafi zawiesić się po agresywnym skanie. W środę konta, porównane z listą zatrudnionych i umów cywilnych, bo lekarze na kontraktach często odchodzą bez obiegówki; konto dostawcy bez umowy to decyzja dla dyrektora. W czwartek umowy i ich braki. W piątek systemy, bez których placówka nie przyjmie pacjenta, z szacowanym czasem odtworzenia, podpis dyrektora i aktualizacja spisu dopisana do procedury odbioru systemu i do obiegówki.

Spis to także mapa dla atakującego. Dostęp do niego ma wąska grupa osób, a jedna aktualna kopia leży poza siecią placówki, bo przy szyfrowaniu plik na serwerze zniknie razem z resztą. Spisu nie zlecajcie w całości firmie zewnętrznej: dobrze obsłuży skaner, ale nie wie, że apteka ma własny program na komputerze pod biurkiem.

W szpitalach, w których prowadziłem projekty, najrzadziej widziałem kompletną listę kont, którymi logują się dostawcy. Jeśli na cały tydzień nie ma zgody, od tego arkusza zacznijcie.

Kierownik podmiotu: szkolenie, odpowiedzialność i pierwsze pytania do IT

Spis mówi, co placówka ma. O tym, które ryzyka przyjmie, a na które wyda pieniądze, decyduje kierownik podmiotu. Kierownikiem podmiotu (art. 2 pkt 8a ustawy o KSC) jest kierownik jednostki według ustawy o rachunkowości, a w jednostce sektora finansów publicznych kierownik tej jednostki. W SPZOZ to zwykle dyrektor, w spółce członkowie zarządu (art. 3 ust. 1 pkt 6 ustawy o rachunkowości). Rada nadzorcza nie jest kierownikiem, pełnomocnicy są z definicji wyłączeni.

Kierownik podejmuje decyzje w sprawie systemu zarządzania bezpieczeństwem, planuje adekwatne środki finansowe, przydziela zadania i nadzoruje ich wykonanie, dba o to, żeby personel znał swoje obowiązki, i zapewnia zgodność z przepisami (art. 8d). Odpowiada za wykonywanie obowiązków w zakresie cyberbezpieczeństwa (art. 8c ust. 1), także wtedy, gdy powierzył je innej osobie za jej zgodą (art. 8c ust. 3). Gdy zarząd jest wieloosobowy i nie wskazano osoby odpowiedzialnej, odpowiadają wszyscy jego członkowie (art. 8c ust. 2). Powierzyć można zadania. Nadzór zostaje.

Szkolenie raz w roku kalendarzowym

Kierownik i osoba, której powierzono obowiązki kierownika w zakresie cyberbezpieczeństwa, przechodzą szkolenie raz w roku kalendarzowym, a udział musi być udokumentowany (art. 8e ust. 1 i 3). Przepis należy do obowiązków z rozdziału 3 ustawy, więc placówka w okresie dostosowawczym musi go wykonywać od 3 kwietnia 2027; szkolenie w marcu 2027, jak w planie, liczy się za rok 2027. Zakres ustawa wiąże z obowiązkami podmiotu, odsyłając między innymi do art. 8, 8d, 9 do 12b i 15 (art. 8e ust. 2). Nie mówi, ile szkolenie ma trwać ani kto ma je prowadzić, więc placówka może zrobić je na własnych systemach i ryzykach zamiast ogólnego kursu.

Sprawdza się jeden dzień w trzech częściach. Rano obowiązki kierownika i stan wdrożenia: co zrobione, czego brakuje, ile to kosztuje. Przed południem ćwiczenie przy stole: piątek, 15:30, na ekranach komunikat o zaszyfrowaniu; przebieg tej godziny opisuje poradnik o awarii. Po południu decyzje do protokołu, z terminami i nazwiskami. Przy stole siedzą kierownik, osoba z powierzonymi obowiązkami, kierownik IT, pielęgniarka naczelna i ktoś z finansów, więc jeden dzień zamyka obowiązek obu osób. Zewnętrzny prowadzący dostaje spis i analizę ryzyka, więc najpierw podpisuje zobowiązanie do poufności.

Szkolenie wpiszcie do kalendarza zarządu na stały miesiąc w pierwszej połowie roku; zrobione w grudniu spełnia literę przepisu, ale jego decyzje trafią do planu finansowego rok później. Szkolenie z 2026 roku nie obejmuje 2027. Gdy dyrektor zmienia się w trakcie roku, szkolenie poprzednika nie przechodzi na następcę, a gdy odchodzi osoba z powierzonymi obowiązkami, zarządzenie trzeba zmienić i uzyskać zgodę następcy.

Kara osobista bez mitów

To nie jest odpowiedzialność karna. Karę pieniężną nakłada decyzją organ właściwy do spraw cyberbezpieczeństwa (art. 74 ust. 1), dla ochrony zdrowia co do zasady minister właściwy do spraw zdrowia (art. 41 pkt 5), najwcześniej od 3 kwietnia 2028. Nie grozi tylko po ataku: katalog w art. 73a ust. 1 obejmuje między innymi niewykonanie obowiązków z art. 8 (pkt 2) i z art. 8d (pkt 3), brak szkolenia (pkt 4), brak osób do kontaktu (pkt 6) i niewykonanie obowiązków zgłoszeniowych (pkt 9), a kara jest możliwa także za zaniechanie jednorazowe (art. 73a ust. 2). Górną granicę liczy się od wynagrodzenia ukaranego (art. 73a ust. 4 i 5), a przy wysokości organ bierze pod uwagę między innymi możliwości finansowe kierownika (art. 76a ust. 1).

Sześć pytań do działu IT

Pytania nadają się dla nowego dyrektora w pierwszym tygodniu i dla każdego kierownika po szkoleniu. Przy każdym prosicie o dowód z datą, a nie o zapewnienie.

1. Co mamy, gdzie to działa i kto za to odpowiada? Dowodem jest spis.
2. Kiedy ostatnio odtworzyliście system z kopii i ile to trwało? Dowodem jest protokół; przebieg testu opisuje poradnik o infrastrukturze.
3. Kto zauważy atak w nocy i kto do mnie zadzwoni? Odpowiedź daje rozdział o monitoringu.
4. Kto z zewnątrz ma dostęp do naszych systemów i na jakiej umowie? Dowodem jest rejestr dostępów zdalnych (dostawcy).
5. Co się kończy w najbliższych 12 miesiącach? Umowy, licencje, wsparcie producenta, certyfikaty, z datą i kwotą netto; to wkład do planu finansowego z art. 8d pkt 2 i do budżetu IT, a systemy bez wsparcia opisuje poradnik o infrastrukturze.
6. Co się stanie, gdy jedna osoba z IT nie odbierze telefonu? Dowodem jest dokumentacja, z której zastępca poradził sobie sam podczas jej ostatniego urlopu (kto utrzymuje).

Jeśli na trzy pytania zespół odpowiada „sprawdzę”, macie plan pracy na kwartał. Nowy dyrektor nie zamawia w pierwszym miesiącu zewnętrznego audytu, bo firma opisze to, co usłyszy od tych samych ludzi.

Teczka kierownika zawiera program szkolenia, listę obecności, notatkę z odpowiedziami na sześć pytań, także tymi „nie wiemy”, decyzje z terminami i nazwiskami, zarządzenie albo uchwałę o powierzeniu obowiązków ze zgodą osoby, której je powierzono, i protokół ćwiczenia. Do tego informacja z Krajowego Rejestru Karnego w aktach osób, które realizują zadania z art. 8 lub 11; kierownik dopuszcza je do tych zadań po jej otrzymaniu (art. 8f ust. 1). Przepis nie robi wyjątku dla osób zatrudnionych przed nowelizacją.

Dostawcy w łańcuchu dostaw: ocena firm z dostępem zdalnym

System zarządzania bezpieczeństwem obejmuje bezpieczeństwo łańcucha dostaw produktów, usług i procesów ICT (art. 8 ust. 1 pkt 2 lit. e ustawy o KSC), z uwzględnieniem podatności związanych z każdym dostawcą i jakości jego usług (art. 8 ust. 2). Obowiązek jest placówki, nie dostawcy. RODO mówi to samo: administrator korzysta wyłącznie z podmiotów przetwarzających, które zapewniają wystarczające gwarancje (art. 28 ust. 1). Po sierpniowym wycieku danych z systemu jednego z dostawców oprogramowania medycznego do Prezesa UODO do 17 września 2026 wpłynęło ponad 2 tysiące zawiadomień od administratorów (komunikat UODO z 25 września 2026). Atak był u dostawcy, zgłaszały placówki; mechanizm opisuje poradnik o RODO.

Najpierw tabela, potem ocena

Ocena zaczyna się od arkusza dostawców ze spisu, rozszerzonego o kolumny: system, do którego dostawca ma dostęp, rodzaj konta, skąd się łączy, gdzie są dane i kopie, czy dotyka danych pacjentów, co się stanie, jeśli jego usługa zatrzyma się na dobę, i data ostatniej oceny. Pamięć działu IT tych kolumn nie wypełni. Zapomniane konta znajduje się w regułach zapory i VPN, w katalogu kont bez logowania od miesięcy i na stanowiskach, gdzie technik kiedyś zainstalował własny program do zdalnego pulpitu, który omija VPN i nie zostawia śladu w dziennikach placówki.

Taki rejestr zalecił CSIRT Centrum e-Zdrowia (CSIRT CeZ) razem z Ministerstwem Zdrowia w zaleceniach bezpieczeństwa przekazanych dostawcom oprogramowania w ochronie zdrowia 16 września 2026, z oceną przed współpracą i okresowo w jej trakcie. Zalecenia są adresowane do dostawców i nie są przepisem, ale placówka potrzebuje tej samej tabeli. Tabela ustala kolejność: najpierw dostawcy z dostępem do danych pacjentów i do systemów, bez których staje izba przyjęć. Serwis drukarek poczeka.

Cztery pytania do każdego dostawcy

Kto ma konto i jak jest chronione. Dostawca podaje imienną listę osób z dostępem i zgłasza każdą zmianę, a placówka raz na kwartał porównuje ją z kontami w swoich systemach, bo technik odchodzi od dostawcy, a jego konto u was działa dalej. Jak ma wyglądać samo konto serwisu, opisuje rozdział o kontach.

Gdzie leżą dane i kopie. Dostawca podaje na piśmie lokalizację serwerów, kopii i zespołu serwisowego; przekazanie danych poza Europejski Obszar Gospodarczy wymaga spełnienia warunków rozdziału V RODO (art. 44). Jeśli system działa u dostawcy, placówka powinna zobaczyć protokół testu odtworzenia, bo sama odpowiada za testowanie planów ciągłości i odtworzenia (art. 8 ust. 1 pkt 2 lit. f ustawy o KSC). „Robimy kopie codziennie” nie jest odpowiedzią. Odpowiedzią jest data ostatniego odtworzenia i czas, jaki zajęło.

Jak dostawca zgłasza incydent. Terminy zgłoszenia incydentu poważnego liczą się od wykrycia (dwa zegary), a gdy incydent zaczyna się u dostawcy, placówka wykrywa go często dopiero z jego powiadomienia. Umowa podaje więc czas powiadomienia w godzinach, krótszy niż 24 godziny, całodobowy kontakt po obu stronach i obowiązek przekazania dzienników potrzebnych do zgłoszenia. Podmiot przetwarzający zgłasza naruszenie administratorowi bez zbędnej zwłoki (art. 33 ust. 2 RODO).

Kto faktycznie wykonuje pracę. Serwis często robi podwykonawca, hosting inna firma. Dalszy podmiot przetwarzający wymaga uprzedniej pisemnej zgody administratora, szczegółowej albo ogólnej, a przy ogólnej informacji o zmianach i możliwości sprzeciwu (art. 28 ust. 2 RODO).

Ankieta to deklaracja, dowód to co innego

Na ankietę większość dostawców odpowie „tak” przy każdym punkcie. Ocena ma sens, gdy przy odpowiedzi jest dowód: lista imiennych kont z datą ostatniego logowania, zrzut konfiguracji dostępu zdalnego z MFA, protokół testu odtworzenia, wykaz podwykonawców, pisemna odpowiedź, jak dostawca stosuje zalecenia CSIRT CeZ. Pytania zebrał materiał Pytania do dostawcy oprogramowania medycznego (PDF). Drugi dowód placówka zbiera sama: próbne zgłoszenie w piątek o 20:00 na numer z umowy i przegląd dziennika logowań konta serwisowego za ostatni miesiąc. Godzina takiej pracy mówi więcej niż dwadzieścia stron ankiety.

Gdy dostawca nie spełnia wymagań

Systemu szpitalnego nie zmienia się w kwartał, a producent tomografu jest jeden, więc wynik oceny rzadko brzmi „wymieniamy”. Częściej placówka dokłada zabezpieczenia wokół dostawcy: dostęp tylko przez bramę placówki, połączenie włączane przez dział IT na zgłoszenie, serwer dostawcy w osobnym segmencie sieci. Braki i przyjęte zabezpieczenia trafiają do tabeli z datą ponownej oceny. Taki zapis pokazuje, że placówka zna ryzyko (art. 8 ust. 2), a wymiana dostawcy zostaje decyzją na koniec umowy.

Zapisy o incydencie, dziennikach, audycie, podwykonawcach i zwrocie danych wprowadza się aneksem albo przy przedłużeniu umowy; opisuje je poradnik o umowie z dostawcą, a punkt po punkcie Lista kontrolna umowy z dostawcą (PDF).

Konta, uwierzytelnianie wieloskładnikowe (MFA) i dostęp serwisu

Wspólne konto „rejestracja” z hasłem na karteczce pod blatem, lekarz po urlopie przyjmujący na loginie koleżanki, konto „pielęgniarki” zalogowane przy stanowisku od nocnej zmiany, aktywny login rezydenta, który skończył staż na oddziale. Każde z tych obejść powstało po to, żeby pacjent nie czekał. Skutek jest ten sam: w dokumentacji są wpisy, których autora nie da się ustalić.

System dokumentacji medycznej ma zapewniać identyfikację osoby, która dokonuje wpisu lub zmiany, zakres zmian i czas wpisu (§ 1 ust. 6 pkt 3 i 4 rozporządzenia Ministra Zdrowia w sprawie rodzajów, zakresu i wzorów dokumentacji medycznej oraz sposobu jej przetwarzania). Konto wspólne zapisze „rejestracja”, a nie człowieka; lekarz na koncie koleżanki zostawia wpis z nieprawdziwym autorem. RODO każe dobrać zabezpieczenia do ryzyka (art. 32 ust. 1), a podmiot kluczowy albo ważny ma do tego polityki kontroli dostępu i bezpieczne środki komunikacji uwzględniające uwierzytelnianie wieloskładnikowe w stosownych przypadkach (art. 8 ust. 1 pkt 2 lit. n i l ustawy o KSC). Stronę prawną upoważnień opisuje poradnik o RODO.

Luki, które wracają

Konta wspólne: „rejestracja”, „pielęgniarki”, „admin”. Konta osób, które odeszły, bo o odejściu wiedziały kadry, a informatyk nie. Informatyk czyta pocztę na koncie z pełnymi uprawnieniami do serwerów. Lokalne konto administratora ma to samo hasło na każdym komputerze. Poczta i VPN działają bez MFA. Wymuszana co miesiąc zmiana hasła tych luk nie zamyka; lepiej działa długie hasło zmieniane, gdy jest powód, i menedżer haseł dla kont serwisowych.

MFA: od czego zacząć

MFA to logowanie, w którym poza hasłem trzeba pokazać coś drugiego, na przykład kod z aplikacji albo klucz sprzętowy. Ustawa nie wymienia systemów, więc kolejność wynika z ryzyka: najpierw wszystko, do czego da się zalogować spoza placówki (poczta, VPN, panel usług w chmurze, zdalny pulpit), potem konta administracyjne (serwery, domena, kopie, zapora). Zalecenia CSIRT CeZ mówią o metodach odpornych na phishing co najmniej dla kont uprzywilejowanych: kod z SMS-a pracownik może przepisać na fałszywej stronie, a klucz sprzętowy sprawdza adres strony. Lekarz, który kilkadziesiąt razy dziennie wraca do systemu w sieci wewnętrznej, nie potrzebuje kodu przy każdym logowaniu. Potrzebuje własnego konta, blokady ekranu i szybkiego powrotu do sesji, na przykład kartą. MFA przy każdym stanowisku przy łóżku pacjenta skończy się obejściem.

Dostęp serwisu dostawcy

Zalecenia CSIRT CeZ o indywidualnych kontach i rejestrowanym dostępie serwisowym ograniczonym czasowo przekładają się w placówce na cztery zasady.

1. Każdy technik dostawcy ma własne konto. Konto „serwis” znika.
2. Dostęp jest domyślnie wyłączony. Włącza go wasz informatyk na czas zgłoszenia z numerem i wyłącza po jego zamknięciu.
3. Każda sesja zostawia ślad: kto, kiedy, skąd, do jakiego systemu i co w nim zrobił.
4. Program do zdalnego pulpitu nie działa na stałe na komputerze w rejestracji ani u kierownika.

Połączenie, którego nikt nie potrafi opisać, najpierw rozpoznajcie, a potem wyłączcie. W szpitalu może za nim stać wymiana wyników z laboratorium.

Przegląd kont i konto osoby, która odchodzi

Listy kont z każdego miejsca, do którego ktoś się loguje, porównujecie z listą osób z kadr, umów kontraktowych i umów ze studentami i agencjami. Przy każdym koncie ustalacie, czyje jest, czy ta osoba nadal pracuje, kiedy ostatnio się logowała i czy uprawnienia pasują do tego, co robi. Konta nieużywane wyłączacie, wspólne zastępujecie imiennymi, a konta administratorów rozdzielacie na konto do codziennej pracy i osobne konto administracyjne z MFA odpornym na phishing. Konto awaryjne na dzień, w którym nie działa logowanie, leży w zapieczętowanej kopercie, a każde jego użycie jest zapisane i przejrzane.

Konto osoby, która odchodzi, jest wyłączane w ciągu doby. Najlepiej, gdy wygasa samo, z datą końca umowy wpisaną przy zakładaniu, co jest najprostsze przy kontraktach, rezydentach i personelu z agencji. Przegląd kont robicie raz na kwartał, a porównanie logowań z datami końca umów raz w miesiącu, z zapisaną datą i wynikiem.

Dane pacjentów poza produkcją: kopie na serwerach testowych

Na pytanie inspektora ochrony danych, w ilu bazach są dane pacjentów, dział IT zwykle odpowiada: w jednej. Konsola wirtualizacji często pokazuje więcej: maszyny „test” po sprawdzaniu nowej wersji, po szkoleniu rezydentów, po uruchomieniu połączenia z laboratorium, każda z pełną bazą, kontem administratora z hasłem z dnia instalacji i bez wiersza w rejestrze czynności przetwarzania. Produkcja jest pilnowana, bo pracuje na niej oddział. Kopia jest zapomniana, bo nikt już na niej nie pracuje. Do tego dochodzą bazy przekazane dostawcy do analizy błędu i zrzuty na laptopach wdrożeniowców.

RODO nie zna pojęcia „dane testowe”. Dane spseudonimizowane, które przy użyciu dodatkowych informacji można przypisać osobie, nadal są danymi osobowymi (motyw 26 i art. 4 pkt 5 RODO), więc kopia podlega minimalizacji, ograniczeniu przechowywania i zasadzie poufności (art. 5 ust. 1 lit. c, e i f), a nieuprawniony dostęp do niej jest naruszeniem jak na produkcji (art. 4 pkt 12). Ustawa o prawach pacjenta dopuszcza przetwarzanie danych z dokumentacji przez osoby utrzymujące system na podstawie upoważnienia (art. 24 ust. 2). Test aktualizacji da się uzasadnić utrzymaniem systemu; szkolenie na prawdziwych kartach albo praca programisty nad nowym modułem wymagają zapisanej odpowiedzi inspektora ochrony danych, zanim kopia powstanie. Podmiot kluczowy albo ważny zapewnia też bezpieczeństwo rozwoju, utrzymania i testowania systemu (art. 8 ust. 1 pkt 2 lit. b ustawy o KSC), więc serwer testowy ma wiersz w spisie.

Trzy drogi zamiast jednej kopii

Pacjenci testowi przygotowani przez placówkę wystarczają do odbioru funkcji, szkoleń i większości testów aktualizacji, jeśli zestaw ma przypadki trudne: pacjenta bez numeru PESEL, noworodka, przeniesienie między oddziałami (odbiór systemu). Kopia spseudonimizowana służy testom, które potrzebują prawdziwej objętości danych: wydajności, raportów, rozliczeń; nadal ma konta imienne, dziennik i datę usunięcia. Pełna kopia produkcji jest dla zadań, których bez prawdziwych danych nie da się zrobić: testu odtworzenia, próbnej migracji, błędu występującego u jednego pacjenta. Dostaje wtedy zabezpieczenia produkcji i właściciela z imienia i nazwiska.

Odtworzona baza pamięta konfigurację produkcji: interfejsy do laboratorium, przypomnienia SMS, połączenie z P1 z certyfikatem placówki. Uruchomiona bez zmian potrafi wysłać pacjentowi przypomnienie o wizycie sprzed miesięcy albo przesłać do P1 dokument, którego nikt nie wystawił. Najpierw więc odcięcie harmonogramu zadań, wysyłki, interfejsów i P1, potem start. Do testów wymiany z P1 dostawcy mają środowisko integracyjne Centrum e-Zdrowia.

Pseudonimizacja tabeli pacjentów to najprostsza część pracy, bo dane identyfikujące są też w wolnym tekście epikryz, w nagłówkach badań obrazowych i w tabelach historii zmian, a rzadkie rozpoznanie z datą przyjęcia wskazuje osobę bez nazwiska. Skrypt pseudonimizujący jest więc osobnym produktem z właścicielem i spisem pól, uruchamianym na kopii jeszcze w strefie produkcyjnej, zanim baza trafi na serwer testowy.

Spis z datą usunięcia

Każda kopia danych pacjentów poza produkcją, także u dostawcy, ma w spisie cztery informacje: po co powstała, kto jest właścicielem, jaki ma zakres danych i kiedy zostanie usunięta. To część rejestru czynności przetwarzania, który zawiera cele i, jeśli to możliwe, planowane terminy usunięcia (art. 30 ust. 1 lit. b i f RODO). Kopia przekazana dostawcy ma numer zgłoszenia i datę usunięcia, a dostawca potwierdza usunięcie na piśmie, bo zwrot albo usunięcie danych po zakończeniu usług (art. 28 ust. 3 lit. g RODO) przychodzi przy umowie serwisowej dopiero po latach. Prostsze bywa odwrócenie kierunku: serwis łączy się do kopii w placówce na koncie imiennym. Usunięcie obejmuje bazę, jej kopie zapasowe i migawki maszyny wirtualnej.

Kto wykrywa w nocy: monitoring bezpieczeństwa przy małym dziale IT

Alarm z czwartku, 23:40, przyszedł mailem do śpiącego informatyka. Był, tylko nikt go nie przeczytał.

Terminy zgłoszenia incydentu poważnego biegną od wykrycia (art. 11 ust. 1 ustawy o KSC; oba zegary opisuje poradnik o awarii). Wygodny wniosek, że incydent zauważony w poniedziałek rano ma termin we wtorek rano, psują dwa przepisy. Wczesne ostrzeżenie wskazuje moment wystąpienia i moment wykrycia incydentu (art. 12 ust. 1 pkt 4), więc noc z czwartku na piątek będzie w zgłoszeniu. System zarządzania bezpieczeństwem ma obejmować system informacyjny monitorowaniem w trybie ciągłym (art. 8 ust. 1 pkt 2 lit. g). Ustawa nie wymaga człowieka przy ekranie przez całą dobę. Wymaga, żeby placówka umiała pokazać, jak alarm z nocy trafia do kogoś, kto może coś z nim zrobić.

Co obserwować

Źródła sygnałów to kontroler domeny, zapora, oprogramowanie ochronne na serwerach i stacjach, serwer kopii zapasowych, połączenia zdalne dostawców i serwer bazy systemu szpitalnego. Telefon w nocy uzasadnia krótka, ustalona z góry lista zdarzeń: nowe konto administratora, logowanie konta serwisowego poza uzgodnionym oknem, wyłączona ochrona na serwerze, zatrzymane zadanie kopii, masowa zmiana plików, duży eksport danych na nieznany adres. Przy każdej pozycji stoi osoba, która odbiera. Zegary wszystkich urządzeń biorą czas z jednego źródła, a dzienniki zdarzeń trafiają na serwer poza domeną placówki, bo atakujący z kontem administratora zaczyna od czyszczenia śladów.

Trzy modele

Własny dyżur działa przy co najmniej trzech osobach zdolnych do obsługi incydentu. Jeden informatyk nie obsłuży 365 nocy w roku: dyżur nie może naruszać 11 godzin nieprzerwanego odpoczynku (art. 151⁵ § 2 i art. 132 § 1 Kodeksu pracy), a gdy nocne usuwanie awarii ten odpoczynek przerwie, pracownikowi przysługuje w okresie rozliczeniowym równoważny okres odpoczynku (art. 132 § 2 pkt 2 i § 3), więc każda noc z wezwaniem wraca w grafiku jako godziny, w których go nie ma.

Usługę zarządzaną ustawa przewiduje wprost: podmiot powołuje wewnętrzne struktury albo zawiera umowę z dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa (art. 14 ustawy o KSC). Usługa daje ludzi przy ekranach, ale nie znajomość placówki: analityk o 3:00 nie wie, że serwer laboratorium wolno odłączyć, a serwera systemu szpitalnego nie, bo za dwie godziny oddziały zlecają poranne leki.

W modelu mieszanym firma patrzy przez całą dobę i wykonuje pierwsze czynności z podpisanej listy, na przykład izoluje zainfekowaną stację albo blokuje konto. Decyzje, które dotykają pacjentów, zostają w placówce: wyłączenie systemu, przejście na papier, zawiadomienie dyspozytorni. Przy jednym albo dwóch informatykach ten model ma najwięcej sensu. Osoba decyzyjna pod telefonem nie musi być informatykiem, ale ma od dyrektora na piśmie, co rozstrzyga sama, a przy czym go budzi.

Umowa z firmą przenosi pracę, a odpowiedzialność za obowiązki z art. 8, 11 i 14 zostaje przy kierowniku (art. 8c). Dzienniki zdarzeń zawierają dane osobowe pracowników, a często pacjentów, więc gdy firma przetwarza je w imieniu placówki, potrzebna jest umowa powierzenia (art. 28 ust. 3 RODO).

Próba nocna

Próbę uzgadnia się z firmą i z dyrektorem, a osoba pod telefonem nie wie, której nocy przyjdzie alarm. O 2:00 firma wywołuje umówiony alarm testowy, na przykład utworzenie konta administratora na stacji testowej. Mierzy się trzy czasy: od zdarzenia do alarmu u analityka, od alarmu do telefonu w placówce, od telefonu do decyzji. Protokół jest dowodem, że monitorowanie w trybie ciągłym działa. Pierwszą próbę róbcie przed 3 kwietnia 2027, potem raz w roku i po każdej zmianie listy dyżurów albo firmy.

Próba wyłapuje błędy, których nie widać w dzień: alarm krytyczny idzie pocztą, która przy szyfrowaniu przestaje działać, zamiast SMS-em albo telefonem; serwer bazy systemu szpitalnego nie jest podłączony, bo dostawca systemu nie zgodził się na agenta, a nikt nie ustalił zastępczo wysyłki dzienników; „reakcja w 30 minut” oznacza mail z numerem zgłoszenia; numer z listy dyżurów prowadzi do osoby, która odeszła. Pierwsze tygodnie usługi dają setki fałszywych alarmów, więc strojenie reguł wpisuje się do umowy jako etap z terminem, a potem przegląda alarmy raz w miesiącu. Lista telefonów leży wydrukowana w portierni i dyżurce, obok procedur z materiału Praca bez systemu przez 72 godziny (PDF).

Oferty porównujcie na tej samej liście źródeł zdarzeń i w całym okresie umowy. Oferent odpowiada na piśmie, co robi w pierwszych 30 minutach po nocnym alarmie, co wolno mu bez waszej zgody, jak powiadamia, gdy nie działa wasza poczta, czy wyda zapis momentu wykrycia i co oddaje w dniu zakończenia umowy.

Stan bezpieczeństwa na jednej stronie dla podmiotu tworzącego i rady społecznej

Spis, testy, konta i monitoring kosztują, a w szpitalu publicznym o pieniądzach rozmawia się także z radą społeczną i podmiotem tworzącym. Gdy kierownik IT pokazuje radzie społecznej schemat sieci i wersje systemów, pytanie przedstawiciela starosty brzmi zwykle: czy jeśli tego nie kupimy, szpital przestanie działać? Rada i podmiot tworzący potrzebują wiedzieć, co szpital ryzykuje, co zrobił od ostatniego razu i jakiej decyzji się od nich oczekuje.

Rada społeczna działa w podmiocie leczniczym niebędącym przedsiębiorcą, w przypadku szpitala zwykle w SPZOZ, i opiniuje między innymi plan finansowy z planem inwestycyjnym oraz zakup aparatury i sprzętu medycznego (art. 48 ust. 1 i 2 ustawy o działalności leczniczej). Podmiot tworzący, w potocznym języku organ założycielski, nadzoruje szpital pod względem zgodności z prawem, celowości, gospodarności i rzetelności, może żądać informacji i dokumentów (art. 121) i co roku ocenia jego sytuację na podstawie raportu udostępnianego w BIP (art. 53a). Kierownik planuje adekwatne środki na obowiązki z zakresu cyberbezpieczeństwa (art. 8d pkt 2 ustawy o KSC), więc dyrektor, który nie umie wytłumaczyć potrzeb temu, kto daje pieniądze, zostaje z odpowiedzialnością bez budżetu. Szpital prowadzony przez spółkę rady społecznej nie ma i tę samą stronę przedstawia zarządowi, radzie nadzorczej i wspólnikowi.

Osiem pozycji

Stały układ, ten sam na każdym posiedzeniu, przy każdej pozycji status w trzech kolorach, jedno zdanie i zmiana od ostatniego raportu.

1. Status wobec ustawy o KSC: wpis, stan wdrożenia, w podmiocie kluczowym przygotowanie do audytu, data szkolenia kierownika w tym roku.
2. Kopia i praca bez systemu: data ostatniego testu odtworzenia, jego czas wobec czasu zaakceptowanego przez dyrektora, data ostatniego ćwiczenia pracy na papierze.
3. Incydenty: ile zdarzeń rozpatrzono, ile spełniało przesłanki zgłoszenia, czy któryś zatrzymał oddział.
4. Systemy i urządzenia bez wsparcia producenta i plan dla nich.
5. Dostęp: konta osób, które odeszły, i MFA dla dostępu zdalnego.
6. Umowy, które wygasają w najbliższym roku, i droga wyjścia z danymi.
7. Budżet IT: wykonanie wobec planu, z podziałem na wydatki wymuszone prawem, utrzymanie i rozwój.
8. Decyzje, o które prosi dyrektor: najwyżej trzy, każda z kwotą netto, terminem i skutkiem odmowy.

Kolory definiuje się raz, na piśmie. Zielony: działa i zostało sprawdzone w tym okresie. Żółty: działa, ale nie zostało sprawdzone, albo termin zbliża się bez planu. Czerwony: nie działa, termin minął albo jest ryzyko przestoju oddziału. Bez definicji wszystko wychodzi na zielono. Każda pozycja wynika z istniejącego dokumentu; jeśli dokumentu nie ma, pozycja jest żółta.

Liczby, które coś mówią

Dostępność 99,9% w skali roku nie mówi, czy przestój trafił na nocny dyżur izby przyjęć, więc tylko uspokaja. Liczba, która mówi coś zarządowi, ma datę i odnosi się do decyzji, na przykład: ostatni test odtworzenia bazy systemu szpitalnego trwał 9 godzin, a dyrektor zgodził się na 8. Jak ustala się tę granicę, opisuje poradnik o awarii. Zero zgłoszeń przez rok daje radzie prawo zapytać, czy nic się nie stało, czy nikt nie umie tego rozpoznać. Nazwy serwerów, wersje systemów i opis niezałatanych luk zostają w dokumentacji bezpieczeństwa, bo materiały rady czyta wiele osób, a raport z art. 53a jest w BIP.

Pierwszą stronę przygotujcie na posiedzenie, na którym opiniowany jest plan finansowy, i zróbcie ją uczciwie, nawet jeśli połowa pozycji wyjdzie na żółto. Stronę przedstawia dyrektor, bo odpowiedzialność z art. 8c jest jego. Ten sam układ co kwartał buduje historię: gdy pozycja jest żółta trzeci raz z rzędu, decyzja broni się sama.

Test gotowości w dziesięciu pytaniach

Dziesięć pytań z 24 punktów listy kontrolnej, na jedno spotkanie dyrektora z kierownikiem IT i pełnomocnikiem do spraw cyberbezpieczeństwa. Dowody kierownik IT zbiera dzień wcześniej w jednym folderze. Odpowiedź bez dowodu liczy się jako „nie”.

1. Czy wiemy, czy jesteśmy podmiotem kluczowym, ważnym, czy jesteśmy poza ustawą? Dowód: notatka z wyliczeniem i potwierdzenie wniosku o wpis. Status.
2. Kiedy ostatnio odtworzyliśmy system krytyczny z kopii i ile to trwało? Przepisy nie podają częstotliwości testu, rytm ustala polityka na podstawie analizy ryzyka. W praktyce szpital co kwartał odtwarza inny system krytyczny, więc każdy przechodzi test co najmniej raz w roku, a od ostatniego testu któregokolwiek systemu krytycznego nie mija więcej niż pół roku. Przychodnia w chmurze prosi dostawcę o odtworzenie na osobnej instancji i sprawdza pięć kart, a umowa przewiduje taki test. Dowód: Protokół testu odtworzenia kopii (PDF) z czasem do chwili, w której personel znów pracuje. Kopie.
3. Czy mamy spis systemów z właścicielem przy każdym? Dowód: spis z datą weryfikacji każdego wiersza. Spis.
4. Kto z dostawców loguje się do nas zdalnie i czym? Dowód: rejestr dostępów zdalnych i konfiguracja MFA. Konta i dostęp.
5. Ile godzin placówka wytrzyma bez systemu? Dowód: analiza ryzyka z czasem odtworzenia i dopuszczalną utratą danych, ustalonymi przez dyrektora i pielęgniarkę naczelną, i wydrukowane procedury. RPO i RTO, praca bez systemu.
6. Kto w nocy z soboty na niedzielę decyduje o zgłoszeniu incydentu? Dowód: procedura z zastępstwami, wyznaczenie co najmniej dwóch osób do kontaktu z podmiotami krajowego systemu cyberbezpieczeństwa (art. 9 ust. 1 pkt 1 ustawy o KSC), ich dostęp do S46, protokół próby nocnej. Monitoring, dwa zegary.
7. Czy konto osoby, która odeszła w zeszłym miesiącu, jest wyłączone? Dowód: przykład z ostatniego odejścia i wynik przeglądu kont. Konta i dostęp.
8. Czy urządzenia medyczne są oddzielone od reszty sieci? Dowód: schemat sieci z regułami ruchu i rejestr wyjątków od aktualizacji (art. 8 ust. 1 pkt 5 lit. b). Urządzenia medyczne.
9. Co dostawca zrobi, gdy incydent będzie po jego stronie? Dowód: zapis o czasie powiadomienia i umowa powierzenia z listą podwykonawców. Dostawcy.
10. Czy kierownik przeszedł szkolenie w tym roku kalendarzowym, a przed 3 kwietnia 2027 czy ma je w kalendarzu? Dowód: teczka kierownika, a w aktach osób z zadaniami z art. 8 i 11 informacje z KRK. Kierownik.

W kilka dni nie zbuduje się segmentacji sieci ani systemu zarządzania bezpieczeństwem. Da się zamknąć punkty, które zależą od decyzji, a nie od zakupów: wyznaczyć osoby do kontaktu i dać im dostęp do S46, wyłączyć wspólne konta serwisowe, wydrukować procedurę pracy bez systemu, umówić szkolenie kierownika, odtworzyć jeden system z kopii. Dla reszty kierownik zatwierdza plan z datami i nazwiskami. Plan nie zwalnia z obowiązku, ale pokazuje, że placówka zna swoje luki i zarządza ryzykiem, czego wymaga art. 8 ust. 1 pkt 1.

Co to znaczy na waszej skali

Obowiązki zależą od statusu, a status od formy i wielkości, więc przy każdej skali najpierw jest odpowiedź, czy ustawa zwykle obejmuje placówkę, a potem, co z poradnika bierze. Jak z wielkością placówki zmieniają się warstwy IT, opisuje tekst Kwestia skali.

Gabinet lekarski

Gabinet co do zasady jest poza ustawą: indywidualna praktyka nie jest podmiotem leczniczym, a gabinet prowadzony przez spółkę jest zwykle mikroprzedsiębiorcą; wyjątkiem bywa spółka w dużej grupie. Obowiązują RODO i rozporządzenie o dokumentacji medycznej. Naruszenie danych pacjentów zgłaszacie Prezesowi UODO w tym samym terminie co szpital, rejestr czynności przetwarzania prowadzicie, bo zwolnienie dla mniejszych podmiotów nie obejmuje danych o zdrowiu (art. 30 ust. 5 RODO), a z dostawcą programu macie umowę powierzenia (art. 28 ust. 3 RODO). Na spis wystarczy jedna strona: program, dostawca, sposób wyciągnięcia danych, kto łączy się zdalnie i czym, certyfikat do P1 z datą ważności. Lekarz i osoba do pomocy mają dwa konta, bo wpis ma mieć autora. MFA włączcie na poczcie i w programie w chmurze, a kopię kartoteki trzymajcie poza gabinetem i raz na pół roku sprawdźcie, czy się odtwarza.

Przychodnia

Przychodnia prowadzona przez mikro albo małego przedsiębiorcę i SPZOZ zatrudniający mniej niż 50 osób co do zasady są poza ustawą. Policzcie jednak przesłanki z kadrami i księgowością, łącznie z grupą, i zapiszcie wynik; SPZOZ od 50 zatrudnionych jest podmiotem ważnym, a placówka samorządowej jednostki budżetowej albo spółki komunalnej wymaga oceny indywidualnej. Poniżej progu ustawa o KSC nie wymaga wpisu, S46 ani systemu zarządzania bezpieczeństwem, ale trzy rozdziały dotyczą was i tak, bo wynikają z RODO i rozporządzenia o dokumentacji. Konta: imienne konto każdej rejestratorki, data końca umowy lekarza kontraktowego jako data wygaśnięcia konta, MFA na poczcie i zdalnym dostępie. Dostawcy: umowa powierzenia z podwykonawcami, prawem do audytu i zwrotem danych (art. 28 ust. 2 i ust. 3 lit. g i h RODO) i przegląd komputerów w rejestracji, czy nie został na nich program do zdalnego pulpitu z wdrożenia. Kopie danych: potwierdzenie usunięcia kopii z ostatniej migracji u dostawcy i szkolenia rejestracji na pacjentach testowych.

Sieć przychodni

Status liczy się dla całego podmiotu, a przy osobnych spółkach jednej grupy razem z przedsiębiorstwami powiązanymi, więc sieć łatwo przekracza próg, którego żadna lokalizacja nie przekracza sama. Jeśli sieć podlega ustawie, poradnik dotyczy jej w całości, poza audytem, gdy jest podmiotem ważnym, i robi się go raz dla wszystkich lokalizacji: jeden wzór spisu, jedna procedura incydentu, jedna tabela dostawców. Konta dostawców spisujcie jednak dla każdej lokalizacji, bo ta sama firma serwisowa często ma w każdej inne konto, i sprawdźcie, czy konto w jednej przychodni nie otwiera drogi do pozostałych. Jedna usługa zarządzana i jedna osoba decyzyjna wystarczą na całą sieć, a w każdej lokalizacji kierownik wie, do kogo dzwoni w poniedziałek o 7:30. Gdy lokalizacje prowadzą osobne spółki, każda sama składa wniosek o wpis i zgłasza swoje incydenty.

Szpital

Dla tej skali napisany jest plan z kalendarza. SPZOZ jest podmiotem ważnym od 50 zatrudnionych i kluczowym od 250; szpital prowadzony przez spółkę sprawdza progi średniego przedsiębiorcy, a spółka powiatu także przepis o podmiotach publicznych. Szpital powiatowy z jednym albo dwoma informatykami zaczyna od kont i dostawców, testu kopii i procedury incydentu, bo one decydują, czy po ataku wróci do pracy w dni, czy w tygodnie. Informatyk robi spis, przegląd kont, testy i ocenę dostawców w arkuszu, a monitoring szpital kupuje jako usługę w modelu mieszanym. Spotkanie z pielęgniarką naczelną o dopuszczalnym przestoju i dzień szkolenia wymagają czasu dyrektora, więc trafiają do kalendarza dyrekcji od razu.

Szpital specjalistyczny

Szpital specjalistyczny albo kliniczny zatrudniający 250 osób i więcej jest podmiotem kluczowym, więc dochodzi audyt; szpital instytutu badawczego sprawdza też przepis o podmiotach publicznych z rozdziału o statusie. Audytora i zakres ustalcie w 2027 roku, a nie w ostatnim kwartale przed 3 kwietnia 2028; audytor zaczyna od spisu, więc system spoza spisu wypada z audytu. Najwięcej pracy jest przy urządzeniach: arkusz aparatury wypełniają razem dział IT i dział aparatury, a dostępy serwisowe producentów trafiają do tego samego rejestru co dostępy dostawców oprogramowania. Praca całodobowa oznacza, że na liście telefonów firmy monitorującej jest osoba z działu aparatury, która w nocy powie, które urządzenie wolno odłączyć, a którego nie wolno ruszać w trakcie badania; jak oddzielić taki sprzęt, opisuje poradnik o infrastrukturze. Bezpieczeństwo jest osobną funkcją: ten, kto administruje serwerami, nie sprawdza sam, czy robi to bezpiecznie, a osoba zgłaszająca incydent przez S46 nie odtwarza w tej samej godzinie systemów.

Sieć szpitali

Grupa może zrobić raz wzór spisu, procedury, wymagania wobec dostawców i jedno miejsce monitorowania, jeśli w każdym szpitalu ktoś w nocy decyduje na miejscu. Każdy podmiot wpisany do wykazu ma jednak własnego kierownika, własne szkolenie i własne dowody: test odtworzenia w jednym szpitalu nie jest dowodem dla pozostałych. Spółka prowadząca kilka szpitali jest jednym podmiotem, a bez uchwały wskazującej osobę odpowiedzialną odpowiadają wszyscy członkowie zarządu. Mały szpital w dużej grupie może być podmiotem kluczowym przez doliczenie przedsiębiorstw powiązanych, chyba że ma system informacyjny niezależny od reszty grupy albo nie świadczy z nią usług wspólnie (art. 5 ust. 6 i 7). Co przenieść na centralę, opisuje poradnik o rosnącej placówce.

Typowe błędy

Polityka przed spisem. Segregator powstaje w październiku, bo „dokument jest wymagany”, a spis, analiza ryzyka i test kopii nigdy. Pierwsze pytanie audytora o system spoza segregatora kończy rozmowę o polityce.

Szkolenie kierownika bez decyzji. Certyfikat z ogólnego kursu jest jedynym śladem, plan finansowy nie ma pozycji na cyberbezpieczeństwo, a na szkolenie pojechał zastępca, któremu niczego nie powierzono.

Ankieta dostawcy uznana za dowód. Dowodem jest lista kont, konfiguracja, protokół i próbne zgłoszenie w piątek wieczorem.

Konta serwisowe bez daty końca. Konto „serwis” działa od wdrożenia, zdalny pulpit na stałe, konto technika, który odszedł od dostawcy, dalej aktywne. To samo z kontami kontraktowych lekarzy i rezydentów bez daty wygaśnięcia.

Monitoring bez właściciela wykrycia. Firma patrzy przez całą dobę, ale alarm krytyczny idzie mailem, numer dyżurny prowadzi do osoby, która odeszła, a nikt nie ma na piśmie, kto w nocy decyduje o odłączeniu sieci.

Raport z liczbami, które tylko uspokajają. Dostępność 99,9% i „brak poważnych incydentów” zamiast daty testu odtworzenia, jego czasu i liczby rozpatrzonych zdarzeń. Pierwsza prośba o pieniądze po roku ciszy wygląda wtedy jak wydatek do obcięcia.

Od czego zacząć w tym tygodniu

1. Policzcie status z kadrami i księgowością, łącznie z grupą, i zapiszcie wynik z datą; jeśli placówka podlega ustawie, a nie ma jej w wykazie, złóżcie wniosek.
2. Sprawdźcie, czy szpital był operatorem usługi kluczowej, i wpiszcie do kalendarza właściwe terminy zgłaszania incydentów i audytu.
3. Zróbcie listę kont, którymi logują się dostawcy, z firmą, systemem i numerem umowy, i wyłączcie wspólne konta serwisowe.
4. Wybierzcie jeden system krytyczny i umówcie test jego odtworzenia na osobnym serwerze, z protokołem.
5. Wyznaczcie co najmniej dwie osoby do kontaktu z podmiotami krajowego systemu cyberbezpieczeństwa i sprawdźcie ich dostęp do S46.
6. Ustalcie na piśmie, kto w nocy decyduje o odłączeniu sieci i o zgłoszeniu incydentu, i wydrukujcie listę telefonów do portierni i dyżurki.
7. Wpiszcie do kalendarza kierownika datę szkolenia z art. 8e, najpóźniej na marzec 2027, a potem na stały miesiąc każdego roku.

Wszystkie 24 punkty z opisem dowodu, w kolejności z kalendarza, są w materiale Lista kontrolna KSC: gotowość szpitala na 3 kwietnia 2027 (PDF). Wydrukujcie go przed spotkaniem dyrekcji z działem IT i zaznaczajcie tylko to, co możecie pokazać.

Na ile z dziesięciu pytań testu gotowości odpowiecie dziś dokumentem z datą, a na ile tylko zapewnieniem?