Jak przygotować zarząd i kadrę kierowniczą do nowych obowiązków KSC i NIS2?

KSC i NIS2 – jakie obszary organizacji obejmują nowe obowiązki

Obowiązki związane z KSC i NIS2 nie ograniczają się do zabezpieczenia infrastruktury IT. Dotyczą odporności organizacji na zdarzenia, które mogą zakłócić świadczenie usług, naruszyć bezpieczeństwo informacji lub zatrzymać istotne procesy. Dlatego przygotowanie do zgodności wymaga uwzględnienia nie tylko technologii, lecz także sposobu zarządzania, organizacji pracy, relacji z dostawcami oraz zależności między systemami a działalnością operacyjną.

NIS2 to unijna dyrektywa określająca wymagania w zakresie cyberbezpieczeństwa dla objętych nią podmiotów. KSC oznacza krajowy system cyberbezpieczeństwa, którego podstawę prawną w Polsce stanowi ustawa o krajowym systemie cyberbezpieczeństwa. Nie są to dwa niezależne zestawy wymagań: przepisy krajowe służą wdrożeniu dyrektywy i określają zasady realizacji obowiązków w Polsce. Ocenę sytuacji konkretnej organizacji należy zatem opierać na aktualnym brzmieniu polskich przepisów, z uwzględnieniem terminów ich stosowania i regulacji przejściowych, a nie wyłącznie na treści NIS2.

Pierwszą kwestią jest ustalenie, czy organizacja podlega regulacji i do jakiej kategorii należy. NIS2 rozróżnia podmioty kluczowe i ważne oraz obejmuje szerszy zakres sektorów niż poprzednia dyrektywa — między innymi energetykę, transport, ochronę zdrowia, infrastrukturę cyfrową, gospodarkę odpadami i wybrane rodzaje produkcji. Znaczenie mają rodzaj prowadzonej działalności, wielkość podmiotu oraz szczególne przesłanki objęcia regulacją. Sama liczba pracowników lub ogólne przypisanie firmy do branży nie wystarczają do prawidłowej kwalifikacji. Jednocześnie dostawca podmiotu objętego NIS2 może otrzymywać wymagania bezpieczeństwa w umowach, nawet jeśli sam nie podlega bezpośrednio tym obowiązkom.

Na poziomie organizacyjnym zakres wymagań łączy zarządzanie ryzykiem, bezpieczeństwo systemów i informacji oraz ciągłość działania. Obejmuje zapobieganie incydentom, ich obsługę, odtwarzanie działalności po zakłóceniu i ocenę skuteczności zabezpieczeń. Podejście NIS2 uwzględnia różne źródła zagrożeń: nie tylko cyberataki, ale również błędy człowieka, awarie czy zdarzenia fizyczne wpływające na systemy sieciowe i informacyjne. Środki bezpieczeństwa powinny być odpowiednie i proporcjonalne do ryzyka, skali działalności oraz możliwych skutków zakłóceń.

W praktyce oznacza to konieczność uwzględnienia procesów pozostających poza działem IT. Zakupy i współpraca z dostawcami wpływają na bezpieczeństwo łańcucha dostaw, procesy kadrowe — na dostęp do informacji i kompetencje pracowników, a operacje — na możliwość utrzymania usług podczas awarii. Znaczenie mają również bezpieczne nabywanie, rozwijanie i utrzymywanie systemów, zarządzanie podatnościami, kontrola dostępu oraz ochrona środowiska, w którym działa infrastruktura.

Punktem wyjścia jest więc rozpoznanie, które usługi, procesy, zasoby i zależności zewnętrzne wymagają ochrony. Tak określony zakres pozwala traktować przygotowanie do KSC i NIS2 jako spójny program organizacyjny, a nie odrębne zadanie techniczne lub samo uzupełnienie dokumentacji.

Rola zarządu i kadry kierowniczej: nadzór, decyzje i odpowiedzialność

