Najtrudniejszym operacyjnie obowiązkiem znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 20 t.j., zmiana Dz.U. 2026 poz. 252) — wykonującej art. 23 dyrektywy 2022/2555 (NIS2) — jest raportowanie incydentów poważnych. Ustawa daje na pierwsze, wstępne ostrzeżenie tylko 24 godziny od momentu wykrycia, na pełne zgłoszenie — 72 godziny, a na sprawozdanie końcowe — miesiąc. Te terminy są krótkie, biegną niezależnie od dnia tygodnia i godziny wykrycia, a niezachowanie któregokolwiek z nich jest podstawą kary z art. 73 ust. 1 KSC. W tym wpisie tłumaczymy, jak działają art. 11, art. 12, art. 12a i art. 12b KSC oraz co trzeba mieć przygotowane, żeby procedurę faktycznie przeprowadzić.

Czym jest „incydent poważny" i kto go klasyfikuje?

Punktem wyjścia jest art. 2 pkt 7 KSC, który definiuje incydent poważny jako incydent, który powoduje lub może spowodować poważne obniżenie jakości lub przerwanie ciągłości świadczenia usługi przez podmiot kluczowy lub podmiot ważny, straty finansowe dla tego podmiotu lub wpływa na inne osoby fizyczne, osoby prawne, jednostki organizacyjne nieposiadające osobowości prawnej przez wywołanie poważnej szkody materialnej lub niematerialnej.

Sama definicja jest ogólna — konkretne progi uznawania incydentu za poważny wynikają z dwóch źródeł:

  • dla podmiotów objętych aktami wykonawczymi Komisji Europejskiej wydawanymi na podstawie art. 23 ust. 11 dyrektywy 2022/2555 (NIS2) — progi określa Komisja. Dla dostawców usług DNS, rejestrów TLD, dostawców chmury, centrów danych, MSSP, MSP, platform handlowych, wyszukiwarek i platform społecznościowych — progi określone są w rozporządzeniu wykonawczym Komisji (UE) 2024/2690 z 17 października 2024 r.;
  • dla pozostałych podmiotów — progi określi Rada Ministrów w drodze rozporządzenia, zgodnie z art. 11 ust. 4 KSC, według rodzaju zdarzenia w poszczególnych sektorach i podsektorach z załączników nr 1 i 2 do ustawy.

Art. 11 ust. 4 KSC wskazuje cztery kryteria, którymi rozporządzenie ma się kierować:

  • liczba użytkowników, których dotyczy zakłócenie świadczenia usługi;
  • czas oddziaływania incydentu na świadczoną usługę;
  • zasięg geograficzny obszaru, którego dotyczy incydent;
  • inne czynniki charakterystyczne dla danego sektora lub podsektora.

Klasyfikacja incydentu jako poważnego jest obowiązkiem podmiotu kluczowego lub ważnego (art. 11 ust. 1 pkt 3 KSC). To pierwsza decyzja, która musi zapaść w ramach obsługi incydentu — i często to ona okaże się najtrudniejsza, bo bywa, że pełen obraz skutków pojawia się dopiero po godzinach analizy.

Oś czasu — co i kiedy raportujesz

Trójetapowa konstrukcja czasowa raportowania (24h / 72h / 1 miesiąc) wynika wprost z art. 23 ust. 4 dyrektywy NIS2 — terminy są maksymalne i nie mogą być przez ustawodawstwo krajowe wydłużane. Art. 11 ust. 1 KSC wprowadza pięcioetapową ścieżkę raportowania:

  1. Wczesne ostrzeżenie (art. 11 ust. 1 pkt 4) — niezwłocznie, nie później niż w ciągu 24 godzin od momentu wykrycia incydentu poważnego, do właściwego CSIRT sektorowego;
  2. Zgłoszenie incydentu poważnego (art. 11 ust. 1 pkt 4a) — niezwłocznie, nie później niż w ciągu 72 godzin od momentu wykrycia, do właściwego CSIRT sektorowego;
  3. Sprawozdanie okresowe (art. 11 ust. 1 pkt 4b) — na wniosek właściwego CSIRT sektorowego;
  4. Sprawozdanie końcowe (art. 11 ust. 1 pkt 4c) — nie później niż w ciągu miesiąca od dnia zgłoszenia poważnego incydentu;
  5. Sprawozdanie z postępu obsługi (art. 12b KSC) — w przypadku, gdy obsługa incydentu nie zakończyła się w terminie sprawozdania końcowego. Wówczas sprawozdanie końcowe składa się ponownie — nie później niż w ciągu miesiąca od dnia zakończenia obsługi.

