KSC 2026/2027 – najważniejsze terminy, których kierownictwo nie może przegapić

KSC 2026/2027 w pigułce: co się zmienia i co to znaczy dla zarządu oraz kierownictwa

Dla zarządu najważniejsza zmiana polega na tym, że cyberbezpieczeństwo staje się wyraźnie przypisaną odpowiedzialnością kierowniczą, a nie wyłącznie zadaniem działu IT. Kierunek wyznaczony przez dyrektywę NIS2 obejmuje zatwierdzanie środków zarządzania ryzykiem cyberbezpieczeństwa i nadzór nad ich wdrażaniem. W praktyce oznacza to konieczność powiązania decyzji o bezpieczeństwie z budżetem, ciągłością działania i ryzykiem biznesowym.

Określenie „KSC 2026/2027” nie oznacza odrębnej ustawy. To skrót opisujący krajowe wymagania cyberbezpieczeństwa i ich wdrażanie w perspektywie tych lat. Trzeba przy tym rozróżnić obowiązujące przepisy ustawy o krajowym systemie cyberbezpieczeństwa, wymagania NIS2 oraz krajowe przepisy wdrażające tę dyrektywę. Sam zapis w dyrektywie nie przesądza jeszcze o dacie wykonania konkretnego obowiązku przez polską organizację. Znaczenie mają ostateczne brzmienie przepisów krajowych, ich wejście w życie i regulacje przejściowe.

Co zmienia podejście wynikające z NIS2?

W porównaniu z dotychczasowym modelem KSC, opartym między innymi na operatorach usług kluczowych i dostawcach usług cyfrowych, zmiany dotyczą przede wszystkim trzech obszarów:

• Szerszego zakresu podmiotów. NIS2 obejmuje więcej sektorów i wprowadza podział na podmioty kluczowe oraz ważne. Przy ocenie objęcia regulacją liczą się między innymi rodzaj działalności, wielkość organizacji i ustawowe wyjątki — nie tylko jej nazwa, kod działalności czy przekonanie, że „nie jesteśmy firmą technologiczną”.
• Szerszego rozumienia bezpieczeństwa. Ochrona systemów pozostaje niezbędna, ale wymagania obejmują również organizację pracy, odporność usług i ryzyka związane z łańcuchem dostaw. Sam zakup narzędzi zabezpieczających nie wystarczy.
• Wyraźniejszej rozliczalności. Znaczenie ma nie tylko posiadanie dokumentacji, lecz także faktyczne stosowanie przyjętych zasad. Podmioty kluczowe i ważne podlegają odmiennym modelom nadzoru, ale zakwalifikowanie do drugiej grupy nie oznacza zwolnienia z zasadniczych obowiązków bezpieczeństwa.

Co to oznacza dla decyzji kierownictwa?

Zarząd powinien traktować dostosowanie jako zmianę sposobu zarządzania organizacją, a nie jednorazowy projekt zgodności. Potrzebuje wiedzy, które usługi są istotne dla działalności, jakie skutki może wywołać ich zakłócenie i czy poziom zabezpieczeń odpowiada rzeczywistemu ryzyku. Nie chodzi o przejmowanie technicznych zadań specjalistów, lecz o świadome podejmowanie decyzji i nadzorowanie ich wykonania.

Istotne jest również rozróżnienie dwóch sytuacji: bezpośredniego podlegania KSC oraz wymagań otrzymywanych od klientów objętych regulacją. Dostawca spoza ustawowego zakresu może odczuć zmiany poprzez warunki umów i oczekiwania dotyczące bezpieczeństwa. Nie staje się jednak automatycznie podmiotem kluczowym lub ważnym tylko dlatego, że obsługuje taki podmiot.

Dla kierownictwa perspektywa 2026/2027 oznacza więc przede wszystkim potrzebę prawidłowego ustalenia statusu organizacji i skali niezbędnych zmian. Te lata nie są jednym, wspólnym terminem zgodności dla wszystkich. Dopiero właściwa kwalifikacja prawna pozwala racjonalnie określić zakres prac, potrzebne zasoby i pilność decyzji.

Mapa obowiązków i ról (governance): odpowiedzialności zarządu, CISO/ICT, właścicieli procesów, dostawców i audytu

