Analiza luk KSC/NIS2 – jak sprawdzić, czego brakuje podmiotowi?

Jednym z pierwszych praktycznych etapów wdrożenia nowych obowiązków cyberbezpieczeństwa powinna być analiza luk, czyli uporządkowane porównanie wymagań wynikających z ustawy o krajowym systemie cyberbezpieczeństwa ze stanem rzeczywiście funkcjonującym w podmiocie.

Dla podmiotów działających w Polsce punktem odniesienia jest przede wszystkim ustawa o KSC wdrażająca dyrektywę NIS2, uzupełniona – gdy ma to zastosowanie – bezpośrednio obowiązującymi aktami prawa Unii Europejskiej. Nie należy traktować KSC i NIS2 jako dwóch równoległych checklist.

Celem analizy nie jest odpowiedź na pytanie „czy mamy politykę bezpieczeństwa?”, lecz ustalenie, które wymagania mają zastosowanie, jak są realizowane, jakie istnieją dowody ich wykonania i czego nadal brakuje.

Dobrze przeprowadzona analiza powinna zakończyć się planem działań zawierającym priorytety, właścicieli, terminy, budżet i sposób potwierdzenia wykonania. Sama analiza luk nie jest odrębnie nazwanym obowiązkiem ustawowym. Jest praktyczną metodą przygotowania podmiotu do realizacji KSC, w tym wdrożenia i utrzymywania systemu zarządzania bezpieczeństwem informacji – SZBI.

Najważniejsza zasada: analiza luk nie może ograniczać się do przeglądu dokumentów. Trzeba badać równocześnie wymaganie prawne, faktyczny sposób działania oraz dowody jego wykonywania. Procedura tworzenia kopii zapasowych nie oznacza zgodności, jeżeli nie można wykazać, że kopie rzeczywiście powstają i da się z nich odtworzyć dane.

Najpierw ustal właściwy model KSC

Największym błędem metodologicznym jest rozpoczęcie analizy od uniwersalnej checklisty bezpieczeństwa bez wcześniejszego ustalenia statusu podmiotu. Zakres wymagań zależy między innymi od tego, czy organizacja jest podmiotem kluczowym, podmiotem ważnym, podmiotem ważnym będącym podmiotem publicznym, właściwym podmiotem systemu szkolnictwa wyższego i nauki albo podmiotem działającym w kilku sektorach.

W przypadku podmiotu publicznego trzeba dodatkowo uwzględnić art. 16d KSC, który wiąże wykonywanie wskazanych obowiązków z wykorzystywaniem systemu informacyjnego do realizacji zadania publicznego.

Model z art. 8 ust. 1

Podmioty kluczowe i większość podmiotów ważnych wdrażają SZBI w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi. Model obejmuje między innymi:

• systematyczne szacowanie ryzyka i zarządzanie nim;
• bezpieczeństwo nabywania, rozwoju i utrzymania systemów;
• bezpieczeństwo fizyczne, personelu i łańcucha dostaw;
• ciągłość działania, monitorowanie i ocenę skuteczności zabezpieczeń;
• edukację, cyberhigienę, kryptografię i bezpieczną komunikację;
• kontrolę dostępu i zarządzanie aktywami;
• zarządzanie podatnościami, aktualizacjami i incydentami.

W tym modelu analiza luk musi być powiązana z analizą ryzyka. Nie można automatycznie przyjąć, że brak określonej technologii – na przykład EDR – oznacza niezgodność z KSC. Prawidłowe pytanie brzmi: czy zastosowane zabezpieczenia są odpowiednie i proporcjonalne do oszacowanego ryzyka, charakteru systemu oraz możliwego wpływu incydentu na świadczoną usługę?

Model z art. 8 ust. 3 i załącznika nr 4

Podmiot ważny będący podmiotem publicznym nie stosuje art. 8 ust. 1. Opracowuje, wdraża, realizuje, monitoruje i utrzymuje SZBI spełniający wymagania załącznika nr 4.

Ten sam model stosują wskazane w art. 8 ust. 3 podmioty systemu szkolnictwa wyższego i nauki, niebędące organizacjami badawczymi, w zakresie, w jakim realizują zadania publiczne z wykorzystaniem systemów informacyjnych.

Podmiot publiczny powinien ponadto uwzględnić system informacyjny dostarczany przez inny podmiot publiczny w zakresie odpowiadającym jego kompetencjom wynikającym z polityki bezpieczeństwa tego systemu albo przepisów regulujących jego działanie.

