Gotowość do Aktu UE o cybersolidarności z ISO 27001

Incydent o 03:17, który zmienia współpracę w UE w zagadnienie audytowe

O 03:17 we wtorkowy poranek Maria, CISO InnovateCloud, patrzy na ekran pełen alertów. Jej firma jest średniej wielkości europejskim dostawcą SaaS obsługującym klientów logistycznych w Niemczech, Francji i Polsce. Pierwszy alert wygląda na podejrzany dostęp uprzywilejowany w produkcyjnym tenancie. Dziesięć minut później dostawca zarządzanych usług bezpieczeństwa zgłasza podobną aktywność dotyczącą dwóch innych klientów. O 04:00 SOC widzi wywołania API z infrastruktury wcześniej kojarzonej z przygotowaniem ataków ransomware.

InnovateCloud nie było pierwotnym celem. W strefie oddziaływania najwyraźniej znalazł się kluczowy dostawca infrastruktury. Skutek jest jednak teraz problemem Marii.

Jeden z dotkniętych klientów to niemiecki bank oczekujący odpowiedzi zgodnie z DORA. Drugi to dostawca krytyczny w sektorze energetycznym, już sklasyfikowany zgodnie z krajowymi przepisami wdrażającymi NIS2. Środowisko może zawierać dane osobowe, ale eksfiltracja danych nie została jeszcze potwierdzona. Zespół bezpieczeństwa chce natychmiast powstrzymać zagrożenie. Dział prawny chce wiedzieć, czy rozpoczął się 24-godzinny termin wczesnego ostrzeżenia NIS2. Osoba odpowiedzialna za prywatność pyta, czy może powstać obowiązek zgłoszenia naruszenia zgodnie z GDPR. Zarząd chce wiedzieć, czy niedostępność usługi może rozprzestrzenić się na inne państwa członkowskie.

W 2026 r. nie jest to już wyłącznie kryzys wewnętrzny.

Akt UE o cybersolidarności zmienia operacyjną rzeczywistość dużych i transgranicznych incydentów cyberbezpieczeństwa. Wprowadza mechanizmy wykrywania, gotowości i reagowania na poziomie UE, w tym Europejski system ostrzegania o cyberbezpieczeństwie, Mechanizm reagowania na sytuacje nadzwyczajne w cyberbezpieczeństwie oraz Unijną rezerwę cyberbezpieczeństwa. Nawet jeżeli organizacja nigdy bezpośrednio nie zwróci się o pomoc do rezerwy, jej dowody, kontakty z organami, umowy z dostawcami, osie czasu incydentu i komunikacja z klientami mogą stać się częścią szerszego europejskiego łańcucha reagowania.

Luka ujawnia się szybko. Wiele organizacji ma narzędzia, zgłoszenia i polityki, ale nie ma dowodów, które wytrzymują kontrolę regulacyjną. Mogą powiedzieć: „skontaktowaliśmy się z organem regulacyjnym”, ale nie potrafią wykazać, kto był upoważniony, jaki próg uruchomił kontakt, co zostało przekazane, czy logi zostały zabezpieczone, czy dostawca był umownie zobowiązany do pomocy ani czy raport końcowy można odtworzyć na podstawie decyzji podejmowanych w toku incydentu.

Rozwiązaniem nie jest kolejny odizolowany „segregator Aktu o cybersolidarności”. Rozwiązaniem jest system zarządzania bezpieczeństwem informacji ISO/IEC 27001:2022, który wytwarza dowody raz i pozwala wykorzystywać je ponownie wobec oczekiwań NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 2019.

Te dowody powstają przed incydentem.

Dlaczego Akt UE o cybersolidarności podnosi standard dowodowy

Akt o cybersolidarności zaprojektowano z myślą o wykrywaniu cyberzagrożeń, gotowości i reagowaniu kryzysowym na poziomie UE. Jego praktyczny skutek dla CISO, audytorów i menedżerów zgodności jest jasny: koordynacja incydentów na dużą skalę wymaga dowodów szybszych, czystszych, bardziej spójnych i łatwiejszych do udostępnienia zaufanym interesariuszom.

Gdy możliwy jest wpływ transgraniczny, organizacja może potrzebować koordynacji z krajowymi CSIRT, właściwymi organami, regulatorami sektorowymi, organami ochrony danych, nadzorcami finansowymi, organami ścigania, klientami, podmiotami przetwarzającymi, dostawcami oraz zewnętrznymi zespołami reagowania na incydenty. Unijna rezerwa cyberbezpieczeństwa dodaje kolejny wymiar, ponieważ wcześniej zweryfikowani prywatni dostawcy mogą wspierać gotowość, reagowanie i odtwarzanie. To sprawia, że nadzór nad dostawcami, umocowanie prawne, postępowanie z danymi i zabezpieczenie materiału dowodowego stają się jeszcze ważniejsze.

Podmioty prywatne znajdują się w centrum tej rzeczywistości. Dostawcy chmury obliczeniowej, centra danych, dostawcy usług zarządzanych, dostawcy zarządzanych usług bezpieczeństwa, operatorzy infrastruktury cyfrowej, fintechy i platformy SaaS często posiadają telemetrię, logi, dane o wpływie na klientów oraz fakty techniczne, których organy potrzebują do zrozumienia poważnego incydentu.

