Kiedy zgłosić incydent DORA? Terminy i progi

Kiedy zgłosić incydent DORA? Poznaj progi klasyfikacji, terminy raportowania i dowody ograniczające ryzyko naruszenia obowiązków regulacyjnych w praktyce.

Awaria usługi płatniczej trwa 40 minut, ale dotyczy części klientów. W tym samym czasie SOC widzi anomalie wskazujące na możliwy dostęp do danych, a dostawca chmury nie potwierdza jeszcze źródła problemu. To właśnie w takim momencie pytanie kiedy zgłosić incydent DORA musi mieć operacyjną, a nie intuicyjną odpowiedź. Czekanie na pełne ustalenie przyczyny może naruszyć termin raportowy. Zgłoszenie bez potwierdzonych faktów może natomiast uruchomić niepotrzebną eskalację i obciążyć zespół błędną klasyfikacją.

DORA wymaga od podmiotów finansowych sprawnego zarządzania incydentami związanymi z ICT, ich klasyfikowania oraz raportowania incydentów poważnych właściwemu organowi. Kluczowe jest rozdzielenie trzech decyzji: czy zdarzenie jest incydentem ICT, czy osiąga próg incydentu poważnego oraz kiedy rozpoczyna się zegar raportowy. W dojrzałej organizacji te decyzje wynikają z danych, progów i jasno przypisanej odpowiedzialności, a nie z dyskusji prowadzonej ad hoc na kanale kryzysowym.

Kiedy zgłosić incydent DORA do właściwego organu?

Zgłoszeniu podlega poważny incydent związany z ICT. Nie każdy alert SOC, wykryta podatność, niedostępność pojedynczego komponentu czy nieudana próba phishingu spełnia ten próg. Incydent staje się raportowalny wtedy, gdy po klasyfikacji według kryteriów DORA zostanie uznany za poważny.

To rozróżnienie ma znaczenie praktyczne. Krytyczna podatność w systemie wystawionym do internetu może wymagać natychmiastowej remediacji, dodatkowego monitoringu i analizy ekspozycji, lecz sama w sobie nie jest automatycznie incydentem podlegającym zgłoszeniu. Jeśli jednak doszło do wykorzystania podatności, naruszenia dostępności, integralności, poufności lub autentyczności usług i danych, zespół powinien uruchomić proces klasyfikacji bez oczekiwania na pełny raport forensic.

Ocena powagi nie może opierać się wyłącznie na liczbie alertów lub technicznej skali zdarzenia. DORA wymaga analizy wpływu na klientów, transakcje i usługi, w tym funkcje krytyczne lub istotne. W praktyce należy także ocenić czas trwania niedostępności, zasięg geograficzny, utratę lub naruszenie danych, skutki reputacyjne oraz wymierny wpływ ekonomiczny. Szczegółowe progi i zasady agregacji wynikają z regulacyjnych standardów technicznych, dlatego powinny być odwzorowane w wewnętrznej metodyce organizacji.

Klasyfikacja zaczyna się od faktów, nie od etykiety „poważny”

Pierwsze 30-60 minut obsługi incydentu powinno służyć zebraniu minimalnego zestawu informacji potrzebnych do triage. Zespół musi ustalić, jaka usługa została dotknięta, czy wspiera funkcję krytyczną lub istotną, ilu klientów i kontrahentów odczuwa skutki oraz czy zakłócone zostały transakcje lub procesy operacyjne. Należy również określić moment wykrycia, przewidywany początek incydentu i aktualny status ograniczania skutków.

Nie oznacza to, że wszystkie dane muszą być od razu kompletne. W incydencie ransomware, awarii dostawcy SaaS lub kompromitacji kont uprzywilejowanych część ustaleń będzie hipotezą. Metodyka powinna wyraźnie rozdzielać fakty potwierdzone, szacunki operacyjne i elementy nadal badane. Taka dyscyplina pozwala wysłać terminowe zgłoszenie wstępne, a jednocześnie chroni organizację przed przedstawianiem regulatorowi niezweryfikowanych twierdzeń jako pewników.

Terminy raportowania: zegar uruchamia klasyfikacja

Po zaklasyfikowaniu zdarzenia jako poważnego podmiot finansowy składa zgłoszenie wstępne zasadniczo do końca dnia roboczego, w którym dokonano klasyfikacji, nie później jednak niż w ciągu czterech godzin od tej klasyfikacji. DORA ogranicza również maksymalny czas od momentu uzyskania wiedzy o incydencie - zgłoszenie wstępne powinno nastąpić nie później niż w ciągu 24 godzin od tego momentu.

Te dwa punkty czasowe są źródłem częstych błędów. Organizacja nie powinna traktować terminu 24 godzin jako standardowego bufora na analizę. Jeżeli incydent można wiarygodnie zaklasyfikować jako poważny po dwóch godzinach, od tej klasyfikacji biegnie krótszy termin. Dlatego właściciel procesu musi mieć prawo do podjęcia decyzji i dostęp do właściwego kanału raportowego także poza zwykłymi godzinami pracy.

