Przygotowanie do NIS2 zacznij od zakresu i odpowiedzialności
Przygotowanie firmy do NIS2 zacznij od potwierdzenia, czy i w jakim zakresie dotyczą jej przepisy, a potem przypisz właścicieli usług, ryzyk oraz dowodów działania. Zakup narzędzia przed tymi ustaleniami może powiększyć koszty, ale nie odpowie na pytanie, które procesy i decyzje organizacja musi faktycznie kontrolować.
Stan prawny: 7 października 2026 r. NIS2 jest dyrektywą unijną, a obowiązki podmiotów w Polsce wynikają z przepisów krajowych, w tym z nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa. Kwalifikacja zależy od rzeczywistej działalności, sektora, wielkości oraz reguł szczególnych; nie jest poradą prawną ani wynikiem samego kodu PKD. [1][2]
Najbezpieczniejszy początek to wspólna praca osób odpowiedzialnych za biznes, zgodność i IT. Jedna grupa opisuje usługi oraz decyzje, druga weryfikuje podstawę prawną, a IT pokazuje zależności, dostępne dowody i ograniczenia środowiska.
Jeżeli status prawny został potwierdzony, zobacz, jak może wyglądać techniczna analiza luk i dowodów.
Sprawdź zakres analizy gotowości do NIS2
Najpierw udokumentuj kwalifikację, zamiast zakładać obowiązki
Wynik kwalifikacji powinien być krótkim, datowanym zapisem: opis działalności, usługi świadczone przez podmiot, przyjęty sektor lub podsektor, dane o wielkości, rozpoznane wyjątki, źródła oraz osoba zatwierdzająca. Dzięki temu firma może wrócić do założeń po zmianie usług, struktury grupy albo przepisów.
Ministerstwo Cyfryzacji wskazuje, że samoidentyfikacja wymaga analizy faktycznej działalności, właściwych kodów PKD, sektorów z załączników, wielkości podmiotu i reguł szczególnych. Nie jest to zadanie, które należy zostawić wyłącznie administratorowi albo rozstrzygać według skróconej listy z internetu. [3]
Równolegle warto odnotować wymagania umowne. Organizacja nieobjęta bezpośrednio konkretnym obowiązkiem może otrzymać od klienta pytania o incydenty, dostęp administracyjny, kopie lub dostawców. To jednak osobny, kontraktowy zakres; nie należy przedstawiać go jako przesądzonego obowiązku ustawowego.
Zbuduj obraz usług, danych, dostawców i zależności
Nie da się zarządzać ryzykiem dla środowiska opisanego wyłącznie listą komputerów. Zidentyfikuj usługi, bez których firma nie realizuje istotnych procesów: tożsamość, pocztę, systemy finansowe lub produkcyjne, przechowywanie danych, łączność, kopie oraz usługi zewnętrzne. Przy każdej zapisz właściciela biznesowego, właściciela technicznego, zależności i sposób odzyskania kontroli.
Warto oddzielić zasób od usługi. Serwer, tenant, domena czy urządzenie są elementami środowiska. Usługą jest możliwość obsługi zamówienia, kontaktu z klientem albo realizacji procesu księgowego. To rozróżnienie pomaga ocenić skutki niedostępności oraz zdecydować, które dowody i testy są potrzebne najpierw.
Dostawcy są częścią tego obrazu. Zapisz, kto dostarcza usługę, kto jest właścicielem konta rozliczeniowego, kto ma dostęp administracyjny, jakie są kanały kontaktu oraz czy firma potrafi odzyskać dokumentację i dane przy zmianie współpracy. Nie zakładaj, że dostawca automatycznie odpowiada za wszystkie obowiązki organizacji.
Przypisz decyzje do właścicieli, nie tylko zadania do IT
NIS2 nakłada na organy zarządzające obowiązek zatwierdzania środków zarządzania ryzykiem cyberbezpieczeństwa i nadzorowania ich wdrożenia. To oznacza, że kierownictwo potrzebuje informacji o ryzykach, priorytetach i ograniczeniach, a nie tylko końcowej polityki do podpisu. [1]
W praktyce rozdziel cztery role: właściciel usługi ocenia wpływ na działalność, osoba techniczna utrzymuje lub zmienia środowisko, właściciel ryzyka akceptuje decyzję biznesową, a koordynator pilnuje dowodów i terminów. Jedna osoba może pełnić kilka ról w małej firmie, lecz odpowiedzialność powinna być zapisana wraz z zastępstwem.
Przy dostawcy zewnętrznym uzgodnij granice: kto wykonuje aktualizacje, kto obserwuje zdarzenia, kto zatwierdza zmianę, kto testuje kopię, kto informuje o problemie i jak przekazywana jest dokumentacja. Nie wynika z tego automatycznie całodobowa dostępność, SLA, przejęcie każdego systemu ani prawo do ingerencji bez odrębnego ustalenia.
Opisz wyłącznie kontekst regulacyjny, krytyczne usługi i stan dokumentacji — bez haseł, tokenów, kluczy ani pełnych logów.
Przejdź do bezpiecznego formularzaChecklista: zamień wymagania na rejestr ryzyka i dowody działania
Dyrektywa wskazuje między innymi polityki analizy ryzyka i bezpieczeństwa systemów, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, ocenę skuteczności środków, podstawową higienę cybernetyczną, kryptografię, bezpieczeństwo zasobów ludzkich, kontrolę dostępu i uwierzytelnianie wieloskładnikowe lub ciągłe. Środki powinny być proporcjonalne do ryzyka, a ich dobór wymaga oceny konkretnego podmiotu. [1]
Zamiast budować długą listę deklaracji, dla każdego priorytetu zapisz ryzyko, usługę, właściciela, aktualny stan, decyzję, termin oraz dowód. Dowodem może być wynik przeglądu kont uprzywilejowanych, protokół testu odtworzenia, zatwierdzona ocena dostawcy, zapis ćwiczenia incydentowego lub potwierdzony plan naprawczy.
Nie traktuj dokumentu jako dowodu sam w sobie. Polityka jest potrzebna, lecz warto sprawdzić, czy odpowiada jej rzeczywista konfiguracja, procedura oraz ślad wykonania. Jeżeli dowodu nie ma, uczciwą odpowiedzią jest luka do zaplanowania, a nie deklaracja zgodności.
- Ustal katalog usług krytycznych, właścicieli i ich zastępstwa.
- Zapisz ryzyka wraz z decyzją, priorytetem, terminem oraz kryterium zamknięcia.
- Sprawdź konta uprzywilejowane, MFA, aktualizacje i zasady dostępu adekwatnie do zakresu.
- Ustal zakres kopii, odpowiedzialność i test odtworzenia dla najważniejszych usług.
- Oceń istotnych dostawców oraz warunki dostępu, incydentów i przekazania danych.
- Przećwicz scenariusz incydentu oraz zapisz wnioski i właścicieli poprawek.
Ograniczenia: przygotowanie nie potwierdza zgodności ani nie eliminuje ryzyka
Inwentaryzacja, analiza luk i plan działań mogą uporządkować pracę, ale nie są certyfikatem zgodności, poradą prawną ani gwarancją uniknięcia incydentu. Skuteczność kontroli zależy od aktualności środowiska, jakości wdrożenia, zachowania użytkowników, dostawców i rzeczywistego przebiegu zdarzeń.
Nie kopiuj gotowej dokumentacji bez sprawdzenia zakresu. Taki dokument może pominąć usługę krytyczną, przypisać zadanie osobie bez uprawnienia albo stworzyć dowód pozorny. Przy zmianie działalności, istotnego dostawcy, struktury organizacyjnej lub systemu należy wrócić do kwalifikacji oraz rejestru ryzyka.
Jeżeli organizacja otrzymała formalne zawiadomienie lub wpis dotyczący KSC, zachowaj dokumenty, potwierdź terminy w aktualnych źródłach i skoordynuj działania prawne z technicznymi. Techniczna analiza pomaga zrozumieć stan środowiska, ale nie rozstrzyga obowiązków ustawowych.
Kiedy potrzebna jest pomoc przy analizie gotowości do NIS2
Analiza gotowości jest przydatna po potwierdzeniu lub uprawdopodobnieniu zakresu regulacyjnego, gdy firma nie potrafi połączyć obowiązków z usługami, właścicielami i dowodami. Może też uporządkować materiał dla zarządu przed podjęciem decyzji o priorytetach, budżecie lub kolejności prac.
Dobrym punktem wyjścia jest niesekretny opis działalności, potwierdzony kontekst prawny, lista usług krytycznych, znani dostawcy i stan dokumentacji. Konkretna metodologia, dostęp do systemów, termin oraz rezultat wymagają uzgodnienia zakresu. Nie wysyłaj w pierwszej wiadomości haseł, kodów MFA, tokenów, kluczy, pełnych konfiguracji ani materiału z aktywnego incydentu.
Przekaż tylko ogólny kontekst, uzgodniony zakres i dostępność dokumentacji.
Omów analizę gotowości do NIS2Źródła
Źródła zewnętrzne zweryfikowane podczas aktualizacji 2026-10-07. Przed działaniem sprawdź ich bieżącą wersję.