NIS2 już wskazuje ten kierunek. Obejmuje wiele średnich i dużych podmiotów z sektorów określonych w załączniku I i załączniku II, które świadczą usługi lub prowadzą działalność w UE. Obejmuje również niektóre podmioty niezależnie od wielkości, w tym dostawców usług zaufania, dostawców usług DNS, rejestry nazw domen najwyższego poziomu oraz dostawców usług rejestracji nazw domen. Załącznik I obejmuje infrastrukturę cyfrową, taką jak usługi w chmurze obliczeniowej, usługi centrów danych, sieci dostarczania treści, dostawców DNS, dostawców usług zaufania i rejestry TLD. Obejmuje także zarządzanie usługami ICT w modelu B2B, w tym dostawców usług zarządzanych oraz dostawców zarządzanych usług bezpieczeństwa. Załącznik II obejmuje dostawców cyfrowych, takich jak internetowe platformy handlowe, wyszukiwarki internetowe i platformy usług sieci społecznościowych.

DORA dodaje drugą warstwę dla sektora finansowego. Od 17 stycznia 2025 r. stosuje się do szerokiego zakresu podmiotów finansowych, w tym instytucji kredytowych, instytucji płatniczych, instytucji pieniądza elektronicznego, firm inwestycyjnych, dostawców usług w zakresie kryptoaktywów, systemów obrotu, zakładów ubezpieczeń i reasekuracji, agencji ratingowych, dostawców usług finansowania społecznościowego i innych. Tworzy również istotne oczekiwania wobec zewnętrznych dostawców usług ICT, ponieważ podmioty finansowe pozostają odpowiedzialne za usługi ICT realizowane w outsourcingu.

Incydent fintechu w 2026 r. może być więc koordynowany kanałami nadzorczymi DORA, podczas gdy dostawca SaaS lub MSSP wspierający ten fintech może podlegać NIS2. To samo zdarzenie techniczne może tworzyć różne obowiązki zgłoszeniowe, oczekiwania dowodowe i zobowiązania umowne dla różnych uczestników.

ISO/IEC 27001:2022 daje organizacjom system operacyjny do zarządzania tą złożonością. Klauzule 4.1 do 4.4 wymagają, aby organizacja zdefiniowała SZBI w swoim kontekście biznesowym, zidentyfikowała zainteresowane strony oraz ich wymagania prawne, regulacyjne i umowne, określiła granice i zależności oraz ustanowiła system zarządzania. Klauzule 5.1 do 5.3 czynią kierownictwo odpowiedzialnym za politykę, zasoby, integrację i przypisanie ról. Klauzule 6.1.1 do 6.1.3 wymagają powtarzalnej oceny ryzyka, postępowania z ryzykiem oraz Deklaracji stosowania. Klauzula 8.1 wymaga kontroli operacyjnej, w tym nadzoru nad procesami, produktami i usługami dostarczanymi zewnętrznie.

To jest sedno gotowości do Aktu o cybersolidarności: wykazać, że reagowanie kryzysowe jest zarządzane, testowane i audytowalnie identyfikowalne, a nie improwizowane.

Model dowodowy Clarysec: jeden incydent, wiele obowiązków

Incydent transgraniczny nie czeka, aż zespoły prawne go sklasyfikują. Dowody trzeba zabezpieczać od pierwszego alertu, a następnie kierować do właściwych ścieżek raportowania i koordynacji.

Podejście Clarysec łączy trzy aktywa:

1. Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, który przekształca wdrożenie ISO/IEC 27001:2022 w sekwencyjną, gotową do audytu ścieżkę.
2. Zenith Controls: The Cross-Compliance Guide Zenith Controls, który mapuje środki kontrolne ISO/IEC 27002:2022 na powiązane środki kontrolne, atrybuty, zdolności operacyjne, domeny bezpieczeństwa oraz przekrojowe oczekiwania dowodowe między ramami.
3. Szablony polityk Clarysec dotyczące reagowania na incydenty, zabezpieczania materiału dowodowego, bezpieczeństwa dostawców, logowania, monitorowania i ciągłości działania, dostosowane do środowisk enterprise i MŚP.

W Zenith Blueprint, w fazie „Środki kontrolne w praktyce”, krok 22 odnosi się do środka kontrolnego ISO/IEC 27002:2022 5.5, Kontakt z organami. Stwierdza on:

Środek kontrolny 5.5 zapewnia, że organizacja jest przygotowana do kontaktu z organami zewnętrznymi, gdy jest to potrzebne, nie reaktywnie ani w panice, lecz poprzez zdefiniowane wcześniej, ustrukturyzowane i dobrze rozumiane kanały.

Ta sama sekcja stawia pytanie, na które każdy CISO powinien odpowiedzieć przed kryzysem:

jeżeli wasza organizacja stałaby się celem cyberataku, uczestniczyła w naruszeniu ochrony danych lub była objęta dochodzeniem, kto skontaktowałby się z organami? Skąd wiedziałby, co powiedzieć? W jakich warunkach taki kontakt zostałby zainicjowany?