Kolejnym elementem jest raport pośredni, składany co do zasady w ciągu 72 godzin od zgłoszenia wstępnego. Powinien uzupełniać obraz zdarzenia o zweryfikowane informacje dotyczące wpływu, działań ograniczających, przyczyn oraz dalszego ryzyka. Raport końcowy przekazuje się zasadniczo miesiąc po raporcie pośrednim albo po jego ostatniej aktualizacji. Jego rolą nie jest powtórzenie chronologii, lecz wykazanie, że organizacja ustaliła źródłową przyczynę, opanowała skutki i wdrożyła kontrolowaną remediację.

W Polsce właściwym organem dla danego podmiotu będzie co do zasady organ wskazany w jego reżimie nadzorczym. Procedura powinna więc uwzględniać nie tylko terminy DORA, ale także aktualne wymagania kanału zgłoszeniowego, formatów i kontaktów eskalacyjnych. To element, który trzeba okresowo testować, a nie tylko opisać w polityce.

Jak działać, gdy skala incydentu nie jest jeszcze znana?

Największe ryzyko proceduralne pojawia się wtedy, gdy incydent rozwija się etapami. Początkowo dotyczy jednego regionu, jednej aplikacji albo ograniczonej puli klientów, po czym ujawnia się jego zależność od centralnej platformy tożsamości, dostawcy chmury lub systemu rozliczeniowego. W takich przypadkach właściwą reakcją nie jest ani automatyczne zaniżanie klasyfikacji, ani zgłaszanie każdego incydentu „na wszelki wypadek”. Potrzebna jest cykliczna ponowna ocena.

Dobra procedura określa częstotliwość rekwalifikacji, właściciela decyzji i minimalne dane wejściowe. W praktyce warto powiązać ją z rytmem zarządzania kryzysowego, na przykład przy każdej istotnej zmianie zasięgu, odkryciu naruszenia danych, przekroczeniu czasu niedostępności lub potwierdzeniu wpływu na funkcję krytyczną. Każda zmiana klasyfikacji powinna zostawić ślad: kto podjął decyzję, na podstawie jakich danych i o której godzinie.

Szczególnej uwagi wymagają zdarzenia po stronie zewnętrznych dostawców ICT. Odpowiedzialność regulacyjna podmiotu finansowego nie znika dlatego, że przyczyną był operator chmury, dostawca usług zarządzanych czy producent oprogramowania. Umowy, SLA i runbooki muszą zapewniać szybkie przekazywanie danych o wpływie, czasie trwania, zakresach klientów oraz działaniach naprawczych. Bez tych informacji organizacja nie obroni ani klasyfikacji, ani kompletności raportu.

Dowody, które należy zachować od pierwszego alertu

Regulator, audyt wewnętrzny i zarząd będą oceniać nie tylko to, czy raport wysłano w terminie. Równie ważne będzie, czy decyzja była racjonalna i odtwarzalna. Dlatego obsługa incydentu DORA powinna tworzyć pakiet dowodowy równolegle z działaniami technicznymi.

Pakiet ten obejmuje rejestr czasu wykrycia, kwalifikacji i zgłoszenia, dane o dostępności usług, liczbę dotkniętych klientów lub transakcji, decyzje zespołu kryzysowego, komunikację z dostawcami oraz historię zmian klasyfikacji. Niezbędne są też dowody wykonania działań ograniczających: reguły blokujące, izolacja segmentów, reset poświadczeń, przywrócenie kopii zapasowych, zmiany konfiguracji i wyniki walidacji po naprawie.

Dla zarządu te dane powinny zostać przełożone na język ryzyka biznesowego: wpływ na ciągłość usługi, ekspozycję finansową, status obowiązków regulacyjnych, ryzyko powtórzenia i koszt trwałej remediacji. Techniczny raport bez takiego przełożenia nie wspiera decyzji o priorytetach ani finansowaniu działań naprawczych.

Test procedury przed realnym incydentem

Najczęściej problemem nie jest brak polityki raportowania DORA, lecz brak sprawdzenia jej pod presją czasu. Organizacja może mieć poprawnie opisane role, ale nie wiedzieć, kto klasyfikuje incydent w nocy, jak pobrać dane transakcyjne w weekend albo kto zatwierdza zgłoszenie, gdy CISO jest niedostępny.

Ćwiczenie tabletop powinno obejmować realistyczny scenariusz, na przykład kompromitację konta administratora dostawcy, niedostępność systemu płatniczego albo wyciek danych w środowisku chmurowym. Warto mierzyć czas do zebrania danych, czas do klasyfikacji, kompletność dowodów i zdolność do przygotowania zgłoszenia wstępnego. Rezultatem powinny być nie tylko wnioski, ale też właściciele działań, SLA dla brakujących danych oraz terminy zamknięcia luk.

SprintTech pomaga łączyć ten test regulacyjny z perspektywą SOC, architektury i ciągłości działania, tak aby procedura nie pozostawała dokumentem compliance. Najlepszym momentem na ustalenie, kto i kiedy zgłasza incydent DORA, jest spokojny dzień operacyjny - wtedy można przećwiczyć decyzje, usunąć blokady dostępu do danych i zbudować dowody, których w kryzysie nie da się odtworzyć.