Klasyfikacja istotności incydentów dla DORA, NIS2 i GDPR

Telefon o incydencie o 02:17, który staje się decyzją regulacyjną

O 02:17 w czwartkowy poranek Sarah, CISO FinScale, widzi pierwszy alert: anomalny ruch API, gwałtowny wzrost liczby nieudanych uwierzytelnień oraz opóźnienie panelu płatności przekraczające 3000 ms. W ciągu kilku minut obsługa klienta zgłasza błędy statusu płatności. Dostawca chmury informuje, że nie występuje incydent obejmujący całą platformę. SOC widzi podejrzane tokeny dostępu z dwóch regionów geograficznych. Zespół produktowy potwierdza, że panel wrócił online po 19 minutach, ale dwunastu klientów zdążyło już otworzyć zgłoszenia.

O 03:05 Sarah uczestniczy już w telekonferencji sztabu incydentowego z kierownikiem incydentu, doradcą prawnym, koordynatorem ds. prywatności, osobą odpowiedzialną za operacje chmurowe oraz sponsorem ze strony kierownictwa. Pytanie techniczne jest dość jasne: co stało się z bramą API? Pytania regulacyjne są trudniejsze:

1. Czy jest to poważny incydent związany z ICT w rozumieniu DORA?
2. Czy jest to istotny incydent w rozumieniu NIS2?
3. Czy wystąpiło naruszenie ochrony danych osobowych w rozumieniu GDPR wymagające zgłoszenia?
4. Czy organizacja może wykazać, w jaki sposób doszła do tych odpowiedzi?

Błędna odpowiedź może stworzyć ekspozycję regulacyjną. Zbyt wolna odpowiedź może spowodować przekroczenie terminu zgłoszenia. Odpowiedź nieudokumentowana może nie przejść audytu ISO/IEC 27001:2022 kilka miesięcy później.

To jest wyzwanie reagowania na incydenty w 2026 r. Wiele organizacji ma plan reagowania na incydenty, procedury informatyki śledczej, podręczniki prywatności oraz szablony komunikacji kryzysowej. Znacznie mniej organizacji ma możliwy do obrony model klasyfikacji istotności incydentów, który przekształca zaszumione zdarzenie bezpieczeństwa w udokumentowaną decyzję zgodną z oczekiwaniami dowodowymi DORA, NIS2, GDPR i ISO/IEC 27001:2022.

Rozwiązaniem nie są trzy odrębne procesy wstępnej kwalifikacji. Rozwiązaniem jest jeden nadzorowany model istotności incydentów z odrębnymi nakładkami regulacyjnymi, mierzalnymi progami, zasadami eskalacji, rejestrami decyzji oraz wymaganiami dotyczącymi gromadzenia materiału dowodowego. W praktyce istotność incydentu nie powinna być etykietą wybieraną pod presją. Powinna być kontrolowaną decyzją biznesową, która wytrzyma weryfikację regulatorów, audytorów, członków zarządu, klientów oraz IOD.

Dlaczego klasyfikacja istotności incydentów jest obecnie mechanizmem kontrolnym na poziomie zarządu

Klasyfikacja incydentów była kiedyś przede wszystkim techniczna: poziom zagrożenia złośliwym oprogramowaniem, dotknięte hosty, wykorzystane podatności oraz to, czy doszło do eksfiltracji danych. W 2026 r. jest również prawna, finansowa, społeczna i umowna.

DORA czyni cyfrową odporność operacyjną obowiązkiem ładu zarządczego podmiotów finansowych. Od organu zarządzającego oczekuje się zdefiniowania, zatwierdzenia i nadzorowania ram zarządzania ryzykiem ICT oraz zachowania odpowiedzialności za te ramy. Obejmuje to ciągłość działania ICT, plany reagowania i odtwarzania, kanały zgłaszania poważnych incydentów, ryzyko stron trzecich ICT oraz wnioski z incydentów.

NIS2 podnosi znaczenie ładu zarządczego dla podmiotów kluczowych i ważnych. Article 20 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorowały ich wdrożenie oraz uczestniczyły w szkoleniach. Łączy również nieskuteczność zarządzania ryzykiem i zgłaszania incydentów z poważnymi konsekwencjami nadzorczymi. W przypadku podmiotów kluczowych maksymalne administracyjne kary pieniężne mogą wynosić co najmniej 10 000 000 EUR albo 2 procent całkowitego rocznego światowego obrotu, zależnie od tego, która wartość jest wyższa. W przypadku podmiotów ważnych próg wynosi co najmniej 7 000 000 EUR albo 1,4 procent obrotu, zależnie od tego, która wartość jest wyższa.