W przygotowaniach do KSC 2026/2027 nie wystarczy wskazać osoby „od cyberbezpieczeństwa”. Trzeba rozdzielić trzy kwestie: kto podejmuje decyzje, kto realizuje zadania i kto niezależnie ocenia ich wykonanie. Bez tego CISO może odpowiadać za ryzyko, którego nie ma prawa zaakceptować, dział ICT — za ciągłość procesów, których nie kontroluje, a zarząd — otrzymywać raporty bez informacji, co wymaga jego rozstrzygnięcia.

W Cognity często słyszymy pytania, jak praktycznie podzielić odpowiedzialność za cyberbezpieczeństwo — odpowiadamy na nie także na blogu. Poniższa mapa opisuje podział organizacyjny. Szczegółowe obowiązki prawne należy przypisać zgodnie z obowiązującym brzmieniem KSC, statusem podmiotu i jego strukturą zarządzania. Wewnętrzne powierzenie zadania nie zmienia automatycznie tego, na kim spoczywa odpowiedzialność ustawowa.

Zarząd i kierownictwo: decyzje, uprawnienia i nadzór

Na najwyższym szczeblu zarządzania powinny zapadać decyzje o kierunku działań, zasobach oraz granicach akceptowanego ryzyka. Rolą zarządu lub właściwego organu kierującego jest zapewnienie, że odpowiedzialność za cyberbezpieczeństwo ma odzwierciedlenie w rzeczywistych uprawnieniach: do przydzielania budżetu, ustalania priorytetów i egzekwowania działań od jednostek organizacyjnych.

Kierownictwo poszczególnych obszarów przekłada te decyzje na działania operacyjne. Nie każde ryzyko musi trafiać do zarządu, ale musi być jasne, które decyzje można podejmować samodzielnie, a które wymagają eskalacji. Dotyczy to zwłaszcza sytuacji, gdy ograniczenie ryzyka oznacza istotny koszt, zmianę sposobu świadczenia usługi albo czasowe ograniczenie jej dostępności.

CISO i ICT: koordynowanie bezpieczeństwa a wykonanie techniczne

CISO, czyli osoba kierująca bezpieczeństwem informacji, koordynuje podejście do bezpieczeństwa: przedstawia kierownictwu obraz ryzyka, rekomenduje wymagania i ocenia, czy organizacja realizuje przyjęte założenia. Powinien mieć dostęp do decydentów oraz możliwość zgłaszania problemów również wtedy, gdy są one niewygodne dla obszaru technologicznego.

ICT odpowiada przede wszystkim za techniczną realizację przydzielonych zadań oraz utrzymanie infrastruktury i usług. CISO określa lub współtworzy wymagania bezpieczeństwa, natomiast zespoły techniczne wdrażają je w swoim zakresie. W mniejszych organizacjach funkcje te mogą być łączone, lecz trzeba rozpoznać konflikt interesów: osoba wdrażająca rozwiązanie nie powinna być jedynym źródłem oceny jego skuteczności. Samo stanowisko CISO nie oznacza też uprawnienia do akceptowania każdego ryzyka biznesowego.

Właściciele procesów: odpowiedzialność po stronie biznesu

Właściciel procesu określa, jakie informacje i usługi są potrzebne do jego działania oraz jakie skutki wywoła ich utrata, niedostępność lub nieuprawniona zmiana. To on wnosi kontekst biznesowy, którego nie zastąpi analiza techniczna. Powinien współdecydować o wymaganiach ochrony i priorytetach, a ryzyko akceptować wyłącznie w granicach przyznanych uprawnień. Ryzyko dotyczące procesu nie staje się wyłącznym problemem ICT tylko dlatego, że jego źródłem jest system informatyczny.

Dostawcy: realizacja usług, nie przejęcie całej odpowiedzialności

Dostawca odpowiada za uzgodniony zakres usług oraz własne obowiązki prawne. Po stronie organizacji musi jednak pozostać właściciel relacji, który rozumie zależność od tej usługi i potrafi egzekwować wymagania. Zakupy oraz obsługa prawna wspierają ustalenia kontraktowe, a CISO i ICT — ocenę bezpieczeństwa i aspektów technicznych. Outsourcing może przenieść wykonanie zadania, ale nie zwalnia automatycznie podmiotu z jego obowiązków wynikających z KSC.

Audyt: niezależna ocena zamiast zarządzania wdrożeniem