To nie jest administracyjna papierologia. W środowisku Aktu o cybersolidarności jest to różnica między spokojnym wczesnym ostrzeżeniem a sprzecznymi komunikatami w różnych jurysdykcjach.

Zenith Controls traktuje środek kontrolny ISO/IEC 27002:2022 5.5, Kontakt z organami, jako zapobiegawczy i korygujący, powiązany z poufnością, integralnością i dostępnością oraz ukierunkowany na koncepcje Identify, Protect, Respond i Recover. Łączy 5.5 z planowaniem i przygotowaniem zarządzania incydentami, zgłaszaniem zdarzeń, informacjami o zagrożeniach, grupami specjalnego zainteresowania oraz reagowaniem na incydenty.

Ten sam przewodnik traktuje środek kontrolny ISO/IEC 27002:2022 5.24, Planowanie i przygotowanie zarządzania incydentami bezpieczeństwa informacji, jako kontrolę korygującą powiązaną z Respond i Recover. Jego powiązania z oceną zdarzeń, reagowaniem na incydenty, wnioskami po incydencie, logowaniem, monitorowaniem, bezpieczeństwem podczas zakłóceń i ciągłością działania pokazują, co audytorzy często testują: czy plan łączy wykrywanie, klasyfikację, eskalację, dowody, odtwarzanie i uczenie się.

W zakresie postępowania z materiałem dowodowym szczególnie ważny jest środek kontrolny ISO/IEC 27002:2022 5.28, Zabezpieczanie materiału dowodowego. Zenith Controls łączy go z reagowaniem na incydenty, logowaniem, monitorowaniem i zgłaszaniem zdarzeń. W poważnym incydencie transgranicznym właśnie tutaj dochodzenie techniczne staje się możliwe do obrony.

Mapowanie gotowości do Aktu o cybersolidarności na dowody ISO 27001

Akt UE o cybersolidarności tworzy środowisko gotowości i koordynacji. ISO/IEC 27001:2022 zapewnia mechanizm wytwarzania dowodów. NIS2, DORA i GDPR definiują wiele szczegółowych oczekiwań dotyczących raportowania, zarządzania i ochrony.

Zwróć uwagę, czego tu nie ma: oddzielnego silosu zgodności. Te same dowody, które wspierają certyfikację ISO/IEC 27001:2022, mogą wspierać rozliczalność kierownictwa w NIS2, zarządzanie ryzykiem ICT w DORA, rozliczalność bezpieczeństwa w GDPR, wyniki komunikacyjne NIST CSF oraz oczekiwania COBIT 2019 dotyczące zapewnienia.

NIS2: zegar raportowania startuje w momencie uzyskania wiedzy

NIS2 ma kluczowe znaczenie dla gotowości w 2026 r., ponieważ definiuje etapowy proces zgłaszania incydentów.

Article 23 wymaga, aby podmioty kluczowe i ważne bez zbędnej zwłoki powiadamiały swój CSIRT lub właściwy organ o znaczących incydentach wpływających na świadczenie usług. Wczesne ostrzeżenie musi zostać przekazane bez zbędnej zwłoki i nie później niż w ciągu 24 godzin od uzyskania wiedzy o znaczącym incydencie. Powinno wskazywać, w stosownych przypadkach, czy podejrzewa się działania złośliwe lub bezprawne oraz czy możliwy jest wpływ transgraniczny.

Zgłoszenie incydentu następuje bez zbędnej zwłoki i nie później niż 72 godziny od uzyskania wiedzy, aktualizując wczesne ostrzeżenie oraz przedstawiając wstępną ocenę wagi, wpływu i dostępnych wskaźników naruszenia bezpieczeństwa. Raport końcowy należy złożyć w terminie jednego miesiąca od zgłoszenia incydentu, z opisem wagi, wpływu, prawdopodobnego rodzaju zagrożenia lub przyczyny źródłowej, środków łagodzących oraz wpływu transgranicznego.

Dlatego reagowanie na incydenty nie może zaczynać się od pustego dokumentu.

Enterprise Polityka reagowania na incydenty Polityka reagowania na incydenty stwierdza:

NIS2 Article 23 (zgłoszenie w ciągu 24 godzin od uzyskania wiedzy o incydencie)

MŚP Polityka reagowania na incydenty - MŚP Polityka reagowania na incydenty - MŚP przenosi tę samą logikę terminów na praktyczne zarządzanie:

„Harmonogramy reagowania, w tym odtwarzanie danych i obowiązki powiadamiania, muszą być udokumentowane i dostosowane do wymagań prawnych, takich jak 72-godzinny obowiązek zgłoszenia naruszenia ochrony danych osobowych zgodnie z GDPR.”

Z Polityki reagowania na incydenty - MŚP, sekcja „Wymagania dotyczące ładu zarządczego”, klauzula 5.3.2.

Wymusza ona również wieloreżimową ocenę w ramach procesu incydentowego:

„Jeżeli zaangażowane są dane klientów, Dyrektor Generalny musi ocenić prawne obowiązki powiadomienia na podstawie zastosowania GDPR, NIS2 lub DORA.”

Z Polityki reagowania na incydenty - MŚP, sekcja „Postępowanie z ryzykiem i wyjątki”, klauzula 7.4.1.

W scenariuszu Aktu o cybersolidarności stwierdzenie „możliwy jest wpływ transgraniczny” nabiera znaczenia operacyjnego. Wczesne ostrzeżenie może nie zawierać pełnych faktów, ale organizacja musi umieć wykazać, dlaczego podejrzewała lub nie podejrzewała wpływu transgranicznego na podstawie dostępnych dowodów.

Rejestr incydentu powinien obejmować:

• Kiedy organizacja uzyskała wiedzę.
• Kto zakwalifikował zdarzenie jako potencjalny incydent.
• Które usługi, kraje, klienci lub sektory mogły zostać dotknięte.
• Czy podejrzewano działalność złośliwą lub bezprawną.
• Jakie wskaźniki naruszenia bezpieczeństwa były dostępne.
• Jakiej ścieżki kontaktu z organami użyto.
• Czy wymagana była komunikacja z klientami.
• Jakie dowody zabezpieczono przed zasadniczymi działaniami naprawczymi.

Najlepszy czas na zaprojektowanie tych pól jest przed 03:17.

DORA: gdy klient jest regulowany, ale logi posiada dostawca

DORA zmienia rozmowę z dostawcami. Podmioty finansowe muszą zarządzać ryzykiem stron trzecich w obszarze ICT jako częścią swoich ram zarządzania ryzykiem ICT. Outsourcing usług ICT nie przenosi odpowiedzialności regulacyjnej z podmiotu finansowego.

DORA wymaga strategii zarządzania ryzykiem stron trzecich w obszarze ICT, rejestrów umów dotyczących usług ICT, należytej staranności, planowania audytów i inspekcji, praw do rozwiązania umowy oraz przetestowanych strategii wyjścia dla krytycznych lub ważnych usług ICT. Article 30 wymaga jasności umownej, w tym opisów usług, lokalizacji, postępowania z danymi, poufności, integralności, dostępności, poziomów usług, pomocy podczas incydentów ICT, współpracy z organami oraz praw do rozwiązania umowy. W przypadku funkcji krytycznych lub ważnych stosuje się bardziej rygorystyczne warunki.

Wróćmy do incydentu Marii. Niemiecki bank podlega DORA. InnovateCloud świadczy usługi SaaS. MSSP wykrywa podejrzaną aktywność. Dostawca infrastruktury chmurowej posiada część kluczowych logów audytowych. Podwykonawca obsługuje część potoku telemetrii. Bank pozostaje odpowiedzialny, ale nie może poprawnie sklasyfikować i zgłosić incydentu bez dowodów od dostawcy.

Clarysec adresuje to poprzez klasyfikację dostawców i dowody umowne. Enterprise Polityka bezpieczeństwa dostawców i stron trzecich Polityka bezpieczeństwa dostawców i stron trzecich wymaga:

Umowy z dostawcami muszą obejmować:

MŚP Polityka bezpieczeństwa dostawców i stron trzecich - MŚP Polityka bezpieczeństwa dostawców i stron trzecich - MŚP stosuje tę samą logikę zgodności w lżejszym modelu operacyjnym:

Umowy muszą obejmować obowiązkowe klauzule dotyczące:

Wartość znajduje się w harmonogramie stojącym za tymi słowami: obowiązki zgłaszania incydentów, dostęp do logów, prawo do audytu, poufność, lokalizacja danych, kontrole podwykonawców, współpraca z organami, wsparcie odtwarzania i obowiązki wyjścia.

Zenith Blueprint, faza „Środki kontrolne w praktyce”, krok 23, wskazuje ścieżkę wdrożenia:

Sporządź pełny wykaz aktualnych dostawców i dostawców usług (5.19) oraz sklasyfikuj ich na podstawie dostępu do systemów, danych lub kontroli operacyjnej. Dla każdego sklasyfikowanego dostawcy zweryfikuj, czy oczekiwania bezpieczeństwa są jasno ujęte w umowach (5.20), w tym poufność, dostęp, zgłaszanie incydentów i obowiązki w zakresie zgodności.

Następnie odnosi się do ryzyka dalszego łańcucha:

Dla każdego dostawcy krytycznego ustal, czy korzysta z podwykonawców (podwykonawców przetwarzania), którzy mogą uzyskać dostęp do waszych danych lub systemów. Udokumentuj, w jaki sposób wymagania bezpieczeństwa informacji są przenoszone na te strony, poprzez warunki umowne waszego dostawcy albo wasze własne bezpośrednie klauzule.

To również gotowość do Unijnej rezerwy cyberbezpieczeństwa. Jeżeli zewnętrzny dostawca reagowania wchodzi do waszego środowiska podczas sytuacji awaryjnej, musicie znać podstawę prawną, zakres dostępu, reguły dowodowe, obowiązki postępowania z danymi, ścieżkę koordynacji z organami i warunki wyjścia. DORA czyni to wyraźnym dla podmiotów finansowych. NIS2 czyni to istotnym dla podmiotów kluczowych i ważnych. ISO/IEC 27001:2022 czyni to audytowalnym.