Cyberbezpieczeństwo wymaga decyzji zarządczych, a nie wyłącznie działań działu IT. Zgodnie z art. 20 dyrektywy NIS2 państwa członkowskie mają zapewnić, aby organy zarządzające podmiotów kluczowych i ważnych zatwierdzały środki zarządzania ryzykiem w cyberbezpieczeństwie oraz nadzorowały ich wdrażanie. Dyrektywa przewiduje również możliwość pociągnięcia tych organów do odpowiedzialności za naruszenie obowiązków dotyczących takich środków. Szczegółowe zasady odpowiedzialności w Polsce należy ustalać na podstawie obowiązujących przepisów krajowych, w tym ustawy o krajowym systemie cyberbezpieczeństwa (KSC).

Rolą zarządu nie jest dobór konfiguracji technicznych ani samodzielne projektowanie zabezpieczeń. Powinien natomiast rozumieć, jakie zagrożenia mogą zakłócić działalność organizacji, jakie działania ograniczają ich skutki i jakich zasobów wymaga wdrożenie tych działań. Zatwierdzenie dokumentu bez zrozumienia jego znaczenia dla działalności nie zastępuje świadomej decyzji. Kierownictwo potrzebuje informacji przedstawionych językiem konsekwencji biznesowych: przerw w świadczeniu usług, utraty danych, zobowiązań wobec klientów i kosztów przywrócenia działalności.

W praktyce warto rozdzielić trzy poziomy zaangażowania:

• Zarząd lub właściwy organ zarządzający — zatwierdza kierunek działań i środki zarządzania ryzykiem, zapewnia odpowiednie zasoby oraz nadzoruje realizację podjętych decyzji.
• Kadra kierownicza obszarów biznesowych i operacyjnych — przekłada ustalenia na organizację pracy, wskazuje zależności i potrzeby swoich obszarów oraz odpowiada za wykonanie powierzonych zadań.
• IT, bezpieczeństwo i compliance — dostarczają ocen i rekomendacji, realizują zadania zgodnie z kompetencjami oraz wyjaśniają kierownictwu techniczne i prawne konsekwencje dostępnych rozwiązań.

Delegowanie zadań nie oznacza automatycznego przeniesienia odpowiedzialności prawnej. Powołanie osoby odpowiedzialnej za bezpieczeństwo lub powierzenie usług zewnętrznemu dostawcy nie zastępuje nadzoru organu zarządzającego. Jednocześnie nie należy utożsamiać odpowiedzialności każdego kierownika z odpowiedzialnością członka zarządu — znaczenie mają przepisy, formalna funkcja i zakres powierzonych kompetencji.

Rekomendujemy, aby podział zadań uzupełnić jasnym określeniem uprawnień decyzyjnych: kto zatwierdza wydatki, kto rozstrzyga konflikty między wymaganiami bezpieczeństwa a potrzebami operacyjnymi oraz które sprawy wymagają decyzji zarządu. Ustalenia warto utrwalić w matrycy odpowiedzialności i upoważnieniach, a istotne decyzje — dokumentować wraz z uzasadnieniem. Akceptacja ryzyka przez kierownictwo nie może przy tym służyć jako uzasadnienie odstąpienia od obowiązku wynikającego z prawa.

3. Szkolenie kierownictwa jako element programu zgodności (nie jednorazowe wydarzenie)

Szkolenie zarządu powinno rozwijać zdolność podejmowania decyzji dotyczących cyberbezpieczeństwa, a nie jedynie potwierdzać obecność uczestników. Artykuł 20 NIS2 przewiduje szkolenia dla członków organów zarządzających podmiotów kluczowych i ważnych. Ich celem jest zdobycie wiedzy i umiejętności pozwalających rozpoznawać ryzyko oraz oceniać praktyki zarządzania ryzykiem w cyberbezpieczeństwie i ich wpływ na świadczone usługi. Szczegółowe wymagania dotyczące realizacji obowiązku w Polsce należy ustalać na podstawie obowiązujących przepisów KSC, odróżniając wymogi prawne od rekomendowanych praktyk rozwojowych.

Przygotowanie programu warto rozpocząć od krótkiej diagnozy: jakie decyzje podejmują uczestnicy, z jakich informacji korzystają i których zagadnień nie potrafią jeszcze samodzielnie ocenić. Pomocne są rozmowy z przedstawicielami zarządu, bezpieczeństwa, IT, compliance i operacji oraz analiza wykorzystywanych w organizacji materiałów. Dzięki temu szkolenie odnosi się do rzeczywistych potrzeb, zamiast powielać ogólny kurs świadomości zagrożeń przeznaczony dla wszystkich pracowników.

