Raportowanie incydentów DORA i zabezpieczenia ISO 27001 w 2026 roku

Jest 08:17 we wtorkowy poranek w 2026 roku. Sarah, CISO europejskiego fintechu, widzi na pulpicie migający żółty sygnał — nie czerwony. Krytyczna platforma rozrachunku płatności zaczyna działać wolniej. Transakcje nie kończą się całkowitym niepowodzeniem, ale trwają trzy razy dłużej, niż dopuszcza umowa o gwarantowanym poziomie usług (SLA). SOC obserwuje nietypowe próby uwierzytelniania na koncie administratora. Dostawca infrastruktury chmurowej zgłasza degradację usługi w jednej strefie dostępności. Obsługa klienta zaczyna odbierać telefony od klientów korporacyjnych z pytaniami, dlaczego pliki płatnicze są opóźnione.

Nikt nie wie jeszcze, czy jest to cyberatak, nieskuteczność mechanizmów odporności operacyjnej, awaria dostawcy, incydent dotyczący prywatności, czy wszystkie te problemy jednocześnie.

Sarah ma problem DORA, zanim fakty techniczne są kompletne. Czy to poważny incydent związany z ICT? Czy wpływa na funkcję krytyczną lub istotną? Czy przekroczył wewnętrzny próg istotności? Kogo należy powiadomić, kiedy i z jakim materiałem dowodowym? Jeżeli w grę wchodzą dane osobowe, czy rozpoczął się również termin zgłoszeniowy GDPR? Jeżeli zewnętrzny dostawca ICT jest elementem łańcucha incydentu, kto odpowiada za ustalenie faktów?

W tym miejscu podmioty finansowe odkrywają różnicę między posiadaniem planu reagowania na incydenty a posiadaniem audytowalnego modelu operacyjnego raportowania incydentów DORA.

Raportowanie incydentów DORA w 2026 roku wymaga czegoś więcej niż szybkiej eskalacji. Wymaga możliwego do obrony łańcucha od wykrycia do klasyfikacji, od klasyfikacji do raportowania organowi nadzorczemu, od raportowania do działań naprawczych oraz od działań naprawczych do wniosków po incydencie. ISO/IEC 27001:2022 zapewnia strukturę systemu zarządzania. Zabezpieczenia opisane w ISO/IEC 27002:2022 oraz w Załączniku A ISO/IEC 27001:2022 określają praktyczne oczekiwania kontrolne. Polityki Clarysec, 30-etapowa mapa drogowa i przewodnik po zgodności międzyramowej przekładają te oczekiwania na wdrożenie gotowe do przedstawienia jako dowód w audycie.

Dlaczego raportowanie incydentów DORA zawodzi pod presją

Większość niepowodzeń w raportowaniu incydentów DORA nie zaczyna się od zaniedbania. Zaczyna się od niejednoznaczności.

Analityk bezpieczeństwa widzi alert, ale nie wie, czy kwalifikuje się on jako incydent związany z ICT w rozumieniu DORA. Menedżer usługi IT traktuje degradację wydajności jako techniczny problem usługowy, podczas gdy funkcja zgodności uznaje ją za zdarzenie regulacyjne. Dział prawny czeka na potwierdzenie przed eskalacją. Właściciel biznesowy nie potrafi jeszcze ilościowo określić wpływu na klientów. CISO potrzebuje materiału dowodowego, ale właściwe logi są rozproszone między usługami chmurowymi, urządzeniami końcowymi, systemami tożsamości, SIEM oraz platformami dostawców.

Zanim organizacja uzgodni klasyfikację, okno raportowania jest już pod presją.

DORA Articles 17 to 21 ustanawiają uporządkowane oczekiwania dotyczące zarządzania incydentami związanymi z ICT, ich klasyfikacji, raportowania, treści raportów i obsługi nadzorczej. Dla podmiotów finansowych praktyczny wymóg jest jasny: monitorować, zarządzać, rejestrować, klasyfikować, raportować, aktualizować i wyciągać wnioski z incydentów związanych z ICT w sposób możliwy do późniejszego odtworzenia.

Polityka reagowania na incydenty [IRP] Clarysec osadza DORA bezpośrednio w ramach odniesienia:

DORA UE (2022/2554): Article 17: wymagania dotyczące raportowania incydentów ICT przez instytucje finansowe do właściwych organów.

