Incydent poważny według KSC – zgłoszenie w 24 i 72 godziny

Incydent poważny to zdarzenie cyberbezpieczeństwa, które według art. 2 pkt 7 ustawy o KSC ma znaczący lub potencjalnie znaczący negatywny wpływ na świadczone usługi, odbiorców usług lub inne podmioty — oceniane przez pryzmat skutków operacyjnych, finansowych i bezpieczeństwa, a nie przez sztywne progi liczbowe w ustawie. Podmiot kluczowy i ważny po wpisie do Wykazu zgłasza taki incydent w Systemie S46 w trzech etapach czasowych.

Stan prawny sprawdzony: 27 lipca 2026 r. Artykuł informacyjny — przy wątpliwościach co do kwalifikacji zdarzenia skonsultuj prawnika i CSIRT GOV. Nie wymyślaj progów typu „X rekordów = incydent poważny” — ustawa operuje oceną znaczącego wpływu, nie checklistą liczbową.

Spis treści

• Definicja incydentu poważnego (art. 2 pkt 7)
• Wczesne ostrzeżenie — 24 godziny
• Zgłoszenie incydentu — 72 godziny
• Sprawozdanie końcowe — zasadniczo do miesiąca
• Checklist operacyjny
• Rola kierownika i S46
• FAQ

Definicja incydentu poważnego (art. 2 pkt 7)

Art. 2 pkt 7 definiuje incydent poważny jako incydent, który znacząco lub w potencjale znacząco zakłóca świadczenie usług podmiotu, narusza integralność, poufność lub dostępność sieci/informacji w sposób istotny dla otoczenia — odbiorców usług, łańcucha dostaw, bezpieczeństwa publicznego. Ocena jest jakościowa i kontekstowa: ten sam ransomware u dostawcy IT może być poważny u operatora energii, a mniej krytyczny u podmiotu bez usług sektorowych — ale każdy przypadek wymaga analizy, nie automatycznej reguły.

Co nie jest w definicji: ustawowy próg „powyżej N użytkowników”, „powyżej Y GB danych” czy „Z godzin przestoju”. W praktyce organizacja powinna mieć kryteria wewnętrzne oparte o wpływ na usługi (RTO/RPO), wrażliwość danych, wymogi umowne i skutki dla innych podmiotów — z zastrzeżeniem, że ostateczna kwalifikacja może być kwestionowana przez organ.

Przykłady sytuacji wymagających analizy (nie automatycznej kwalifikacji): niedostępność systemu produkcyjnego wpływająca na dostawy sektorowe, wyciek danych klientów usługi krytycznej, kompromitacja kont uprzywilejowanych u operatora infrastruktury, atak na dostawcę MSP obsługującego wiele podmiotów wpisanych do Wykazu.

Powiązane: wpis do Wykazu i S46, SZBI — zarządzanie incydentami.

Wczesne ostrzeżenie — 24 godziny

Po stwierdzeniu (lub uzasadnionym podejrzeniu) incydentu poważnego podmiot przekazuje wczesne ostrzeżenie do CSIRT GOV przez System S46 w ciągu 24 godzin od momentu, w którym podmiot się o nim dowiedział — nie od pierwszego logu w SIEM, jeśli zespół jeszcze nie ocenił charakteru zdarzenia.

Wczesne ostrzeżenie może zawierać niepełne informacje — ustawa przewiduje aktualizację. Ważne elementy:

• wstępna ocena, że incydent może spełniać definicję poważną,
• dotknięte usługi/systemy,
• szacowany wpływ na odbiorców,
• działania natychmiastowe (izolacja, reset haseł, wycofanie tokenów),
• osoba kontaktowa 24/7.

Błąd: czekanie na „pełny raport forensyki” przed 24 h — termin liczy się od wiadomości podmiotu, nie od zamknięcia dochodzenia.

Praktyka: utrzymuj szablon wczesnego ostrzeżenia w języku polskim, wypełniany w 30–60 minut przez duty officer + kierownika ds. bezpieczeństwa informacji.

Zgłoszenie incydentu — 72 godziny

W 72 godziny od dowiedzenia się o incydencie poważnym składasz właściwe zgłoszenie w S46 — bardziej szczegółowe niż wczesne ostrzeżenie. Powinno rozwinąć:

• wektor ataku (jeśli znany) i timeline,
• zakres dotkniętych aktywów i danych,
• liczbę lub kategorię odbiorców usług dotkniętych skutkiem (bez fikcyjnych progów ustawowych),
• środki zaradcze i status usług,
• współpracę z innymi CSIRT / dostawcami,
• ocenę, czy incydent nadal spełnia definicję poważną.

Jeśli po 24 h okaże się, że zdarzenie nie było poważne, dokumentujesz wycofanie kwalifikacji wewnętrznie — ale jeśli wczesne ostrzeżenie poszło, skontaktuj się z CSIRT GOV zgodnie z komunikatem systemu (aktualizacja / zamknięcie).