GDPR dodaje inną perspektywę. Naruszenie ochrony danych osobowych nie ogranicza się do potwierdzonego publicznego ujawnienia lub skradzionych plików. Obejmuje przypadkowe lub niezgodne z prawem zniszczenie, utratę, zmianę, nieuprawnione ujawnienie danych osobowych lub nieuprawniony dostęp do nich. Administratorzy muszą ocenić ryzyko dla osób fizycznych i wykazać rozliczalność decyzji o zgłoszeniu albo braku zgłoszenia.

ISO/IEC 27001:2022 zapewnia tym obowiązkom strukturę dowodową. Klauzule 4.1 do 4.4 wymagają, aby organizacja rozumiała swój kontekst, wymagania stron zainteresowanych, zakres, interfejsy i zależności. Klauzule 5.1 do 5.3 wymagają zaangażowania kierownictwa, polityki, ról, odpowiedzialności i raportowania. Klauzule 6.1.1 do 6.1.3 wymagają planowania opartego na ryzyku, oceny ryzyka, postępowania z ryzykiem oraz Deklaracji stosowania. Klauzule 8.1 do 8.3 wymagają kontroli operacyjnej, kontroli zmian, zachowanych dowodów oraz ponownej oceny, gdy zmieniają się warunki ryzyka. ISO/IEC 27001:2022

Gdy odbywa się rozmowa dotycząca incydentu, pytanie nie powinno brzmieć: „Kto uważa, że to jest krytyczne?”. Powinno brzmieć: „Czego wymagają od nas teraz zatwierdzone kryteria, przesłanki prawne, dowody i zasady eskalacji?”.

Jedno zdarzenie, trzy systemy klasyfikacji regulacyjnej

DORA, NIS2 i GDPR nie używają tego samego języka w odniesieniu do incydentów. To główny powód, dla którego organizacje mają trudności w pierwszej godzinie.

DORA Article 17 wymaga od podmiotów finansowych ustanowienia procesu zarządzania incydentami związanymi z ICT, który wykrywa incydenty ICT, zarządza nimi i dokonuje zgłoszeń, rejestruje incydenty związane z ICT oraz istotne cyberzagrożenia, usuwa przyczyny źródłowe, wykorzystuje wskaźniki wczesnego ostrzegania, kategoryzuje i klasyfikuje incydenty, przypisuje role, zarządza komunikacją, eskaluje poważne incydenty do kadry kierowniczej wyższego szczebla oraz przywraca bezpieczne operacje.

DORA Article 18 wymaga klasyfikacji z użyciem kryteriów takich jak dotknięci klienci, dotknięte strony transakcji, transakcje, czas trwania, przestój, zasięg geograficzny, utrata danych wpływająca na dostępność, autentyczność, integralność lub poufność, krytyczność dotkniętych usług oraz wpływ ekonomiczny. DORA Article 19 wymaga zgłaszania poważnych incydentów związanych z ICT oraz komunikacji z klientami, jeżeli dotknięte są ich interesy finansowe.

NIS2 Article 23 definiuje istotny incydent jako incydent, który spowodował lub może spowodować poważne zakłócenie operacyjne lub stratę finansową albo wpłynął lub może wpłynąć na inne podmioty, powodując znaczną szkodę materialną lub niematerialną. Wymaga wczesnego ostrzeżenia w ciągu 24 godzin od uzyskania wiedzy o istotnym incydencie, zgłoszenia incydentu w ciągu 72 godzin, raportów pośrednich na żądanie oraz raportu końcowego w ciągu miesiąca od zgłoszenia incydentu. W stosownych przypadkach dotknięci odbiorcy usług muszą również zostać poinformowani o środkach lub działaniach naprawczych, które mogą podjąć.

GDPR stawia pytanie o ryzyko dla prywatności. Czy naruszenie bezpieczeństwa spowodowało zniszczenie, utratę, zmianę, nieuprawnione ujawnienie danych osobowych lub nieuprawniony dostęp do nich? Jeżeli tak, administrator musi ocenić ryzyko dla praw i wolności osób fizycznych. Jeżeli naruszenie może skutkować ryzykiem, organ nadzorczy co do zasady należy powiadomić w ciągu 72 godzin od uzyskania wiedzy. Jeżeli może skutkować wysokim ryzykiem, konieczne może być poinformowanie osób, których dane dotyczą, bez zbędnej zwłoki.