Audyt sprawdza, czy przyjęty podział odpowiedzialności i mechanizmy kontroli rzeczywiście działają. Nie powinien zastępować właścicieli procesów, podejmować za nich decyzji o ryzyku ani zarządzać działaniami, które następnie sam ocenia. Jego wartością jest niezależny osąd, a nie przejęcie odpowiedzialności za zgodność. Ustalenia audytu wymagają reakcji kierownictwa; za usunięcie nieprawidłowości odpowiadają wskazani właściciele, nie audytor.

Oś czasu KSC 2026/2027: kluczowe kamienie milowe i terminy

W kalendarzu KSC trzeba oddzielić datę wejścia w życie przepisów od terminów wykonania poszczególnych obowiązków. Publikacja nowelizacji, objęcie organizacji regulacją, zgłoszenie do wykazu i zakończenie okresu dostosowawczego nie muszą przypadać tego samego dnia. Dla kierownictwa oznacza to konieczność śledzenia kilku powiązanych terminów, a nie jednej daty „gotowości na KSC”.

Poniższa oś pokazuje sposób interpretowania tych zależności. Przykładowe daty są scenariuszami obliczeniowymi, a nie potwierdzonym harmonogramem ustawowym na lata 2026–2027. Wiążące terminy należy ustalić na podstawie ogłoszonego tekstu nowelizacji, jej przepisów przejściowych oraz regulacji dotyczących konkretnej kategorii podmiotu.

Punkt odniesienia: termin unijny a obowiązki w Polsce

Dyrektywa NIS2 wyznaczyła państwom członkowskim termin przyjęcia i opublikowania przepisów wdrażających na 17 października 2024 r., a rozpoczęcie ich stosowania — na 18 października 2024 r. Nie należy jednak traktować tych dat jako jednolitego terminu wykonania wszystkich nowych obowiązków przez każdą polską organizację. Harmonogram dostosowania do krajowych przepisów zależy od ich ostatecznego brzmienia. Jednocześnie oczekiwanie na nowe regulacje nie znosi obowiązków wynikających z już obowiązującej ustawy o KSC.

Kamienie milowe, które wyznaczają właściwą oś czasu

Scenariusze dat dla lat 2026–2027

Aby pokazać wpływ daty początkowej na kalendarz, przyjmijmy wyłącznie na potrzeby przykładu dwa okresy: sześć i dwanaście miesięcy od T0. Nie są to deklarowane tutaj ustawowe okresy dostosowawcze. Można je zastosować do rzeczywistego harmonogramu tylko wtedy, gdy odpowiedni przepis przewiduje właśnie taki termin i taki moment rozpoczęcia jego biegu.

Tabela pokazuje przesunięcie obciążeń między latami, nie prognozę legislacyjną. Ostateczny dzień upływu konkretnego terminu trzeba dodatkowo sprawdzić według właściwych zasad jego obliczania. Jeżeli ustawa wiąże obowiązek z późniejszym spełnieniem kryteriów przez organizację, nie wolno automatycznie liczyć go od daty wejścia w życie całej nowelizacji.

Zależności regulacyjne, które mogą zmienić harmonogram

Brak rozporządzenia wykonawczego nie oznacza automatycznego odroczenia wszystkich obowiązków. Trzeba ustalić, które wymagania wynikają bezpośrednio z ustawy, a których wykonanie rzeczywiście zależy od dodatkowych przepisów. Podobnie uruchomienie wykazu lub systemu zgłoszeniowego nie powinno być uznawane za wspólny początek wszystkich terminów bez wyraźnej podstawy prawnej.

Osobnego sprawdzenia wymagają organizacje już objęte KSC, podmioty wchodzące do systemu po zmianie przepisów oraz jednostki podlegające regulacjom sektorowym. Ich kalendarze mogą się różnić. Z kolei terminy uruchamiane zdarzeniem, zwłaszcza incydentem, biegną niezależnie od rocznego harmonogramu dostosowania — nie można zakładać, że okres przejściowy dla jednego obowiązku odracza również pozostałe.

Co musi być gotowe przed każdym terminem: decyzje governance, SZBI, ocena ryzyka, procedury incydentowe, szkolenia, testy i audyty

Przed terminem dotyczącym wdrożenia obowiązków KSC organizacja powinna umieć wykazać nie tylko, że przyjęła odpowiednie dokumenty, lecz także że stosuje opisane w nich zabezpieczenia i procedury. Polityka zatwierdzona przez zarząd nie zastępuje działającego procesu, a zakup narzędzia nie dowodzi, że ktoś potrafi wykorzystać je podczas incydentu. Gotowość oznacza połączenie decyzji, wdrożenia i sprawdzenia skuteczności.

