3 października 2026 r. minął jeden z pierwszych ważnych terminów wynikających z nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa wdrażającej NIS2. Dla wielu podmiotów był to termin samodzielnego zgłoszenia do Wykazu KSC. Sam wpis nie oznacza jednak osiągnięcia zgodności. Przeciwnie – dla większości organizacji dopiero teraz zaczyna się najważniejszy etap: uporządkowanie zarządzania ryzykiem, wdrożenie Systemu Zarządzania Bezpieczeństwem Informacji, przygotowanie obsługi incydentów, zabezpieczenie łańcucha dostaw oraz stworzenie mechanizmów pozwalających wykazać, że cyberbezpieczeństwo rzeczywiście działa, a nie istnieje jedynie w dokumentacji.
Wpis do Wykazu KSC był dopiero pierwszym krokiem
Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa weszła w życie 3 kwietnia 2026 r. i wprowadziła w Polsce rozwiązania wynikające z dyrektywy NIS2. Dotychczasowy model został rozszerzony na znacznie większą grupę organizacji, które w zależności od spełnianych kryteriów mogą zostać zakwalifikowane jako podmioty kluczowe albo podmioty ważne.
Dla przedsiębiorstw, które już w dniu wejścia nowych przepisów spełniały kryteria objęcia systemem i nie były wpisywane z urzędu, jednym z pierwszych obowiązków była samorejestracja w Wykazie KSC. Termin ten upłynął 3 października 2026 r.
Łatwo jednak popełnić błąd i potraktować rejestrację jak najważniejszy punkt całego procesu. W rzeczywistości wpis do wykazu jest przede wszystkim formalnym początkiem funkcjonowania organizacji w nowym systemie cyberbezpieczeństwa.
Największa część pracy dotyczy tego, co dzieje się wewnątrz przedsiębiorstwa: jak identyfikuje ono ryzyko, zabezpiecza systemy, kontroluje dostęp, reaguje na incydenty, chroni kopie zapasowe, ocenia dostawców oraz zapewnia możliwość kontynuowania działalności po poważnym zdarzeniu.
Dlatego dla organizacji objętej KSC najważniejsze pytanie pod koniec 2026 r. nie powinno już brzmieć: „czy jesteśmy wpisani do wykazu?”, lecz „czy potrafimy wykazać, że rzeczywiście zarządzamy cyberbezpieczeństwem zgodnie z wymaganiami?”.
3 kwietnia 2027 r. – data, której nie warto traktować jako początku projektu
Kolejnym kluczowym terminem jest 3 kwietnia 2027 r. Do tego czasu podmioty objęte przepisami powinny przygotować się do realizacji obowiązków wynikających ze znowelizowanej ustawy, w tym wdrożyć wymagane rozwiązania organizacyjne i techniczne oraz rozpocząć korzystanie z systemu S46.
Sześć miesięcy może wydawać się długim okresem. W praktyce jest to jednak stosunkowo niewiele czasu, jeżeli organizacja rozpoczyna od podstaw.
Trzeba bowiem nie tylko napisać polityki i procedury. Najpierw należy ustalić, jakie zasoby rzeczywiście trzeba chronić, jakie systemy są krytyczne dla działalności, jakie występują zależności od dostawców oraz jakie scenariusze mogą doprowadzić do poważnego zakłócenia usług.
Dopiero na tej podstawie można sensownie dobrać zabezpieczenia.
Jeżeli przedsiębiorstwo pozostawi większość prac na pierwszy kwartał 2027 r., może odkryć, że części problemów nie da się rozwiązać samym dokumentem. Konieczne mogą być zmiany konfiguracji systemów, segmentacja sieci, dodatkowe mechanizmy uwierzytelniania, przebudowa kopii zapasowych, zmiana umów z dostawcami, zakup usług bezpieczeństwa albo uporządkowanie uprawnień setek użytkowników.
Dlatego termin ustawowy powinien oznaczać moment, w którym rozwiązania już funkcjonują, a nie datę pierwszego spotkania zespołu projektowego.
SZBI – system zarządzania, a nie segregator z procedurami
Jednym z najważniejszych obowiązków jest przygotowanie i wdrożenie Systemu Zarządzania Bezpieczeństwem Informacji, czyli SZBI.
Samo określenie „system zarządzania” jest tutaj kluczowe. Nie chodzi wyłącznie o stworzenie zbioru dokumentów opisujących, jak organizacja powinna działać. Chodzi o ustanowienie powtarzalnego mechanizmu, dzięki któremu ryzyka są identyfikowane, oceniane, ograniczane i ponownie analizowane.
Dobry SZBI powinien pozwolić odpowiedzieć przynajmniej na kilka podstawowych pytań:
- Co chronimy? Jakie systemy, informacje, urządzenia, usługi i procesy są istotne dla organizacji?
- Przed czym je chronimy? Jakie zagrożenia mogą doprowadzić do utraty poufności, integralności lub dostępności?
- Jak duże jest ryzyko? Jakie może być prawdopodobieństwo zdarzenia i jego wpływ na działalność?
- Jak ograniczamy ryzyko? Jakie zabezpieczenia techniczne, organizacyjne i operacyjne zostały wdrożone?
- Kto odpowiada? Kto podejmuje decyzje, kto utrzymuje zabezpieczenia i kto reaguje na incydenty?
- Skąd wiemy, że system działa? Jak prowadzimy monitoring, testy, przeglądy, audyty oraz działania korygujące?
W tym miejscu naturalnie pojawia się ISO/IEC 27001. Norma może stanowić bardzo dobre ramy do budowania systemowego podejścia do bezpieczeństwa informacji, ale samo posiadanie certyfikatu nie powinno być utożsamiane z automatycznym spełnieniem każdego wymagania KSC.
Organizacja powinna zawsze wykonać analizę zgodności pomiędzy własnym SZBI, faktycznie wdrożonymi zabezpieczeniami a konkretnymi obowiązkami wynikającymi z przepisów.
Incydent nie może uruchamiać improwizacji
Nowe regulacje jeszcze mocniej pokazują, że cyberbezpieczeństwo należy oceniać nie tylko przez pryzmat tego, czy firma potrafi zapobiec atakowi, lecz również tego, czy potrafi prawidłowo zareagować, gdy zabezpieczenia zawiodą.
To szczególnie istotne w przypadku ransomware, przejęcia kont uprzywilejowanych, wycieku informacji, niedostępności systemów lub naruszenia infrastruktury obsługującej kluczowe procesy.
W chwili incydentu nie powinno się dopiero ustalać:
- kto podejmuje decyzję o izolacji systemów,
- kto kontaktuje się z zespołem technicznym,
- kto kwalifikuje zdarzenie,
- kto odpowiada za zgłoszenie incydentu,
- kto informuje kierownictwo, klientów i partnerów biznesowych,
- gdzie znajdują się kopie zapasowe,
- w jaki sposób przywrócić najważniejsze procesy.
Procedura reagowania na incydenty powinna więc istnieć przed incydentem, a następnie zostać przećwiczona.
Ćwiczenie typu tabletop, podczas którego osoby odpowiedzialne otrzymują przykładowy scenariusz ataku i przechodzą przez kolejne decyzje, często ujawnia problemy niewidoczne podczas zwykłego przeglądu dokumentacji.
Może się okazać, że kontakt do jednej z kluczowych osób jest dostępny wyłącznie w systemie, który właśnie przestał działać, administrator nie ma dostępu do kopii zapasowej, a procedura wymaga akceptacji osoby przebywającej poza organizacją.
Cyberodporność zaczyna się więc tam, gdzie firma potrafi działać także wtedy, gdy normalne narzędzia przestają być dostępne.
Łańcuch dostaw – zabezpieczenia firmy kończą się dopiero u dostawcy
Jednym z najważniejszych elementów współczesnego zarządzania cyberbezpieczeństwem jest bezpieczeństwo łańcucha dostaw.
Firma może posiadać dobrze zabezpieczoną infrastrukturę, wieloskładnikowe uwierzytelnianie, monitoring i doświadczony zespół IT, a jednocześnie pozostawać podatna na atak przeprowadzony poprzez dostawcę oprogramowania, firmę serwisową, operatora chmury, biuro księgowe albo podmiot posiadający zdalny dostęp do systemów.
Dlatego ocena ryzyka nie powinna kończyć się na własnej sieci.
Organizacja powinna wiedzieć, którzy dostawcy mają dostęp do jej informacji i infrastruktury, jakie usługi są krytyczne dla ciągłości działania oraz co wydarzy się w przypadku awarii lub cyberataku u partnera.
Praktyczne zarządzanie tym ryzykiem może obejmować między innymi:
- klasyfikację dostawców według znaczenia i poziomu dostępu,
- weryfikację stosowanych przez nich zabezpieczeń,
- wymagania dotyczące zgłaszania incydentów,
- kontrolę kont i dostępów zewnętrznych,
- ustalenie zasad aktualizacji i zarządzania podatnościami,
- odpowiednie wymagania bezpieczeństwa w umowach,
- okresowe przeglądy najważniejszych dostawców.
Nie każdy dostawca wymaga oczywiście takiego samego poziomu kontroli. Firma sprzątająca bez dostępu do systemów informatycznych generuje inny profil ryzyka niż dostawca utrzymujący środowisko produkcyjne lub administrator posiadający zdalne konto uprzywilejowane.
Podstawą jest podejście oparte na ryzyku, a nie wysyłanie identycznej ankiety bezpieczeństwa do wszystkich kontrahentów.
Zarząd nie może delegować całej odpowiedzialności do IT
Jedna z najważniejszych zmian w sposobie myślenia o cyberbezpieczeństwie polega na odejściu od przekonania, że jest to wyłącznie problem działu IT.
Cyberbezpieczeństwo dotyczy ciągłości działania całej organizacji. Atak może zatrzymać produkcję, sprzedaż, logistykę, płatności, obsługę klientów i komunikację. Może doprowadzić do utraty danych, naruszenia zobowiązań kontraktowych oraz poważnych kosztów finansowych i reputacyjnych.
Dział IT może konfigurować zapory sieciowe, systemy EDR czy mechanizmy uwierzytelniania. Nie powinien jednak samodzielnie decydować, jaki poziom ryzyka biznesowego organizacja jest gotowa zaakceptować.
To wymaga udziału kierownictwa.
Zarząd powinien rozumieć przynajmniej:
- które procesy i systemy są krytyczne,
- jakie są najważniejsze ryzyka cybernetyczne,
- których ryzyk nie udało się jeszcze odpowiednio ograniczyć,
- jak wygląda gotowość do reagowania na incydent,
- czy organizacja potrafi odtworzyć działalność po awarii lub ataku,
- jakie działania wymagają inwestycji i decyzji biznesowych.
Jeżeli raport dla zarządu ogranicza się do stwierdzenia, że „antywirus działa, a firewall jest aktualny”, to organizacja prawdopodobnie nie zarządza jeszcze ryzykiem cybernetycznym na poziomie wymaganym przez współczesny biznes.
Najpierw luka, potem plan – jak wykorzystać najbliższe miesiące?
Najbardziej praktycznym sposobem rozpoczęcia przygotowań jest analiza luk, czyli porównanie stanu obecnego organizacji z wymaganiami, które powinna spełnić.
Nie chodzi przy tym o stworzenie tabeli zawierającej kilkaset pozycji oznaczonych kolorami czerwonym, żółtym i zielonym. Analiza powinna prowadzić do konkretnego planu działania.
Każda wykryta luka powinna mieć przynajmniej określone:
- ryzyko, którego dotyczy,
- działanie naprawcze,
- osobę odpowiedzialną,
- termin realizacji,
- wymagane zasoby,
- sposób potwierdzenia wykonania.
Dzięki temu wymagania prawne przestają być abstrakcyjną listą obowiązków, a zamieniają się w projekt możliwy do zarządzania.
Część działań może być stosunkowo prosta: aktualizacja polityki haseł, uporządkowanie kont użytkowników czy określenie odpowiedzialności za incydenty. Inne wymagają miesięcy – przykładowo przebudowa architektury kopii zapasowych, wdrożenie monitoringu bezpieczeństwa, uporządkowanie dostawców lub przygotowanie planów odtwarzania środowiska IT.
Właśnie dlatego najbliższe miesiące powinny być traktowane jako czas wdrażania, testowania i poprawiania systemu, a nie wyłącznie przygotowywania dokumentacji przed kontrolą.
KSC 2.0 zmienia pytanie: nie „czy mamy zabezpieczenia?”, lecz „czy umiemy to wykazać?”
Dojrzałość cyberbezpieczeństwa nie polega na posiadaniu jak największej liczby narzędzi. Firma może kupić firewall nowej generacji, system SIEM, rozwiązanie EDR i usługi SOC, a mimo to nadal pozostawać słabo przygotowana do rzeczywistego incydentu.
Problemem może być brak właścicieli procesów, nieaktualna lista aktywów, nieprzetestowane kopie zapasowe, niekontrolowane konta administratorów albo dostawca posiadający dostęp, o którym nikt już nie pamięta.
Z drugiej strony organizacja nie musi posiadać najbardziej rozbudowanego zestawu technologii na rynku, aby zarządzać bezpieczeństwem w sposób dojrzały. Kluczowe jest dopasowanie środków do rzeczywistego ryzyka, systematyczna ocena ich skuteczności i możliwość wykazania, dlaczego zostały zastosowane.
Dlatego przygotowanie do KSC 2.0 warto potraktować jako projekt porządkujący całą organizację. Pozwala on zidentyfikować krytyczne procesy, zależności technologiczne, dostawców, podatności i scenariusze, które wcześniej często pozostawały niewidoczne.
3 kwietnia 2027 r. nie powinien być więc postrzegany wyłącznie jako termin zgodności. Powinien być momentem, w którym przedsiębiorstwo potrafi już odpowiedzieć na znacznie ważniejsze pytanie: co zrobimy, jeżeli jutro jeden z naszych kluczowych systemów przestanie działać wskutek cyberataku – i czy jesteśmy w stanie udowodnić, że przygotowaliśmy się na taki scenariusz?