Pojedynczy incydent wymaga zatem równoległej klasyfikacji.

Dla podmiotów finansowych DORA jest sektorowym aktem prawnym Unii dotyczącym zarządzania ryzykiem ICT oraz obowiązków zgłaszania incydentów, które nakładają się na NIS2. Nie oznacza to, że NIS2 przestaje mieć znaczenie. Może nadal mieć znaczenie dla współpracy, przepływów informacji, usług poza perymetrem DORA, niefinansowych podmiotów grupy, usług chmurowych, usług zarządzanych oraz umownych zobowiązań wobec klientów. Model istotności incydentów powinien rejestrować nie tylko wynik, lecz także logikę stosowalności.

Model Clarysec: klasyfikuj zdarzenie, nie emocje

Clarysec zaczyna od środka kontrolnego ISO/IEC 27002:2022 5.25, dotyczącego oceny zdarzeń związanych z bezpieczeństwem informacji i podejmowania decyzji, jako wspólnego punktu odniesienia dla zgodności. W Zenith Controls: The Cross-Compliance Guide Zenith Controls ten temat jest zmapowany przez pozycję „Ocena zdarzeń związanych z bezpieczeństwem informacji i podejmowanie decyzji” dla środka kontrolnego 5.25, wspieraną przez „Planowanie i przygotowanie do zarządzania incydentami bezpieczeństwa informacji” dla środka kontrolnego 5.24 oraz „Gromadzenie materiału dowodowego” dla środka kontrolnego 5.28.

Najważniejszym momentem zgodności często nie jest powstrzymanie incydentu. Jest nim punkt decyzyjny, w którym zdarzenie bezpieczeństwa staje się incydentem regulacyjnym albo zostaje w sposób możliwy do obrony zarejestrowane jako zdarzenie o niższej istotności.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Clarysec Zenith Blueprint opisuje ten moment w fazie Stosowanie środków kontrolnych, krok 23:

„Nie każda anomalia jest katastrofą. Nie każdy alert oznacza naruszenie bezpieczeństwa. W realnym świecie zespoły bezpieczeństwa i jednostki biznesowe są zalewane szumem: próbami logowania, anomaliami w logach, drobnymi naruszeniami polityk, aktywnością shadow IT. Prawdziwym wyzwaniem nie jest samo wykrycie, lecz odróżnienie nieszkodliwego od szkodliwego oraz wiedza, co wymaga eskalacji.”

To zdanie oddaje problem operacyjny. Alert SIEM nie oznacza automatycznie poważnego incydentu DORA. Tymczasowa niedostępność nie oznacza automatycznie istotnego incydentu NIS2. Podejrzane zapytanie do bazy danych nie oznacza automatycznie naruszenia podlegającego zgłoszeniu według GDPR. Każde z nich może stać się zdarzeniem podlegającym zgłoszeniu w zależności od wpływu, zakresu, danych, dotkniętych stron oraz dowodów.

Zenith Blueprint, faza Zarządzanie ryzykiem, krok 10, zaleca również, aby definicje wpływu dostosować do skali działalności i ekspozycji regulacyjnej:

„Przy definiowaniu wpływu warto powiązać poziomy z konkretną skalą działalności. Na przykład: „Poważny wpływ finansowy = strata > 100 tys. USD” (dostosuj do swojego kontekstu). Należy też uwzględnić wpływ regulacyjny: na przykład naruszenie ochrony danych osobowych może automatycznie być „poważne” lub „krytyczne” ze względu na kary i wymagania zgłoszeniowe GDPR, nawet jeśli bezpośrednia strata finansowa jest niejasna.”

To jest zasada projektowa klasyfikacji istotności incydentów na 2026 r.: istotność incydentu to wpływ biznesowy plus wpływ prawny plus pewność materiału dowodowego.

Praktyczna taksonomia istotności incydentów dla DORA, NIS2 i GDPR

Możliwa do obrony taksonomia powinna oddzielać wewnętrzny poziom istotności incydentu od klasyfikacji regulacyjnej. Wewnętrzny poziom istotności decyduje o pilności reakcji, alokacji zasobów i eskalacji do kierownictwa. Klasyfikacja regulacyjna decyduje o zgłoszeniu, przeglądzie prawnym i komunikacji zewnętrznej.