Sprawdź przepisy szczególne

Podział na art. 8 ust. 1 i art. 8 ust. 3 nie wyczerpuje wszystkich przypadków. Przed zbudowaniem checklisty trzeba sprawdzić także:

• szczegółowe wymagania wydane na podstawie art. 8a;
• art. 8b oraz rozporządzenie wykonawcze Komisji (UE) 2024/2690 dla wskazanych dostawców usług cyfrowych i ICT;
• dodatkowe wymagania rozporządzenia delegowanego Komisji (UE) 2024/1366 dla właściwych podmiotów z podsektora energii elektrycznej;
• szczególną relację KSC–DORA wynikającą z art. 8i dla sektora bankowości i infrastruktury rynków finansowych.

Prawidłowym punktem odniesienia są wymagania właściwe dla konkretnego statusu, sektora i rodzaju działalności podmiotu, a nie jedna uniwersalna checklista „NIS2”.

Najważniejsze terminy przy analizie luk

Przy stanie prawnym na 7 sierpnia 2026 r. analiza powinna uwzględniać harmonogram wdrożenia.

Art. 33 nowelizacji przewiduje 12 miesięcy na realizację obowiązków rozdziału 3 oraz 24 miesiące na pierwszy audyt dla podmiotów kluczowych objętych przepisem przejściowym. Dotychczasowi operatorzy usług kluczowych zachowują dotychczasowy cykl audytowy – audyt co najmniej raz na trzy lata, licząc od sporządzenia i podpisania raportu z poprzedniego audytu.

Termin 3 października 2026 r. nie jest ogólnym terminem dla podmiotów publicznych wpisywanych z urzędu. Harmonogram Ministerstwa przewiduje samorejestrację od 7 maja do 3 października 2026 r. dla podmiotów niewpisywanych z urzędu.

Załącznik nr 4 – czego szukać?

Część I załącznika nr 4 stanowi podstawowy katalog wymagań, które SZBI podmiotu ważnego będącego podmiotem publicznym obejmuje co najmniej.

Szczególnie istotne jest to, że załącznik wymaga nie tylko wykonywania kopii, ale także sprawdzania ich kompletności i możliwości odtworzenia oraz testowania procedury działania na wypadek awarii lub incydentu.

Część II nie jest prostą listą niezgodności

Część II załącznika nr 4 stanowi, że SZBI może dodatkowo obejmować między innymi rozwiązania dotyczące ograniczania błędów ludzkich, wysokiej dostępności, korzystania z chmury i dużych generatywnych modeli AI, dodatkowego monitoringu, testów bezpieczeństwa, wymagań dla dostawców oraz dodatkowych środków technicznych i organizacyjnych.

Analiza powinna ocenić zasadność zastosowania takich środków. Nie należy mechanicznie oznaczać każdego niewdrożonego elementu części II jako odrębnego naruszenia.

Analiza musi obejmować więcej niż SZBI

Sprawdzenie samego art. 8 lub załącznika nr 4 nie stanowi pełnej analizy obowiązków KSC.

Zarządzanie i odpowiedzialność

Trzeba sprawdzić przydzielenie zadań, nadzór kierownika, planowanie adekwatnych środków finansowych, świadomość personelu oraz rzeczywiste wykonywanie zadań wynikających z art. 8d. Analiza powinna objąć także coroczne szkolenie kierownika oraz – jeżeli taką osobę wyznaczono – osoby, której powierzono obowiązki kierownika w zakresie cyberbezpieczeństwa.

Organizacja wykonywania obowiązków – art. 14

Należy ustalić, czy podmiot powołał wewnętrzne struktury odpowiedzialne za cyberbezpieczeństwo albo zawarł umowę z dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa. W podmiocie publicznym trzeba dodatkowo ustalić, czy część obowiązków nie jest wykonywana wspólnie w trybie art. 16e–16h oraz jaki jest zakres takiego modelu.

Weryfikacja osób – KRK

Analiza nie powinna zakładać masowej weryfikacji całego działu IT. Art. 8f dotyczy osób realizujących zadania z art. 8 albo art. 11. Przed rozpoczęciem takich zadań osoba przedstawia podmiotowi wymaganą informację z Krajowego Rejestru Karnego, a kierownik dopuszcza ją do wykonywania zadań po otrzymaniu dokumentu.

