NIS2: zgłaszanie incydentów w 24h, 72h i miesiąc — jak data center pomaga zmieścić się w terminach

Od 3 kwietnia 2026 roku polska nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (KSC), wdrażająca dyrektywę NIS2, obowiązuje już realnie. Wśród nowych obowiązków najwięcej zamieszania powoduje nie sam katalog wymaganych zabezpieczeń, ale harmonogram zgłaszania poważnych incydentów: zegar zaczyna tykać od momentu wykrycia zdarzenia, nie od chwili, w której zespół IT ma pełen obraz sytuacji. Dla podmiotów kluczowych i ważnych oznacza to konieczność przebudowy procesu reagowania na incydenty pod ścisłe terminy ustawowe.

W tym wpisie pokazujemy, jakie dokładnie są terminy, jak je rozumieć w praktyce oraz co partner data center — taki jak Sprint Data Center — może realnie wziąć na siebie, żeby zespół IT nie musiał gonić pierwszej godziny.

Trzy terminy, które trzeba znać na pamięć

Nowelizacja KSC implementująca NIS2 ustala kaskadę trzech zgłoszeń do właściwego CSIRT (sektorowego lub krajowego — CSIRT NASK, CSIRT GOV lub CSIRT MON, w zależności od podmiotu):

• 24 godziny od wykrycia — wstępne powiadomienie. Krótka informacja: doszło do poważnego incydentu, dotyczy systemu X, podejrzewamy wektor Y, na razie nie znamy pełnego zakresu.
• 72 godziny od wykrycia — pełne zgłoszenie. Powinno zawierać ocenę szkód, wstępną klasyfikację (np. atak złośliwego oprogramowania, naruszenie poufności danych), opis działań naprawczych i wskazanie, czy incydent ma charakter transgraniczny.
• miesiąc od wykrycia — raport końcowy. Pełen opis przyczyn, podjętych środków, wniosków i ewentualnych działań długoterminowych.

Liczy się moment wykrycia, a nie moment, w którym ktoś z zarządu zatwierdził treść powiadomienia. Jeśli SOC zauważa anomalię w sobotę o 22:30, niedziela rano jest już połową okna.

Co kwalifikuje się jako „poważny incydent"

Ustawa wskazuje cechy poważnego incydentu (m.in. wpływ na ciągłość świadczonej usługi, naruszenie poufności lub integralności istotnych danych, znaczące straty finansowe). W praktyce każda firma będzie musiała ustalić własny próg na podstawie rozporządzeń wykonawczych i wytycznych branżowych — i ten próg powinien być wpisany w procedurę SZBI, nie ustalany na kolanie w trakcie incydentu.

Stawką są kary administracyjne, których nakładanie ruszy po 3 kwietnia 2028 — do 10 mln euro lub 2% obrotu dla podmiotów kluczowych i do 7 mln euro lub 1,4% obrotu dla ważnych, plus osobista odpowiedzialność członków zarządu.

Dlaczego ten harmonogram jest trudny w praktyce

Doświadczenie z RODO (72h na powiadomienie UODO o naruszeniu danych) pokazało, że teoretycznie luźne okno potrafi być w praktyce ciasne. Trzy najczęstsze powody:

1. Wykrycie ≠ pewność. Pierwsze sygnały zwykle są niejednoznaczne (anomalia w logach, wzrost ruchu, pojedynczy alert SIEM). Zegar tyka, ale zespół jeszcze nie wie, czy to false positive.
2. Wewnętrzne zespoły IT rzadko pracują 24/7. Większość polskich firm średniej wielkości ma jednego administratora lub niewielki dział IT, który po godzinach reaguje „na telefon". To utrudnia spełnienie 24-godzinnego okna w nocy i w weekend.
3. Koordynacja z dostawcami trwa. Jeśli incydent dotyczy serwerów w kolokacji albo łącz operatorskich, część odpowiedzi technicznej leży po stronie partnera infrastruktury. Bez umownie określonego trybu kontaktu można stracić cenne godziny na samo dotarcie do właściwego inżyniera.

Jak partner data center realnie skraca czas reakcji

Tu pojawia się rola operatora data center jako uzupełnienia wewnętrznego SZBI, a nie jego substytutu. Kilka konkretnych mechanizmów dostępnych w ramach kolokacji w Sprint Data Center:

• Monitoring 24/7/365 + wsparcie techniczne dostępne całą dobę. Anomalie sieciowe i zdarzenia na poziomie warstwy fizycznej widać po stronie operatora w czasie rzeczywistym — to skraca okres pomiędzy wystąpieniem a wykryciem.
• Ochrona AntyDDoS. Atak wolumetryczny, który bez filtracji od razu generowałby alert „poważnego incydentu", często jest tłumiony zanim w ogóle zostanie zauważony przez aplikację — co zmniejsza liczbę zgłoszeń kwalifikowanych jako poważne.
• Redundancja energetyczna i klimatyzacyjna. Awaria zasilania w pojedynczym centrum danych może w warunkach NIS2 zostać zaklasyfikowana jako poważny incydent dotyczący dostępności. Architektury z podwójnym zasilaniem, UPS i agregatem ograniczają to ryzyko u źródła.
• Sformalizowane procesy komunikacyjne. Umowa kolokacji + umowa powierzenia (DPA) + dane kontaktowe do dyżurnego inżyniera = szybkie wejście w tryb incident response, zamiast szukania właściwej osoby w piątek po godzinach. Warto sprawdzić pakiety administracyjne i usługi dodatkowe jako uzupełnienie kontraktu.
• Backup i odtwarzanie poza lokacją. Skuteczna procedura backupu poza główną serwerownią to często różnica między „zgłaszamy ransomware jako poważny incydent z naruszeniem dostępności" a „odtworzyliśmy usługę w godzinę, raportujemy tylko ślad próby ataku".