Ta sama polityka łączy zarządzanie incydentami z zabezpieczeniami ISO/IEC 27002:2022 5.25 do 5.27, obejmując odpowiedzialności za ocenę incydentu, reakcję, komunikację i doskonalenie.

Dla mniejszych firm technologii finansowych oraz szczupłych podmiotów regulowanych Polityka reagowania na incydenty — SME [IRP-SME] Clarysec przekłada ten obowiązek na praktykę, podkreślając, że DORA wymaga od podmiotów finansowych klasyfikowania, raportowania i śledzenia incydentów oraz zakłóceń związanych z ICT.

To sformułowanie ma znaczenie. Zgodność z DORA nie sprowadza się do szablonu raportu. Organizacja musi klasyfikować, raportować i śledzić. Oznacza to materiał dowodowy dotyczący zdarzenia początkowego, kryteriów decyzji, poziomu istotności, decyzji raportowej, komunikacji, działań odzyskiwania, udziału dostawcy i działań następczych.

ISO/IEC 27001:2022 jako centrum koordynacji incydentów DORA

Dojrzały system zarządzania bezpieczeństwem informacji (SZBI) zgodny z ISO/IEC 27001:2022 nie powinien stać się kolejnym silosem zgodności obok DORA. Powinien pełnić funkcję centrum koordynacji raportowania incydentów DORA.

SZBI już wymaga przypisania właścicielstwa ryzyk, doboru zabezpieczeń, audytu wewnętrznego, przeglądu zarządzania, udokumentowanych informacji, ciągłego doskonalenia oraz dowodów działania zabezpieczeń. DORA dodaje sektorową presję raportową, ale ISO/IEC 27001:2022 zapewnia strukturę ładu, dzięki której proces może być powtarzalny.

Zenith Blueprint: 30-etapowa mapa drogowa audytora [ZB] Clarysec wzmacnia tę integrację w kroku 13, Planowanie postępowania z ryzykiem i Deklaracja stosowania. Blueprint zaleca mapowanie zabezpieczeń na ryzyka i klauzule w celu zapewnienia identyfikowalności, w tym dodawanie do ryzyk odniesienia do zabezpieczenia z Załącznika A oraz wskazywanie, kiedy zabezpieczenia wspierają GDPR, NIS2 lub DORA.

Dla incydentu Sarah dotyczącego rozrachunku płatności wpis w rejestrze ryzyk mógłby brzmieć:

„Zakłócenie lub naruszenie bezpieczeństwa platformy przetwarzania płatności.”

Zmapowane zabezpieczenia ISO/IEC 27001:2022 z Załącznika A obejmowałyby 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 oraz 8.16, z adnotacją DORA dotyczącą klasyfikacji i raportowania poważnego incydentu związanego z ICT.

Zenith Controls: przewodnik po zgodności międzyramowej [ZC] Clarysec działa następnie jako kompas zgodności międzyramowej. W Zenith Controls Clarysec mapuje zabezpieczenia ISO/IEC 27002:2022 na inne zabezpieczenia ISO/IEC 27001:2022, powiązane normy, oczekiwania audytowe oraz regulacje, takie jak DORA, GDPR i NIS2. Nie tworzy odrębnych „zabezpieczeń Zenith”. Pokazuje, jak istniejące zabezpieczenia ISO działają razem i w jaki sposób są testowane.

Proces raportowania DORA można postrzegać jako łańcuch zabezpieczeń:

Nie można zgłosić tego, czego się nie wykryło. Nie można sklasyfikować tego, czego się nie oceniło. Nie można uzasadnić decyzji raportowej bez zapisów. Nie można doskonalić procesu bez przeglądu po incydencie.

Zabezpieczenie 6.8: zegar DORA uruchamiają ludzie

W scenariuszu Sarah pierwszy użyteczny sygnał może nie pochodzić z SOC. Może pochodzić od opiekuna relacji słyszącego skargi klientów, użytkownika z finansów widzącego nieudane partie rozrachunkowe albo inżyniera zauważającego anomalne opóźnienia.

Dlatego zabezpieczenie 6.8 ISO/IEC 27001:2022 z Załącznika A, Zgłaszanie zdarzeń bezpieczeństwa informacji, jest kluczowe dla DORA. Czyni zgłaszanie odpowiedzialnością całego personelu, a nie wyłącznie funkcją operacji bezpieczeństwa.

W Zenith Blueprint, krok 16, Zabezpieczenia osobowe II, Clarysec stwierdza:

Skuteczny system reagowania na incydenty zaczyna się nie od narzędzi, lecz od ludzi.

Krok 16 zaleca jasne kanały zgłoszeń, szkolenie z zakresu świadomości bezpieczeństwa, kulturę bez obwiniania, triage, poufność oraz okresowe symulacje. Najbardziej praktyczny komunikat jest prosty:

„W razie wątpliwości — zgłoś.”

To zasada kontrolna DORA. Jeżeli pracownicy czekają, aż będą mieć pewność, organizacja traci czas. Jeżeli zgłaszają wcześnie, organizacja może ocenić, sklasyfikować i podjąć decyzję.

W Zenith Controls 6.8 jest zmapowane jako zabezpieczenie detekcyjne wspierające poufność, integralność i dostępność. Łączy się z 5.24, ponieważ kanały zgłoszeń muszą być częścią planu obsługi incydentów. Zasila 5.25, ponieważ zdarzenia mogą zostać ocenione tylko wtedy, gdy są zgłoszone. Uruchamia 5.26, ponieważ formalna reakcja zaczyna się po ocenie zgłoszeń.

Dla DORA wspiera to Articles 17 i 18, zgodnie z którymi podmioty finansowe muszą zarządzać, klasyfikować i raportować poważne incydenty związane z ICT oraz istotne cyberzagrożenia. Wspiera to również GDPR Article 33 i Recital 85, ponieważ zgłoszenie wewnętrzne decyduje o tym, jak szybko naruszenie ochrony danych osobowych zostanie zidentyfikowane i eskalowane.

Praktycznym wdrożeniem Clarysec jest jednostronicowa instrukcja „Jak zgłosić incydent ICT”. Powinna obejmować:

• Co zgłaszać, w tym niedostępność usług, podejrzane wiadomości e-mail, utracone urządzenia, nietypowe zachowanie systemów, podejrzenie naruszenia bezpieczeństwa dostawcy, nieuprawniony dostęp, wyciek danych oraz degradację usługi wpływającą na klientów.
• Jak zgłaszać, z użyciem monitorowanej skrzynki pocztowej, kategorii zgłoszenia, infolinii, kanału współpracy lub portalu SOC.
• Co uwzględnić, na przykład czas, system, użytkownika, proces biznesowy, zaobserwowany wpływ, zrzuty ekranu, jeżeli jest to bezpieczne, oraz informację, czy mogą być dotknięci klienci lub dane osobowe.
• Czego nie robić, w tym nie usuwać logów, nie restartować systemów krytycznych bez polecenia, nie kontaktować się z klientami zewnętrznie bez zatwierdzenia oraz nie prowadzić dochodzenia poza zakresem swojej roli.
• Co dzieje się dalej, w tym triage, klasyfikacja, eskalacja, reakcja, zabezpieczenie materiału dowodowego oraz możliwa ocena regulacyjna.

Celem nie jest przekształcenie każdego pracownika w śledczego. Celem jest uczynienie każdego pracownika wiarygodnym źródłem sygnału.

Zabezpieczenie 5.25: punkt decyzji klasyfikacyjnej DORA

Raportowanie poważnych incydentów związanych z ICT w DORA zależy od klasyfikacji. W tym miejscu centralne znaczenie ma zabezpieczenie 5.25 ISO/IEC 27001:2022 z Załącznika A, Ocena i decyzja dotycząca zdarzeń bezpieczeństwa informacji.

Zenith Blueprint, krok 23, wyjaśnia praktyczne wyzwanie:

Nie każda anomalia jest katastrofą. Nie każdy alert oznacza naruszenie bezpieczeństwa.

Następnie opisuje cel 5.25 jako:

odróżnienie tego, co nieszkodliwe, od tego, co szkodliwe, oraz wiedzę, co wymaga eskalacji.

Dla DORA jest to moment, w którym zdarzenie bezpieczeństwa, degradacja usługi, awaria dostawcy, ujawnienie danych lub zakłócenie operacyjne są oceniane względem kryteriów poważnego incydentu. Organizacja musi uwzględnić wpływ operacyjny, dotknięte usługi, funkcje krytyczne lub istotne, liczbę dotkniętych klientów i transakcji, czas trwania, zasięg geograficzny, wpływ na dane, konsekwencje reputacyjne oraz wpływ ekonomiczny.