Wymóg uznaje się za spełniony również w przypadku osoby posiadającej ważne poświadczenie bezpieczeństwa uprawniające do dostępu do informacji niejawnych o klauzuli „poufne” albo wyższej. Trzeba zatem ustalić, kto wykonuje zadania z art. 8 lub 11, czy wobec tych osób przeprowadzono proces, czy dokument przedstawiono przed dopuszczeniem do zadań i czy występuje przypadek właściwego poświadczenia bezpieczeństwa.

Osoby kontaktowe, obowiązki wobec użytkowników i S46

Zasadą jest wyznaczenie przez podmiot kluczowy albo ważny co najmniej dwóch osób kontaktowych. Co najmniej jedna osoba wystarcza w przypadku mikro- lub małego przedsiębiorcy oraz podmiotu ważnego będącego podmiotem publicznym.

Analiza powinna zweryfikować liczbę osób, aktualność ich danych, zastępstwo, gotowość do korzystania z S46, zapewnienie użytkownikowi dostępu do wiedzy o cyberzagrożeniach oraz możliwość zgłoszenia cyberzagrożenia, incydentu lub podatności. Art. 9 wskazuje również, że po uzyskaniu wpisu podmiot rozpoczyna korzystanie z S46, przy czym dla podmiotów objętych okresem przejściowym harmonogram przewiduje czas do 3 kwietnia 2027 r.

Dokumentacja

Art. 10 rozróżnia dokumentację normatywną i operacyjną. Dokumentację operacyjną stanowią zapisy potwierdzające wykonywanie czynności wymaganych dokumentacją normatywną, w tym automatycznie generowane logi.

W przypadku podmiotu ważnego będącego podmiotem publicznym część IV załącznika nr 4 dodatkowo wymaga dokumentowania realizacji działań wskazanych do wykonania w SZBI.

Incydenty

Analiza powinna objąć przyjmowanie informacji o zdarzeniach, klasyfikację, eskalację, obsługę incydentu, terminy raportowania, dostęp do S46, zabezpieczenie dowodów, komunikację z użytkownikami i właściwego odbiorcę zgłoszenia.

Podmiot ważny publiczny – obowiązuje zgłoszenie w ciągu 72 godzin

Art. 12c nie znosi zasadniczego obowiązku zgłoszeniowego. Podmiot ważny będący podmiotem publicznym nadal zgłasza incydent poważny niezwłocznie, nie później niż w ciągu 72 godzin od jego wykrycia. Nie przekazuje natomiast wczesnego ostrzeżenia, sprawozdania okresowego, sprawozdania z postępu obsługi ani sprawozdania końcowego.

Do którego CSIRT zgłaszać incydent?

Do dnia ogłoszenia przez właściwy organ komunikatu o osiągnięciu zdolności operacyjnej przez CSIRT sektorowy podmioty kluczowe i ważne zgłaszają incydenty poważne do właściwego CSIRT MON, CSIRT NASK albo CSIRT GOV. Do CSIRT sektorowego zgłoszenia kieruje się od dnia następującego po dniu opublikowania komunikatu o osiągnięciu przez ten zespół zdolności operacyjnej.

Wyjątek dotyczy sektorowych zespołów cyberbezpieczeństwa powołanych przed 2025 r. W sektorach objętych tym wyjątkiem zgłoszenia są kierowane do zespołu sektorowego, który z dniem wejścia nowelizacji w życie stał się CSIRT sektorowym. W analizie warto zatem zapisać, jaki CSIRT jest obecnie właściwy i czy procedura wskazuje aktualnego adresata.

Jak przeprowadzić analizę luk krok po kroku?

Krok 1. Potwierdź kwalifikację

Przed przygotowaniem checklisty ustal status podmiotu, podstawę prawną, sektor i podsektor, rodzaje działalności, właściwy model SZBI, regulacje szczególne, organ właściwy, aktualnie właściwy CSIRT oraz ewentualny zakres wspólnego wykonywania obowiązków. Rezultatem powinna być udokumentowana karta kwalifikacji KSC.

Krok 2. Określ zakres systemów i procesów

Nie zaczynaj od pytania „jakie komputery posiadamy?”. Najpierw ustal, jakie usługi lub zadania realizuje podmiot, które procesy wpływają na ich realizację, jakie systemy wspierają te procesy, jakie informacje są przetwarzane, od jakiej infrastruktury zależą i którzy dostawcy uczestniczą w ich utrzymaniu.

