NIS2 i nowa ustawa o KSC w 2026 r. – kto podlega, jakie są terminy i jak wdrożyć obowiązki

Nowa KSC obowiązuje od 3 kwietnia 2026 r.

Polska nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa wdrażająca NIS2 weszła w życie 3 kwietnia 2026 r. Zmieniła zakres podmiotów objętych systemem, mechanizm identyfikacji i katalog obowiązków organizacyjnych, technicznych oraz sprawozdawczych.

Dla przedsiębiorcy kluczowe jest odejście od pytania „czy mamy certyfikat bezpieczeństwa?” na rzecz pytania „czy spełniamy ustawowe kryteria podmiotu kluczowego albo ważnego i czy potrafimy wykazać adekwatne zarządzanie ryzykiem?”. Kwalifikacja wymaga analizy sektora, rodzaju działalności, wielkości i wyjątków ustawowych.

Wykaz KSC – termin 3 października 2026 r.

Ministerstwo Cyfryzacji uruchomiło samoobsługowy Wykaz KSC. Podmiot spełniający kryteria powinien złożyć wniosek o wpis w terminie ustawowym; dla podmiotów spełniających przesłanki w dniu wejścia w życie nowelizacji wskazywany termin upływa 3 października 2026 r.

Nie warto czekać do ostatnich dni. Samoidentyfikacja może wymagać ustalenia kodów i rodzaju działalności, struktury grupy, zatrudnienia, danych finansowych oraz relacji z podmiotami powiązanymi. Błędna kwalifikacja może prowadzić zarówno do pominięcia obowiązków, jak i do niepotrzebnego objęcia firmy reżimem, który jej nie dotyczy.

Co trzeba przygotować do 3 kwietnia 2027 r.?

W komunikatach Ministerstwa Cyfryzacji 3 kwietnia 2027 r. wskazywany jest jako istotny termin wdrożenia nowych obowiązków oraz podłączenia do systemu S46 dla nowych podmiotów. Zakres obejmuje między innymi systemowe zarządzanie cyberbezpieczeństwem, obsługę incydentów, wyznaczenie odpowiedzialności i mechanizmy kontaktu z systemem KSC.

Roczny okres nie powinien być traktowany jako czas na odłożenie projektu. Ocena ryzyka, inwentaryzacja aktywów, uporządkowanie dostawców, wdrożenie logowania i odtwarzania po awarii wymagają decyzji technicznych i budżetowych, których nie da się bezpiecznie wykonać w ostatnim miesiącu.

SZBI i zarządzanie ryzykiem – dokument ma wynikać z infrastruktury

System zarządzania bezpieczeństwem informacji powinien odpowiadać rzeczywistym procesom i zasobom. Punktem wyjścia jest inwentaryzacja usług, systemów, danych, zależności i kluczowych dostawców. Dopiero na tej podstawie ocenia się ryzyko oraz dobiera środki organizacyjne i techniczne.

Najczęstszy błąd to tworzenie polityk oderwanych od konfiguracji produkcyjnej. Jeżeli dokument mówi o MFA, kopiach zapasowych i segmentacji, a organizacja nie potrafi wykazać ich działania, problemem jest nie tylko luka techniczna, lecz również niewiarygodna dokumentacja compliance.

Rola kierownictwa i odpowiedzialność za cyberbezpieczeństwo

NIS2 i krajowe przepisy wzmacniają rolę organów zarządzających. Zarząd powinien znać istotne ryzyka, zatwierdzać kierunek działań, rozumieć konsekwencje incydentów i otrzymywać informacje umożliwiające realny nadzór. Nie oznacza to, że członkowie zarządu mają konfigurować zapory sieciowe.

Potrzebny jest czytelny model raportowania: jakie ryzyka są krytyczne, kto jest właścicielem działań naprawczych, jaki jest termin, jakie zasoby są potrzebne i co potwierdza wykonanie. Wtedy decyzja zarządcza opiera się na danych, a nie na ogólnym zapewnieniu, że „IT się tym zajmuje”.

Incydent: 24 godziny to czas na działanie, nie na rozpoczęcie analizy

Nowy reżim KSC przewiduje szybkie zgłaszanie istotnych incydentów. Publiczne materiały dla przedsiębiorców wskazują między innymi wczesne ostrzeżenie do właściwego CSIRT w ciągu 24 godzin. Dlatego organizacja musi przed incydentem wiedzieć, kto kwalifikuje zdarzenie, kto kontaktuje się z CSIRT i skąd pobiera dane techniczne potrzebne do zgłoszenia.

Procedura powinna współgrać z RODO, DORA i obowiązkami kontraktowymi. Jeden atak ransomware może uruchomić kilka różnych zegarów, a raporty kierowane do różnych odbiorców nie zawsze mają ten sam zakres. Centralny rejestr decyzji i jedna chronologia zdarzenia ograniczają ryzyko sprzecznych komunikatów.

