Cyberbezpieczeństwo NIS2 a obowiązki zarządu

3 dni temu

Atak ransomware, który zatrzymuje produkcję albo odcina klientów od systemu transakcyjnego, nie jest już wyłącznie problemem działu IT. W perspektywie regulacyjnej cyberbezpieczeństwo NIS2 staje się zagadnieniem zarządczym, prawnym i finansowym. Zarząd nie może ograniczyć się do przyjęcia informacji, iż firma ma firewall, kopie zapasowe i umowę z dostawcą IT. Musi umieć wykazać, iż rozpoznaje ryzyka, zatwierdza adekwatne środki oraz nadzoruje ich rzeczywiste działanie.

NIS2 to dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555. Wyznacza wspólne minimalne standardy zarządzania ryzykiem cybernetycznym i raportowania poważnych incydentów. Jej praktyczne znaczenie dla polskich przedsiębiorców zależy od krajowych przepisów wdrażających, w szczególności nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa. Sama dyrektywa nie zastępuje krajowej ustawy, ale określa kierunek, którego polskie rozwiązania nie mogą pominąć.

Kogo obejmuje cyberbezpieczeństwo NIS2

NIS2 odchodzi od przekonania, iż obowiązki cyberbezpieczeństwa dotyczą tylko operatorów infrastruktury krytycznej. Regulacja obejmuje podmioty działające w sektorach kluczowych i ważnych. Do pierwszej grupy zaliczają się między innymi energetyka, transport, bankowość, infrastruktura rynków finansowych, ochrona zdrowia, woda, infrastruktura cyfrowa, administracja publiczna i przestrzeń kosmiczna. Druga grupa obejmuje na przykład usługi pocztowe i kurierskie, gospodarowanie odpadami, produkcję wybranych dóbr, dostawców usług cyfrowych, badania oraz część podmiotów z branży żywnościowej.

Punktem wyjścia jest co do zasady kryterium wielkości przedsiębiorstwa. Dyrektywa zasadniczo obejmuje podmioty średnie i duże, ale przewiduje istotne wyjątki. Określone podmioty mogą podlegać reżimowi niezależnie od rozmiaru, o ile ich usługi mają szczególne znaczenie dla funkcjonowania gospodarki lub społeczeństwa. Dotyczy to przykładowo niektórych dostawców usług DNS, rejestrów nazw domen czy dostawców usług zaufania.

Nie wystarczy więc odpowiedzieć na pytanie, czy spółka zatrudnia co najmniej 50 osób. Trzeba ustalić jej faktyczny profil działalności, rolę w łańcuchu dostaw, strukturę grupy oraz kwalifikację według polskich przepisów wdrażających. Dla platformy technologicznej, dostawcy chmury, fintechu czy spółki tworzącej oprogramowanie granice mogą być mniej oczywiste niż dla klasycznego przedsiębiorstwa energetycznego.

Kwalifikacja nie jest formalnością

Błędne uznanie, iż firma nie jest objęta NIS2, może oznaczać brak budżetu, procedur i kompetencji w chwili, gdy organ nadzoru oczekuje już konkretnych dowodów compliance. Z drugiej strony nadmierne kopiowanie wymagań przeznaczonych dla dużej infrastruktury do małej organizacji może generować koszty bez proporcjonalnego efektu bezpieczeństwa.

Właściwa analiza powinna połączyć perspektywę regulacyjną z techniczną. Prawnik ustala podstawę obowiązku i rolę przedsiębiorcy w sektorze. Osoba odpowiedzialna za bezpieczeństwo ocenia zależności systemowe, dane, dostawców oraz skutki niedostępności usług. Dopiero na tej podstawie zarząd może podjąć obronną decyzję co do zakresu programu NIS2.

Zarząd odpowiada za governance, nie za konfigurację serwera

Jedna z najistotniejszych zmian wprowadzanych przez NIS2 dotyczy organów zarządzających. Mają one zatwierdzać środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorować ich wdrożenie oraz odbywać odpowiednie szkolenia. W języku praktyki korporacyjnej oznacza to włączenie cyberbezpieczeństwa do governance spółki.

Nie chodzi o to, aby członek zarządu samodzielnie oceniał konfigurację systemu SIEM albo parametry szyfrowania. Powinien jednak otrzymywać informacje pozwalające mu wykonywać nadzór: mapę krytycznych usług, rejestr najpoważniejszych ryzyk, wyniki testów, status wdrożenia zaleceń audytowych, informacje o incydentach i zależnościach od dostawców. Zarząd powinien także wiedzieć, kto podejmuje decyzje w pierwszych godzinach kryzysu i kto jest uprawniony do komunikacji z klientami, organami oraz mediami.

Dobrą praktyką jest przypisanie odpowiedzialności w uchwale, regulaminie organizacyjnym albo polityce bezpieczeństwa. Dokument powinien rozdzielać kompetencje zarządu, kierownictwa operacyjnego, zespołu bezpieczeństwa, compliance, działu prawnego i właścicieli systemów. Samo wskazanie osoby odpowiedzialnej za IT nie zwalnia organu zarządzającego z obowiązku nadzoru.

Środki bezpieczeństwa mają wynikać z ryzyka

