Obowiązki zgłaszania incydentów NIS2: wczesne ostrzeżenie w ciągu 24 godzin w praktyce

Obowiązki zgłoszeniowe wynikające z NIS2 zobowiązują objęte nimi podmioty do zgłaszania poważnych incydentów bezpieczeństwa w stopniowanej kaskadzie terminów: wczesne ostrzeżenie w ciągu 24 godzin, pełne zgłoszenie w ciągu 72 godzin i sprawozdanie końcowe w ciągu miesiąca, każdorazowo do właściwego organu lub krajowego zespołu CSIRT. Ta kaskada jest operacyjnym rdzeniem, od którego zależy zdolność organizacji do zgłaszania incydentów.

• Trzy terminy, jeden wyzwalacz: 24 godziny na wczesne ostrzeżenie, 72 godziny na pełne zgłoszenie, miesiąc na sprawozdanie końcowe, liczone od uzyskania wiedzy o incydencie, a nie od jego początku.
• Jeden kanał odbiorcy: właściwy organ krajowy lub CSIRT (w Austrii właściwy CSIRT, dla przedsiębiorstw obecnie CERT.at, pod nadzorem Federalnego Urzędu ds. Cyberbezpieczeństwa podległego BMI; w Niemczech BSI).
• Prawdziwym wąskim gardłem nie jest formularz, lecz wykrywanie: jeśli zauważysz incydent za późno, wyścig z 24-godzinnym zegarem jest już przegrany.

Dlaczego istnieje kaskada terminów

NIS2 zastępuje dawną dyrektywę NIS i znacznie rozszerza zakres stosowania. W Niemczech liczba objętych przedsiębiorstw rośnie według szacunków BSI z około 4500 do około 29 500; w Austrii objętych jest około 4000 przedsiębiorstw z 18 sektorów. Im szerszy zakres stosowania, tym większe znaczenie sprawnie działającego systemu zgłaszania: na podstawie napływających zgłoszeń organy budują obraz sytuacji, ostrzegają inne podmioty i koordynują działania przy incydentach transgranicznych.

Stopniowana logika odpowiada na realny konflikt. W pierwszych godzinach incydentu bezpieczeństwa stan faktów jest niejasny, bo pełnej analizy śledczej jeszcze nie ma. Jednocześnie organy potrzebują wczesnego sygnału. Kaskada rozwiązuje ten problem, wymagając najpierw niewiele, ale szybko (wczesne ostrzeżenie), a merytoryczną głębię uzupełniając w ciągu 72 godzin i miesiąca.

Kluczowa i często pomijana kwestia: terminy biegną od uzyskania wiedzy (awareness) o poważnym incydencie, a nie od momentu, w którym atak faktycznie się rozpoczął. To przesuwa ryzyko compliance na wcześniejszy etap, do wykrywania. Właśnie tu pojawia się strukturalna asymetria, którą organizacje odpowiedzialne za obronę znają w 2026 roku: atakujący działają asynchronicznie i tolerują ponowne próby, podczas gdy obrońcy są związani 24-godzinnym wczesnym ostrzeżeniem.

Trzy etapy w szczegółach: termin, treść, odbiorca

Poniższa tabela podsumowuje kaskadę NIS2. Służy jako orientacja; dokładne zasady wynikają z odpowiedniej krajowej ustawy wdrażającej.

Ważne: jeśli w chwili składania sprawozdania miesięcznego incydent nadal trwa, zamiast sprawozdania końcowego składa się najpierw sprawozdanie z postępów; ostateczne sprawozdanie następuje po zakończeniu obsługi incydentu.

Kto jest odbiorcą i co się zmienia w Niemczech, Austrii i Szwajcarii?

NIS2 jest dyrektywą UE i wywołuje konkretne skutki dopiero poprzez krajowe ustawy wdrażające. W praktyce w regionie DACH (Niemcy, Austria, Szwajcaria) oznacza to różnych adresatów i różne harmonogramy:

• Niemcy: ustawa wdrażająca NIS2 (NIS2UmsuCG) obowiązuje od 6 grudnia 2025 r., bez okresu przejściowego. Właściwy jest BSI; portal rejestracyjny uruchomiono na początku 2026 roku. BSI zapowiedział, że będzie aktywnie identyfikować niezarejestrowane podmioty.
• Austria: ustawa NISG 2026 została ogłoszona 23 grudnia 2025 r. i obowiązuje od 1 października 2026 r. Podmioty kluczowe i ważne zgłaszają poważne incydenty cyberbezpieczeństwa zgodnie z § 34 ust. 1 do właściwego dla nich sektorowego CSIRT lub, jeśli takiego nie ma, do krajowego CSIRT. Dopóki sektorowe zespoły CSIRT nie zostaną upoważnione, zgłoszenia przyjmuje CERT.at jako krajowy CSIRT za pośrednictwem platformy zgłoszeniowej USP; dla administracji publicznej właściwy jest GovCERT (§ 8 ust. 4). Organem nadzorczym jest Federalny Urząd ds. Cyberbezpieczeństwa, bezpośrednio podległy Federalnemu Ministerstwu Spraw Wewnętrznych, czyli BMI (§ 3a). Podmioty muszą się zarejestrować w ciągu trzech miesięcy od wejścia ustawy w życie (§ 29 ust. 3). Ustawa opiera się na samodzielnej kwalifikacji i samodeklaracji objętych nią podmiotów.
• Szwajcaria (dla porównania): Szwajcaria nie jest związana NIS2, ale ma równoległy reżim w postaci znowelizowanej ustawy o bezpieczeństwie informacji. Od 1 kwietnia 2025 r. operatorzy infrastruktury krytycznej muszą zgłaszać poważne cyberataki do Federalnego Urzędu ds. Cyberbezpieczeństwa (BACS) w ciągu 24 godzin; w pierwszych sześciu miesiącach wpłynęły tam 164 zgłoszenia.

Dla firm działających w kilku krajach regionu DACH oznacza to niewygodną rzeczywistość: kilka kanałów zgłoszeń, kilka organów, częściowo różne progi. Do tego dochodzą kolejne reżimy z własną, ale strukturalnie podobną logiką zgłoszeń. Unijny akt o cyberodporności obowiązuje we wszystkich branżach w odniesieniu do produktów z elementami cyfrowymi. Producenci muszą od 11 września 2026 r. zgłaszać aktywnie wykorzystywane podatności i poważne incydenty bezpieczeństwa dotyczące ich produktów: wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin, za każdym razem do właściwego CSIRT za pośrednictwem jednolitej platformy zgłoszeniowej prowadzonej przez ENISA. W sektorze finansowym obowiązuje DORA, które dla incydentów związanych z ICT zaklasyfikowanych jako poważne przewiduje własne, stopniowane zgłaszanie incydentów, ze wstępnym zgłoszeniem w ciągu czterech godzin od klasyfikacji.

Konkretny przykład: 24-godzinny zegar tyka

Średniej wielkości producent maszyn (według NIS2 prawdopodobnie „podmiot ważny”) zauważa w piątek o 22:14 nietypowe zdarzenia uwierzytelniania. W 2026 roku wykrywanie jest typowym wąskim gardłem: badania pokazują, że duża część wykryć ma charakter „malware-free”, bo atakujący logują się przy użyciu ważnych danych uwierzytelniających, zamiast się włamywać, a do tego stali się drastycznie szybsi (średni breakout time 29 minut w 2025 roku, najszybsza zaobserwowana wartość 27 sekund). Spóźnione wykrycie, albo jego brak, bo w weekend nikt nie dyżuruje, kosztuje tu godziny, których później zabraknie przy 24-godzinnym terminie.

Uproszczony przebieg:

```
22:14 Wiedza o incydencie: wykryto anomalne logowania (T0, start biegu terminu)
→ zegar 24 h biegnie do soboty 22:14
23:30 Wstępna ocena: podejrzenie przejętej tożsamości, poważny?
Sob 03:00 Wczesne ostrzeżenie do organu/CSIRT (w ciągu 24 h):
"Poważny incydent, podejrzenie złośliwego działania,
skutek transgraniczny obecnie niewykluczony"
→ zegar 72 h biegnie do poniedziałku 22:14
Pon 18:00 Pełne zgłoszenie (w ciągu 72 h):
waga, objęte systemy, wskaźniki, pierwsze działania
+1 mies. Sprawozdanie końcowe: analiza przyczyn, działania naprawcze, wnioski
```

Kluczowe jest to, że wczesne ostrzeżenie trzeba było wysłać w nocy i w weekend. Bez zdolności wykrywania 24/7, czy to przez własny SOC, dostawcę MDR, czy triaż wspierany przez AI, dotrzymanie 24-godzinnego terminu byłoby w praktyce niemożliwe.

Jak pomaga proces lub agent i gdzie leży granica

Narzędzia SOC wspierane przez AI działają dokładnie w trzech newralgicznych punktach kaskady: wykrywanie, dokumentacja, śledzenie terminów. We wdrożeniach produkcyjnych udokumentowano wyraźny wzrost efektywności w triażu na poziomie 1: dostawcy raportują redukcję alertów obsługiwanych ręcznie o 70–90 procent; niektóre narzędzia podają czas analizy rzędu kilku minut wobec około 25 minut przy pracy ręcznej. Dla obowiązku zgłaszania ma to znaczenie, bo szybsze i bardziej niezawodne wykrywanie uruchamia 24-godzinny zegar wcześniej i w bardziej uporządkowany sposób.