Wspólna podstawa wiedzy nie oznacza identycznego programu dla każdej roli. Zarząd potrzebuje przede wszystkim umiejętności interpretowania informacji o ryzyku i oceny uzasadnienia proponowanych działań. Kierownicy obszarów powinni rozumieć, jak wymagania bezpieczeństwa przekładają się na pracę ich zespołów. Wspólny moduł pomaga uporządkować pojęcia, natomiast ćwiczenia warto dopasować do zakresu decyzji poszczególnych uczestników.

Rekomendujemy zaplanowanie szkolenia jako powtarzalnego cyklu obejmującego trzy elementy:

• Przygotowanie do pełnienia funkcji — szkolenie wprowadzające dla osób obejmujących stanowiska zarządcze i kierownicze, uwzględniające specyfikę organizacji.
• Utrwalanie umiejętności — krótkie warsztaty decyzyjne i omówienia przypadków, podczas których uczestnicy wykorzystują wiedzę w sytuacjach zbliżonych do swojej pracy.
• Aktualizację wiedzy — uzupełnianie programu po istotnych zmianach prawnych, organizacyjnych lub technologicznych oraz po rozpoznaniu luk kompetencyjnych.

Częstotliwość działań rozwojowych należy powiązać z wymaganiami prawnymi i potrzebami organizacji. Samo powtarzanie tej samej prezentacji nie zapewnia postępu. W podejściu learning by doing uczestnicy mogą na przykład ocenić uzasadnienie inwestycji w zabezpieczenia albo wskazać, jakich informacji brakuje do podjęcia decyzji. Ćwiczenie powinno kończyć się omówieniem argumentów i niejasności, z wykorzystaniem materiałów odpowiednio zabezpieczonych lub zanonimizowanych.

Program wymaga również jednoznacznie wskazanego właściciela. HR może koordynować organizację i ewidencję szkoleń, natomiast osoby odpowiedzialne za bezpieczeństwo i compliance powinny uczestniczyć w określaniu celów oraz aktualizacji treści. Rekomendowany zestaw dokumentów obejmuje plan rozwoju kompetencji, program i materiały szkoleniowe, potwierdzenia uczestnictwa oraz wyniki oceny wiedzy i zadania uzupełniające.

Certyfikat uczestnictwa dokumentuje udział, ale sam nie dowodzi skuteczności przygotowania ani pełnej zgodności organizacji. Warto sprawdzić, czy uczestnicy potrafią zastosować wiedzę w krótkim zadaniu sytuacyjnym, a rozpoznane trudności uwzględnić w kolejnych zajęciach. W ten sposób szkolenie staje się stałym elementem programu zgodności i systemu zarządzania bezpieczeństwem informacji (SZBI), zamiast działaniem zamykanym po zakończeniu warsztatu.

Wdrożenie SZBI: kluczowe kroki, role i dokumenty

System zarządzania bezpieczeństwem informacji (SZBI) łączy zasady, odpowiedzialności i zabezpieczenia w jeden sposób zarządzania ochroną informacji. Nie jest wyłącznie projektem IT ani zbiorem polityk. Ma zapewniać poufność, integralność i dostępność informacji w procesach organizacji. W przygotowaniu do obowiązków KSC i NIS2 porządkuje działania oraz pozwala powiązać wymagania z konkretnymi właścicielami, procedurami i dowodami ich stosowania.

Pierwszym krokiem jest określenie zakresu SZBI i rozpoznanie stanu obecnego. Należy wskazać usługi i procesy objęte systemem, przetwarzane informacje, wykorzystywane zasoby oraz zależności od dostawców. Zakres nie powinien ograniczać się do infrastruktury informatycznej: znaczenie mają również ludzie, dokumentacja papierowa, lokalizacje i usługi zewnętrzne. Analiza luk pozwala następnie ustalić, które rozwiązania już działają, które wymagają poprawy, a których brakuje w świetle wymagań mających zastosowanie do organizacji.