Wewnętrzny poziom istotności nie jest końcową odpowiedzią regulacyjną. Jest trybem operacyjnym. Zdarzenie SEV 3 może stać się naruszeniem podlegającym zgłoszeniu według GDPR po przeglądzie logów. Niedostępność SEV 2 może nie być poważnym incydentem DORA, jeżeli progi wpływu nie zostały spełnione. Incydent ransomware SEV 1 może jednocześnie uruchomić DORA, NIS2, GDPR, umowy z klientami oraz koordynację z organami ścigania.

Bardziej szczegółowa macierz klasyfikacji pomaga zespołowi przejść od alertu do działania.

Model powinien być osadzony w polityce, a nie pozostawiony podczas telekonferencji kryzysowej osobie o najsilniejszym głosie. Polityka dla SME Incident Response Policy-sme Incident Response Policy-sme - SME, Wymagania dotyczące ładu, klauzula 5.3.1, stanowi:

„Dyrektor Generalny, przy udziale dostawcy IT, musi sklasyfikować wszystkie incydenty według istotności w ciągu jednej godziny od powiadomienia.”

Ta sama polityka dla SME, Postępowanie z ryzykiem i wyjątki, klauzula 7.4.1, dodaje:

„Jeżeli zdarzenie obejmuje dane klientów, Dyrektor Generalny musi ocenić prawne obowiązki zgłoszeniowe na podstawie stosowalności GDPR, NIS2 lub DORA.”

Dla większych organizacji korporacyjna Incident Response Policy Incident Response Policy, Wymagania dotyczące ładu, klauzula 5.3, formalizuje tę samą koncepcję:

„Klasyfikację incydentów należy prowadzić według modelu warstwowego:”

Język polityki ma znaczenie, ponieważ regulatorzy i audytorzy zapytają, czy kryteria klasyfikacji istniały przed incydentem. Macierz wymyślona po fakcie jest słabym dowodem. Macierz zatwierdzona, objęta szkoleniami, przećwiczona i stosowana konsekwentnie jest możliwa do obrony.

Rejestr decyzji: najważniejszy artefakt dowodowy

Gdy audytorzy, regulatorzy lub członkowie zarządu analizują incydent, rzadko pytają tylko: „Co się stało?”. Pytają: „Kiedy wiedzieliście, kto zdecydował, na podstawie jakich dowodów i dlaczego nie zgłosiliście wcześniej?”.

Dlatego Clarysec rekomenduje prowadzenie rejestru decyzji o istotności incydentu dla każdego zdarzenia SEV 3 i wyższego oraz dla każdego zdarzenia obejmującego dane osobowe, usługi krytyczne, klientów finansowych, usługi zarządzane, infrastrukturę chmurową lub wpływ transgraniczny.

To mapuje się bezpośrednio na ISO/IEC 27001:2022. Klauzula 8.1 wymaga, aby procesy były planowane, wdrażane i kontrolowane, a wystarczające udokumentowane informacje były zachowywane w celu wykazania, że działały zgodnie z planem. Klauzule 8.2 i 8.3 wymagają ponownej oceny w przypadku wystąpienia istotnych zmian oraz zachowania dowodów postępowania z ryzykiem. Środki kontrolne z Załącznika A od A.5.24 do A.5.28 tworzą kręgosłup zarządzania incydentami: planowanie i przygotowanie, ocena zdarzeń i decyzja, reakcja, uczenie się z incydentów oraz gromadzenie materiału dowodowego.

Polityka SME Data Protection and Privacy Policy-sme Data Protection and Privacy Policy-sme - SME, Egzekwowanie i zgodność, klauzula 8.3.2, wspiera część modelu dotyczącą GDPR:

„Koordynator ds. prywatności określi istotność, zainicjuje działania powstrzymujące i udokumentuje sprawę”

Ocena prywatności nie powinna zaczynać się dopiero wtedy, gdy zegar regulacyjny staje się niewygodny. Powinna być częścią procesu wstępnej kwalifikacji.

Przykład praktyczny: klasyfikacja incydentu API Sarah

Wróćmy do FinScale. Jest to platforma fintech B2B korzystająca z infrastruktury chmurowej, zewnętrznego dostawcy analityki oszustw oraz dostawcy zarządzanych usług bezpieczeństwa. W odniesieniu do części działalności jest podmiotem finansowym objętym DORA. Jest również dostawcą usług cyfrowych z operacjami istotnymi dla NIS2 w jednym państwie członkowskim. Przetwarza dane osobowe klientów jako administrator dla usług kont oraz jako podmiot przetwarzający dla części klientów korporacyjnych.