W modelu z art. 8 ust. 1 SZBI obejmuje system informacyjny wykorzystywany w procesach wpływających na świadczenie usługi. System finansowy, kadrowy, pocztowy czy urządzenie mobilne powinny zostać zinwentaryzowane i ocenione pod kątem wpływu na usługę. Niższa krytyczność nie oznacza automatycznie wyłączenia z zakresu SZBI.

Krok 3. Zbuduj rejestr wymagań

Każdy wymóg powinien stanowić odrębny rekord.

Krok 4. Zbieraj dowody, nie deklaracje

Odpowiedź „tak, wykonujemy backup” nie wystarcza. Osoba prowadząca analizę powinna sprawdzić konfigurację, harmonogram, raport z wykonania kopii, lokalizację przechowywania i wynik testu odtworzenia. W innych obszarach dowodami mogą być zarządzenia, procedury, rejestry, konfiguracje, logi, raporty systemowe, protokoły testów, zgłoszenia serwisowe, umowy, dokumentacja zmian uprawnień i potwierdzenia szkoleń.

Krok 5. Oddziel stan realizacji od stanu dowodów

Bezpieczniej stosować dwa odrębne pola.

Takie podejście pozwala odróżnić realny brak zabezpieczenia od sytuacji, w której zabezpieczenie działa, ale nie jest prawidłowo dokumentowane.

Krok 6. Opisz lukę precyzyjnie

Zamiast „backup – częściowo” lepiej zapisać:

W przypadku podmiotu stosującego załącznik nr 4 kopie bazy systemu X wykonywane są codziennie, lecz nie przedstawiono dowodu ich wymaganej logicznej i fizycznej separacji ani testu możliwości odtworzenia.

Zamiast „dostawcy – brak zgodności” lepiej:

Umowa utrzymaniowa systemu X nie określa zasad eskalacji incydentu ani obowiązku przekazania informacji niezbędnych podmiotowi do wykonania jego obowiązków KSC.

Krok 7. Ustal priorytet

Priorytet powinien uwzględniać charakter obowiązku, ryzyko, wpływ na świadczenie usługi, krytyczność systemu, zależności od innych działań, potrzebę zakupu albo zmiany umowy, czas wdrożenia, koszt i termin ustawowy. Szczególnie wcześnie trzeba identyfikować luki wymagające postępowania zakupowego lub istotnych zmian infrastruktury.

Krok 8. Przygotuj plan działań naprawczych

Końcowym wynikiem powinien być operacyjny plan.

Każde działanie powinno mieć właściciela, termin oraz jednoznaczny sposób potwierdzenia zakończenia.

Co powinno trafić do raportu dla kierownika?

Raport zarządczy powinien pokazać najważniejsze luki prawne i organizacyjne, luki krytyczne, istotne ryzyka, działania wymagające budżetu lub zamówienia, opóźnienia, właścicieli działań oraz decyzje wymagane od kierownika.

Można wykorzystywać liczbowe wskaźniki postępu, ale nie należy przedstawiać ich jako ustawowego „procentu zgodności z NIS2”. Prawo nie przewiduje takiej kategorii.

Analiza luk, przegląd SZBI i audyt to różne procesy

Analiza luk może zostać wykonana własnymi zasobami albo ze wsparciem doradcy. Nie powinna być nazywana audytem ustawowym, jeśli nie spełnia warunków art. 15. W przypadku podmiotu ważnego będącego podmiotem publicznym załącznik nr 4 wymaga przeglądu SZBI co najmniej raz w roku oraz w dodatkowych sytuacjach wskazanych w załączniku.

Kogo zaangażować?

Rozmowa wyłącznie z administratorem IT może prowadzić do przeoczenia luk dotyczących personelu, dostawców, użytkowników, finansowania albo odpowiedzialności kierownictwa.

Najczęstsze błędy

Uniwersalna checklista dla każdego podmiotu

Podmiot stosujący art. 8 ust. 1 i podmiot ważny publiczny stosujący załącznik nr 4 nie powinny automatycznie otrzymać identycznych zestawów wymagań.

Analiza według ISO 27001 zamiast KSC

ISO 27001 może być wartościowym punktem odniesienia, ale nie zastępuje szczególnych wymagań ustawowych.

Ocena samych dokumentów

Istnienie procedury nie potwierdza jeszcze, że proces faktycznie działa.