Wszystkie zgłoszenia są przekazywane za pomocą systemu teleinformatycznego z art. 46 ust. 1 KSC (system S46) — to rozwiązanie wynika z art. 11 ust. 2 KSC.

Jak liczyć terminy — i dlaczego to jest pułapka

Terminy biegną od momentu wykrycia incydentu poważnego, a nie od momentu jego wystąpienia ani od decyzji o klasyfikacji. To istotny detal, bo ustawa nie precyzuje, kto wykrywa — wystarczy, że zdarzenie zostało zauważone przez pracownika, system monitorujący, użytkownika, klienta lub stronę trzecią. Od tej chwili biegnie 24-godzinny zegar wczesnego ostrzeżenia.

Zegar nie zatrzymuje się w nocy ani w weekend. Atak ransomware wykryty w piątek o 18:00 musi być zgłoszony jako wczesne ostrzeżenie najpóźniej w sobotę o 18:00, a pełne zgłoszenie — w poniedziałek o 18:00. Kalendarz zarządu i tabela urlopowa nie wpływają na bieg terminów.

W praktyce oznacza to konieczność wcześniejszego ustalenia:

  • kto w organizacji może uruchomić procedurę zgłoszenia (powinno być co najmniej dwie wyznaczone osoby kontaktowe z art. 9 ust. 1 pkt 1 KSC, dostępne w trybie 24/7);
  • jak technicznie przekazać zgłoszenie poza godzinami pracy (dostępność systemu S46 pod konkretnym podpisem elektronicznym, alternatywne kanały);
  • kiedy podejmuje się decyzję o klasyfikacji incydentu jako poważnego (procedura, kompetencja decyzyjna, eskalacja).

Bez przygotowanej procedury reakcji na incydent (incident response plan) firma w realnym kryzysie traci pierwsze 6–12 godzin na ustalenie tych podstaw — a przy 24-godzinnym terminie to oznacza, że na samo zgłoszenie pozostaje już bardzo mało czasu.

Co zawiera wczesne ostrzeżenie (art. 12 ust. 1 KSC)

Art. 12 ust. 1 KSC dokładnie opisuje sześć obowiązkowych elementów wczesnego ostrzeżenia:

  1. dane podmiotu zgłaszającego — firma, numer z właściwego rejestru, siedziba i adres;
  2. imię i nazwisko, numer telefonu służbowego oraz adres służbowej poczty elektronicznej osoby dokonującej zgłoszenia;
  3. imię i nazwisko, numer telefonu służbowego oraz adres służbowej poczty elektronicznej osoby uprawnionej do składania wyjaśnień;
  4. wskazanie momentu wystąpienia i wykrycia incydentu poważnego oraz czasu jego trwania;
  5. wskazanie, czy incydent został wywołany działaniem bezprawnym lub w złej wierze, jeżeli możliwa jest taka ocena;
  6. określenie, czy incydent dotyczy innych państw członkowskich UE.

Wczesne ostrzeżenie może też zawierać wniosek o wskazanie wytycznych do wdrożenia środków lub o dodatkowe wsparcie techniczne (art. 12 ust. 2 KSC). CSIRT sektorowy ma na odpowiedź — uwaga — także 24 godziny, w trakcie których przekazuje wytyczne lub udziela wsparcia, a w przypadku incydentu wyczerpującego znamiona przestępstwa — informacje o sposobie zgłoszenia organom ścigania.

W praktyce wczesne ostrzeżenie to dokument, który trzeba móc wypełnić w 1–2 godziny od decyzji o klasyfikacji incydentu jako poważnego. Większość danych jest stała (firma, rejestr, osoby kontaktowe) — to można przygotować z wyprzedzeniem jako szablon. Zmienne są tylko punkty 4–6: czas, ocena bezprawności, zasięg transgraniczny.

Co zawiera pełne zgłoszenie (art. 12 ust. 3 KSC)

Pełne zgłoszenie incydentu poważnego — składane w ciągu 72 godzin — jest dokumentem znacznie obszerniejszym. Art. 12 ust. 3 KSC wymaga pięciu kategorii informacji:

  1. opis wpływu incydentu na świadczenie usługi, w tym:
    • wskazanie usługi, na którą incydent miał wpływ,
    • liczba użytkowników, na których incydent miał wpływ,
    • zasięg geograficzny obszaru, którego dotyczy incydent,
    • wpływ incydentu na świadczenie usługi przez inne podmioty;
  2. opis przyczyn incydentu, sposób jego przebiegu oraz prawdopodobne skutki oddziaływania na systemy informacyjne lub świadczone usługi;
  3. informacje o podjętych działaniach zapobiegawczych;
  4. informacje o podjętych działaniach naprawczych;
  5. aktualizacja informacji z wczesnego ostrzeżenia, jeżeli nastąpiła ich zmiana.