GDPR: pytanie o naruszenie ochrony danych w kryzysie cyberbezpieczeństwa

Nie każdy incydent cyberbezpieczeństwa jest naruszeniem ochrony danych osobowych, ale każdy poważny incydent powinien zostać oceniony pod tym kątem.

GDPR stosuje się do przetwarzania w kontekście działalności jednostki organizacyjnej w UE, a także do administratorów lub podmiotów przetwarzających spoza UE, którzy oferują towary lub usługi osobom fizycznym w UE albo monitorują ich zachowanie w UE. Definiuje dane osobowe, przetwarzanie, administratora, podmiot przetwarzający oraz naruszenie ochrony danych osobowych. Jego zasady obejmują integralność, poufność i rozliczalność, co oznacza, że administratorzy muszą być w stanie wykazać zgodność.

Podczas incydentu o 03:17 zespół Marii musi zapytać:

• Czy uzyskano dostęp do danych osobowych, ujawniono je, zmieniono, utracono lub zniszczono?
• Czy InnovateCloud jest administratorem, podmiotem przetwarzającym, czy pełni obie role wobec dotkniętych danych?
• Czy zaangażowane są szczególne kategorie danych osobowych?
• Którzy klienci lub które osoby fizyczne są dotknięte?
• Czy logi wystarczają do oceny zakresu?
• Czy obowiązki powiadomienia zgodnie z GDPR biegną równolegle z obowiązkami NIS2 lub DORA?

Dlatego koordynacja prywatności należy do eskalacji incydentu, a nie do późnego przeglądu prawnego po odbudowie systemów i rotacji logów.

MŚP Polityka logowania i monitorowania - MŚP Polityka logowania i monitorowania - MŚP stwierdza:

Alerty o wysokim priorytecie muszą zostać eskalowane do GM i Koordynatora ds. prywatności w ciągu 24 godzin

Ta klauzula jest prosta, ale rozwiązuje realny wzorzec nieskuteczności. Osoby odpowiedzialne za prywatność potrzebują dowodów, gdy są one jeszcze wystarczająco świeże, aby ustalić, czy doszło do naruszenia ochrony danych osobowych i czy osoby fizyczne są narażone na ryzyko.

Zbuduj 24-godzinny pakiet dowodowy dla incydentu transgranicznego

Praktyczne ćwiczenie gotowości powinno symulować pierwsze 24 godziny incydentu transgranicznego. Celem nie jest nadmierne raportowanie. Celem jest wykazanie, że organizacja potrafi zebrać fakty, podjąć możliwe do obrony decyzje i utrzymać spójną komunikację.

Scenariusz

Wasz MSSP wykrywa podejrzany dostęp uprzywilejowany z nietypowego regionu do produkcyjnego tenanta. Ta sama infrastruktura źródłowa pojawia się w alertach dotyczących dwóch klientów w dwóch państwach członkowskich. Jeden klient jest podmiotem finansowym. Dotknięte środowisko zawiera dane osobowe, ale eksfiltracja danych nie została potwierdzona.

Krok 1: Otwórz rejestr incydentu

Utwórz zgłoszenie incydentu przy użyciu zatwierdzonych pól klasyfikacji. Uwzględnij czas uzyskania wiedzy, źródło wykrycia, dotknięte aktywa, dotknięte usługi, kraje potencjalnie dotknięte, podejrzewaną aktywność złośliwą, początkową wagę i kierownika incydentu.

Powiąż to ze środkami kontrolnymi ISO/IEC 27002:2022 5.24, 5.25 i 5.26 oraz ze środkami kontrolnymi załącznika A ISO/IEC 27001:2022 A.5.24, A.5.25 i A.5.26.

Krok 2: Uruchom ścieżkę decyzyjną dotyczącą organów

Użyj macierzy kontaktów z organami wymaganej przez krok 22 Zenith Blueprint. Zidentyfikuj organy, które mogą być właściwe: krajowy CSIRT, organ ochrony danych, regulator finansowy, organy ścigania i regulator sektorowy.

Zarejestruj decyzję i uzasadnienie. Jeżeli wczesne ostrzeżenie NIS2 nie zostanie złożone, zapisz dlaczego. Jeżeli możliwy jest wpływ transgraniczny, zarejestruj dowody wspierające ten wniosek.

Krok 3: Zabezpiecz dowody przed zasadniczą remediacją

Enterprise Polityka zabezpieczania materiału dowodowego i informatyki śledczej Polityka zabezpieczania materiału dowodowego i informatyki śledczej stwierdza:

Wszystkie zebrane dowody powinny być jednoznacznie zidentyfikowane, oznaczone i przechowywane w bezpiecznym repozytorium z:

MŚP Polityka zabezpieczania materiału dowodowego i informatyki śledczej - MŚP Polityka zabezpieczania materiału dowodowego i informatyki śledczej - MŚP wprowadza tę samą dyscyplinę w prostszej formie:

„Każdy element dowodów cyfrowych musi zostać zarejestrowany z:”

Z Polityki zabezpieczania materiału dowodowego i informatyki śledczej - MŚP, sekcja „Wymagania dotyczące ładu zarządczego”, klauzula 5.2.1.

Na potrzeby ćwiczenia tabletop zbierz przykładowe wpisy dowodowe: eksport alertu SIEM, logi dostawcy tożsamości, zapisy sesji uprzywilejowanych, migawkę punktu końcowego, logi zapory sieciowej, logi audytowe chmury, notatki dotyczące wpływu na klientów i zatwierdzenia komunikacji.

Krok 4: Aktywuj wsparcie dostawców

Sprawdź rejestr dostawców. Zidentyfikuj MSSP, dostawcę chmury i krytycznych podwykonawców. Potwierdź klauzule wsparcia incydentowego, kontakty eskalacyjne, okresy przechowywania logów, format dowodów i obowiązki współpracy z organami.

Wspiera to bezpośrednio wymagania DORA dotyczące ryzyka stron trzecich w obszarze ICT oraz oczekiwania NIS2 dotyczące bezpieczeństwa łańcucha dostaw.

Krok 5: Przygotuj trzy komunikaty

Przygotuj trzy komunikaty z tej samej bazy faktów:

Krok 6: Zamknij ćwiczenie wnioskami po incydencie

Zaktualizuj rejestr ryzyk, Deklarację stosowania, rejestr dostawców i plan reagowania na incydenty. Jeżeli ćwiczenie ujawni brakujące logi, niejasne kontakty z organami lub słabe klauzule dostawców, uruchom działania korygujące.

Zenith Blueprint, faza „Środki kontrolne w praktyce”, krok 23, instruuje organizacje, aby walidowały zdolności incydentowe w ten sposób:

Wybierz niedawne zdarzenie albo przeprowadź ćwiczenie typu tabletop, aby zwalidować plan. Zarejestruj wszystkie decyzje, role i komunikację (5.26) oraz zaktualizuj plan o wyciągnięte wnioski (5.27). Potwierdź, że istnieją procedury zabezpieczenia dowodów kryminalistycznych (5.28), w tym migawek logów, kopii zapasowych oraz bezpiecznej izolacji dotkniętych systemów.

Ten akapit jest agendą ćwiczenia gotową do audytu.

Logowanie: różnica między koordynacją a spekulacją

Koordynacja incydentu transgranicznego zawodzi, gdy wszyscy mają opinie, a nikt nie ma znaczników czasu.

Zenith Blueprint, faza „Środki kontrolne w praktyce”, krok 19, ujmuje to jasno:

Logowanie jest krwiobiegiem każdego bezpiecznego środowiska IT. Bez niego incydenty pozostają niewidoczne, rozliczalność zanika, a związki przyczynowo-skutkowe rozpływają się w powietrzu.

Dalej wskazuje:

W swojej istocie logowanie dotyczy identyfikowalności. Gdy coś idzie nie tak — niezależnie od tego, czy jest to nieudana próba logowania, usunięcie krytycznych plików, czy nieautoryzowany skrypt uruchomiony na serwerze — logi dostarczają kryminalistyczną nić, która pomaga rozplątać to, co naprawdę się wydarzyło.

W przypadku NIS2 logi wspierają 72-godzinne zgłoszenie incydentu zawierające początkową wagę, wpływ i wskaźniki naruszenia bezpieczeństwa. W przypadku DORA logi wspierają klasyfikację poważnego incydentu związanego z ICT, analizę przyczyny źródłowej, wpływ operacyjny i rozliczalność stron trzecich. W przypadku GDPR logi wspierają ocenę, czy uzyskano dostęp do danych osobowych lub czy je ujawniono. W kontekście Aktu o cybersolidarności logi wspierają wspólną świadomość sytuacyjną bez zmuszania zespołów reagowania do opierania się na spekulacjach.

Jeżeli odpowiedź na którekolwiek pytanie brzmi „nie wiadomo”, problem należy ująć w planie postępowania z ryzykiem.

Ciągłość działania i bezpieczne operacje kryzysowe

Rozmowa o Akcie o cybersolidarności naturalnie koncentruje się na reagowaniu na incydenty, ale odporność oznacza również utrzymanie bezpieczeństwa usług krytycznych podczas zakłócenia.

NIS2 Article 21 wymaga podejścia uwzględniającego wszystkie zagrożenia, obejmującego obsługę incydentów, ciągłość działania, zarządzanie kopiami zapasowymi, odtwarzanie po awarii, zarządzanie kryzysowe, bezpieczeństwo łańcucha dostaw, obsługę podatności, ocenę skuteczności, cyberhigienę, kryptografię, bezpieczeństwo HR, kontrolę dostępu, zarządzanie aktywami, uwierzytelnianie wieloskładnikowe, bezpieczną komunikację oraz zabezpieczoną komunikację awaryjną, jeżeli ma zastosowanie.