Artykuł 21 NIS2 nie tworzy jednego zamkniętego katalogu technologii do kupienia. Wymaga stosowania odpowiednich i proporcjonalnych środków technicznych, operacyjnych oraz organizacyjnych, uwzględniających stan wiedzy technicznej, koszty, skalę działalności i poziom ryzyka. To podejście wymaga uzasadnienia, a nie odhaczania listy zakupów.

W praktyce program powinien obejmować zarządzanie incydentami, ciągłość działania i odtwarzanie po awarii, bezpieczeństwo łańcucha dostaw, bezpieczny rozwój i utrzymanie systemów, zarządzanie podatnościami, szkolenia oraz higienę cybernetyczną. Znaczenie mają również polityki dostępu, zarządzanie aktywami, wieloskładnikowe uwierzytelnianie, kryptografia i bezpieczne kanały komunikacji.

Dla wielu firm największym problemem nie będzie brak polityki, ale rozjazd między polityką a praktyką. Kopie zapasowe mogą istnieć, ale nie być testowane. Dostęp administracyjny może być formalnie ograniczony, ale przez cały czas współdzielony. Umowa z dostawcą SaaS może zawierać ogólne zapewnienie o bezpieczeństwie, ale nie gwarantować prawa do informacji o incydencie, audytu ani odpowiednich parametrów odtworzenia usługi.

Łańcuch dostaw wymaga negocjacji kontraktowych

NIS2 szczególnie mocno eksponuje ryzyko wynikające z relacji z bezpośrednimi dostawcami i usługodawcami. Nie oznacza to, iż każda umowa musi zostać zastąpiona rozbudowanym kontraktem audytowym. Zakres zabezpieczeń powinien zależeć od tego, czy dostawca ma dostęp do danych, systemów produkcyjnych albo procesów krytycznych.

W umowach warto rozważyć postanowienia dotyczące minimalnych standardów bezpieczeństwa, obowiązku szybkiego zawiadomienia o incydencie, współpracy przy analizie zdarzenia, podwykonawców, lokalizacji przetwarzania oraz zasad zakończenia współpracy i zwrotu danych. Szczególnej ostrożności wymagają podmioty korzystające z usług chmurowych, zewnętrznych centrów operacyjnych bezpieczeństwa i narzędzi opartych na generatywnej AI.

Incydent trzeba umieć rozpoznać i zgłosić

NIS2 przewiduje wieloetapowe raportowanie znaczących incydentów. Co do zasady wczesne ostrzeżenie powinno nastąpić w ciągu 24 godzin od uzyskania wiedzy o incydencie, zgłoszenie incydentu w ciągu 72 godzin, a raport końcowy w ciągu miesiąca. Szczegółowa procedura, adekwatny organ i kanał raportowania wynikają jednak z przepisów krajowych.

Termin zaczyna biec nie od chwili pełnego ustalenia przyczyny ataku, ale od momentu uzyskania wiedzy o zdarzeniu spełniającym ustawowe kryteria. Dlatego procedura nie może zakładać, iż przedsiębiorca najpierw przez kilka dni zakończy analizę techniczną, a dopiero potem zawiadomi adekwatny podmiot. Potrzebny jest mechanizm szybkiej eskalacji z działu IT do osób odpowiedzialnych za decyzję prawną i komunikacyjną.

Trzeba odróżnić obowiązki NIS2 od zgłoszenia naruszenia ochrony danych osobowych na gruncie RODO. Jeden incydent może uruchomić oba reżimy, ale ich przesłanki, odbiorcy zgłoszeń i przedmiot oceny nie są identyczne. Incydent może być znaczący dla ciągłości usługi, choć nie obejmuje danych osobowych. Może też prowadzić do naruszenia danych, które nie osiąga progu znaczącego incydentu w rozumieniu przepisów o cyberbezpieczeństwie.

Sankcje są tylko częścią ryzyka

Dyrektywa wymaga, by krajowe sankcje były skuteczne, proporcjonalne i odstraszające. Przewiduje minimalne poziomy maksymalnych kar administracyjnych: dla podmiotów kluczowych co najmniej 10 mln euro albo 2% światowego rocznego obrotu, a dla podmiotów ważnych co najmniej 7 mln euro albo 1,4% obrotu. Ostateczny model odpowiedzialności i wysokość kar należy zawsze oceniać według obowiązujących regulacji krajowych.

Dla zarządu równie dotkliwe mogą być skutki biznesowe: zatrzymanie działalności, roszczenia kontrahentów, utrata tajemnicy przedsiębiorstwa, koszt odtworzenia środowiska, problemy z finansowaniem albo obowiązki informacyjne wobec inwestorów. W spółkach regulowanych trzeba dodatkowo ocenić relację NIS2 z DORA, przepisami sektorowymi i wymogami nadzorczymi.

Najbardziej użytecznym pierwszym krokiem nie jest zakup kolejnego narzędzia bezpieczeństwa. Jest nim rzetelna decyzja zarządu o przeprowadzeniu analizy kwalifikacji pod NIS2, mapowaniu usług krytycznych i sprawdzeniu, czy firma potrafi wykazać swoje działania w pierwszej dobie po incydencie. To właśnie wtedy compliance przestaje być dokumentem, a staje się zdolnością organizacji do ochrony własnego biznesu.

Idź do oryginalnego materiału