Integracja z KSC i NIS2: proces 72 h powinien być ćwiczony — tabletop co najmniej raz rocznie, z udziałem kierownika (odpowiedzialność mimo delegacji).

Sprawozdanie końcowe — zasadniczo do miesiąca

Sprawozdanie końcowe składasz zasadniczo w terminie do miesiąca od zgłoszenia (o ile organ lub przepisy nie wskazują inaczej w konkretnym przypadku). Zawiera:

• root cause (w stopniu możliwym do ustalenia),
• pełny timeline i wpływ na usługi,
• środki naprawcze i zapobiegawcze,
• wnioski dla SZBI (aktualizacja analizy ryzyka),
• potwierdzenie zamknięcia incydentu lub statusu resztkowego.

To moment, w którym audytor lub organ oceni, czy podmiot realnie zarządza incydentami, czy tylko „klika w S46”. Powiązane dowody: logi, tickety, decyzje zarządu, komunikacja z odbiorcami usług (jeśli wymagana).

Checklist operacyjny

Przed incydentem (przygotowanie):

• [ ] Wpis do Wykazu i aktywne konto S46 (instrukcja wpisu)
• [ ] Playbook incydentu z ścieżką 24 h / 72 h / miesiąc
• [ ] Duty roster 24/7 z eskalacją do kierownika
• [ ] Szablony formularzy S46 (wczesne ostrzeżenie, zgłoszenie, końcowe)
• [ ] Lista krytycznych systemów i właścicieli
• [ ] Kanał prawny i komunikacji (PR) zatwierdzony przez zarząd
• [ ] Ćwiczenie tabletop z datą i uczestnikami

W godzinach 0–24:

• [ ] Potwierdź czy zdarzenie może być poważne (art. 2 pkt 7 — wpływ, nie progi liczbowe)
• [ ] Izoluj / ogranicz skutki
• [ ] Zbierz minimalny zestaw dowodów (timeline, scope)
• [ ] Złóż wczesne ostrzeżenie w S46
• [ ] Powiadom wewnętrznie zarząd i kierownika

W godzinach 24–72:

• [ ] Uzupełnij analizę techniczną i biznesową
• [ ] Złóż zgłoszenie w S46
• [ ] Dokumentuj decyzje (retencja logów, reset, restore)
• [ ] Koordynuj dostawców i ewentualne inne CSIRT

Do miesiąca:

• [ ] Sprawozdanie końcowe
• [ ] Aktualizacja analizy ryzyka i planu naprawczego
• [ ] Retrospektywa i aktualizacja playbooka

Rola kierownika i S46

Kierownik ds. bezpieczeństwa informacji odpowiada za proces — delegowanie na SOC nie zdejmuje odpowiedzialności. Kierownik powinien mieć szkolenie roczne (udokumentowane) i być dostępny w eskalacji 24 h.

System S46 to obowiązkowy kanał po wpisie — e-mail do CSIRT nie zastępuje zgłoszenia w platformie. Dostęp uzyskujesz po wpisie do Wykazu.

Sam SIEM lub EDR nie spełniają obowiązku zgłoszenia — narzędzie wykrywa; podmiot ocenia i zgłasza w terminie. Wdrożenie monitoringu bez procedury S46 to luka organizacyjna, nie zgodność.

W praktyce warto rozdzielić dwa zegary: zegar operacyjny (containment, przywrócenie usług) i zegar regulacyjny (24 h / 72 h / miesiąc). Zespół techniczny może walczyć z atakiem, ale równolegle kierownik lub IRT lead musi monitorować, czy próg wiadomości o powadze już nastąpił — inaczej 24 h mija w trakcie „jeszcze tylko restore backupu”.

FAQ

Czy muszę zgłaszać każdy ransomware?

Nie automatycznie — oceniasz wpływ wg art. 2 pkt 7. Ransomware na stanowisku bez wpływu na usługi może nie być poważny; na systemie produkcyjnym sektorowym — zwykle wymaga ścieżki 24/72 h.

Czy są ustawowe progi „X użytkowników”?

Nie w art. 2 pkt 7. Unikaj wewnętrznych polityk, które obiecują „poniżej 1000 klientów nie zgłaszamy” — to ryzyko prawne.

Co liczy się jako moment „dowiedzenia się”?

Moment, w którym podmiot (reprezentowany przez personel odpowiedzialny) mógł rozsądnie uznać powagę — często decyzja kierownika lub IRT po wstępnej analizie, nie pierwszy alert automatyczny bez weryfikacji.

Czy podmiot ważny też zgłasza w 24/72 h?

Tak — obowiązek dotyczy podmiotów wpisanych do Wykazu, kluczowych i ważnych.

Czy DevSentinel zgłasza incydenty za klienta?

Nie — wspieramy procedury, playbooki i technologię; zgłoszenie w S46 składa uprawniony przedstawiciel podmiotu. DevSentinel nie gwarantuje zgodności.

Przygotuj proces zanim będzie potrzebny — cyberbezpieczeństwo i NIS2.