W Zenith Controls 5.25 jest mapowane bezpośrednio do DORA Article 18, Major ICT Incident Classification. Jest to uporządkowany proces oceny służący ustaleniu, czy zaobserwowane zdarzenie kwalifikuje się jako incydent bezpieczeństwa. Łączy się również z 8.16, Działania monitorujące, ponieważ alerty i dane z logów muszą zostać poddane triage’owi, oraz z 5.26, ponieważ klasyfikacja uruchamia reakcję.

W tym obszarze wiele organizacji nie przechodzi audytów. Mają zgłoszenia, ale nie mają zapisów klasyfikacji. Mają etykiety istotności, ale nie mają kryteriów. Mają raporty regulacyjne, ale nie mają ścieżki decyzyjnej potwierdzającej, dlaczego incydent został albo nie został uznany za poważny.

Clarysec adresuje ten problem, osadzając klasyfikację DORA w modelu istotności incydentów. W korporacyjnej Polityce reagowania na incydenty klauzula 5.3.1 zawiera jasny przykład poziomu 1:

Poziom 1: Krytyczny (np. potwierdzone naruszenie ochrony danych, wybuch ransomware, naruszenie bezpieczeństwa systemu produkcyjnego)

Dla mniejszych organizacji Polityka reagowania na incydenty — SME dodaje ścisłe oczekiwanie operacyjne:

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

Taki jednogodzinny cel klasyfikacyjny jest istotny, ponieważ wymusza dyscyplinę ładu. Mniejszy podmiot regulowany może nie mieć SOC działającego 24/7, ale nadal może określić, kto klasyfikuje, kto doradza i jak szybko musi zostać podjęta decyzja.

Rekord triage’u incydentu DORA–ISO

Aby klasyfikacja była możliwa do obrony, utwórz rekord triage’u incydentu DORA w systemie zgłoszeniowym, GRC lub systemie zarządzania incydentami. Rekord powinien być tworzony dla każdego potencjalnie istotnego zdarzenia ICT, nawet jeżeli później zostanie obniżony jego poziom.

Dodaj notatkę decyzyjną:

„Na podstawie zakłócenia usługi płatniczej wpływającego na krytyczny proces biznesowy, nierozwiązanej przyczyny źródłowej oraz potencjalnego wpływu na klientów zdarzenie zostaje eskalowane jako potencjalny poważny incydent związany z ICT. Funkcja zgodności i dział prawny mają ocenić wymagania dotyczące zgłoszenia regulacyjnego. Zainicjowano zabezpieczenie materiału dowodowego.”

Ten pojedynczy rekord wspiera śledzenie zgodnie z DORA Article 17, klasyfikację zgodnie z Article 18, decyzje raportowe zgodnie z Article 19, ocenę ISO/IEC 27001:2022 z Załącznika A 5.25, zgłaszanie 6.8, reakcję 5.26 oraz postępowanie z materiałem dowodowym 5.28.

Zabezpieczenia 5.24 i 5.26: planowanie, role i reakcja

Gdy wystąpi incydent DORA, plan reakcji musi już odpowiadać na niewygodne pytania.

Kto ma uprawnienia do klasyfikacji? Kto kontaktuje się z właściwym organem? Kto zatwierdza początkowe powiadomienie? Kto komunikuje się z klientami? Kto kontaktuje się z zewnętrznym dostawcą ICT? Kto decyduje, czy incydent uruchamia również obowiązek powiadomienia GDPR? Kto zabezpiecza materiał dowodowy? Kto odpowiada za raport końcowy?

Zabezpieczenie 5.24 ISO/IEC 27001:2022 z Załącznika A, Planowanie i przygotowanie zarządzania incydentami bezpieczeństwa informacji, odpowiada na te pytania przed kryzysem. Zabezpieczenie 5.26, Reagowanie na incydenty bezpieczeństwa informacji, zapewnia, że plan przekłada się na kontrolowane działania podczas incydentu.

W Zenith Controls 5.24 jest powiązane z DORA Articles 17 to 21, ponieważ operacjonalizuje udokumentowane, testowane i przeglądane reagowanie na incydenty, w tym wewnętrzną eskalację, zewnętrzne powiadomienia regulacyjne, komunikację z interesariuszami oraz wnioski po incydencie.

ISO/IEC 27035-1:2023 wspiera to podejście, rozszerzając zarządzanie incydentami poza procedury reakcji na politykę, planowanie, zdolności, relacje, mechanizmy wsparcia, świadomość, szkolenia i regularne testowanie. ISO/IEC 27035-2:2023 dodatkowo opisuje proces zarządzania incydentami od przygotowania po wnioski po incydencie.