O 02:17 wykryto anomalny ruch API. O 02:35 otwarto zgłoszenie incydentu. O 03:00 Sarah kończy wstępną kwalifikację z kierownikiem incydentu.

Po pierwsze, ustalono wewnętrzny poziom istotności. Incydent wpłynął na dostępność panelu klienta przez 19 minut, obejmował podejrzane tokeny dostępu i dotknął krytycznej funkcji dostępnej dla klientów. Został sklasyfikowany jako SEV 3 Umiarkowany do czasu potwierdzenia, z eskalacją do kierownika incydentu, koordynatora ds. prywatności, doradcy prawnego oraz właściciela usługi.

Po drugie, zakończono weryfikację DORA. Zespół sprawdza dotkniętych klientów, strony transakcji, transakcje, czas trwania, przestój, zasięg geograficzny, utratę danych, krytyczność i wpływ ekonomiczny. Nie potwierdzono nieudanych ani zmienionych transakcji. Przestój jest ograniczony. Utrata danych nie została wykazana. Ponieważ jednak może być dotknięty krytyczny komponent usługi finansowej oraz interesy finansowe klientów, incydent pozostaje monitorowany pod kątem DORA i może zostać reklasyfikowany.

Po trzecie, zarejestrowano weryfikację NIS2. Zespół odnotowuje, że DORA jest podstawowym sektorowym reżimem zgłaszania dla obowiązków objętego regulacją podmiotu finansowego. Sprawdza również, czy incydent wpływa na usługi lub klientów poza perymetrem DORA. Na tym etapie nie potwierdzono poważnego zakłócenia operacyjnego ani znacznej szkody.

Po czwarte, rozpoczęto weryfikację GDPR. Podejrzane tokeny mogły umożliwić dostęp do danych w panelu klienta. Koordynator ds. prywatności dokumentuje kategorie danych, dotkniętych użytkowników, zakres tokenów, przejrzane logi, informację, czy dane były przeglądane lub eksportowane, oraz środki bezpieczeństwa, takie jak unieważnienie tokenu i kontrola dostępu.

O 04:20 analiza logów pokazuje, że dwa tokeny zostały użyte do dostępu do metadanych panelu 41 klientów, obejmujących imiona i nazwiska, identyfikatory kont oraz status transakcji, ale bez danych uwierzytelniających płatności ani dokumentów tożsamości. Zespół aktualizuje incydent do SEV 2 Poważny, ponieważ naruszona została poufność danych osobowych i może być wymagana komunikacja z klientami. IOD ocenia ryzyko GDPR dla osób fizycznych. Decyzja DORA zostaje ponownie przeanalizowana na podstawie wpływu na klientów, wpływu na transakcje i wpływu ekonomicznego.

Na tym polega praktyczna wartość modelu. Klasyfikacja początkowa nie jest końcowym wnioskiem prawnym. Jest decyzją opartą na dowodach, którą można aktualizować wraz z rozwojem ustaleń.

Logowanie, monitorowanie i materiał dowodowy informatyki śledczej: warstwa dowodowa

Model istotności incydentów bez dowodów jest opinią ze spotkania. Oczekiwanie na 2026 r. jest takie, że klasyfikacja jest wspierana przez logi, monitorowanie, zabezpieczone artefakty oraz łańcuch dowodowy.

Polityka SME Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME, Egzekwowanie i zgodność, klauzula 8.3.4, stanowi:

„Dochodzenia dotyczące naruszeń muszą być wspierane odpowiednimi logami, aby spełnić zasadę rozliczalności wynikającą z GDPR i DORA”

Równie ważne jest postępowanie z materiałem dowodowym informatyki śledczej. Polityka SME Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy-sme - SME, Wymagania dotyczące ładu, klauzula 5.3.1, wymaga:

„Dla każdego incydentu należy prowadzić prosty rejestr łańcucha dowodowego, np. plik Excel lub dokument szablonowy.”

W środowiskach korporacyjnych Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy, Wymagania dotyczące ładu, klauzula 5.5, wymaga:

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

Zenith Blueprint, faza Stosowanie środków kontrolnych, krok 23, wyjaśnia, dlaczego ma to znaczenie dla środka kontrolnego ISO/IEC 27002:2022 5.28:

„Gdy dochodzi do incydentu bezpieczeństwa informacji, jednym z najbardziej krytycznych, a zarazem często pomijanych elementów reakcji jest materiał dowodowy. Nie logi, nie zrzuty ekranu, nie luźne narracje, lecz właściwie zabezpieczone, respektujące łańcuch dowodowy i odporne na manipulację dowody.”