DORA podobnie wymaga ładu zarządczego, zarządzania ryzykiem ICT, zarządzania incydentami, testowania odporności, zarządzania ryzykiem stron trzecich, ciągłości działania i odtwarzania. Mniejsze podmioty mogą mieć uproszczone wymagania, ale nadal potrzebują udokumentowanego zarządzania ryzykiem ICT, monitorowania, odpornych systemów, obsługi incydentów, identyfikacji zależności od stron trzecich, kopii zapasowych, odtwarzania, testowania, uczenia się po incydencie i szkoleń.

Enterprise Polityka ciągłości działania i odtwarzania po awarii Polityka ciągłości działania i odtwarzania po awarii zaczyna od prostego wymagania:

Plany powinny obejmować:

Za tym sformułowaniem stoją dowody ciągłości działania, których oczekują audytorzy: priorytety odtwarzania, docelowe czasy odtworzenia, docelowe punkty odtworzenia, harmonogramy kopii zapasowych, testy odtwarzania, role kryzysowe, alternatywna komunikacja, zależności od dostawców i działania doskonalące po ćwiczeniach.

Kluczowe są tu środki kontrolne ISO/IEC 27002:2022 5.29 i 5.30. Środek kontrolny 5.29 dotyczy bezpieczeństwa informacji podczas zakłócenia. Środek kontrolny 5.30 dotyczy gotowości ICT do ciągłości działania. W Zenith Controls planowanie incydentowe w ramach 5.24 jest powiązane z bezpieczeństwem podczas zakłóceń i szerszym planowaniem ciągłości działania. Jest to szczególnie istotne, gdy normalne kanały są niedostępne, systemy tożsamości działają w trybie zdegradowanym lub zespoły kryzysowe muszą koordynować działania z organami poprzez zabezpieczoną komunikację awaryjną.

Mapa zgodności przekrojowej: NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 2019

CISO nie potrzebuje pięciu oddzielnych programów incydentowych. Potrzebuje jednego modelu dowodowego, który można oglądać przez pięć perspektyw.

Metoda profili Current i Target w NIST CSF 2.0 jest szczególnie użyteczna dla organizacji, które nie są jeszcze wystarczająco dojrzałe do pełnej zintegrowanej platformy GRC. Zachęca organizacje do określenia zakresu profilu, zebrania danych wejściowych, takich jak polityki, priorytety ryzyka przedsiębiorstwa, analizy wpływu na biznes, wymagania, normy, procedury, środki bezpieczeństwa i role, a następnie do analizy luk i utworzenia priorytetowego planu działań. To bardzo przypomina praktyczny sprint gotowości do Aktu o cybersolidarności: aktualne dowody, docelowe obowiązki, plan luk, właściciele, daty i ścieżka audytowa.

Audytorzy COBIT 2019 i pracujący zgodnie z praktyką ISACA zwykle pytają, czy cele ładu zarządczego mają właścicieli, są mierzone i monitorowane. Nie zadowoli ich odpowiedź „zajmuje się tym SOC”. Zapytają, w jaki sposób organy zarządcze zatwierdzają środki dotyczące ryzyka, jak raportowane są wyniki, jak nadzorowane jest ryzyko stron trzecich, jak akceptowane są wyjątki i jak śledzone są działania korygujące.

Jak audytorzy przetestują ten sam incydent

Ten sam incydent o 03:17 generuje różne pytania audytowe w zależności od mandatu oceniającego.

Audytor ISO/IEC 27001:2022 zacznie od SZBI. Zapyta, czy proces incydentowy jest w zakresie, czy wymagania zainteresowanych stron obejmują NIS2, DORA, GDPR i umowy, czy ocena ryzyka uwzględniała scenariusze transgraniczne i dostawcze, czy środki kontrolne z załącznika A zostały wybrane w Deklaracji stosowania oraz czy zapisy operacyjne dowodzą, że proces został zastosowany.

Organ lub oceniający skoncentrowany na NIS2 skupi się na rozliczalności kierownictwa, środkach zarządzania ryzykiem z Article 21 i raportowaniu z Article 23. Może zapytać, kiedy organizacja uzyskała wiedzę, dlaczego incydent był lub nie był znaczący, jak oceniono wpływ transgraniczny, czy poinformowano klientów oraz czy środki korygujące podjęto bez zbędnej zwłoki.

Nadzorca DORA lub zespół audytu wewnętrznego zapyta, czy incydent wpłynął na funkcje krytyczne lub ważne, czy zewnętrzni dostawcy ICT wsparli reakcję, czy podmiot finansowy zachował odpowiedzialność, czy rejestr informacji był dokładny, czy incydent sklasyfikowano prawidłowo oraz czy wnioski po incydencie wróciły do testowania odporności i nadzoru nad dostawcami.

Audytor GDPR lub organ ochrony danych zapyta, czy organizacja miała wystarczające dowody, aby ustalić, czy doszło do naruszenia danych osobowych, czy role administratora i podmiotu przetwarzającego były jasne, czy osoby, których dane dotyczą, były narażone na ryzyko, czy środki kontroli poufności i integralności były odpowiednie oraz czy utrzymywano zapisy rozliczalności.