Art. 12 ust. 5 KSC łagodzi nieco rygor: podmiot przekazuje informacje znane mu w chwili dokonywania zgłoszenia i uzupełnia je w trakcie obsługi incydentu. Innymi słowy — nie trzeba w 72 godzinach mieć finalnej, pełnej analizy incydentu. Trzeba mieć zgłoszenie zawierające stan wiedzy w danym momencie.

Art. 12 ust. 7 KSC daje CSIRT prawo zwrócić się o uzupełnienie wczesnego ostrzeżenia lub zgłoszenia o dodatkowe informacje, w tym informacje stanowiące tajemnice prawnie chronione. Art. 12 ust. 6 i 8 KSC przewidują, że podmiot może w razie konieczności przekazać tajemnicę przedsiębiorstwa (oznaczoną odpowiednio), gdy jest to konieczne do realizacji zadań CSIRT.

Sprawozdanie końcowe (art. 12a KSC)

Art. 12a KSC określa, że sprawozdanie końcowe — składane w ciągu miesiąca od dnia zgłoszenia — zawiera:

  1. szczegółowy opis incydentu poważnego, w tym spowodowane zakłócenia i szkody;
  2. rodzaj zagrożenia lub przyczynę, która prawdopodobnie była źródłem incydentu;
  3. zastosowane i wdrażane środki ograniczające ryzyko;
  4. transgraniczne skutki incydentu, jeżeli wystąpiły.

To jest finalny dokument analizy incydentu — porównywalny z formalnym post-mortem. W praktyce stanowi też podstawę do aktualizacji systemu zarządzania bezpieczeństwem informacji (art. 8 KSC), procedur reakcji na incydent oraz programu szkoleń.

Sprawozdanie z postępu (art. 12b KSC)

Niektóre incydenty wymagają obsługi dłuższej niż miesiąc — w szczególności złożone ataki ukierunkowane (APT), kompleksowe naruszenia łańcucha dostaw, sytuacje wymagające reverse engineering. Art. 12b ust. 1 KSC przewiduje wówczas obowiązek przekazania sprawozdania z postępu obsługi incydentu, a po zakończeniu obsługi — sprawozdania końcowego nie później niż w ciągu miesiąca od dnia jej zakończenia (art. 12b ust. 2).

Praktyczny przykład: atak ransomware wykryty 1 maja. Wczesne ostrzeżenie — do 2 maja. Pełne zgłoszenie — do 4 maja. Sprawozdanie końcowe — termin: 4 czerwca. Jeżeli obsługa wciąż trwa 4 czerwca, składa się sprawozdanie z postępu. Obsługa zakończona 15 lipca? Sprawozdanie końcowe trzeba złożyć do 15 sierpnia.

Informowanie użytkowników — art. 11 ust. 2a i 2b KSC

Oprócz zgłoszenia do CSIRT sektorowego, podmiot kluczowy lub ważny ma dwa dodatkowe obowiązki informacyjne wobec użytkowników swoich usług:

  • Art. 11 ust. 2a KSC — w przypadku zaistnienia poważnego cyberzagrożenia podmiot informuje użytkowników, na których takie cyberzagrożenie może mieć wpływ, o możliwych środkach zapobiegawczych, które użytkownicy ci mogą podjąć. Podmiot informuje użytkowników także o samym poważnym cyberzagrożeniu, jeżeli nie spowoduje to zwiększenia poziomu ryzyka dla bezpieczeństwa systemów informacyjnych.
  • Art. 11 ust. 2b KSC — podmiot informuje użytkowników o incydencie poważnym, jeżeli ma on niekorzystny wpływ na świadczenie tych usług.

To dwie różne sytuacje. „Poważne cyberzagrożenie" w rozumieniu art. 2 pkt 11f KSC to cyberzagrożenie, które przez swoje właściwości techniczne może mieć poważny wpływ na bezpieczeństwo systemów informacyjnych lub użytkowników — to scenariusz prewencyjny. „Incydent poważny" — scenariusz reakcji na zdarzenie, które już zaszło.

W praktyce komunikacja z użytkownikami w trakcie incydentu wymaga równolegle z procedurą prawną także uzgodnionej polityki PR — co i jak komunikować, w jakim momencie, jakim kanałem. Brak wewnętrznej koordynacji często prowadzi do wewnętrznie sprzecznych komunikatów lub do informacji rozsianej na portalach branżowych przed zgłoszeniem do CSIRT.

