Ustawa o KSC: checklista na 3 października 2026 dla działu IT
3 października 2026 to termin na złożenie wniosku o wpis do wykazu dla podmiotów, które spełniały kryteria 3 kwietnia 2026. Podmiot, który spełni je później, ma co do zasady sześć miesięcy od tego momentu. Druga ważna data to 3 kwietnia 2027: koniec okresu dostosowawczego dla obowiązków, w tym wdrożenia systemu zarządzania bezpieczeństwem informacji.
Ten tekst to lista kontrolna dla działu IT, który dostał temat "ogarnijcie KSC" i nie wie, od czego zacząć. Uwaga porządkowa: nie jestem prawnikiem i to nie jest porada prawna. To praktyczna mapa tego, co po stronie IT musi się wydarzyć, żeby firma zdążyła. Interpretację przepisów dla Waszej konkretnej sytuacji potwierdźcie z obsługą prawną.
Krok 1: ustalcie, czy w ogóle podlegacie
Nowa ustawa działa na zasadzie samoidentyfikacji. Nikt nie przyśle Wam pisma z informacją, że jesteście podmiotem kluczowym lub ważnym. Musicie to ustalić sami, na podstawie sektora działalności i wielkości firmy.
Do sprawdzenia:
- czy działacie w jednym z sektorów wymienionych w załącznikach ustawy (energia, transport, zdrowie, infrastruktura cyfrowa, usługi ICT, produkcja wybranych kategorii, gospodarka odpadami i inne),
- czy spełniacie kryteria średniego przedsiębiorcy albo większego podmiotu, z uwzględnieniem zatrudnienia, danych finansowych oraz przedsiębiorstw partnerskich i powiązanych,
- czy jesteście dostawcą dla podmiotu kluczowego, bo wtedy wymagania mogą przyjść do Was łańcuchem dostaw, nawet bez formalnego objęcia ustawą.
Wynik tej analizy spiszcie. Jeśli uznacie, że nie podlegacie, dokument z uzasadnieniem też ma wartość: pokazuje, że decyzja była świadoma, a nie wynikała z niewiedzy.
Chcecie szybką wstępną orientację przed pełną analizą? Sprawdźcie w trzy pytania, czy prawdopodobnie podlegacie - to nie zastępuje analizy prawnej, ale pokazuje, w którą stronę patrzeć.
Krok 2: wpis do wykazu przed 3 października
Jeśli podlegacie, rejestrujecie się w wykazie podmiotów kluczowych i ważnych. Sama rejestracja to formalność, ale wymaga wcześniejszego przygotowania danych: zakresu działalności, danych kontaktowych osób odpowiedzialnych, informacji o świadczonych usługach.
Praktyczna rada: wyznaczcie osobę kontaktową do spraw cyberbezpieczeństwa już teraz. Ta rola i tak będzie potrzebna przy zgłaszaniu incydentów, a wpisanie przypadkowej osoby "bo ktoś musiał być" mści się później.
Krok 3: inwentaryzacja, czyli fundament, który wywraca większość firm
Tu zaczyna się prawdziwa praca. Nie da się zarządzać bezpieczeństwem systemów, których się nie zna. Potrzebujecie odpowiedzi na pytania:
- jakie serwery, usługi i aplikacje utrzymujecie (produkcja, test, zapomniane maszyny "tymczasowe" sprzed trzech lat),
- jakie systemy operacyjne i w jakich wersjach na nich działają,
- które z nich są krytyczne dla świadczenia usług objętych ustawą,
- kto jest właścicielem każdego systemu, czyli kto podejmuje decyzje o zmianach.
Z doświadczenia: w firmach, które nigdy nie robiły formalnej inwentaryzacji, ten krok zwykle ujawnia zapomniane maszyny i usługi. Nie zakładam z góry żadnego procentu, bo skala zależy od organizacji. To nie jest powód do wstydu, tylko właśnie po to robi się inwentaryzację.
Krok 4: proces zarządzania podatnościami
Ustawa wymaga obsługi podatności jako procesu ciągłego. Minimalny sensowny kształt:
- regularne, automatyczne skanowanie wszystkich zinwentaryzowanych systemów (nie ręczne, nie "raz na kwartał przed zebraniem"),
- priorytetyzacja znalezisk: co naprawiamy natychmiast, co w ustalonym terminie, co świadomie akceptujemy,
- zdefiniowane terminy napraw (SLA) zależne od krytyczności podatności,
- ścieżka dla wyjątków: kto może zaakceptować ryzyko, na jak długo, z jakim uzasadnieniem,
- zapis tego wszystkiego w miejscu, z którego da się później wygenerować dowód.
Ostatni punkt jest najczęściej pomijany, a to on decyduje o wyniku audytu. Proces, którego nie da się udokumentować, z punktu widzenia audytora nie istnieje.
Krok 5: obsługa incydentów
Podmioty kluczowe i ważne zgłaszają poważne incydenty: wczesne ostrzeżenie w 24 godziny od uzyskania informacji o zdarzeniu spełniającym kryteria incydentu, zgłoszenie w 72 godziny i raport końcowy zasadniczo w ciągu miesiąca od zgłoszenia. Dla niektórych podmiotów publicznych ważnych przewidziano tryb uproszczony, bez wczesnego ostrzeżenia i raportu końcowego. Zanim to nastąpi, potrzebujecie:
- definicji, co u Was jest incydentem i kto decyduje o jego istotności,
- rejestru incydentów, także tych niezgłaszanych (audytor pyta o proces, nie tylko o zgłoszenia),
- przećwiczonej ścieżki: kto pisze zgłoszenie, kto je zatwierdza, gdzie są dane dostępowe do systemu zgłoszeń.
Krok 6: dowody, czyli jak to wszystko udowodnić
Każdy z powyższych kroków generuje artefakty: wynik analizy podlegania, potwierdzenie wpisu, rejestr aktywów, wyniki skanów z historią, decyzje o akceptacji ryzyka, rejestr incydentów. Audytor lub organ nadzoru będzie chciał je zobaczyć za konkretny okres.
Możecie je trzymać w katalogach sieciowych i arkuszach. Możecie też użyć narzędzia, które historię skanów, terminy, decyzje i eksport dowodów prowadzi automatycznie. Zbudowałem Secvalis dokładnie do tego drugiego scenariusza i jeśli chcesz zobaczyć, jak taki proces wygląda w praktyce, wejdź do publicznego demo. Bez rejestracji, na fikcyjnych danych.
Podsumowanie terminów
- do 3.10.2026: wniosek o wpis dla podmiotów spełniających kryteria w dniu wejścia nowelizacji w życie,
- do 3.04.2027: dostosowanie do obowiązków, w tym wdrożony SZBI, proces podatności i procedury zgłaszania incydentów.
Kalendarz jest nieubłagany o tyle, że inwentaryzacja i wdrożenie procesu podatności w średniej firmie zajmują tygodnie, nie dni. Im później start, tym więcej rzeczy będzie robionych na skróty, a skróty w dokumentacji widać na audycie najlepiej.