Przydatne funkcje wsparcia na kolejnych etapach kaskady:

• Wykrywanie: wzbogacanie alertów, korelacja wielu źródeł, deduplikacja i priorytetyzacja, aby poważny incydent w ogóle został w porę rozpoznany jako taki.
• Dokumentacja: automatyczne, odporne na manipulacje rejestrowanie znaczników czasu, objętych systemów, podjętych kroków i wskaźników naruszenia bezpieczeństwa jako podstawa zgłoszenia 72-godzinnego i sprawozdania końcowego.
• Śledzenie terminów: workflow obsługi incydentu, który od momentu uzyskania wiedzy (awareness) odlicza terminy 24 h, 72 h i miesięczny, uruchamia eskalacje i utrzymuje widoczny status (wczesne ostrzeżenie wysłane / zgłoszenie otwarte / sprawozdanie do złożenia).

Granica pozostaje jednak jasna: według stanu na 2026 rok żaden gotowy do produkcji SOC nie działa autonomicznie bez ludzkiej kontroli w krytycznych punktach decyzyjnych. Dla obowiązku zgłaszania szczególnie istotne są dwa ryzyka. Po pierwsze halucynowana atrybucja incydentów: duże modele językowe generują brzmiące wiarygodnie, ale błędne przypisania do grup sprawców lub regionów geograficznych, a fałszywa informacja przekazana organowi waży bardzo dużo. Po drugie audytowalność: NIS2 wymaga dowodów procesu decyzyjnego; wnioski generowane przez AI muszą pozostać zrozumiałe i weryfikowalne. Dlatego ocena, czy incydent jest poważny, zatwierdzenie treści i komunikacja zewnętrzna z organem pozostają w gestii człowieka. Agent przyspiesza i dokumentuje, ale nie podejmuje decyzji i niczego samodzielnie nie zgłasza na zewnątrz.

Praktyczna wskazówka z codzienności zespołów obrony: logi, maile phishingowe i ruch rozpoznawczy mogą celowo zawierać treści typu prompt injection, które manipulują LLM obrońcy. Jeśli włączasz AI w proces zgłaszania, poznaj ochronę przed prompt injection używanego narzędzia i zleć jej przetestowanie.

Praktyczne przygotowanie w pięciu punktach

1. Zdefiniuj moment uzyskania wiedzy: kiedy incydent uznaje się za „znany”? Ten moment uruchamia wszystkie terminy i musi być jednoznacznie udokumentowany.
2. Zapewnij wykrywanie 24/7: własny SOC, dostawca MDR lub triaż wspierany przez AI: bez ciągłego wykrywania 24-godzinnego terminu nie da się dotrzymać.
3. Wyjaśnij z wyprzedzeniem kanał zgłoszeń: rejestracja we właściwym organie, dane dostępowe do portalu zgłoszeń, wyznaczone osoby odpowiedzialne.
4. Workflow incydentu ze śledzeniem terminów: proces, który odwzorowuje trzy etapy i automatycznie uruchamia eskalacje.
5. Przetestuj proces zgłaszania: ćwiczenia sztabowe (tabletop), które realistycznie odgrywają 24-godzinne wczesne ostrzeżenie, łącznie ze scenariuszem nocnym i weekendowym.

Dla agencji i decydentów B2B

Dla agencji marketingowych i dostawców usług B2B obowiązek zgłaszania z NIS2 ma znaczenie z dwóch powodów. Po pierwsze jako kwestia łańcucha dostaw: jeśli pracujesz dla podmiotu kluczowego lub ważnego, przez wymogi umowne często w praktyce podlegasz jego oczekiwaniom w zakresie bezpieczeństwa i zgłaszania, a uporządkowane procesy wykrywania i dokumentacji stają się kryterium wyboru w przetargach. Po drugie jako obszar treści i doradztwa: kaskada terminów wymaga wyjaśnienia, ma duże znaczenie w wyszukiwaniu i jest naturalnym punktem zaczepienia dla rzetelnych treści, które warto cytować. Blck Alpaca projektuje w tym celu wspierane przez AI bazy wiedzy i moduły procesowe, które łączą wykrywanie, dokumentację i śledzenie terminów, jako solidną podstawę, a nie zamiennik ludzkiej odpowiedzialności w procesie zgłaszania.

Uwaga: ten artykuł służy orientacji merytorycznej i nie stanowi porady prawnej. Konkretne progi, klasyfikacje i procedury według NIS2, NIS2UmsuCG, NISG 2026, CRA lub DORA należy wyjaśnić z wykwalifikowanymi doradcami w danej jurysdykcji.