Wyjątek dla podmiotów ważnych będących podmiotami publicznymi (art. 12c KSC)

Art. 12c KSC stanowi, że do podmiotu ważnego będącego podmiotem publicznym stosuje się przepisy art. 11 i art. 12, z wyjątkiem przepisów o przekazywaniu wczesnego ostrzeżenia, sprawozdania okresowego, sprawozdania z postępu obsługi incydentu i sprawozdania końcowego. Innymi słowy, podmiot ważny będący publicznym ma obowiązek obsługi incydentu (art. 11 ust. 1 pkt 1), klasyfikacji (pkt 3), zgłoszenia incydentu poważnego w 72 godzinach (pkt 4a), współdziałania z CSIRT (pkt 5) i usuwania podatności (pkt 6) — ale jest zwolniony z wczesnego ostrzeżenia w 24 godzinach oraz z sprawozdań okresowych i końcowych.

To ulga, która ma swoje uzasadnienie operacyjne — w sektorze publicznym procesy zgłoszeń są często prowadzone przez wiele podmiotów współpracujących, a sprawozdawczość jest realizowana przez inne kanały (m.in. ABW, RCB).

Adresat zgłoszenia — CSIRT sektorowy

Art. 11 ust. 1 pkt 4 i 4a KSC wyraźnie wskazują właściwego CSIRT sektorowego jako adresata zgłoszenia. Dla każdego sektora wymienionego w załącznikach nr 1 i 2 do ustawy organ właściwy do spraw cyberbezpieczeństwa ustanowił lub ustanowi CSIRT sektorowy (art. 44 KSC). Dla sektora bankowości i infrastruktury rynków finansowych jest to CSIRT KNF.

Trzeba pamiętać, że to inny adresat niż sam organ właściwy. CSIRT KNF jest jednostką techniczno-operacyjną nadzoru, KNF jako organ nadzoru — instancją regulacyjną. Zgłoszenie incydentu trafia do CSIRT, ale w razie naruszenia przepisów to organ właściwy może wszcząć postępowanie nadzorcze (art. 53 KSC) i nałożyć karę (art. 73 KSC).

Dla podmiotów objętych jednocześnie KSC i DORA istnieją dwie ścieżki raportowania:

  • Ścieżka KSC (art. 11) — do CSIRT sektorowego, wedle terminów 24h/72h/1 miesiąc;
  • Ścieżka DORA (art. 19–20) — do organu właściwego w rozumieniu DORA (KNF lub NBP), również 24h/72h/1 miesiąc.

Co istotne, art. 8i ust. 1 KSC dla sektora bankowości i infrastruktury rynków finansowych wyłącza stosowanie art. 11 KSC w zakresie zgłaszania incydentów (z wyjątkiem ust. 1 pkt 5 — współdziałanie z CSIRT i przechowywanie dowodów). W sektorze finansowym podstawową ścieżką jest więc DORA, nie KSC. Tematowi temu poświęcamy osobny wpis o art. 8i i lex specialis.

Połączenie z RODO — kiedy dwa zgłoszenia, kiedy jedno

Wiele incydentów cybersec to równocześnie incydenty naruszenia ochrony danych osobowych — w szczególności ransomware z eksfiltracją danych, błąd konfiguracji ujawniający dane klientów, atak phishingowy skutkujący przejęciem konta z dostępem do danych. W takich przypadkach mamy dwa równoległe obowiązki:

  • Zgłoszenie do UODO w terminie 72 godzin od stwierdzenia naruszenia (art. 33 RODO) — bez konieczności klasyfikacji jako „poważnego" w rozumieniu KSC;
  • Zgłoszenie do CSIRT sektorowego w terminach 24 godzin (wczesne ostrzeżenie) i 72 godzin (pełne zgłoszenie) — o ile incydent kwalifikuje się jako poważny w rozumieniu KSC.

Te dwa obowiązki są niezależne. Nie ma „konsumpcji" zgłoszenia — zgłoszenie do UODO nie zwalnia z zgłoszenia do CSIRT i odwrotnie. Sama dyrektywa NIS2 w art. 35 wprost przewiduje równoległe stosowanie obowiązków NIS2 i RODO przy zdarzeniach łączących obie regulacje. Natomiast przy nakładaniu kar art. 76c ust. 1 KSC przewiduje, że jeżeli za czyn zagrożony karą z KSC nałożono prawomocnie karę przez Prezesa UODO (z tytułu naruszenia ochrony danych), organ KSC nie wszczyna postępowania, poprzestając na pouczeniu. To detal istotny strategicznie — szczegółowo omawiamy go w wpisie o odpowiedzialności zarządu.

Co powinno być w „kalendarzu cybersec" zarządu