Zenith Blueprint, krok 23, podaje bezpośrednią instrukcję wdrożeniową:

Upewnij się, że masz aktualny plan reagowania na incydenty (5.24), obejmujący przygotowanie, eskalację, reakcję i komunikację.

Plan reagowania na incydenty gotowy na DORA powinien definiować:

• Zespół reagowania na incydenty ICT oraz zastępców.
• Uprawnienia do klasyfikacji istotności i eskalacji raportowania DORA.
• Odpowiedzialności działu prawnego, funkcji zgodności, prywatności, komunikacji, IT, bezpieczeństwa, dostawców i właścicieli biznesowych.
• Kryteria klasyfikacji poważnego incydentu związanego z ICT.
• Procedury początkowego, pośredniego i końcowego raportowania regulacyjnego.
• Ocenę wyzwalaczy powiadomień GDPR, NIS2, umownych, ubezpieczenia cyber oraz zarządu.
• Kroki powstrzymania, usunięcia zagrożenia, odzyskiwania i walidacji.
• Wymagania dotyczące zabezpieczenia materiału dowodowego.
• Procedury eskalacji dostawcy i dostępu do logów.
• Śledzenie wniosków po incydencie i działań korygujących.

Polityka reagowania na incydenty — SME łączy również terminy reakcji z wymogami prawnymi:

Terminy reakcji, w tym odzyskiwanie danych i obowiązki powiadamiania, muszą być udokumentowane i dostosowane do wymogów prawnych, takich jak 72-godzinny wymóg zgłoszenia naruszenia ochrony danych osobowych zgodnie z GDPR.

Jest to kluczowe, ponieważ jeden incydent ICT może stać się poważnym incydentem DORA, naruszeniem ochrony danych osobowych GDPR, istotnym incydentem NIS2, zdarzeniem wymagającym umownego powiadomienia klienta oraz problemem zarządzania dostawcą. Plan musi koordynować te nakładające się warstwy, zamiast traktować je jak odrębne światy.

Zabezpieczenia 8.15 i 8.16: logi pozwalają uzasadnić raport

Raportowanie incydentów DORA zależy od faktów. Fakty zależą od rejestrowania i monitorowania.

W scenariuszu rozrachunku płatności Sarah musi wiedzieć, kiedy zaczęła się degradacja, które systemy zostały dotknięte, czy użyto kont uprzywilejowanych, czy dane opuściły środowisko, czy awaria dostawcy chmury jest spójna z wewnętrzną telemetrią oraz kiedy zakończono odzyskiwanie.

Zabezpieczenie 8.15 ISO/IEC 27001:2022 z Załącznika A, Rejestrowanie, oraz 8.16, Działania monitorujące, wspierają tę bazę dowodową. W Zenith Controls oba łączą się z 5.24, ponieważ planowanie reagowania na incydenty musi obejmować użyteczne dane logów i zdolność monitorowania. Zabezpieczenie 8.16 łączy się również z 5.25, ponieważ alerty muszą zostać poddane triage’owi i przekształcone w decyzje.

Polityka rejestrowania i monitorowania — SME [LMP-SME] Clarysec zawiera praktyczny wymóg eskalacji:

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

Dla podmiotów objętych DORA potencjalnie poważne incydenty ICT zwykle wymagają szybszego modelu eskalacji operacyjnej, szczególnie gdy dotknięte są funkcje krytyczne lub istotne. Sam wzorzec ładu jest jednak prawidłowy: alerty o wysokim priorytecie nie mogą pozostawać wyłącznie w IT. Muszą dotrzeć do ról biznesowych, prywatności i zarządczych.

Model rejestrowania gotowy na DORA powinien obejmować:

• Scentralizowane rejestrowanie dla systemów krytycznych, platform tożsamości, urządzeń końcowych, usług chmurowych, narzędzi bezpieczeństwa sieci i aplikacji biznesowych.
• Synchronizację czasu między systemami, aby osie czasu incydentów były wiarygodne.
• Kategoryzację alertów dostosowaną do istotności incydentu i klasyfikacji DORA.
• Przechowywanie logów dostosowane do potrzeb regulacyjnych, umownych i śledczych.
• Kontrole dostępu chroniące integralność logów.
• Procedury pozyskiwania migawek logów podczas poważnych incydentów.
• Wymagania dostępu do logów dostawców dla krytycznych usług ICT.