Zamiana analizy w listę zakupów

Brak konkretnego produktu nie oznacza automatycznie niezgodności. Środki trzeba odnosić do właściwego przepisu, modelu i ryzyka.

Automatyczne traktowanie części II załącznika nr 4 jako niezgodności

Elementy tej części wymagają oceny zasadności zastosowania.

Nadużywanie statusu „nie dotyczy”

Każde takie oznaczenie powinno posiadać merytoryczne uzasadnienie.

Brak właściciela, terminu albo dowodu zamknięcia

Luka pozostaje otwarta, dopóki nie można zweryfikować wykonania zaplanowanego działania.

Checklista analizy luk

Co powinno powstać po analizie?

Minimalny zestaw rezultatów to:

1. karta kwalifikacji KSC;
2. rejestr wymagań właściwy dla konkretnego podmiotu;
3. rejestr luk ze stanem realizacji i stanem dowodów;
4. plan działań naprawczych z właścicielami, terminami i budżetem;
5. raport zarządczy dla kierownika.

Rejestr luk powinien być aktualizowany wraz z postępem wdrożenia. Zamknięcie luki powinno następować po wykonaniu działania i zweryfikowaniu jego rezultatu.

Podsumowanie

Analiza luk KSC/NIS2 powinna odpowiedzieć na sześć podstawowych pytań:

1. Co jest wymagane od naszego podmiotu?
2. Jakie przepisy szczególne mają zastosowanie?
3. Które systemy, procesy i usługi są objęte wymaganiami?
4. Czy wymaganie jest faktycznie realizowane?
5. Czy jego realizację można wykazać?
6. Co należy zrobić, aby usunąć stwierdzoną lukę?

Dla większości podmiotów punktem odniesienia będzie model oparty na ryzyku z art. 8 ust. 1. Dla podmiotu ważnego będącego podmiotem publicznym oraz właściwych podmiotów systemu szkolnictwa wyższego i nauki – art. 8 ust. 3 i załącznik nr 4. W określonych sektorach trzeba dodatkowo uwzględnić przepisy szczególne i bezpośrednio stosowane regulacje unijne.

Dobra analiza nie kończy się oceną „zgodne / niezgodne”. Jej rezultatem powinien być realny plan dojścia do zgodności, który wskazuje, co trzeba zrobić, kto odpowiada za rezultat, do kiedy działanie ma zostać wykonane, jakie są potrzeby finansowe i jak zostanie potwierdzone jego zakończenie.

Zobacz także

• Plan wdrożenia KSC w JSFP – harmonogram do 3 kwietnia 2027 r.;
• Pełny SZBI z art. 8 ust. 1 a szczególny model z art. 8 ust. 3;
• Załącznik nr 4 do ustawy o KSC – wymagania SZBI;
• Kto odpowiada za obowiązki KSC w jednostce? Macierz RACI+N.

Podstawy prawne i źródła

• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa – tekst jednolity ogłoszony w Dz.U. z 2026 r. poz. 20 ↗, z późniejszymi zmianami;
• Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw – Dz.U. z 2026 r. poz. 252 ↗;
• Ustawa z dnia 29 maja 2026 r. o zmianie ustawy o zarządzaniu kryzysowym oraz niektórych innych ustaw – Dz.U. z 2026 r. poz. 815 ↗;
• aktualny tekst ujednolicony ustawy o KSC, uwzględniający Dz.U. z 2026 r. poz. 20, 252 i 815 ↗;
• Ministerstwo Cyfryzacji – najważniejsze terminy nowelizacji KSC ↗;
• System S46 – samorejestracja w Wykazie KSC ↗;
• Ministerstwo Cyfryzacji – obowiązki podmiotów kluczowych i ważnych ↗.

Aktualny tekst ujednolicony Kancelarii Sejmu oraz materiały Ministerstwa Cyfryzacji i Systemu S46 mają charakter informacyjny i pomocniczy. Podstawowymi źródłami prawa pozostają akty ogłoszone w Dzienniku Ustaw oraz ustawy zmieniające.

Zastrzeżenie: Artykuł ma charakter informacyjny i nie stanowi opinii prawnej. Analiza luk powinna zostać dostosowana do statusu konkretnego podmiotu, podstawy kwalifikacji, sektora działalności, właściwego modelu SZBI, regulacji szczególnych, zakresu świadczonych usług lub realizowanych zadań oraz wykorzystywanych systemów informacyjnych.