Nie każdy termin wymaga jednak zamknięcia całego programu cyberbezpieczeństwa. Zakres prac trzeba przypisać do konkretnego obowiązku i przepisów mających zastosowanie do danego podmiotu. Poniższe zestawienie opisuje oczekiwany stan przygotowania poszczególnych obszarów, a nie jeden wspólny termin ustawowy dla wszystkich działań.

Co powinno być zatwierdzone, wdrożone i sprawdzone

Ocena ryzyka, test i audyt odpowiadają na różne pytania

Ocena ryzyka wskazuje, co może zagrozić działalności i jakie działania są potrzebne. Test sprawdza, czy wybrane rozwiązanie rzeczywiście działa. Audyt ocenia spełnienie określonych kryteriów na podstawie dowodów. Te działania uzupełniają się, ale nie są zamienne: poprawny wynik testu odtworzenia kopii zapasowej nie potwierdza zgodności całego SZBI, a audyt dokumentacji nie zastępuje praktycznej próby przywrócenia usługi.

Podobnie szkolenie nie zastępuje ćwiczenia. Przekazanie zasad zgłaszania incydentów buduje wiedzę; symulacja pozwala sprawdzić, czy zgłoszenie trafi do właściwej osoby, czy zostanie prawidłowo ocenione i czy decyzje zapadną wystarczająco szybko. W Cognity omawiamy to zagadnienie zarówno od strony technicznej, jak i praktycznej – zgodnie z realiami pracy uczestników.

Warunek odbioru: brak luk uniemożliwiających wykonanie obowiązku

Przed uznaniem danego obszaru za gotowy trzeba sprawdzić jego zależności. Procedura incydentowa pozostanie niewykonalna bez dostępu do informacji i osób decyzyjnych. Plan ciągłości będzie niepełny, jeżeli zakłada odtworzenie usługi, którego nikt nie sprawdził. Ocena ryzyka straci wartość, jeśli pomija systemy rzeczywiście wspierające działalność.

Nie każda niedoskonałość blokuje gotowość, ale każda istotna luka wymaga rozstrzygnięcia. Działania doskonalące można zaplanować, o ile nie oznacza to przekroczenia terminu spełnienia obowiązku. Akceptacja ryzyka przez kierownictwo nie uchyla wymagań ustawowych, a plan naprawczy nie jest automatycznie równoznaczny z ich wykonaniem.

Jak wyznaczać terminy wewnętrzne, gdy brakuje twardych dat: podejście, priorytetyzacja i bufor bezpieczeństwa

Brak ostatecznej daty obowiązywania nowych wymagań KSC nie powinien oznaczać wstrzymania przygotowań. Dla kierownictwa oznacza natomiast konieczność rozdzielenia dwóch kwestii: terminu wynikającego z prawa oraz wewnętrznej daty osiągnięcia gotowości. Pierwszy trzeba ustalić na podstawie właściwych przepisów i ich zastosowania do organizacji. Drugi należy wyznaczyć tak, aby pozostał czas na sprawdzenie rezultatów i usunięcie braków — nie tylko na formalne zakończenie projektu.

Oddziel daty potwierdzone od założeń planistycznych

Każda data przyjęta do planowania powinna mieć określony status: potwierdzony termin prawny, założenie zależne od przebiegu procesu legislacyjnego albo wewnętrzny cel organizacji. Data wskazana w projekcie przepisów nie jest równoznaczna z obowiązującym terminem. Także sam horyzont 2026/2027 nie wystarcza do wyznaczenia dnia, w którym konkretny podmiot musi spełnić określony obowiązek.

Jeżeli termin zależy od zdarzenia prawnego, plan można początkowo budować względem punktu „T”, precyzyjnie opisując, co ma nim być. Nie należy automatycznie utożsamiać publikacji ustawy, jej wejścia w życie i początku stosowania poszczególnych wymagań. Dopiero po potwierdzeniu właściwego zdarzenia i okresu przejściowego można bezpiecznie przeliczyć harmonogram na daty kalendarzowe.

Planuj wstecz od gotowości, nie od końca prac

Wewnętrzny termin powinien uwzględniać cały ciąg zależności: przygotowanie rozwiązania, jego wdrożenie, sprawdzenie w praktyce oraz ewentualne poprawki. Punktem wyjścia jest najdłuższy ciąg prac, których nie da się wykonać równolegle. Sumowanie czasu wszystkich zadań zawyży harmonogram, ale pominięcie oczekiwania na zakup, uzgodnienie umowy czy dostępność specjalistów może go niebezpiecznie skrócić.