Audytorzy nie uznają stwierdzenia „SIEM to ma” za wystarczający dowód. Zapytają, czy właściwe logi istniały, czy alerty były przeglądane, czy eskalacja nastąpiła na czas oraz czy logi zostały zabezpieczone, gdy incydent stał się potencjalnie raportowalny.

Zabezpieczenie 5.28: zabezpieczanie materiału dowodowego i łańcuch nadzoru

W poważnym incydencie związanym z ICT materiał dowodowy pełni trzy funkcje: wspiera dochodzenie techniczne, rozliczalność regulacyjną i możliwość obrony prawnej.

Jeżeli materiał dowodowy jest niekompletny, nadpisany, zmieniony albo nieudokumentowany, organizacja może mieć trudności z udowodnieniem, co się wydarzyło. Może również mieć trudności z uzasadnieniem swojej decyzji klasyfikacyjnej.

Polityka zabezpieczania materiału dowodowego i informatyki śledczej [ECF] Clarysec stwierdza:

Rejestr łańcucha nadzoru musi towarzyszyć wszystkim fizycznym lub cyfrowym materiałom dowodowym od momentu pozyskania przez archiwizację lub przekazanie i musi dokumentować:

Wersja SME, Polityka zabezpieczania materiału dowodowego i informatyki śledczej — SME [ECF-SME], upraszcza wymaganie:

Każdy element cyfrowego materiału dowodowego musi zostać zarejestrowany z:

Wniosek operacyjny jest bezpośredni. Postępowanie z materiałem dowodowym nie może zaczynać się dopiero wtedy, gdy poprosi o niego dział prawny. Musi być wbudowane w reagowanie na incydenty.

ISO/IEC 27006-1:2024 wzmacnia to oczekiwanie audytowe, podkreślając procedury identyfikowania, zbierania i zabezpieczania materiału dowodowego z incydentów bezpieczeństwa informacji. Dla DORA ten sam zestaw dowodów może wspierać początkowe powiadomienie, aktualizacje pośrednie, raport końcowy, przegląd po incydencie oraz pytania organu nadzorczego.

Praktyczna lista kontrolna materiału dowodowego dla incydentów związanych z DORA powinna obejmować:

• Zgłoszenie incydentu i notatki z triage’u.
• Oś czasu wykrycia, eskalacji, klasyfikacji, raportowania, powstrzymania, odzyskiwania i zamknięcia.
• Alerty SIEM i skorelowane logi.
• Artefakty z urządzeń końcowych i serwerów.
• Logi tożsamości i dostępu uprzywilejowanego.
• Podsumowania ruchu sieciowego.
• Status dostawcy chmury i logi audytowe.
• Komunikację z dostawcami i oświadczenia dotyczące incydentu.
• Zapisy wpływu biznesowego, w tym klientów, usług, transakcji i czasu niedostępności.
• Projekty i złożone zgłoszenia regulacyjne.
• Decyzje i zatwierdzenia kierownictwa.
• Analizę przyczyny źródłowej.
• Wnioski po incydencie i działania korygujące.

Materiał dowodowy musi pokazywać zarówno fakty techniczne, jak i decyzje ładu. Raportowanie DORA nie dotyczy wyłącznie tego, co stało się z systemami. Dotyczy również tego, jak kierownictwo rozpoznało, oceniło, eskalowało, kontrolowało incydent i usprawniło organizację po jego wystąpieniu.

Zabezpieczenie 5.27: wnioski po incydencie i ciągłe doskonalenie

Incydent DORA nie jest zamknięty w momencie złożenia raportu końcowego. Jest zamknięty wtedy, gdy organizacja wyciągnęła z niego wnioski, przypisała działania korygujące, zaktualizowała zabezpieczenia i zweryfikowała usprawnienia.

Zabezpieczenie 5.27 ISO/IEC 27001:2022 z Załącznika A, Uczenie się na podstawie incydentów bezpieczeństwa informacji, łączy raportowanie DORA z cyklem ciągłego doskonalenia ISO/IEC 27001:2022. W Zenith Controls 5.24 jest powiązane z 5.27, ponieważ zarządzanie incydentami jest niekompletne bez analizy przyczyny źródłowej, wniosków po incydencie i doskonalenia zabezpieczeń.