Kolejny krok to ocena ryzyka i dobór proporcjonalnych zabezpieczeń. Właściciele procesów określają znaczenie informacji oraz skutki zakłóceń, a zespoły techniczne i bezpieczeństwa pomagają rozpoznać zagrożenia oraz podatności. Wynikiem powinien być plan postępowania z ryzykiem, wskazujący działania, odpowiedzialnych i potrzebne zasoby. ISO/IEC 27001 może stanowić ramę metodyczną dla SZBI, jednak sam certyfikat nie jest równoznaczny ze spełnieniem wszystkich obowiązków KSC i NIS2. Zgodność trzeba odnosić do konkretnych wymagań prawnych właściwych dla danego podmiotu.

Podział ról należy ustalić przed opracowaniem szczegółowych procedur. Rekomendujemy wyznaczenie koordynatora SZBI, który prowadzi prace między obszarami i dba o spójność systemu. Właściciele procesów odpowiadają za wdrożenie zasad w swoich obszarach, IT za realizację uzgodnionych zabezpieczeń technicznych, a compliance lub dział prawny za identyfikację właściwych wymagań. HR wspiera zasady bezpieczeństwa związane z zatrudnieniem, natomiast zakupy uwzględniają je w relacjach z dostawcami. Macierz odpowiedzialności powinna jasno rozdzielać wykonanie zadania, jego zatwierdzenie i konsultację.

Dokumentację warto budować od ogółu do szczegółu. Polityka bezpieczeństwa informacji określa cele i zasady, opis zakresu wyznacza granice systemu, a metodyka oceny ryzyka zapewnia spójność podejmowanych decyzji. Rejestr zasobów i ich właścicieli, rejestr ryzyk oraz plan postępowania z ryzykiem łączą te założenia z rzeczywistymi procesami. Procedury operacyjne przekładają je na codzienną pracę, między innymi w zakresie nadawania i odbierania uprawnień, klasyfikacji informacji, zarządzania zmianami oraz współpracy z dostawcami.

Przyjęcie dokumentów nie kończy wdrożenia. Każdy dokument powinien mieć właściciela, zatwierdzoną wersję i zasady aktualizacji, a osoby wykonujące zadania muszą znać właściwy sposób postępowania. Skuteczność wdrożenia warto sprawdzić na konkretnym procesie: przy odejściu pracownika powinny zadziałać uzgodnienia między HR, przełożonym i IT dotyczące odebrania dostępów oraz zwrotu zasobów. Dowodem funkcjonowania SZBI jest wykonanie tych czynności i ich udokumentowanie, nie samo istnienie procedury.

5. Zarządzanie incydentami: proces, eskalacja, zgłaszanie i lekcje po incydencie

Procedura zarządzania incydentami powinna odpowiadać na pytania, które podczas zakłócenia wymagają natychmiastowej decyzji: kto koordynuje reakcję, kiedy należy powiadomić kierownictwo, kto może wstrzymać usługę i kto odpowiada za zgłoszenie do właściwej instytucji. Obsługa incydentu nie jest wyłącznie zadaniem IT — wymaga współpracy bezpieczeństwa, operacji, compliance, obsługi prawnej i komunikacji. Zarząd powinien otrzymywać informacje pozwalające ocenić skutki biznesowe oraz rozstrzygać kwestie przekraczające uprawnienia zespołu reagowania.

Proces obejmuje przyjęcie sygnału, ocenę i klasyfikację incydentu, ograniczenie jego skutków, usunięcie przyczyny oraz bezpieczne odtworzenie działania. Równolegle należy zabezpieczać dowody i prowadzić rejestr zdarzeń, ustaleń oraz decyzji. Warto rozróżnić alert wymagający weryfikacji od potwierdzonego incydentu, a także od incydentu podlegającego obowiązkowemu zgłoszeniu. O kwalifikacji nie powinien przesądzać sam rodzaj ataku: istotne są również jego skutki, skala i kryteria wynikające z przepisów właściwych dla organizacji.