Przykładowo, jeżeli przygotowanie i wdrożenie rozwiązania zajmuje osiem tygodni, a jego weryfikacja kolejne dwa, rozpoczęcie prac dziesięć tygodni przed zakładaną datą graniczną nie pozostawia miejsca na poprawki. Przy dodatkowych trzech tygodniach rezerwy start powinien nastąpić co najmniej trzynaście tygodni wcześniej. To wyłącznie przykład planistyczny, a nie termin przewidziany w KSC.

Priorytety ustalaj według ryzyka i zależności

Nie wszystkie działania muszą czekać na ostateczne brzmienie przepisów. W pierwszej kolejności warto uruchamiać prace, które jednocześnie ograniczają istotne ryzyko i pozostaną użyteczne niezależnie od zmian legislacyjnych. Przy ustalaniu kolejności należy brać pod uwagę trzy kryteria:

• Skutek opóźnienia: czy brak danego rozwiązania może zagrozić ciągłości działania, bezpieczeństwu informacji lub zdolności wykonania obowiązku?
• Czas realizacji i zależności: czy zadanie wymaga udziału dostawcy, postępowania zakupowego albo zakończenia innych prac?
• Odwracalność decyzji: czy późniejsza zmiana wymagań będzie oznaczała niewielką korektę, czy kosztowną przebudowę?

Takie podejście pozwala rozpocząć działania potrzebne już dziś, a szczegółowe decyzje silnie zależne od niepotwierdzonych wymagań podejmować etapami. Nie należy jednak odkładać całego zadania tylko dlatego, że jego końcowy zakres może jeszcze wymagać doprecyzowania.

Dobieraj bufor do niepewności

Jednakowy zapas czasu dla wszystkich zadań daje pozorne poczucie kontroli. Większej rezerwy wymagają prace z udziałem podmiotów zewnętrznych, ingerujące w środowisko produkcyjne lub realizowane przez zespoły o ograniczonej dostępności. Mniejsza może wystarczyć tam, gdzie zakres jest stabilny, a sposób wykonania dobrze znany.

Warto przygotować wariant bazowy oraz wariant przyspieszony na wypadek krótszego czasu na dostosowanie. Przesunięcie przewidywanego terminu prawnego nie powinno automatycznie przesuwać wszystkich terminów wewnętrznych. Dodatkowy czas lepiej przeznaczyć na zwiększenie pewności, że wdrożone rozwiązania działają, niż potraktować go jako powód do zatrzymania prac. Z kolei istotna zmiana przepisów powinna uruchamiać ponowną ocenę zakresu, zależności i potrzebnego bufora — zamiast mechanicznej zamiany dat w harmonogramie.

Jak zorganizować kalendarz zgodności: właściciele zadań, cykliczne przeglądy, raportowanie do zarządu i artefakty dowodowe

Kalendarz zgodności KSC na lata 2026/2027 powinien pozwalać kierownictwu szybko odpowiedzieć na trzy pytania: co wymaga działania, kto odpowiada za jego zakończenie i na jakiej podstawie uznajemy obowiązek za wykonany. Sam terminarz z przypomnieniami nie wystarczy. Potrzebny jest wspólny rejestr łączący terminy z zadaniami, decyzjami i dowodami realizacji.

Jeden rejestr, jednoznaczna odpowiedzialność za zadanie

Rejestr można prowadzić w narzędziu GRC, systemie zarządzania zadaniami lub kontrolowanym arkuszu. Ważniejsza od wyboru aplikacji jest spójność danych: zespoły i kierownictwo powinny korzystać z tego samego źródła informacji, zamiast uzgadniać statusy z rozproszonych wiadomości i prezentacji.

Każda pozycja powinna zawierać opis oczekiwanego rezultatu, właściciela zadania, termin, status, zależności oraz odnośnik do dowodu wykonania. Warto także wskazać osobę uprawnioną do odbioru rezultatu. Właścicielem zadania nie powinien być ogólnie „dział IT” lub „bezpieczeństwo”, lecz konkretna osoba albo jednoznacznie przypisana funkcja, z ustalonym zastępstwem na czas nieobecności.

