Praktyczne wskazówki: jak prowadzić program NIS2

Zasada pierwsza: to projekt całej organizacji

• Zarząd odpowiada za mandat, nadzór, zasoby i decyzje.
• CIO może być dyrektorem programu i koordynatorem, ale nie powinien przejmować własności procesów biznesowych ani samodzielnie akceptować ryzyk należących do innych obszarów.
• Dyrektorzy biznesowi są właścicielami swoich procesów, skutków przerw, wymagań RTO/RPO, obejść i działań naprawczych.
• CISO lub funkcja bezpieczeństwa prowadzi metodykę ryzyka, SZBI, monitorowanie i doradztwo.
• IT i OT projektują i utrzymują środki techniczne zgodne z wymaganiami biznesowymi.
• Prawo, compliance, HR i zakupy odpowiadają za swoje procesy, dokumenty i kontrole.

Rekomendowana struktura organizacyjna

Komitet Sterujący

Skład minimalny: sponsor z zarządu, CIO/dyrektor programu, CISO lub osoba odpowiedzialna za SZBI, dyrektor operacyjny lub produkcyjny, dyrektor finansowy, przedstawiciel prawa/compliance, HR, zakupy oraz właściciele najważniejszych procesów zależnie od agendy.

• zatwierdzenie zakresu, metodyki i kryteriów ryzyka
• decyzje budżetowe i usuwanie konfliktów priorytetów
• nadzór nad opóźnieniami i ryzykami programu
• akceptacja ryzyka rezydualnego na odpowiednim poziomie
• zatwierdzenie gotowości i nadzór nad doskonaleniem

CIO — dyrektor programu

• integruje plan i zależności, prowadzi raportowanie
• przygotowuje decyzje dla Komitetu i eskaluje blokady
• pilnuje, aby rozwiązania technologiczne wynikały z BIA i ryzyka
• nie podpisuje za biznes parametrów BIA ani nie akceptuje wszystkich ryzyk

Strumienie robocze

Macierz odpowiedzialności

Rytm spotkań i raportowania

• faza diagnozy i remediacji: strumienie co tydzień, PMO z liderami co tydzień, Komitet co dwa tygodnie, raport do zarządu miesięcznie (częściej przy ryzykach krytycznych)
• po stabilizacji: przegląd operacyjny miesięcznie, Komitet lub przegląd zarządczy kwartalnie, pełny przegląd SZBI co najmniej raz w roku oraz po istotnej zmianie lub incydencie

Jednostronicowy dashboard Komitetu

1. status ogólny: zakres, czas, budżet, ryzyko
2. kluczowe kamienie milowe
3. pięć największych ryzyk programu
4. decyzje wymagane od Komitetu
5. status działań krytycznych
6. status BIA, ryzyka, dokumentów, technologii i testów
7. gotowość dowodowa
8. budżet: plan, wykonanie, forecast
9. opóźnienia właścicieli
10. korzyści: skrócenie odtworzenia, zasięg MFA/EDR, skuteczność backupu, czas reakcji

Jak ustalać priorytety

Stosować ocenę wielokryterialną: ryzyko dla procesów krytycznych, obowiązek prawny, prawdopodobieństwo scenariusza, skala skutku, brak alternatywnego obejścia, czas wdrożenia, zależności, koszt i możliwość szybkiego ograniczenia ryzyka. Najpierw usuwać luki, które mogą prowadzić do zatrzymania krytycznej usługi albo uniemożliwić odtworzenie — nawet jeżeli przygotowanie kompletnej dokumentacji jest łatwiejsze.

Dziesięć praktycznych zasad

1. Nie zaczynaj od listy zakupowej.
2. Nie deleguj BIA do IT.
3. Nie przyjmuj RTO bez kosztowej i technicznej weryfikacji.
4. Nie nazywaj backupu planem ciągłości.
5. Nie zbieraj logów bez scenariuszy detekcji i obsługi.
6. Nie wdrażaj DLP bez klasyfikacji informacji i procesu wyjątków.
7. Nie uznawaj dokumentu za wdrożony bez dowodu działania.
8. Nie oceniaj dostawcy tylko w dniu podpisania umowy.
9. Nie raportuj zarządowi liczby zamkniętych zadań bez informacji o ryzyku.
10. Nie kończ programu w dniu audytu.

Nie kupuj, zanim…

• Nie kupuj SIEM, zanim nie ustalisz źródeł, scenariuszy i obsługi alertów.
• Nie buduj środowiska DR, zanim biznes nie zatwierdzi RTO i RPO.
• Nie wdrażaj DLP przed klasyfikacją informacji.
• Nie kupuj XDR tylko dlatego, że posiadasz EDR.
• Nie twórz dziesiątek polityk bez właścicieli i zapisów.
• Nie zlecaj odpowiedzialności za NIS2 dostawcy IT.

Cztery pytania, które porządkują cały program

1. Czy organizacja podlega KSC?

Najpierw zweryfikuj sektor, rodzaj działalności, wielkość organizacji, strukturę grupy oraz przypadki szczególne. Bez poprawnej kwalifikacji nie da się ustalić obowiązków, terminów i właściwego organu.

2. Jakie usługi i procesy są krytyczne?

BIA pokazuje, które procesy nie mogą długo czekać, jakie skutki wywoła przerwa i od czego zależy ich działanie. To punkt wyjścia do RTO, RPO, backupu, disaster recovery oraz planów awaryjnych.

3. Jakie ryzyka trzeba ograniczyć?

Analiza ryzyka pozwala ustalić priorytety. Nie wszystkie systemy wymagają tego samego poziomu ochrony, a technologia ma odpowiadać na konkretny scenariusz zagrożenia.

4. Jak udowodnić, że system działa?

Potrzebne są nie tylko polityki, lecz także zapisy: wyniki testów, przeglądy dostępów, raporty z backupu, obsłużone incydenty, decyzje zarządu, działania korygujące i mierniki skuteczności.

Materiały mają charakter edukacyjny i nie stanowią opinii prawnej ani gwarancji zgodności. Zakres obowiązków zależy od indywidualnej sytuacji organizacji, aktualnych przepisów, aktów wykonawczych i stanowisk właściwych organów. Przed podjęciem decyzji wymagającej interpretacji prawa należy przeprowadzić analizę odpowiednią dla danego podmiotu.