Eskalacja wewnętrzna powinna opierać się na ustalonych progach, a nie na uznaniowej ocenie pojedynczej osoby. Przykładowymi przesłankami powiadomienia kierownictwa są niedostępność kluczowej usługi, podejrzenie ujawnienia danych, zagrożenie bezpieczeństwa ludzi lub konieczność podjęcia decyzji o istotnych konsekwencjach finansowych. Koordynator incydentu organizuje działania, zespoły techniczne prowadzą analizę i ograniczają skutki, a właściciele procesów określają priorytety operacyjne. Procedura powinna wskazywać także zastępstwa, sposób kontaktu poza godzinami pracy i alternatywny kanał komunikacji na wypadek niedostępności lub przejęcia firmowej poczty.

Zgłaszanie zewnętrzne należy przygotować jako odrębną, lecz równoległą ścieżkę postępowania. W podstawowym modelu przewidzianym w art. 23 NIS2 dla poważnych incydentów wczesne ostrzeżenie przekazuje się bez zbędnej zwłoki, najpóźniej w ciągu 24 godzin od uzyskania wiedzy o incydencie, a zgłoszenie incydentu — zasadniczo najpóźniej w ciągu 72 godzin. Sprawozdanie końcowe składa się co do zasady nie później niż miesiąc po przekazaniu zgłoszenia; dla nadal trwającej obsługi przewidziano odrębny tryb raportowania. Procedurę organizacji trzeba dopasować do obowiązujących przepisów KSC, jej kategorii i ewentualnych wymagań szczególnych, wskazując właściwego odbiorcę oraz kanał zgłoszenia. Nie należy automatycznie utożsamiać modelu dyrektywy ze wszystkimi krajowymi obowiązkami.

Nie należy uzależniać terminowego zgłoszenia od zakończenia analizy technicznej. Organizacja powinna odnotować moment uzyskania wiedzy o incydencie, przekazać wymagane informacje dostępne na danym etapie i uzupełniać je zgodnie z właściwym trybem. Wewnętrzna akceptacja nie może blokować dotrzymania terminu. Compliance i obsługa prawna powinny równolegle ocenić inne obowiązki informacyjne, w tym wynikające z RODO, regulacji sektorowych lub umów. Zgłoszenie w jednym reżimie prawnym nie zastępuje automatycznie pozostałych.

Praktycznym zapleczem procesu są procedura reagowania, matryca eskalacji, aktualna lista kontaktów i zastępstw oraz wzory zgłoszeń i komunikatów. Przydatna jest także krótka karta sytuacyjna dla kierownictwa, zawierająca potwierdzone fakty, wpływ na działalność, podjęte działania, niewiadome i decyzje wymagające zatwierdzenia. Wspólne ćwiczenie scenariuszowe, np. dotyczące zaszyfrowania systemów, pozwala sprawdzić, czy uczestnicy potrafią korzystać z tych dokumentów pod presją czasu.

Po opanowaniu incydentu należy przeprowadzić przegląd jego przebiegu, bez sprowadzania analizy do poszukiwania winnych. Raport powinien wskazywać przyczyny, skuteczność reakcji, opóźnienia w eskalacji i problemy komunikacyjne. Każde działanie naprawcze wymaga właściciela, terminu oraz sposobu potwierdzenia wykonania. Lekcje z incydentu powinny prowadzić do konkretnych zmian w procedurach, zabezpieczeniach i scenariuszach ćwiczeń — samo sporządzenie raportu nie zamyka tego procesu.

6. Nadzór nad ryzykiem: metryki, przeglądy, audyty i raportowanie do kierownictwa

Zarząd potrzebuje informacji nie tylko o wdrożonych zabezpieczeniach, lecz także o tym, czy ograniczają one ryzyko do akceptowalnego poziomu. NIS2 przewiduje stosowanie polityk i procedur służących ocenie skuteczności środków zarządzania ryzykiem w cyberbezpieczeństwie. W praktyce nadzór powinien łączyć mierniki, okresowe przeglądy i ustalenia audytowe z decyzjami dotyczącymi priorytetów, zasobów oraz ryzyka pozostającego po zastosowaniu zabezpieczeń, czyli ryzyka rezydualnego.

Warto rozróżnić wskaźniki efektywności (KPI), które pokazują wykonanie działań, od wskaźników ryzyka (KRI), sygnalizujących poziom zagrożenia dla organizacji. Liczba przeprowadzonych testów nie odpowiada jeszcze na pytanie, czy krytyczna usługa może zostać odtworzona w wymaganym czasie. Dlatego raportowanie powinno uwzględniać wyniki i znaczenie biznesowe działań, a nie wyłącznie ich liczbę.