Praktyczny pakiet dowodowy dla poważnego lub potencjalnie podlegającego zgłoszeniu incydentu powinien obejmować:

• Zgłoszenie incydentu i oś czasu
• Rejestr decyzji o istotności incydentu i historię reklasyfikacji
• Alerty SIEM, alerty EDR, logi chmurowe i logi tożsamości
• Logi dostępu do danych i logi eksportu
• Wpisy inwentarza dotkniętych aktywów i usług
• Ocenę wpływu na klientów, transakcje i geografię
• Arkusz weryfikacji DORA, NIS2 i GDPR
• Ocenę IOD lub prawną
• Zatwierdzenia komunikacji i wysłane komunikaty
• Zapis łańcucha dowodowego
• Analizę przyczyny źródłowej
• Działania korygujące i wnioski z incydentu

Ten pakiet dowodowy wspiera również środki kontrolne ISO/IEC 27001:2022 Załącznik A: A.8.15 rejestrowanie, A.8.16 działania monitorujące, A.5.28 gromadzenie materiału dowodowego, A.5.27 uczenie się z incydentów bezpieczeństwa informacji, A.5.31 wymagania prawne, ustawowe, regulacyjne i umowne oraz A.5.34 prywatność i ochrona danych osobowych umożliwiających identyfikację osoby.

Mapowanie zgodności krzyżowej: zbuduj raz, odpowiadaj wielu audytorom

Najsilniejsze modele istotności incydentów są budowane raz i mapowane wielokrotnie. Zenith Controls zaprojektowano jako kompas zgodności krzyżowej dla tej pracy. W tym obszarze podstawowe pozycje ISO/IEC 27002:2022 to 5.24 planowanie i przygotowanie do zarządzania incydentami bezpieczeństwa informacji, 5.25 ocena zdarzeń związanych z bezpieczeństwem informacji i podejmowanie decyzji, 5.26 reagowanie na incydenty bezpieczeństwa informacji, 5.27 uczenie się z incydentów bezpieczeństwa informacji oraz 5.28 gromadzenie materiału dowodowego.

Te środki kontrolne naturalnie łączą się z systemem zarządzania ISO/IEC 27001:2022. Klauzule 4, 5, 6 i 8 definiują zakres, przywództwo, kryteria ryzyka, postępowanie z ryzykiem oraz dowody operacyjne. ISO/IEC 27002:2022 zapewnia język wdrożenia środków kontrolnych. Myślenie o ciągłości działania w stylu ISO 22301 wspiera progi zakłóceń, priorytety odzyskiwania i zarządzanie kryzysowe. Praktyki zarządzania incydentami w stylu ISO/IEC 27035 wspierają ustrukturyzowane wykrywanie, zgłaszanie, ocenę, reakcję i uczenie się. Ład prywatności w stylu ISO/IEC 27701 wspiera role związane z naruszeniami ochrony danych osobowych, kwestie administratora i podmiotu przetwarzającego, dowody prywatności oraz rozliczalność.

Ten sam model mapuje się na NIST Cybersecurity Framework 2.0. Funkcja GOVERN wymaga, aby obowiązki prawne, regulacyjne, umowne, dotyczące prywatności i swobód obywatelskich były rozumiane i zarządzane. Oczekuje również zdefiniowania apetytu na ryzyko, ról, uprawnień, polityk i nadzoru. Funkcje DETECT, RESPOND i RECOVER wspierają wstępną kwalifikację, analizę, eskalację, powstrzymanie, odtworzenie, komunikację i doskonalenie.

Korzyść jest praktyczna. Gdy nadzorca DORA pyta o uzasadnienie poważnego incydentu związanego z ICT, organ NIS2 pyta o decyzję dotyczącą wczesnego ostrzeżenia w ciągu 24 godzin, organ ochrony danych pyta, dlaczego dokonano albo nie dokonano zgłoszenia GDPR, a audytor ISO pyta, czy SZBI działał zgodnie z planem, organizacja może odpowiedzieć na podstawie tego samego zestawu dowodów.

Jak audytorzy i regulatorzy będą testować Twój model

Audytor ISO/IEC 27001:2022 zwykle zacznie od zakresu i wymagań prawnych. Zapyta, czy DORA, NIS2, GDPR, umowy z klientami oraz obowiązki wobec stron trzecich ICT zostały zidentyfikowane jako wymagania stron zainteresowanych. Następnie prześledzi ścieżkę do kryteriów ryzyka, Deklaracji stosowania, procedur incydentowych, zapisów operacyjnych i przechowywania dowodów. Będzie oczekiwać dowodu, że proces klasyfikacji nie został wymyślony w trakcie incydentu.