W kalendarzu należy wyraźnie rozróżniać terminy wynikające z przepisów, terminy wewnętrzne i daty robocze zależne od określonego zdarzenia. Przy terminie regulacyjnym trzeba zachować źródło oraz informację o jego zastosowaniu do organizacji. Jeżeli data pozostaje warunkowa, wpis powinien wskazywać tę zależność — nie może wyglądać jak potwierdzony obowiązek ustawowy. Zmiany dat i właścicieli powinny pozostawiać historię: kto dokonał zmiany, kiedy i dlaczego.

Stały rytm przeglądów i eskalacja wyjątków

Kalendarz działa tylko wtedy, gdy jest regularnie aktualizowany. Właściciele zadań powinni uzupełniać statusy przed przeglądem, aby spotkanie służyło usuwaniu blokad i podejmowaniu decyzji, a nie zbieraniu podstawowych informacji. Poniższy rytm jest propozycją organizacyjną, a nie częstotliwością narzuconą przez KSC.

Nie należy czekać do cyklicznego spotkania, jeżeli pojawia się ryzyko niedotrzymania obowiązującego terminu. Zasady eskalacji powinny określać, jakie odchylenie wymaga zgłoszenia, do kogo trafia informacja i kto podejmuje decyzję. Przesunięcie daty w rejestrze nie usuwa opóźnienia ani nie zmienia terminu wynikającego z prawa.

Raport dla zarządu: stan realizacji i decyzje do podjęcia

Raport zarządczy nie powinien być kopią całego kalendarza. Wystarczy zwięzły widok pokazujący najbliższe istotne terminy, zadania zagrożone, zaległości oraz kwestie wymagające rozstrzygnięcia. Każdy sygnał ostrzegawczy powinien zawierać przyczynę, możliwy skutek, proponowane działanie i datę potrzebnej decyzji.

Warto oddzielić deklarowane wykonanie od potwierdzonego zamknięcia. Wysoki odsetek zrealizowanych zadań może maskować brak jednego krytycznego rezultatu. Dlatego obok postępu należy pokazywać, które zadania mają zweryfikowany dowód i wymagane zatwierdzenie. Decyzje zarządu powinny wracać do rejestru jako konkretne ustalenia z właścicielem i terminem realizacji.

Artefakty dowodowe jako warunek zamknięcia

Dowodem wykonania może być zatwierdzona wersja dokumentu, protokół przeglądu, raport z testu lub zapis decyzji. Rodzaj dowodu należy dopasować do rezultatu zadania. Samo zaproszenie na spotkanie nie potwierdza, że przegląd się odbył, a istnienie procedury nie dowodzi jej wdrożenia.

Materiały dowodowe najlepiej przechowywać w kontrolowanym repozytorium, a w kalendarzu umieszczać odnośniki do właściwych wersji. Powinny być możliwe do powiązania z zadaniem, datą wykonania i zatwierdzeniem, z dostępem odpowiednim do poufności informacji. Status „zamknięte” powinien oznaczać spełnienie ustalonych kryteriów odbioru i dostępność dowodu, nie tylko deklarację wykonawcy.

Checklist do skopiowania: lista zadań KSC 2026/2027

Poniższą listę można przenieść do rejestru zadań lub narzędzia do zarządzania zgodnością. Nie jest to katalog obowiązków identyczny dla każdej organizacji. Zakres prac i terminy prawne trzeba potwierdzić na podstawie obowiązujących przepisów KSC, przepisów przejściowych oraz kwalifikacji podmiotu. Zadania wykraczające poza wymagania ustawowe warto oznaczyć jako działania wewnętrzne służące ograniczeniu ryzyka.

Do każdego zadania dopisz: właściciela, termin wewnętrzny, termin prawny — jeśli dotyczy — status, dowód wykonania oraz osobę zatwierdzającą. Przy terminie prawnym zapisz podstawę jego ustalenia; nie zastępuj jej orientacyjną datą z harmonogramu projektu.

Governance i zakres zgodności

• ☐ Udokumentować ocenę, czy organizacja podlega KSC i w jakim zakresie; wskazać podstawę kwalifikacji oraz datę jej ostatniej weryfikacji.
• ☐ Potwierdzić, czy wymagane są czynności rejestracyjne lub aktualizacja danych we właściwym wykazie; zachować potwierdzenia ich wykonania.
• ☐ Zatwierdzić przypisanie odpowiedzialności, ścieżkę eskalacji i zasoby potrzebne do realizacji planu. Dowód: decyzja kierownictwa oraz aktualny rejestr odpowiedzialności.