Na poziomie kierowniczym można rozpocząć od trzech grup mierników, dobranych do najważniejszych usług i procesów:

• Ekspozycja na ryzyko: liczba ryzyk przekraczających przyjęty poziom akceptacji oraz krytycznych podatności nieusuniętych w terminach ustalonych przez organizację, ze wskazaniem zagrożonych usług.
• Skuteczność zabezpieczeń: odsetek testów odtworzeniowych zakończonych spełnieniem przyjętych kryteriów oraz stopień objęcia krytycznych systemów wymaganymi zabezpieczeniami.
• Realizacja działań naprawczych: udział przeterminowanych zaleceń o wysokim priorytecie i liczba powtarzających się ustaleń audytowych.

Każdy miernik powinien mieć definicję, źródło danych, osobę odpowiedzialną za aktualizację oraz próg wymagający reakcji. W raporcie należy pokazywać trend i zakres pomiaru: dobry wynik dotyczący części infrastruktury nie może sugerować bezpieczeństwa całej organizacji. Za przygotowanie obrazu ryzyka może odpowiadać funkcja bezpieczeństwa, ale właściciele procesów powinni potwierdzać wpływ biznesowy, a compliance — ocenę zgodności z wymaganiami właściwymi dla danego podmiotu.

Przegląd zarządczy i audyt pełnią różne funkcje. Przegląd służy ocenie aktualnej sytuacji i podejmowaniu decyzji. Audyt dostarcza uporządkowanej, opartej na dowodach oceny zgodności i działania przyjętych rozwiązań; wymaga przy tym odpowiedniej bezstronności. Samo istnienie procedury nie potwierdza jej skuteczności, dlatego ustalenia powinny wynikać również z weryfikacji praktyki. Zakres i częstotliwość audytów należy dostosować do ryzyka oraz obowiązków wynikających z przepisów mających zastosowanie do organizacji.

Jako model organizacyjny można przyjąć miesięczne przeglądy operacyjne i kwartalne raportowanie do zarządu, uzupełniane o przeglądy po istotnych zmianach poziomu ryzyka. To przykładowa praktyka zarządcza, a nie uniwersalny termin ustawowy. Ryzyka przekraczające ustalone progi powinny trafiać do właściwych decydentów bez oczekiwania na kolejne planowe posiedzenie.

Raport dla kierownictwa powinien wskazywać najważniejsze ryzyka, ich wpływ na ciągłość usług, zmiany od poprzedniego przeglądu oraz decyzje wymagające zatwierdzenia. Warto oddzielić krótką część decyzyjną od szczegółowych danych technicznych. Śladem nadzoru powinny być protokoły przeglądów i rejestr decyzji, obejmujące uzasadnienie, właściciela działania, termin oraz sposób potwierdzenia wykonania. Akceptacja ryzyka nie zastępuje spełnienia obowiązku prawnego, a zamknięcie zalecenia powinno opierać się na dowodzie usunięcia problemu, nie tylko na deklaracji wykonawcy.

7. Plan wdrożenia: harmonogram 30/60/90 dni i lista artefaktów do przygotowania

Plan 30/60/90 dni pozwala przełożyć przygotowanie do obowiązków KSC i NIS2 na konkretne zadania, decyzje i dowody wykonania. To rekomendowany harmonogram organizacyjny, a nie termin ustawowy ani gwarancja osiągnięcia pełnej zgodności w trzy miesiące. Przed jego przyjęciem należy potwierdzić zakres obowiązków i terminy właściwe dla organizacji według aktualnie obowiązujących przepisów. Działania pilne, wynikające z prawa lub zidentyfikowanego ryzyka, nie powinny czekać na zakończenie kolejnego etapu.

Za koordynację programu powinna odpowiadać wyznaczona osoba posiadająca mandat zarządu. Każde zadanie wymaga właściciela, terminu, zasobów oraz kryterium odbioru. Compliance lub dział prawny weryfikuje wymagania, zespół bezpieczeństwa koordynuje prace nad SZBI, IT realizuje działania techniczne, a liderzy operacyjni odpowiadają za przygotowanie swoich procesów. HR wspiera organizację szkoleń i dokumentowanie udziału.

