Dyrektywa NIS2: kogo dotyczy i jak przygotować firmę

Dyrektywa NIS2 porządkuje wymagania cyberbezpieczeństwa dla określonych sektorów i organizacji. W praktyce dotyczy odpowiedzialności, zarządzania ryzykiem oraz reagowania na incydenty. Nie zaczynałbym od kupowania kolejnego programu ochronnego. Najpierw trzeba ustalić, czy organizacja podlega przepisom i kto odpowiada za konkretne działania. Bez tego łatwo zapłacić za pozorne przygotowanie.

Co zmienia się poza działem IT

Unijne przepisy rozszerzają zakres wcześniejszej dyrektywy NIS. Rozróżniają podmioty kluczowe i ważne oraz obejmują więcej sektorów. Wśród nich znajdują się infrastruktura cyfrowa, transport, zdrowie, energia i wybrane usługi zarządzania ICT. Obejmują także określone rodzaje produkcji oraz inne działalności wskazane w załącznikach. [1]

Lista sektorów nie jest jeszcze odpowiedzią dla konkretnej firmy. Znaczenie mają rodzaj działalności, wielkość podmiotu i przewidziane wyjątki. Niektóre organizacje podlegają wymaganiom niezależnie od wielkości. Nie wystarczy więc stwierdzenie, że mała firma zawsze pozostaje poza zakresem. Kwalifikację warto udokumentować, zamiast opierać ją na branżowym skrócie. [1]

Przepisy obejmują również rolę kierownictwa. Osoby zarządzające powinny rozumieć ryzyka, zatwierdzać odpowiednie działania i nadzorować ich realizację. Zrzucenie całej odpowiedzialności na administratora serwera nie rozwiązuje problemu. Zwłaszcza gdy administrator nie decyduje o budżecie, zatrudnieniu ani umowach z dostawcami. [2] [6]

Stan w Polsce: ważne daty, nie stare zapowiedzi

Polska nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa została ogłoszona pod pozycją 252 Dziennika Ustaw z 2026 roku. Weszła w życie 3 kwietnia 2026 roku. Nie opisujemy więc wyłącznie projektu oczekującego na uchwalenie. Dyrektywa NIS2 jest wdrażana przez przepisy krajowe, które trzeba czytać wraz z regulacjami sektorowymi. [3]

Ministerstwo wskazało 3 października 2026 roku jako termin samorejestracji określonej grupy podmiotów już spełniających przesłanki 3 kwietnia. Na dzień weryfikacji tego tekstu termin minął. Dotyczy to wskazanej grupy, nie każdej przyszłej organizacji objętej ustawą. Braku wpisu nie traktujmy jako dowodu, że obowiązek nas ominął. [4]

Okresy dostosowawcze i terminy poszczególnych obowiązków wymagają sprawdzenia dla własnego przypadku. Administracja opisuje dwunastomiesięczny okres przygotowania do realizacji określonych wymagań. Nie oznacza on automatycznego zawieszenia wszystkich obowiązków przez rok. Zacznijmy od kwalifikacji, właściwego organu i harmonogramu wynikającego z ustawy. [5]

Pierwszy etap: wiemy, czego właściwie bronimy

Zróbmy spis systemów, danych, usług i osób odpowiedzialnych. Uwzględnijmy aplikacje kupowane przez poszczególne działy oraz narzędzia działające poza głównym serwerem. Potem określmy skutki niedostępności lub utraty danych. Dwie godziny awarii sklepu i dwie godziny awarii sterowania produkcją mogą oznaczać zupełnie inne konsekwencje.

Przypiszmy właścicieli procesów i kryteria akceptacji ryzyka. Zapiszmy, które działania można odroczyć, a które blokują bezpieczne funkcjonowanie. Taka lista pomaga rozmawiać o pieniądzach konkretnie. Zamiast kupować wszystko naraz, możemy wskazać najważniejsze zależności oraz realne terminy poprawy.

Drugi etap: zabezpieczenia, które można sprawdzić

Zakres środków obejmuje między innymi obsługę incydentów, ciągłość działania, bezpieczeństwo dostawców i bezpieczny rozwój systemów. Dochodzą zarządzanie dostępem, cyberhigiena oraz odpowiednie wykorzystanie uwierzytelniania wieloskładnikowego. Dobór działań powinien odpowiadać ryzyku, skali i charakterowi organizacji. Sama nazwa kupionego produktu nie dowodzi skuteczności zabezpieczeń. [2] [6]

Sprawdźmy odebranie dostępu odchodzącemu pracownikowi, odtworzenie kopii i aktualizację krytycznej aplikacji. Ustalmy, kto odbiera alarm poza zwykłymi godzinami pracy. Zweryfikujmy również dostęp awaryjny, gdy podstawowy administrator jest nieobecny. To mało widowiskowe zadania, ale właśnie one pokazują, czy procedury mają pokrycie w rzeczywistości.

Przy dostawcach zapytajmy o zakres odpowiedzialności, zgłaszanie problemów i możliwość odzyskania danych. Hosting nie przejmuje automatycznie odpowiedzialności za wszystkie błędy aplikacji. Umowa powinna określać, kto aktualizuje system i kto usuwa podatności. Bez tego obie strony mogą uważać, że zadanie wykonuje ktoś inny.

Trzeci etap: reagowanie i dowody działania

Unijna dyrektywa przewiduje wieloetapowe zgłaszanie znaczących incydentów, w tym wczesne ostrzeżenie oraz późniejsze zgłoszenie. Szczegółowe terminy i adresata sprawdźmy w przepisach właściwych dla podmiotu. Nie przenośmy uproszczonej infografiki bezpośrednio do procedury operacyjnej. Zespół potrzebuje jasnej instrukcji eskalacji, nawet gdy przyczyna awarii pozostaje nieznana. [2] [6]

Na próbę przeprowadźmy ćwiczenie: niedostępna aplikacja, utracone konto administratora albo podejrzenie wycieku. Zapiszmy decyzje, czasy reakcji i brakujące uprawnienia. Następnie poprawmy procedurę i wyznaczmy termin powtórzenia. Dokumentacja ma pomagać w działaniu, nie tylko dobrze wyglądać podczas kontroli.

Dyrektywa NIS2 wymaga odpowiedzialności w codziennej pracy. Nie obiecywałbym zgodności po jednym audycie albo instalacji narzędzia. Przygotowanie jest procesem, który obejmuje ludzi, umowy i codzienną eksploatację. Dobry początek to krótka lista luk z właścicielem oraz terminem. Kwalifikację prawną potwierdźmy ze specjalistą znającym konkretną organizację. Techniczne porządki można zacząć od razu.

Źródła i data weryfikacji

2026-10-14

1. European Commission: NIS2 Directive
2. Dyrektywa (UE) 2022/2555 — art. 20, 21 i 23
3. Dziennik Ustaw 2026 poz. 252: nowelizacja KSC
4. Ministerstwo Cyfryzacji: termin samorejestracji 3 października
5. Administracja publiczna: nowelizacja KSC — kogo obejmuje
6. Ministerstwo Cyfryzacji: FAQ KSC — materiał pomocniczy, niewiążący