Ryzyko i system zarządzania bezpieczeństwem informacji

• ☐ Zweryfikować zakres SZBI oraz wykaz usług, procesów, systemów i informacji objętych oceną ryzyka.
• ☐ Zaktualizować ocenę ryzyka i plan postępowania z ryzykiem; każdemu działaniu przypisać właściciela oraz termin.
• ☐ Udokumentować decyzje dotyczące ryzyk pozostających po wdrożeniu zabezpieczeń. Dowód: zatwierdzony rejestr ryzyka i plan działań, nie tylko opis przyjętej metody.

Incydenty i zgłoszenia

• ☐ Sprawdzić aktualność kontaktów, zastępstw i kanałów zgłaszania incydentów, także poza standardowymi godzinami pracy.
• ☐ Zweryfikować kryteria kwalifikacji incydentu, właściwych odbiorców zgłoszeń oraz terminy i zakres przekazywanych informacji wynikające z przepisów mających zastosowanie do organizacji.
• ☐ Przeprowadzić próbę obsługi incydentu — od wykrycia do przygotowania zgłoszenia. Dowód: zapis przebiegu ćwiczenia, zmierzone czasy reakcji i lista poprawek.

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

• ☐ Potwierdzić priorytety odtwarzania usług oraz akceptowalne czasy niedostępności i utraty danych z właścicielami procesów.
• ☐ Wykonać test odtworzenia z kopii zapasowych oraz sprawdzić wybrany scenariusz awaryjny. Dowód: wyniki testów z oceną osiągnięcia przyjętych parametrów.
• ☐ Zaktualizować plany ciągłości działania na podstawie wykrytych problemów i przydzielić zadania naprawcze.

Dostawcy i zależności zewnętrzne

• ☐ Wyodrębnić dostawców istotnych dla bezpieczeństwa i ciągłości usług; wskazać właściciela każdej relacji.
• ☐ Ocenić wymagania bezpieczeństwa w umowach, zasady informowania o incydentach oraz dostępność dowodów spełnienia uzgodnionych wymagań.
• ☐ Ustalić sposób ograniczenia zależności od dostawców krytycznych. Dowód: ocena dostawcy, rejestr braków i uzgodniony plan działań.

Szkolenia i świadomość

• ☐ Ustalić grupy odbiorców szkoleń, w tym kierownictwo i osoby pełniące role operacyjne; oddzielić wymagania prawne od potrzeb wynikających z oceny ryzyka.
• ☐ Zrealizować szkolenia i sprawdzić zrozumienie zasad właściwych dla danej roli. Dowód: program, potwierdzenia udziału oraz wyniki weryfikacji wiedzy lub ćwiczeń.

Audyt i zamknięcie ustaleń

• ☐ Potwierdzić, czy organizację obejmuje obowiązek audytu, a jeśli tak — ustalić jego zakres, termin i wymagania wobec wykonawcy.
• ☐ Zgromadzić aktualne dowody wdrożenia i działania zabezpieczeń; sprawdzić, czy dokumenty odpowiadają rzeczywistej praktyce.
• ☐ Przypisać właścicieli i terminy usunięcia niezgodności oraz zweryfikować skuteczność poprawek przed zamknięciem ustaleń.

Zadanie oznaczaj jako zakończone dopiero po sprawdzeniu dowodu wykonania. Samo zatwierdzenie procedury nie potwierdza jej działania, a zamówienie audytu lub szkolenia nie oznacza realizacji obowiązku. Pozycje niedotyczące organizacji oznacz jako „nie dotyczy” wraz z krótkim uzasadnieniem.

Przykładowe scenariusze kwalifikacji + co zrobić, gdy wynik jest niepewny

O objęciu obowiązkami KSC nie przesądza sama nazwa branży, kod PKD ani deklaracja, że organizacja „nie jest infrastrukturą krytyczną”. Znaczenie mają faktycznie wykonywana działalność, rodzaj świadczonych usług, wielkość podmiotu oraz szczególne przesłanki przewidziane w przepisach. Kwalifikację na potrzeby lat 2026–2027 trzeba oprzeć na brzmieniu polskiej ustawy właściwym dla ocenianego okresu, z uwzględnieniem przepisów przejściowych — nie wyłącznie na dyrektywie NIS2, projekcie nowelizacji lub branżowym opracowaniu.

Producent: duża skala działalności nie wystarcza do kwalifikacji