Dni 1–30: ustalenie zakresu, odpowiedzialności i priorytetów. Pierwszy miesiąc należy przeznaczyć na ocenę punktu wyjścia: przegląd istniejących dokumentów, rozpoznanie luk oraz wskazanie usług, systemów i zależności wymagających najpilniejszej uwagi. Szkolenie wprowadzające dla zarządu i liderów powinno przygotować ich do decyzji o zakresie programu, budżecie i odpowiedzialności. Warto wykorzystać dokumentację już funkcjonującą w organizacji zamiast tworzyć równoległy zestaw polityk i rejestrów.

Artefakty do przygotowania do 30. dnia: udokumentowana ocena zastosowania wymagań KSC i NIS2, raport luk, karta programu z harmonogramem i budżetem, matryca odpowiedzialności oraz wstępny rejestr ryzyk. Uzupełnieniem jest plan rozwoju kompetencji kierownictwa, przypisany do konkretnych ról. Kryterium zakończenia etapu stanowi zatwierdzenie przez zarząd priorytetów, właścicieli działań i zasobów potrzebnych do ich realizacji.

Dni 31–60: wdrożenie uzgodnionych rozwiązań i przygotowanie zespołów. Drugi miesiąc obejmuje opracowanie lub aktualizację dokumentacji SZBI oraz uruchomienie działań ograniczających najważniejsze ryzyka. Kierownicy powinni przełożyć ustalenia na zadania swoich zespołów i potwierdzić, że pracownicy znają przypisane im obowiązki. Szkolenia na tym etapie warto oprzeć na scenariuszach decyzyjnych organizacji: zakłóceniu kluczowej usługi, niedostępności dostawcy lub konieczności szybkiej eskalacji incydentu.

Artefakty do przygotowania do 60. dnia: polityka bezpieczeństwa informacji i opis zakresu SZBI, plan postępowania z ryzykiem, procedura obsługi incydentów z zasadami eskalacji i zgłaszania oraz aktualna lista kontaktów i zastępstw. Należy również przygotować wzór raportu dla zarządu, kalendarz przeglądów oraz dokumentację szkoleń obejmującą program, udział i ocenę efektów nauki. Odbiór etapu powinien potwierdzać nie tylko zatwierdzenie dokumentów, lecz także ich udostępnienie właściwym osobom i rozpoczęcie stosowania.

Dni 61–90: sprawdzenie działania i decyzje korygujące. Ostatni etap służy weryfikacji, czy przyjęte rozwiązania działają w praktyce. Rekomendujemy ćwiczenie scenariuszowe z udziałem zarządu, IT, bezpieczeństwa, compliance i operacji oraz przegląd dowodów wykonania najważniejszych zadań. Należy sprawdzić dostępność osób decyzyjnych, obieg informacji i zdolność realizacji procedur, a wykryte problemy przypisać do konkretnych właścicieli.

Artefakty do przygotowania do 90. dnia: raport z ćwiczenia, rejestr działań korygujących, zaktualizowany rejestr ryzyk, raport statusowy dla zarządu oraz protokół przeglądu zawierający decyzje, terminy i przyznane zasoby. Efektem powinien być również plan kolejnego kwartału, uwzględniający niezakończone wdrożenia, dalsze szkolenia i weryfikację skuteczności zabezpieczeń. Otwarte luki muszą pozostać widoczne — zakończenie 90-dniowego programu nie oznacza ich automatycznego zamknięcia.

Wszystkie artefakty należy przechowywać w uporządkowanym repozytorium z kontrolą dostępu i wersji. Każdy dokument powinien mieć właściciela, status zatwierdzenia i termin przeglądu. Miarą postępu nie jest liczba przygotowanych plików, lecz możliwość wykazania, że ustalenia są stosowane, ryzyka mają właścicieli, a zarząd otrzymuje informacje potrzebne do podejmowania decyzji.

Nowelizacja KSC wdrażająca NIS2 w praktyce – dlaczego kierownictwo musi znać nowe obowiązki? 04 października 2026

Nowelizacja KSC wdrażająca NIS2 w praktyce – dlaczego kierownictwo musi znać nowe obowiązki? 04 października 2026