Nadzorca DORA lub zespół audytu wewnętrznego będzie szukał pętli cyklu życia: procesu zarządzania incydentami, wskaźników wczesnego ostrzegania, kryteriów klasyfikacji, eskalacji poważnego incydentu, komunikacji z klientami, przyczyny źródłowej, końcowych wartości wpływu, testowania odporności oraz nadzoru organu zarządzającego. Zapyta również, czy uwzględniono zależności od stron trzecich ICT, zwłaszcza gdy w łańcuch incydentu były zaangażowane chmura, SaaS, zarządzane bezpieczeństwo lub dostawcy outsourcingowi.

Audytor lub organ skoncentrowany na NIS2 sprawdzi, czy podmiot potrafi identyfikować istotne incydenty, dotrzymywać etapowych terminów, komunikować się z dotkniętymi odbiorcami usług i dostarczyć dowody oceny wpływu transgranicznego. Połączy obsługę incydentów ze środkami zarządzania ryzykiem z Article 21, w tym z ciągłością działania, zarządzaniem kryzysowym, bezpieczeństwem łańcucha dostaw, kontrolą dostępu, zarządzaniem aktywami i szkoleniami.

IOD GDPR lub organ nadzorczy zbada, czy organizacja zidentyfikowała dane osobowe, role, osoby, których dane dotyczą, kategorie, dotknięte systemy, typ naruszenia oraz ryzyko dla osób fizycznych. Sprawdzi, czy administrator może wykazać rozliczalność oraz czy powiadomienia podmiotu przetwarzającego do administratorów były terminowe i kompletne.

Audytor działający w perspektywie ISACA lub COBIT 2019 skoncentruje się na dowodach ładu zarządczego. Kto zatwierdził taksonomię istotności incydentów? Kto jest właścicielem ryzyka? Jakie metryki są raportowane kierownictwu? Jak obsługiwane są wyjątki? Jak wnioski z incydentów są przekształcane w usprawnienia środków kontrolnych?

Typowe wzorce niepowodzeń w klasyfikacji incydentów

Pierwszym niepowodzeniem jest myślenie jedną etykietą. Zespoły klasyfikują zdarzenie jako wysokie, średnie lub niskie, ale nie oceniają oddzielnie przesłanek DORA, NIS2 i GDPR. Skutkiem jest etykieta istotności, która nie potrafi wyjaśnić decyzji o zgłoszeniu.

Drugim niepowodzeniem jest uprzedzenie na rzecz potwierdzonego naruszenia. Zespoły czekają na absolutny dowód eksfiltracji, zanim zaangażują prywatność lub dział prawny. Ocena naruszenia według GDPR często zaczyna się od możliwego nieuprawnionego dostępu, utraty, zmiany lub ujawnienia, a nie dopiero od potwierdzonej publikacji danych.

Trzecim niepowodzeniem jest chaos czasowy. Terminy NIS2 i GDPR zależą od uzyskania wiedzy i oceny. Jeżeli zgłoszenie incydentu nie obejmuje czasu uzyskania wiedzy, czasu klasyfikacji i czasu eskalacji, organizacja może mieć trudność z wykazaniem terminowości.

Czwartym niepowodzeniem jest informatyka śledcza uruchamiana dopiero po sprzątaniu. Inżynierowie rotują klucze, odbudowują hosty i usuwają tymczasowe dowody, zanim zostanie uruchomiony tryb dochodzeniowy. Może to zniszczyć dowody potrzebne do przeglądu regulacyjnego, umownego lub prawnego.

Piątym niepowodzeniem jest ślepota na dostawców. DORA, NIS2 i NIST CSF 2.0 podkreślają ryzyko stron trzecich i łańcucha dostaw. Jeżeli dostawca chmury, dostawca usług zarządzanych, procesor płatności, dostawca tożsamości lub dostawca SaaS jest częścią łańcucha incydentu, model klasyfikacji musi uwzględniać wpływ dostawcy oraz umowne obowiązki powiadamiania.

Lista kontrolna wdrożenia Clarysec na 2026 r.

Aby zoperacjonalizować możliwy do obrony model klasyfikacji istotności incydentów, Clarysec rekomenduje następującą sekwencję:

1. Potwierdź stosowalność regulacyjną w zakresie DORA, NIS2, GDPR, umów z klientami oraz przepisów sektorowych.
2. Zaktualizuj zakres SZBI i wymagania stron zainteresowanych zgodnie z ISO/IEC 27001:2022.
3. Zdefiniuj wewnętrzne poziomy istotności z mierzalnymi progami dla przestojów, danych, klientów, geografii, strat finansowych i krytyczności.
4. Dodaj odrębne pytania weryfikacyjne DORA, NIS2 i GDPR do przepływu zgłoszenia incydentu.
5. Zdefiniuj wyzwalacze eskalacji do kierownika incydentu, IOD, działu prawnego, kadry kierowniczej wyższego szczebla i zarządu.
6. Utwórz szablon rejestru decyzji o istotności incydentu.
7. Powiąż klasyfikację z gromadzeniem materiału dowodowego oraz procedurami łańcucha dowodowego.
8. Zweryfikuj pokrycie logowaniem dla zdarzeń tożsamości, chmury, aplikacji, baz danych, sieci i dostawców.
9. Przeprowadź ćwiczenia tabletop dla scenariuszy poważnego incydentu DORA, istotnego incydentu NIS2 oraz naruszenia GDPR.
10. Wprowadź wnioski z incydentów do postępowania z ryzykiem, Deklaracji stosowania, szkoleń i testowania odporności.

Zenith Blueprint, faza Stosowanie środków kontrolnych, krok 16, wzmacnia ludzki aspekt tego modelu: zgłoszenia powinny być rejestrowane, poddawane wstępnej kwalifikacji, eskalowane przez plan reagowania na incydenty, a nawet drobne zdarzenia powinny być śledzone, ponieważ trendy ujawniają słabości kontroli. Promuje podejście niskiego progu zgłaszania: „W razie wątpliwości zgłoś”.

Ten element kultury jest krytyczny. Model istotności incydentów zawodzi, jeżeli pracownicy opóźniają zgłoszenie z obawy przed nadmierną reakcją. Celem jest szybkie zgłaszanie, zdyscyplinowana wstępna kwalifikacja i możliwa do obrony klasyfikacja.

Zamień niepewność incydentu w dowody gotowe do audytu

W 2026 r. klasyfikacja istotności incydentów nie jest już decyzją wyłącznie SOC. Jest regulowanym procesem ładu zarządczego, który musi łączyć kryteria poważnego incydentu związanego z ICT w DORA, progi istotnego incydentu w NIS2, ryzyko naruszenia w GDPR oraz dowody ISO/IEC 27001:2022.

Organizacje, które najlepiej radzą sobie podczas incydentów, nie będą tymi z najgrubszym segregatorem procedur reakcji. Będą nimi te, które potrafią szybko odpowiedzieć na cztery pytania i później udowodnić każdą odpowiedź:

• Co się stało?
• Jak poważne jest to zdarzenie?
• Jakie obowiązki regulacyjne mogą mieć zastosowanie?
• Jakie dowody wspierają decyzję?

Clarysec pomaga organizacjom budować ten pomost przez szablony polityk, taksonomie istotności incydentów, rejestry decyzji, scenariusze tabletop oraz mapowania zgodności krzyżowej. Zacznij od polityk incydentowych, zweryfikuj swoje kryteria ryzyka w Zenith Blueprint Zenith Blueprint i użyj Zenith Controls Zenith Controls, aby zmapować środki kontrolne ISO/IEC 27002:2022 5.24, 5.25, 5.26, 5.27 i 5.28 na DORA, NIS2, GDPR, NIST CSF oraz oczekiwania audytowe.

Jeżeli Twój zespół nie potrafi odpowiedzieć w ciągu pierwszej godziny na pytanie „Czy to jest poważny incydent DORA, istotny incydent NIS2 albo zdarzenie podlegające zgłoszeniu według GDPR?”, kolejnym krokiem nie jest kolejny ogólny plan reagowania na incydenty. Kolejnym krokiem jest możliwy do obrony operacyjny model klasyfikacji istotności incydentów, przetestowany przed następnym telefonem o 02:17.

Chcesz zastąpić panikę procesem? Pobierz szablony polityk Clarysec dotyczące reagowania na incydenty i gromadzenia materiału dowodowego, porównaj obecną taksonomię istotności incydentów z Zenith Blueprint albo zamów ocenę gotowości Clarysec, aby zbudować gotowy do audytu model klasyfikacji incydentów dla DORA, NIS2, GDPR i ISO/IEC 27001.