Zenith Blueprint, krok 23, zaleca organizacjom aktualizowanie planu na podstawie wniosków po incydencie oraz prowadzenie ukierunkowanych szkoleń z reagowania na incydenty i postępowania z materiałem dowodowym. Jest to szczególnie ważne dla DORA, ponieważ powtarzające się opóźnienia klasyfikacyjne, brakujące dowody od dostawców, słabe logi albo niejasna komunikacja mogą stać się przedmiotem zastrzeżeń organu nadzorczego.

Szablon wniosków po incydencie powinien obejmować:

• Co się wydarzyło i kiedy.
• Które funkcje krytyczne lub istotne zostały dotknięte.
• Czy klasyfikacja była terminowa i trafna.
• Czy decyzje raportowe DORA zostały podjęte na podstawie wystarczającego materiału dowodowego.
• Czy oceniono wyzwalacze powiadomień GDPR, NIS2, umownych lub klienckich.
• Czy dostawcy odpowiedzieli w uzgodnionych terminach.
• Czy logi i materiał dowodowy informatyki śledczej zostały zabezpieczone.
• Które zabezpieczenia zawiodły albo których brakowało.
• Które polityki, podręczniki postępowania, szkolenia lub techniczne zabezpieczenia muszą zostać usprawnione.
• Kto odpowiada za każde działanie korygujące i do kiedy.

Zasila to również przegląd zarządzania ISO/IEC 27001:2022. Trendy incydentów powinny być przeglądane przez kierownictwo, a nie ukrywane w technicznych analizach poincydentalnych.

Zgodność międzyramowa: DORA, GDPR, NIS2, NIST i COBIT 2019

DORA jest głównym tematem dla podmiotów finansowych, ale raportowanie incydentów rzadko należy tylko do jednych ram.

Pojedynczy incydent ICT może obejmować raportowanie poważnego incydentu związanego z ICT zgodnie z DORA, zgłoszenie naruszenia ochrony danych osobowych GDPR, raportowanie istotnego incydentu NIS2, obowiązki wynikające z umów z klientami, powiadomienie ubezpieczyciela cyber oraz raportowanie do zarządu.

Zenith Controls pomaga ograniczyć tę złożoność, mapując zabezpieczenia ISO/IEC 27002:2022 między ramami. Na przykład:

Z perspektywy NIST ten sam model wspiera wyniki Detect, Respond i Recover. Z perspektywy COBIT 2019 oraz audytu ISACA kluczowym zagadnieniem jest ład: czy zarządzanie incydentami, ciągłość, ryzyko, zgodność, odpowiedzialności dostawców i monitorowanie wyników są kontrolowane.

Najbardziej dojrzałe organizacje nie tworzą odrębnych procesów dla każdych ram. Tworzą jeden proces zarządzania incydentami z nakładkami regulacyjnymi. Zgłoszenie przechwytuje te same kluczowe fakty raz, a następnie rozgałęzia się na raportowanie DORA, GDPR, NIS2, umowne, ubezpieczeniowe lub sektorowe, gdy jest to wymagane.

Jak audytorzy będą testować Twój proces incydentowy DORA

Proces raportowania incydentów gotowy na DORA musi wytrzymać różne perspektywy audytowe.

Audytor ISO/IEC 27001:2022 zbada, czy SZBI wybrał i wdrożył odpowiednie zabezpieczenia z Załącznika A, czy Deklaracja stosowania wspiera te zabezpieczenia, czy istnieją zapisy incydentów oraz czy audyt wewnętrzny i przegląd zarządzania obejmują wyniki w obszarze incydentów.

Zenith Controls przywołuje metodykę audytu ISO/IEC 19011:2018 dla 5.24, 5.25 i 6.8. Dla 5.24 audytorzy analizują plan reagowania na incydenty pod kątem typów incydentów, klasyfikacji istotności, przypisanych ról, list kontaktowych, ścieżek eskalacji, instrukcji raportowania regulacyjnego i odpowiedzialności komunikacyjnych. Dla 5.25 sprawdzają, czy istnieją udokumentowane kryteria klasyfikacji, takie jak macierze istotności lub drzewa decyzyjne oparte na wpływie na system, wrażliwości danych i czasie trwania. Dla 6.8 oceniają mechanizmy zgłaszania, metryki czasu do zgłoszenia oraz dowody, że zgłoszone zdarzenia są rejestrowane, poddawane triage’owi i rozwiązywane.

