TL;DR
- Odpowiedzialność NIS2 jest na zarządzie — audytorzy sprawdzają, czy operatorzy wykonają działania w wymaganym czasie.
- Runbook musi nazywać systemy, właścicieli, ścieżki komunikacji i lokalizacje dowodów.
- Wczesne ostrzeżenie (24h) i zgłoszenie (72h) wymagają progów ważności i szablonów przygotowanych wcześniej.
- Backup bez testu restore to teatr — trzymaj ostatni raport restore tam, gdzie legal go znajdzie.
Rozmowy o regulacjach często kończą się na wykresach governance. Dla zespołów infrastruktury i security NIS2 to działania w czasie: klasyfikacja, powiadomienia, dowody, odtworzenie. Jeśli żyją tylko w PDF przejrzanym raz przez legal, pierwszy incydent wymyśli proces o 02:00 — a prawnik zapyta o timestampy, których nie masz. NIS2 nie interesuje grubość folderu polityk. Interesuje, czy osoba na dyżurze otworzy runbook, wykona kroki na realnych systemach i wyprodukuje dowód powiadomień w ustawowych oknach.
Wspieraliśmy podmioty essential i important w produkcji, logistyce i IT services w gotowości NIS2. Luka to rzadko brak polityk. To brak operacyjności: definicje ważności interpretowane na pięć sposobów, raporty backupu na share tylko dla admina backupu, numery dostawców prowadzące na voicemail podczas awarii. Runbooki zamykają lukę — nie przez dokładanie stron, lecz przez nazwanie kto co robi na którym systemie, zanim wejdzie adrenalina.
Sekcje runbooka obowiązkowe od dnia pierwszego
Macierz ważności powiązana z triggerami NIS2 jest nie do negocjacji. Zdefiniuj znaczący incydent: czas niedostępności, kategorie danych, wpływ transgraniczny, żądania okupu przeciw krytycznym systemom. Mapuj ważności na zespół kryzysowy, draft wczesnego ostrzeżenia, komunikację z klientem i zgłoszenie do regulatora. Niejasność kosztuje dni. MSP debatował osiemnaście godzin o ransomware, czy PII było „dotknięte”, bo pliki zaszyfrowane, nie exfil — zegar 24h tykał.
Drzewo kontaktów z zastępcami dla CISO, DPO, legal, comms, TAM chmury, ISP, MSSP — numery po godzinach i klauzule eskalacji umownej, nie tylko „otwórz ticket”. Przy DDoS na e-commerce brak drugiego kontaktu ISP dodał cztery godziny, a sprzedaż dowiedziała się z Twittera.
Kroki zabezpieczenia i izolacji per tier zamieniają ogólny plan IR w checklistę. Dla systemów krytycznych: izolacja segmentu, unieważnienie poświadczeń, snapshot logów do niezmiennej pamięci masowej, łańcucha dowodowego. „Odłącz od sieci” bez VLAN/SG/portu to improwizacja pod obserwacją prawną.
Backup, restore i mapa dostawców
Dowód backup/restore w treści runbooka: RPO/RTO per tier, data ostatniego testu, kto podpisał, gdzie raporty. NIS2 akcentuje odporność — backup bez testu to finding i fikcja. Klient przemysłowy w tabletop odkrył, że „nocny backup” file servera failował sześć tygodni po rotacji credentiali. Runbook linkuje teraz do dashboardu backupu i nazywa osobę sprawdzającą status codziennie.
Mapa dostawców: który incydent wymaga powiadomienia którego vendora w jakim SLA. Shared responsibility w chmurze = status page, tier supportu, procedura eksportu dowodów. Kompromitacja tożsamości M365 + on-prem AD: kto otwiera case u Microsoft, kto zabezpiecza logi Entra, kto koreluje z DC — ustalone z góry, nie o 03:00.
Mechanika wczesnego ostrzeżenia i zgłoszenia
Obowiązki 24h i 72h karzą improwizację. Szablony z placeholderami: usługi, kategorie danych, wpływ, status izolacji. Progi ważności uruchamiające legal — nie „zadzwonimy, jak będzie źle”. Legal potrzebuje czasu na słowa; operatorzy na zabezpieczenie dowodów. Wspólna oś czasu aktualizowana co godzinę.
Szablony w języku regulatora i prostym języku dla klienta — często dwa dokumenty, te same fakty. Dostępne dla on-call bez polowania w mailu. Firma logistyczna trzyma pakiety w wiki kanału incydentowego z datą ostatniego przeglądu; legal kwartalnie sign-off po M&A.
Tabletop zamiast kolejnej polityki
Ćwiczenie 90 minut: ransomware na hybrydowym file service lub kompromitacja IAM z regułami mail. Mierz czas decyzji. Luki → poprawki runbooka w ten sam tydzień. Tabletop ujawnia też rozjazd narzędzia z opisem: jeśli runbook mówi „eksport do niezmiennej pamięci”, a nikt nie testował eksportu — napraw narzędzie albo runbook.
Powtarzaj kwartalnie z rotacją ról — CISO nie zawsze dowódcą. NIS2 oczekuje capability organizacji, nie heroizmu jednej osoby z incydentu 2019. Lekcje z ID ticketów; regulatorzy coraz częściej pytają o historię ćwiczeń.
Scenariusz: cloud-first SaaS vs hybrydowy producent
SaaS: izolacja tenantów, listy klientów z CRM, status page zsynchronizowany z sub-processorami w umowach. Dowody w ticketingu, eksporcie czatu, logach chmury z blokadą retencji.
Producent hybrydowy: segmenty OT, historyki on-prem, interlocki bezpieczeństwa. Te same terminy NIS2, ale containment odnosi się do VLAN przy PLC i process safety officer zatwierdzającego izolację zatrzymującą linię. Jeden runbook wymaga rozdziałów per tier — błędem jest ten sam PDF w obu środowiskach bez customizacji.
Zegar 24 h / 72 h przy prawdziwym incydencie
Język prawny jest czysty. Operacje nie. Użyteczny zegar mieści się na jednej stronie obok macierzy ważności:
- T+0 — dyżur ogłasza kandydata na istotny incydent według wcześniej ustalonego progu (czas niedostępności u klienta, kategoria danych, okup, skutek transgraniczny). Nie debata. Przy wątpliwości eskalacja; zegar i tak idzie od pierwszej rozsądnej wiedzy.
- T+2 h — nazwany właściciel powstrzymania, otwarte miejsce na dowody (zgłoszenie + folder), prawny i komunikacja obudzeni jeśli ważność tak każe.
- T+24 h — szkic wczesnego ostrzeżenia wysłany albo świadomie odłożony z powodem na piśmie (fałszywy alarm). Szablon już z nazwami systemów, nie „systemy IT”.
- T+72 h — pakiet zgłoszenia: oś czasu, skutek jak znany, działania, termin kolejnej aktualizacji. Puste pola: „nieznane na HH:MM”, nie cisza.
Widzieliśmy zespoły, które traciły pół dnia na spór, czy zaszyfrowane-ale-niewyprowadzone pliki „się liczą”. Wpiszcie ten przykład do macierzy teraz. Numery CSIRT i dostawców na tej samej stronie — TAM tylko na poczcie głosowej to ustalenie, nie kontakt.
Dwanaście pytań do każdego istotnego dostawcy
Wyślijcie to jako jedną stronę. „Certyfikowane ISO centrum danych” nie jest odpowiedzią.
- Nazwana ścieżka 24/7 i zastępca. Data ostatniego raportu restore dla systemów, które prowadzą u was.
- Gdzie leżą logi, jak długo i jak je dostaniecie, gdy incydentem jest sam dostawca.
- Kto może skasować albo zmienić backupy, które trzymają. Okno immutability.
- Podprocesorzy przy danych produkcji, kraj i jak dowiecie się o zmianie.
- Ich obowiązek incydentowy wobec was — godziny, nie „tak szybko, jak to praktycznie możliwe”.
- Wyjście: format zwrotu danych i test, który już raz zrobiliście.
Dowody z infrastruktury należą obok segregatorów prawnych. Praca audytu i bezpieczeństwa informacji jest pod to nachodzenie — runbooki i pytania, które zadają kontrolerzy, nie kolejna wersja polityki. Dowód backupu: czego wymagać przed podpisem.
Co dalej
Otwórz runbook dziś wieczorem. Zamień „odpowiedni zespół” na imiona, systemy i linki. Zaplanuj tabletop 90 min przed kolejnym przeglądem polityk. Łączymy kontrolki z runbookami w Bezpiecznej infrastrukturze chmurowej i audycie — do wykonania pod presją, nie dla procurementu.
Chcesz porozmawiać o projekcie?
Napisz do nasWięcej na ten temat

Identity Security w praktyce: co audytor sprawdza w pierwszej kolejności
Zanim pojawią się wyniki pentestu, audytor patrzy na tożsamość: MFA, dostęp uprzywilejowany, JML i dowody, że dostęp odpowiada…


