Od alertu do decyzji. NIS2 po samorejestracji: co teraz?

Samorejestracja za nami. Firma znalazła się w Wykazie KSC, potwierdzenie zostało zapisane, temat na chwilę zniknął z kalendarza zarządu. Gratulacje - teraz dopiero zaczyna się prawdziwa zabawa 😊

A potem ktoś zadaje pytanie: „Dobrze, ale co właściwie mamy teraz zrobić?”.

Najlepiej odpowiedzieć na nie innym pytaniem: czy gdy jutro pojawi się poważny alert, firma będzie wiedziała, kto ma podjąć decyzję i na jakiej podstawie?

Bo właśnie pomiędzy „system coś wykrył” a „wiemy, co robimy” rozgrywa się duża część praktycznego wdrożenia NIS2. I mamy wrażenie, że trochę ostatnio o tym zapominamy.

Wpis jest. Teraz potrzebny jest działający system

W Polsce wymagania NIS2 wdraża znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa. Dla podmiotów, które spełniały ustawowe kryteria już 3 kwietnia 2026 r., termin samorejestracji upłynął 3 października. Kolejny ważny termin to 3 kwietnia 2027 r., czyli koniec okresu na wdrożenie nowych obowiązków i rozpoczęcie korzystania z systemu S46. Data wpisu nie uruchamia nowego, pełnego roku na przygotowania.

Co to oznacza dla średniej lub dużej firmy?

Trzeba połączyć zarządzanie ryzykiem, zabezpieczenia, obsługę incydentów, ciągłość działania i współpracę z dostawcami w jeden działający mechanizm. Ministerstwo Cyfryzacji wskazuje te obszary jako elementy przygotowania organizacji do realizacji obowiązków KSC.

Najłatwiej sprawdzić ten mechanizm, przechodząc drogę pojedynczego alertu.

1. Alert musi do kogoś trafić

Narzędzie bezpieczeństwa wykryło podejrzaną aktywność. Pracownik zgłosił nietypową wiadomość. Dostawca poinformował o problemie z usługą.

Na tym etapie firma ma sygnał. Jeszcze nie pełny obraz sytuacji.

Pierwsza rzecz do ustalenia jest bardzo przyziemna: kto ten sygnał odbierze? Skrzynka „bezpieczenstwo@” niewiele pomoże, jeśli nikt nie sprawdza jej po godzinach. Numer do administratora też nie rozwiązuje wszystkiego, jeżeli administrator jest właśnie na urlopie. A ustawodawca, chce zobaczyć, że Wy się staracie.

Potrzebne są uzgodnione kanały zgłoszeń, osoby odpowiedzialne, zastępstwa i zasady eskalacji. Również wtedy, gdy problem pojawia się poza godzinami pracy.

To dobry przykład różnicy między dokumentem a wdrożeniem. W dokumencie jest adres kontaktowy. We wdrożeniu ktoś odbiera zgłoszenie i wie, co zrobić dalej.

2. Techniczny komunikat trzeba przetłumaczyć na skutki dla firmy

„Podejrzane logowanie na konto uprzywilejowane” brzmi jak temat dla IT.

Ale czy chodzi o konto, z którego można zmienić konfigurację usługi? Uzyskać dostęp do danych klientów? Zatrzymać pracę magazynu? Wyłączyć system obsługujący zamówienia?

Bez tej wiedzy trudno ustalić priorytet. Zobaczymy więc jak to można zrobić w praktyce na przykładzie naszego klienta.

W materiałach projektowych dla firmy świadczącej hosting i rejestrację domen, punktem wyjścia było powiązanie usług, systemów i dostępów z ryzykiem oraz procedurą incydentową. Taki sposób pracy pozwala wyjść poza sam komunikat narzędzia i zapytać: co ta aktywność może oznaczać dla świadczonej usługi?

W średniej lub dużej organizacji ta sama logika obejmuje więcej zależności. System może być utrzymywany przez centralne IT, wykorzystywany przez kilka spółek i wspierany przez zewnętrznego dostawcę.

Dlatego lista serwerów to dopiero początek. Potrzebna jest również odpowiedź na pytanie: jaki proces biznesowy zależy od każdego z tych systemów i kto odpowiada za ten proces?

3. Ktoś musi mieć prawo podjąć decyzję

Specjalista potwierdza, że zagrożenie jest realne. Zaleca ograniczenie dostępu lub czasowe wyłączenie części usługi.

I wtedy zaczyna się druga rozmowa.

Czy można zatrzymać obsługę zamówień? Kto akceptuje przerwę? Czy dostawca może samodzielnie zablokować konto? Kiedy trzeba włączyć zarząd?

Takich zasad nie warto ustalać dopiero podczas incydentu.

Tu przydaje się wątek z projektu dla firmy produkcyjnej, dla której tworzyliśmy rekomendacje wdrożeniowe: obok Audytu 0 w zakresie współpracy znalazł się model podziału odpowiedzialności, czyli RACI. Jego praktyczna wartość polega na ustaleniu, kto wykonuje zadanie, kto za nie odpowiada, z kim trzeba się skonsultować i kogo poinformować.

Skrót może brzmieć korporacyjnie. Pytania, na które odpowiada, są bardzo konkretne:

Kto może odłączyć system? Kto ocenia wpływ na działalność? Kto zatwierdza komunikację? Kto pilnuje zgłoszenia do CSIRT?

Dostawca IT może wykonywać działania techniczne i wspierać analizę. Firma potrzebuje jednak własnych zasad nadzoru i podejmowania decyzji. Sam zapis „obsługę zapewnia firma zewnętrzna” pozostawia zbyt wiele miejsca na domysły.

4. Ocena obowiązku zgłoszenia biegnie równolegle z reakcją

Nie każdy alert oznacza incydent poważny. Nie każdy incydent wymaga takiego samego zgłoszenia.

Dlatego procedura powinna obejmować ocenę zdarzenia według właściwych kryteriów i progów. Trzeba ustalić między innymi wpływ na usługę, skalę zakłócenia i możliwe skutki.

Gdy powstaje obowiązek raportowania incydentu poważnego, podstawowy model obejmuje wczesne ostrzeżenie do 24 godzin od wykrycia, zgłoszenie do 72 godzin oraz sprawozdanie końcowe do miesiąca od zgłoszenia. Dla dostawców usług zaufania termin właściwego zgłoszenia jest krótszy. Jeśli obsługa trwa nadal, przewidziano sprawozdanie z postępu i późniejsze sprawozdanie końcowe.

To oznacza, że firma musi umieć działać przy niepełnej wiedzy. Pierwsza informacja nie będzie miała szczegółowości raportu z zakończonego dochodzenia. Ale będzie musiała wyjść od firmy i to jest istotne.

Nie można uzależniać uruchomienia ścieżki zgłoszeniowej od poznania wszystkich przyczyn zdarzenia.

Warto wcześniej sprawdzić dostęp do S46, uprawnienia użytkowników, zastępstwa i sposób zbierania informacji do zgłoszenia. Rejestracja w wykazie oraz gotowość do raportowania to odrębne zadania. Pamiętajcie też, że dostęp do S46 nie musi mieć tylko kierownik - może mięc też firma, która Was obsługuje lub SOC.

5. Przywrócenie działania też wymaga decyzji

„System już działa” to dobra wiadomość. Pozostaje jednak ustalić, czy można bezpiecznie wrócić do normalnej pracy.

Czy usunięto przyczynę problemu? Czy odtworzone dane są poprawne? Czy sprawdzono dostępy? Czy właściciel procesu potwierdził, że usługa działa prawidłowo?

Plan ciągłości działania powinien pomagać odpowiedzieć na te pytania. Określać priorytety odtwarzania, akceptowalną przerwę i utratę danych oraz warunki powrotu do pracy.

Sama informacja „mamy backup” nie rozstrzyga, ile potrwa odtworzenie i czy firma będzie mogła po nim wznowić działalność. To trzeba sprawdzić w praktyce.

6. Po decyzji powinien zostać ślad

Podczas incydentu liczy się działanie. Po incydencie trzeba umieć odtworzyć jego przebieg.

Kiedy wykryto zdarzenie? Co było wtedy wiadomo? Kto zdecydował o ograniczeniu dostępu? Dlaczego przyjęto daną klasyfikację? Jakie działania wykonano i czy potwierdzono ich skuteczność?

Takie informacje mogą znajdować się w rejestrze incydentów, zgłoszeniach serwisowych, potwierdzeniach raportowania i wynikach testów. Ważne, żeby były spójne i dostępne dla uprawnionych osób.

Zapis decyzji pomaga również poprawić proces. Pokazuje, gdzie zabrakło danych, kontaktu, uprawnień albo jasnej odpowiedzialności.

Co zrobić teraz, po samorejestracji?

Dobrym kolejnym krokiem jest przegląd obecnego stanu i luk, a następnie plan działań z właścicielami, terminami i budżetem. W SPIREE taką rolę pełni Audyt 0: porządkuje punkt wyjścia i pozwala ustalić kolejność prac.

Warto też zaplanować krótkie ćwiczenie z udziałem IT, osoby odpowiedzialnej za bezpieczeństwo, właściciela procesu biznesowego, kierownictwa i kluczowego dostawcy.

Wybierzcie jedno zdarzenie wynikające z analizy ryzyka. Przejdźcie je od pierwszego sygnału do przywrócenia działania. Sprawdźcie, kto odbiera zgłoszenie, kto ocenia skutki, kto podejmuje decyzję i kto dokumentuje jej wykonanie.

Jeśli rozmowa zatrzymuje się na „to chyba robi dostawca” albo „musielibyśmy zapytać prezesa”, właśnie znaleźliście konkretne zadanie do wdrożenia.

Po samorejestracji najważniejsza staje się zdolność firmy do działania: od zauważenia problemu, przez ocenę ryzyka, aż po decyzję i sprawdzenie jej skutków.

To właśnie tę drogę warto teraz uporządkować.

Stan informacji: 28 października 2026 r. Wskazane terminy dostosowawcze dotyczą podmiotów spełniających kryteria 3 kwietnia 2026 r. Dla podmiotów objętych ustawą później oraz organizacji podlegających szczególnym zasadom harmonogram wymaga odrębnego ustalenia.