Przegląd nadzorczy DORA skupi się na tym, czy poważne incydenty związane z ICT są wykrywane, klasyfikowane, raportowane, aktualizowane i zamykane zgodnie z oczekiwaniami regulacyjnymi. Kontrolujący może poprosić o przykładowy incydent i prześledzić go od pierwszego alertu do raportu końcowego.

Audytor prywatności skupi się na tym, czy oceniono ryzyko naruszenia ochrony danych osobowych oraz czy uruchomiono obowiązki wynikające z GDPR Article 33 i Article 34. BS EN 17926:2023 jest tu istotna, ponieważ dodaje odpowiedzialności dotyczące incydentów prywatności, kryteria powiadomień, terminy oraz dostosowanie do oczekiwań ujawnień wobec organu nadzorczego.

Ten sam materiał dowodowy może odpowiedzieć na wiele pytań audytowych, jeżeli od początku jest właściwie uporządkowany.

Lista kontrolna gotowości raportowania incydentów DORA na 2026 rok

Przed kolejnym ćwiczeniem typu tabletop, audytem wewnętrznym lub przeglądem nadzorczym przetestuj organizację według tej listy:

• Czy pracownicy wiedzą, jak zgłaszać podejrzewane incydenty ICT?
• Czy istnieje wyznaczony kanał zgłaszania incydentów?
• Czy zdarzenia bezpieczeństwa są spójnie rejestrowane i poddawane triage’owi?
• Czy istnieje udokumentowana macierz istotności i klasyfikacji poważnego incydentu DORA?
• Czy klasyfikacja jest wymagana w określonym czasie od powiadomienia?
• Czy funkcje krytyczne lub istotne są zmapowane na systemy i dostawców?
• Czy wyzwalacze powiadomień DORA, GDPR, NIS2, umownych, ubezpieczeniowych i klienckich są oceniane w jednym procesie?
• Czy role incydentowe są zdefiniowane między IT, bezpieczeństwem, działem prawnym, funkcją zgodności, prywatnością, komunikacją i właścicielami biznesowymi?
• Czy logi są wystarczające do odtworzenia osi czasu incydentów?
• Czy materiał dowodowy jest zabezpieczany z zachowaniem łańcucha nadzoru?
• Czy testowane są obowiązki incydentowe dostawców i prawa dostępu do logów?
• Czy ćwiczenia typu tabletop są prowadzone z użyciem realistycznych scenariuszy DORA?
• Czy wnioski po incydencie są śledzone do działań korygujących?
• Czy metryki incydentów są przeglądane w ramach przeglądu zarządzania?
• Czy Deklaracja stosowania jest zmapowana na zabezpieczenia ISO/IEC 27001:2022 istotne dla DORA?

Jeżeli odpowiedź na którekolwiek z tych pytań brzmi „częściowo”, problem nie dotyczy wyłącznie zgodności. Dotyczy odporności operacyjnej.

Zbuduj model raportowania incydentów DORA gotowy na materiał dowodowy

Raportowanie incydentów DORA w 2026 roku jest testem ładu pod presją. Organizacje, które poradzą sobie dobrze, nie będą tymi z najdłuższymi dokumentami reagowania na incydenty. Będą to organizacje z jasnymi kanałami zgłoszeń, szybką klasyfikacją, wiarygodnymi logami, zabezpieczonym materiałem dowodowym, przeszkolonym personelem, przetestowaną eskalacją dostawców i identyfikowalnością między ramami.

Clarysec może pomóc zbudować taki model operacyjny.

Zacznij od zmapowania ryzyk incydentowych i Deklaracji stosowania z użyciem Zenith Blueprint: 30-etapowej mapy drogowej audytora. Następnie dostosuj zabezpieczenia dotyczące incydentów z Zenith Controls: przewodnikiem po zgodności międzyramowej. Uoperacyjnij proces z wykorzystaniem Polityki reagowania na incydenty, Polityki reagowania na incydenty — SME, Polityki rejestrowania i monitorowania — SME, Polityki zabezpieczania materiału dowodowego i informatyki śledczej oraz Polityki zabezpieczania materiału dowodowego i informatyki śledczej — SME.

Jeżeli zespół kierowniczy chce uzyskać pewność przed kolejnym rzeczywistym incydentem, przeprowadź ćwiczenie typu tabletop dla poważnego incydentu związanego z ICT zgodnie z DORA z wykorzystaniem zestawu narzędzi Clarysec i przygotuj pakiet dowodowy, którego oczekiwałby audytor lub organ nadzorczy.