Łańcuch dostaw i umowy z dostawcami ICT

Ryzyko dostawcy jest częścią ryzyka organizacji. Umowy powinny zapewniać informacje o incydentach, współpracę przy analizie, wymagania bezpieczeństwa, zasady podwykonawstwa, ciągłość działania i możliwość zakończenia współpracy bez utraty danych lub kontroli nad usługą.

Sam kwestionariusz wysłany raz w roku nie wystarcza do zarządzania dostawcą krytycznym. Zakres nadzoru powinien zależeć od znaczenia usługi i dostępu do systemów. Inaczej ocenia się dostawcę materiałów biurowych, a inaczej operatora chmury przechowującej dane produkcyjne.

Co audytować technicznie: tożsamość, segmentację, kopie i monitoring

Ustawa nie zastępuje architektury bezpieczeństwa. W praktyce audyt obejmuje kontrolę dostępu, MFA, zarządzanie uprzywilejowanymi kontami, segmentację sieci, aktualizacje, podatności, szyfrowanie, kopie zapasowe, monitoring, rejestrowanie zdarzeń i procedury odtwarzania.

Nie chodzi o wdrożenie największej liczby produktów bezpieczeństwa. Środki mają być proporcjonalne do ryzyka i skuteczne. Dla każdego kluczowego zabezpieczenia warto wskazać dowód działania: konfigurację, raport testu, log, protokół odtworzenia kopii albo wynik ćwiczenia incydentowego.

Plan wdrożenia NIS2/KSC dla firmy

Praktyczny plan można podzielić na etapy: kwalifikacja podmiotu, Wykaz KSC, inwentaryzacja aktywów i dostawców, analiza luk, projekt docelowych zabezpieczeń, aktualizacja umów, procedura incydentowa, szkolenia i testy. Taki układ pozwala połączyć prawo z pracą zespołu IT oraz budżetem.

Zakres wsparcia opisuję na stronie Prawo nowych technologii. W przypadku podmiotów objętych również DORA lub RODO warto zbudować jedną mapę kontroli i dowodów, zamiast utrzymywać kilka niespójnych systemów compliance.

Podmiot kluczowy czy ważny – kwalifikacja wymaga danych o działalności i wielkości

Klasyfikacja nie powinna opierać się wyłącznie na kodzie PKD. Trzeba ustalić, jaką usługę firma rzeczywiście świadczy, w jakim sektorze działa, jaka jest jej skala oraz czy zastosowanie mają szczególne kryteria lub wyjątki. W grupie kapitałowej znaczenie może mieć sposób liczenia danych przedsiębiorstwa i relacje z podmiotami powiązanymi.

Wynik samoidentyfikacji warto udokumentować w krótkiej notatce z podstawami. Dzięki temu, gdy zmieni się zakres działalności, zatrudnienie albo struktura grupy, można szybko ocenić, czy kwalifikację trzeba powtórzyć.

Ciągłość działania i odtwarzanie po awarii

Cyberbezpieczeństwo obejmuje nie tylko zapobieganie atakom, lecz także zdolność utrzymania lub odtworzenia kluczowych usług. Organizacja powinna znać maksymalny akceptowalny czas niedostępności, zależności między systemami i zasoby potrzebne do odtworzenia.

Plan ciągłości należy testować. Ćwiczenie może ujawnić, że kopia istnieje, ale odtworzenie trwa dłużej niż dopuszcza biznes, brakuje haseł awaryjnych albo dostawca nie ma całodobowego kontaktu. Takie ustalenia powinny prowadzić do konkretnych zmian, a nie jedynie do aktualizacji dokumentu.

Szkolenia i czynnik ludzki

Phishing, błędna konfiguracja i obchodzenie procedur pokazują, że bezpieczeństwo nie jest wyłącznie problemem technicznym. Szkolenie powinno odpowiadać roli pracownika. Administrator potrzebuje innego zakresu niż osoba w księgowości czy członek zarządu.

Warto ćwiczyć scenariusze: podejrzana wiadomość, utrata urządzenia, ujawnienie hasła, błąd dostawcy. Organizacja powinna mierzyć nie tylko frekwencję na szkoleniu, ale także zdolność do zgłoszenia zdarzenia właściwym kanałem.

Audyt i testowanie skuteczności środków

Ocena skuteczności powinna obejmować zarówno dokumentację, jak i stan techniczny. Przegląd dostępu, skan podatności, test odtworzenia, analiza logów i ćwiczenie incydentowe dają inne informacje niż samo sprawdzenie polityki.

W planie audytowym warto priorytetyzować systemy wspierające usługi kluczowe. Wynik audytu powinien rozróżniać ryzyko krytyczne, działania krótkoterminowe oraz zmiany architektoniczne wymagające budżetu i czasu.

Najczęstsze pytania