Przedsiębiorstwo produkcyjne zatrudniające kilkaset osób powinno przede wszystkim ustalić, czy jego rzeczywista działalność należy do kategorii produkcji objętych regulacją. Nie każda fabryka automatycznie podlega tym samym obowiązkom. Inny wynik może dotyczyć producenta urządzeń elektrycznych, a inny przedsiębiorstwa działającego poza wskazanymi kategoriami. Kod PKD jest punktem wyjścia, ale wymaga zestawienia z zakresem działalności i definicjami ustawowymi. Dopiero później można rozstrzygać status podmiotu kluczowego lub ważnego.

Niewielki dostawca usług IT: małe zatrudnienie nie zawsze wyłącza obowiązki

Firma utrzymująca systemy klientów nie powinna kończyć analizy na liczbie pracowników. Trzeba sprawdzić, czy świadczy usługi odpowiadające ustawowym definicjom, przykładowo usług zarządzanych lub zarządzanych usług bezpieczeństwa, oraz jakie zasady ustalania wielkości mają do niej zastosowanie. Nie każda usługa informatyczna oznacza objęcie KSC, ale mały zespół również nie jest uniwersalnym wyłączeniem. Dodatkowo wynik może zależeć od szczególnych przesłanek lub powiązań z innymi przedsiębiorstwami.

Spółka w grupie: osobny podmiot nie zawsze oznacza osobne liczenie wielkości

Spółka świadcząca usługi w sektorze objętym regulacją może samodzielnie wyglądać na małe przedsiębiorstwo, a po uwzględnieniu przedsiębiorstw partnerskich lub powiązanych przekroczyć właściwy próg. Należy więc zbadać strukturę właścicielską i zasady ustalania wielkości, w tym ewentualne ustawowe odstępstwa. Nie oznacza to jednak, że wszystkie spółki grupy automatycznie uzyskują identyczny status: zakres działalności i pozostałe przesłanki wymagają oceny dla konkretnego podmiotu.

Dostawca podmiotu objętego KSC: obowiązek ustawowy a wymaganie kontraktowe

Samo świadczenie usług szpitalowi, operatorowi energetycznemu czy innemu podmiotowi regulowanemu nie przesądza o bezpośrednim objęciu dostawcy KSC. Klient może jednak wymagać określonych zabezpieczeń, informowania o incydentach lub możliwości weryfikacji bezpieczeństwa. Warto wyraźnie oddzielić własne obowiązki ustawowe od zobowiązań wynikających z umowy. Brak bezpośredniej kwalifikacji nie oznacza braku wymagań ze strony odbiorców usług.

Podczas szkoleń Cognity pogłębiamy te zagadnienia na konkretnych przykładach z pracy uczestników.

Niepewny wynik: konsultacja, monitoring i proporcjonalny baseline

Gdy kwalifikacja pozostaje niejednoznaczna, warto przygotować krótką notatkę: opis działalności, dane o wielkości i powiązaniach, rozważane przepisy oraz konkretną wątpliwość. Z takim materiałem konsultacja prawna będzie bardziej użyteczna niż ogólne pytanie „czy podlegamy KSC?”. Jeżeli dostępna jest właściwa ścieżka, można również wystąpić o stanowisko odpowiedniego organu, pamiętając, że nie każda odpowiedź informacyjna ma charakter wiążący.

Monitoring powinien obejmować publikacje w Dzienniku Ustaw, właściwe akty wykonawcze i oficjalne komunikaty organów. Ponowną ocenę mogą uzasadniać także zmiany wewnętrzne: przejęcie spółki, wzrost skali działalności lub uruchomienie nowej usługi. Wniosek „poza zakresem” warto więc zapisać wraz z datą, założeniami i przesłankami jego aktualizacji.

Do czasu rozstrzygnięcia rozsądne jest utrzymywanie baseline’u, czyli minimalnego, proporcjonalnego poziomu zabezpieczeń, opartego na rzeczywistym ryzyku i wymaganiach klientów. To ogranicza ekspozycję organizacji na zagrożenia niezależnie od końcowej kwalifikacji. Nie stanowi jednak potwierdzenia zgodności z KSC, a sama niepewność interpretacyjna nie zawiesza obowiązków ani terminów, jeżeli przepisy już obejmują dany podmiot.

Jak wykorzystać ChatGPT i Copilot w codziennej pracy firmy budowlanej? 06 października 2026

Power Query – 10 najczęstszych problemów z danymi i sposoby ich rozwiązania 04 października 2026