Audyt, który wzmocnił dział IT zamiast go zastępować: klinika medyczna przed NIS2

Kontekst

Klinika ma własny zespół IT, który na co dzień utrzymuje systemy gabinetowe, dokumentację medyczną i sieć w dwóch budynkach. Zbliżające się wymagania NIS2 oraz rosnące oczekiwania kontrahentów sprawiły, że kierownictwo chciało mieć niezależny, techniczny obraz stanu bezpieczeństwa i plan działań, zanim zapyta o to ktoś z zewnątrz.

Zespół IT kliniki poprosił o wsparcie osoby z doświadczeniem z dużych, regulowanych środowisk. Nie po to, by ktoś go zastąpił, lecz by wspólnie ustalić, co naprawdę jest ryzykiem, a co tylko wygląda groźnie w dokumentach, i które tematy techniczne wymagają konsultacji lub wdrożenia.

Wyzwanie

• Placówka medyczna to nie biuroObok komputerów są urządzenia diagnostyczne, systemy gabinetowe i dokumentacja medyczna, do których dostęp mają również dostawcy zewnętrzni. Przerwa w działaniu oznacza odwołane wizyty, a wyciek dotyczy danych o zdrowiu.
• NIS2 mówi, co trzeba osiągnąć, nie jakAnaliza ryzyka, ciągłość działania, zarządzanie incydentami, bezpieczeństwo łańcucha dostaw i kontrola dostępu musiały zostać przełożone na konkretną sieć, konkretne serwery i konkretnych ludzi.
• Własny zespół zna środowisko, ale nie ma dystansuPotrzebne było partnerskie podejście: wspólna praca bez oceniania i bez raportu, który trafia na półkę.

Co zrobiliśmy

1Zasady współpracy

Na pierwszym spotkaniu uzgodniliśmy role: zespół IT kliniki prowadzi, my wnosimy doświadczenie, pytania i wzorce z większych środowisk. Każde ustalenie trafia do wspólnej listy ryzyk, a o priorytetach decyduje kierownictwo kliniki na podstawie wpływu na pacjentów i działanie placówki.

2Przegląd techniczny infrastruktury

Wspólnie przeszliśmy przez sieć i jej podział, serwery i systemy gabinetowe, dokumentację medyczną i kopie zapasowe, stanowiska i urządzenia medyczne, dostępy użytkowników i dostawców, zdalny dostęp, aktualizacje, rejestrowanie zdarzeń oraz procedury na wypadek incydentu.

3Lista ryzyk ustalona wspólnie

Obszary, które wymagały uwagi, to te typowe dla placówek medycznych tej wielkości: rozdzielenie ruchu urządzeń medycznych i systemów gabinetowych od części biurowej, potwierdzenie, że kopie dokumentacji medycznej dają się odtworzyć i w jakim czasie, kontrola zdalnego dostępu dostawców systemów, drugi składnik logowania dla dostępu zdalnego i kont administracyjnych, procedura postępowania przy incydencie zgodna z NIS2 oraz porządek w kontach uprzywilejowanych. Szczegóły ustaleń pozostają poufne.

4Plan działań w kolejności wpływu na pacjentów

Dla każdego ryzyka ustaliliśmy, co zrobić, kto to wykona (zespół kliniki, my, dostawca), ile to kosztuje i co się stanie, jeśli zostanie odłożone. Dzięki temu kierownictwo podejmowało decyzje o priorytetach w języku działania placówki, nie w języku technicznym.

5Wdrożenie wybranych tematów i przekazanie wiedzy

Część działań wykonał zespół kliniki samodzielnie, część zrealizowaliśmy wspólnie. Każde rozwiązanie zostało udokumentowane tak, aby informatycy kliniki mogli je utrzymywać bez nas.

Pod maską

• Metoda: przegląd techniczny z zespołem klienta, lista ryzyk z oceną wpływu na pacjentów i działanie placówki, plan działań z właścicielami i kosztami.
• Odniesienie: wymagania NIS2 w zakresie analizy ryzyka, ciągłości działania, incydentów, łańcucha dostaw i kontroli dostępu.
• Zakres: dwa budynki, systemy gabinetowe i dokumentacja medyczna, urządzenia medyczne w sieci, dostępy dostawców.
• Zastrzeżenie: to ocena techniczna z rekomendacjami, nie audyt certyfikacyjny i nie opinia prawna.

Efekt

• Kierownictwo kliniki ma listę ryzyk w języku wpływu na pacjentów oraz plan działań z kolejnością, kosztem i odpowiedzialnością.
• Zespół IT kliniki dostał wsparcie, a nie ocenę; wiedza z projektu została u niego.
• Najpilniejsze tematy techniczne zostały zaadresowane wspólnie, a pozostałe mają właściciela i termin.
• Klinika ma podstawę do rozmowy o NIS2 z kontrahentami, ubezpieczycielem i audytorem.

Dlaczego to ma znaczenie dla innych firm

NIS2 obejmie wiele podmiotów leczniczych, a przygotowanie nie polega na kupieniu urządzenia ani na raporcie. Polega na tym, by ludzie, którzy znają placówkę od środka, mieli obok siebie kogoś, kto widział, jak robi się to w dużych, regulowanych organizacjach. To model współpracy, który nazywamy wsparciem zespołu IT.

Ze względu na poufność szczegółowe ustalenia, liczby i nazwy systemów zostały pominięte; opis obszarów ryzyka jest uogólniony.