Oceniający NIST CSF 2.0 przełoży zdarzenie na wyniki Govern, Identify, Protect, Detect, Respond i Recover. Będzie szukał oczekiwań interesariuszy, obowiązków prawnych, apetytu na ryzyko, nadzoru nad dostawcami, logowania, monitorowania, wykonania reakcji, komunikacji i walidacji odtwarzania.

Audytor COBIT 2019 lub ISACA skupi się na skuteczności ładu zarządczego i systemu zarządzania: własności, uprawnieniach decyzyjnych, metrykach, akceptacji ryzyka, wydajności procesu, zapewnieniu i ciągłym doskonaleniu.

Właśnie tutaj Zenith Controls jest użyteczny jako kompas zgodności przekrojowej. Nie zmienia nazw oficjalnych środków kontrolnych ani nie tworzy równoległych ram kontroli. Pokazuje, jak środki kontrolne ISO/IEC 27002:2022, takie jak 5.5, 5.24 i 5.28, łączą się ze zdolnościami operacyjnymi, powiązanymi kontrolami i dowodami istotnymi dla audytu.

Co CISO powinni zrobić teraz, aby przygotować się na 2026 r.

Jeżeli przygotowujesz się na operacyjną rzeczywistość Aktu UE o cybersolidarności, zacznij od dowodów, nie od haseł.

Po pierwsze, zaktualizuj kontekst SZBI i analizę zainteresowanych stron. Ustal, czy wasza organizacja, klienci lub dostawcy podlegają NIS2, DORA lub GDPR. Uwzględnij obecność w państwach członkowskich, klasyfikację sektorową, klientów krytycznych, zależności od usług ICT i kontakty z organami.

Po drugie, przeprowadź ćwiczenie tabletop dla incydentu transgranicznego. Użyj scenariusza obejmującego dostawcę, więcej niż jedno państwo członkowskie, możliwą ekspozycję danych osobowych i regulowanego klienta finansowego. Ogranicz czasowo pierwsze 24 godziny.

Po trzecie, przejrzyj umowy z dostawcami. Potwierdź obowiązki powiadamiania, dostęp do logów, wsparcie kryminalistyczne, współpracę z organami, przeniesienie obowiązków na podwykonawców, lokalizację danych, prawo do audytu, wsparcie ciągłości działania i prawa do rozwiązania umowy.

Po czwarte, przetestuj zabezpieczanie materiału dowodowego. Wyeksportuj logi, zabezpiecz migawki, oznacz dowody, zarejestruj łańcuch dowodowy i zwaliduj dostęp do repozytorium. Jeżeli polityka mówi, że dowody są jednoznacznie identyfikowane i bezpiecznie przechowywane, wykaż to.

Po piąte, uzgodnij komunikację incydentową. Wczesne ostrzeżenie NIS2, eskalacja DORA, ocena naruszenia GDPR i powiadomienie klienta nie powinny sobie przeczyć. Mogą mieć różne cele prawne, ale muszą pochodzić z tej samej bazy faktów.

Po szóste, włącz zarząd do ćwiczenia. NIS2 i DORA podnoszą rozliczalność kierownictwa. Klauzule przywództwa ISO/IEC 27001:2022 czynią to audytowalnym. Zarząd, który nigdy nie widział 24-godzinnego zegara zgłoszenia incydentu cyberbezpieczeństwa, nie jest gotowy na kryzys transgraniczny.

Następne kroki z Clarysec

Przyszłość cyberbezpieczeństwa w UE opiera się na współpracy i udowodnionym zaufaniu. Organizacje, które traktują NIS2 i DORA jako odizolowane listy kontrolne, będą miały trudności podczas incydentów transgranicznych. Organizacje, które budują oparte na dowodach systemy operacyjne ISO/IEC 27001:2022, będą potrafiły odpowiadać regulatorom, klientom, audytorom i zespołom reagowania kryzysowego z pewnością.

Clarysec pomaga CISO, menedżerom zgodności, audytorom i właścicielom biznesowym przekształcać unijne regulacje cyberbezpieczeństwa w gotowe do audytu dowody operacyjne poprzez:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap dla ustrukturyzowanego wdrożenia ISO/IEC 27001:2022 i sekwencjonowania audytu.
• Zenith Controls: The Cross-Compliance Guide do mapowania środków kontrolnych dotyczących incydentów, organów, dostawców, dowodów, logowania i ciągłości działania między ramami.
• Szablony polityk Clarysec, w tym Polityka reagowania na incydenty, Polityka zabezpieczania materiału dowodowego i informatyki śledczej, Polityka bezpieczeństwa dostawców i stron trzecich, Polityka ciągłości działania i odtwarzania po awarii, a także wersje dla MŚP tam, gdzie znaczenie ma proporcjonalność.

Najlepszy czas na przygotowanie do koordynacji incydentu transgranicznego jest przed alertem o 03:17. Drugi najlepszy czas jest dziś.

Zacznij od przeglądu gotowości Clarysec, pobierz odpowiedni zestaw polityk albo poproś o omówienie, jak Zenith Blueprint i Zenith Controls mogą pomóc twojemu SZBI wytwarzać dowody, których odporność cybernetyczna w 2026 r. będzie wymagać.