Co istotne — żaden dostawca infrastruktury nie weźmie na siebie obowiązku zgłoszeniowego. To zawsze odpowiedzialność podmiotu kluczowego lub ważnego. Partner data center skraca natomiast czas między zdarzeniem a chwilą, w której wiesz wystarczająco dużo, żeby kliknąć „wyślij" do CSIRT.

Co warto zrobić jeszcze w tym roku

Do 3 października 2026 r. trzeba wpisać się do wykazu podmiotów kluczowych i ważnych. Do 3 kwietnia 2027 r. — wdrożyć środki zarządzania ryzykiem (w tym SZBI). Czas na uporządkowanie procesu incident response jest teraz:

1. Mapuj umowy z dostawcami — kto ma jakie SLA na komunikację w nocy, w weekend, w święto?
2. Zaktualizuj playbook incydentowy — czy uwzględnia 24/72/miesiąc i czy ma role przypisane do osób, a nie do działów?
3. Przetestuj wzór formularza CSIRT — wstępne 24h nie wymaga pełnego raportu, ale zespół powinien wiedzieć, jaki minimalny zestaw pól ma wysłać.
4. Sprawdź zewnętrzne źródła wykrywania — monitoring po stronie data center, MSSP, dostawcy poczty. Im więcej oczu, tym krótszy MTTD (mean time to detect).

Podsumowanie

NIS2 nie wymusza posiadania własnego SOC ani bezgranicznego budżetu. Wymusza natomiast proces — taki, który zmieści się w 24-godzinnym oknie nawet w niedzielę wieczorem. Najprostsza droga to oprzeć część warstwy infrastrukturalnej na partnerze, który już operuje 24/7 i ma kontraktowe procesy reagowania.

Jeśli rozważasz przeniesienie serwerów do polskiego centrum danych z monitoringiem 24/7/365, wsparciem technicznym dostępnym całą dobę i ochroną AntyDDoS — sprawdź ofertę kolokacji w Sprint Data Center jako element architektury NIS2-ready.

FAQ – najczęściej zadawane pytania o zgłaszanie incydentów w NIS2

Czy 24 godziny liczy się od momentu rozpoczęcia incydentu czy od jego wykrycia?

Od wykrycia. Jeśli atak rozpoczął się w środę o 3:00, ale zespół zauważył anomalię dopiero w czwartek o 14:00, zegar 24-godzinny startuje w czwartek o 14:00. Dlatego skrócenie MTTD (mean time to detect) jest tak ważne — każda godzina szybszego wykrycia to godzina więcej na przygotowanie zgłoszenia.

Czy mogę zlecić zgłoszenie do CSIRT zewnętrznemu partnerowi (data center, MSSP)?

Sam obowiązek zgłoszenia leży po stronie podmiotu kluczowego/ważnego i nie da się go formalnie scedować. Można jednak zlecić przygotowanie treści zgłoszenia, koordynację techniczną i kontakt operacyjny z CSIRT zewnętrznemu zespołowi — pod warunkiem, że odpowiedzialność umowna i procedura zatwierdzenia są jasno opisane.

Co się stanie, jeśli przegapię 24-godzinne okno?

Same opóźnienia są przedmiotem oceny CSIRT i organu nadzoru. Administracyjne kary za naruszenia obowiązków NIS2 ruszają od 3 kwietnia 2028 r. — ale już teraz opóźnione zgłoszenie wpłynie na ocenę poziomu dojrzałości procesu i może być argumentem za nałożeniem dotkliwszej kary po wejściu w życie reżimu sankcyjnego.

Czy każdy incydent trzeba zgłaszać do CSIRT?

Nie — tylko incydenty poważne w rozumieniu ustawy (m.in. te, które mają znaczący wpływ na ciągłość usługi, integralność lub poufność istotnych danych, albo powodują znaczące straty). Każdy podmiot powinien mieć w SZBI własną politykę klasyfikacji, opartą na rozporządzeniach wykonawczych do KSC i wytycznych branżowych.

Czy ochrona AntyDDoS u operatora data center zmniejsza obowiązki sprawozdawcze?

Filtracja u operatora najczęściej sprawia, że atak wolumetryczny w ogóle nie powoduje przerwy w świadczeniu usługi — a więc nie spełnia kryteriów „poważnego incydentu" dotyczącego dostępności. Sama próba ataku zostaje zalogowana, ale obowiązek zgłoszenia do CSIRT nie powstaje. To jeden z konkretnych przykładów, w którym warstwa infrastrukturalna obniża obciążenie regulacyjne.