W OT incydent zaczyna się jako awaria – czy zbierzesz dane do zgłoszenia w 24 i 72 godziny?

Druga w nocy, staje linia rozlewnicza. Dyżurny automatyk restartuje sterownik i linia rusza, ale po godzinie staje znowu. Wpis trafia do systemu utrzymania ruchu jako awaria. Rano ktoś z IT zauważa, że logikę sterownika zmieniono zdalnie. Od którego momentu liczyć teraz 24 godziny?

Terminy zgłoszenia zna dziś większość zespołów bezpieczeństwa. W zakładzie produkcyjnym kłopot polega na czym innym. Pierwsza osoba, która widzi incydent, często nie pracuje w bezpieczeństwie i nie nazywa go incydentem.

Co mówi ustawa

Podmiot kluczowy lub ważny ma trzy terminy (art. 11 ust. 1 pkt 4–4c ustawy o KSC):

• wczesne ostrzeżenie o incydencie poważnym najpóźniej w ciągu 24 godzin od jego wykrycia,
• zgłoszenie najpóźniej w ciągu 72 godzin od wykrycia,
• sprawozdanie końcowe w ciągu miesiąca od zgłoszenia.

Jeśli obsługa incydentu wciąż trwa, w terminie sprawozdania końcowego składa się sprawozdanie z postępu. Zgłoszenia idą przez S46 do CSIRT sektorowego. Dopóki CSIRT sektorowy nie ogłosi gotowości, trafiają do CSIRT MON, NASK albo GOV. Podmioty, które spełniały kryteria w dniu wejścia w życie nowelizacji, muszą wdrożyć te obowiązki do 3 kwietnia 2027 r.

Dla OT ważna jest definicja. Incydent to zdarzenie, które ma lub może mieć niekorzystny wpływ na bezpieczeństwo systemów informacyjnych (art. 2 pkt 5). O ataku nie ma tu mowy. Wczesne ostrzeżenie zawiera wręcz informację, czy incydent mógł zostać spowodowany działaniem bezprawnym lub złośliwym. Incydentem poważnym może więc być także błąd konfiguracji SCADA albo awaria sieci przemysłowej.

Awaria, której nikt nie przekazał dalej

Ustawa liczy czas od wykrycia i nie mówi, który dział ma wykryć incydent. Jeśli zdarzenie przez kilka godzin leży w rejestrze awarii, trudno będzie potem bronić tezy, że zegar ruszył dopiero wtedy, gdy sprawa trafiła do SOC.

Potrzebna jest więc prosta reguła. Każdy nieplanowany postój, którego przyczyną może być system informacyjny (sterownik, HMI, sieć, SCADA), od razu trafia do osoby, która decyduje o uznaniu incydentu za poważny. W zespole reagowania musi być ktoś z OT. Trzeba też z góry ustalić, kiedy wolno zatrzymać proces technologiczny. W IT odcięcie hosta to rutyna. W OT ta sama decyzja może zatrzymać produkcję albo narazić ludzi.

Progi czyli co sprawdzić już teraz

Obowiązujące rozporządzenie z 2018 r. określa progi dla sześciu sektorów. Produkcja, żywność, chemikalia czy gospodarka odpadami dostaną je dopiero w nowym rozporządzeniu. Jego projekt był konsultowany do końca września, a stare przepisy wygasają najpóźniej 3 kwietnia 2027 r.

Progi dotyczą liczby dotkniętych użytkowników, czasu zakłócenia, zasięgu geograficznego i strat. W projekcie dla części podsektorów energii pojawia się próg 2 mln zł strat. Projekt przewiduje też kryterium zaszyfrowania danych z żądaniem okupu.

Warto przeczytać część dotyczącą własnego sektora i zadać sobie jedno pytanie: czy w ciągu kilku godzin od postoju linii umiemy podać każdą z tych liczb? Ilu odbiorców dotknie wstrzymana dostawa, jaki jest zasięg, ile wyniosą straty?

Te same dane są potrzebne w zgłoszeniu składanym w ciągu 72 godzin: wpływ na usługę, liczba użytkowników, zasięg, skutki dla innych podmiotów, przyczyny, przebieg i podjęte działania. Jeśli w grę wchodzą dane osobowe, dochodzi odrębne zawiadomienie Prezesa UODO z art. 33 RODO. Jego termin liczy się od stwierdzenia naruszenia.

Od czego zacząć

1. Wskazać, kto decyduje o uznaniu incydentu za poważny, kto go zastępuje i jak dociera do niego informacja z utrzymania ruchu.
2. Dodać do rejestru awarii OT jedno pole: czy przyczyną może być system informacyjny.
3. Sprawdzić w projekcie progi dla swojego sektora i ustalić, kto dostarczy każdą liczbę, także po stronie finansów.
4. Zapisać w umowach z integratorem i dostawcami OT, w jakim czasie przekazują logi i informacje o zdarzeniu.
5. Przećwiczyć pierwsze 24 godziny na scenariuszu, który zaczyna się od zwykłej awarii.

Od pierwszego dnia warto też zapisywać godzinę wykrycia i godzinę decyzji o kwalifikacji, razem z uzasadnieniem. Bez tych dwóch zapisów trudno później wykazać, że terminy zostały dotrzymane.

Źródła

• Ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, Dz.U. 2026 poz. 252 (art. 2 pkt 5 i 7, art. 11 ust. 1 pkt 4–4c, art. 12, art. 12b): https://eli.gov.pl/eli/DU/2026/252/ogl/pol
• Ustawa o krajowym systemie cyberbezpieczeństwa, t.j. Dz.U. 2026 poz. 20, z późn. zm.: https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20260000020
• Ministerstwo Cyfryzacji, Nowelizacja ustawy o KSC – obowiązki podmiotów kluczowych i ważnych: https://www.gov.pl/web/cyfryzacja/nowelizacja-ustawy-o-krajowym-systemie-cyberbezpieczenstwa-ksc—obowiazki-podmiotow-kluczowych-i-waznych
• Kancelaria Prezesa Rady Ministrów, Projekt rozporządzenia Rady Ministrów w sprawie progów uznania incydentu za poważny: https://www.gov.pl/web/premier/projekt-rozporzadzenia-rady-ministrow-w-sprawie-progow-uznania-incydentu-za-powazny
• Rozporządzenie Rady Ministrów z 31 października 2018 r. w sprawie progów uznania incydentu za poważny, Dz.U. 2018 poz. 2180
• Dyrektywa (UE) 2022/2555 (NIS2), art. 23: https://eur-lex.europa.eu/eli/dir/2022/2555/oj
• Rozporządzenie (UE) 2016/679 (RODO), art. 33: https://eur-lex.europa.eu/eli/reg/2016/679/oj

Grzegorz Bielecki

vCISO, vCIO i certyfikowany ekspert ds. bezpieczeństwa (CISM, CDPSE, CEH, ISO 27001 Lead Auditor). Od ponad 15 lat wspiera głównie sektor finansowy w budowaniu odporności cyfrowej. Architekt wdrożeń DORA, NIS2\UKSC oraz norm ISO 27001 (SZBI) i ISO 22301 (SZCD). Posiada doświadczenie w projektach zgodności IT przy pozyskiwaniu licencji KIP KNF. Członek ISSA Polska.