Z naszego doświadczenia firmy, które dobrze radzą sobie z reżimem incydentowym KSC, mają pięć stałych elementów w swoich procedurach:

  • Procedura reakcji na incydent (incident response plan) — opis ról, ścieżki eskalacji, decyzji klasyfikacyjnej, treści komunikatów;
  • Szablony zgłoszeń — wczesnego ostrzeżenia (art. 12 ust. 1), pełnego zgłoszenia (art. 12 ust. 3) i sprawozdania końcowego (art. 12a) — gotowe do uzupełnienia w pierwszych godzinach incydentu;
  • Lista kontaktowa 24/7 — minimum dwóch osób z art. 9 ust. 1 pkt 1 KSC, przeszkolonych z procedury, z dostępem do systemu S46 i alternatywnych kanałów;
  • Tabletop exercises — ćwiczenia symulacyjne raz w roku, w których zarząd i zespół incident response przechodzą przez pełną ścieżkę zgłoszenia. Najlepszy sprawdzian, czy procedura naprawdę działa pod presją czasu;
  • Dokumentacja incydentów — rejestr wszystkich zgłoszeń, sprawozdań, pism od CSIRT, decyzji organu — przechowywany zgodnie z art. 10 ust. 7 KSC przez minimum 2 lata.

Brak któregokolwiek z tych pięciu elementów powoduje, że w realnym kryzysie firma improwizuje — a improwizacja w 24-godzinnym oknie czasowym to bardzo zła pozycja.

Sankcje za niezachowanie terminów

Art. 73 ust. 1 KSC wprost wymienia siedem różnych obowiązków incydentowych, których niewykonanie skutkuje karą pieniężną:

  • art. 73 ust. 1 pkt 5 — niewykonanie obowiązku zapewnienia obsługi incydentu (art. 11 ust. 1 pkt 1);
  • art. 73 ust. 1 pkt 6 — niezgłoszenie wczesnego ostrzeżenia w 24 godzinach (art. 11 ust. 1 pkt 4);
  • art. 73 ust. 1 pkt 7 — niezgłoszenie incydentu poważnego w 72 godzinach (art. 11 ust. 1 pkt 4a);
  • art. 73 ust. 1 pkt 8 — nieprzekazanie sprawozdania okresowego (art. 11 ust. 1 pkt 4b);
  • art. 73 ust. 1 pkt 9 — nieprzekazanie sprawozdania końcowego (art. 11 ust. 1 pkt 4c);
  • art. 73 ust. 1 pkt 10 — niewspółdziałanie z CSIRT podczas obsługi incydentu (art. 11 ust. 1 pkt 5);
  • art. 73 ust. 1 pkt 13 — niekorzystanie z systemu S46 do raportowania (art. 46 ust. 1).

Maksymalne kary — do 10 mln EUR lub 2% przychodów dla podmiotu kluczowego (art. 73 ust. 3), do 7 mln EUR lub 1,4% przychodów dla podmiotu ważnego (art. 73 ust. 4). W przypadku, gdy naruszenie powoduje bezpośrednie i poważne cyberzagrożenie dla obronności, bezpieczeństwa państwa lub zdrowia ludzi — do 100 mln zł (art. 73 ust. 5).

Niezależnie — art. 73a KSC pozwala na karę do 300% wynagrodzenia kierownika podmiotu prywatnego (do 100% — publicznego), m.in. za niewykonanie obowiązków z art. 11 (pkt 9 art. 73a ust. 1).

Jak możemy Ci pomóc?

Wdrożenie procedury reakcji na incydent zgodnej z art. 11–12b KSC to znacznie więcej niż napisanie dokumentu — to przygotowanie organizacji na realny scenariusz, w którym zegar tyka od momentu wykrycia. W Legal Geek wspieramy podmioty kluczowe i ważne w opracowaniu procedury incydentowej, szablonów wczesnego ostrzeżenia, pełnego zgłoszenia i sprawozdania końcowego, a także prowadzimy tabletop exercises symulujące pełną ścieżkę reakcji na incydent — wraz z weryfikacją zgodności z RODO i, dla podmiotów finansowych, z DORA. Jeżeli chcesz sprawdzić, czy Twoja organizacja jest gotowa na pierwszy realny incydent w reżimie KSC — napisz do nas.

W kolejnym wpisie cyklu omawiamy art. 15 KSC — audyt bezpieczeństwa systemu informacyjnego dla podmiotu kluczowego — który jest narzędziem nadzoru zarówno autonomicznym (co 3 lata), jak i nakazowym (decyzją organu po incydencie poważnym).

Co dalej w cyklu?