DORA i incydent ICT: obowiązki zarządu, klasyfikacja i raportowanie

DORA to nie tylko obowiązek działu IT

Rozporządzenie (UE) 2022/2554 obejmuje szeroki katalog podmiotów finansowych i nakłada na nie obowiązki dotyczące odporności cyfrowej. Odpowiedzialność za ramy zarządzania ryzykiem ICT nie może zostać sprowadzona wyłącznie do zespołu technicznego. Organ zarządzający powinien znać najważniejsze ryzyka, zatwierdzać ramy i otrzymywać informacje o poważnych incydentach.

Najpierw trzeba sklasyfikować incydent

Nie każdy błąd systemu albo przerwa w działaniu staje się „poważnym incydentem związanym z ICT”. DORA wymaga oceny według kryteriów takich jak liczba lub znaczenie klientów, czas trwania, zasięg geograficzny, utrata danych, krytyczność dotkniętych usług oraz skutki gospodarcze. Dlatego procedura incident response powinna od początku zbierać dane potrzebne do klasyfikacji.

Wstępne powiadomienie – cztery godziny od klasyfikacji

Zgodnie z art. 5 ust. 1 lit. a rozporządzenia delegowanego (UE) 2025/301 podmiot finansowy przekazuje wstępne powiadomienie tak szybko, jak to możliwe, najpóźniej w ciągu czterech godzin od zakwalifikowania incydentu ICT jako poważnego i nie później niż 24 godziny od chwili, gdy dowiedział się o incydencie. Zasada ta wymaga jednak odczytania razem z wyjątkiem z art. 5 ust. 2: jeśli kwalifikacja incydentu jako poważnego nastąpi dopiero po upływie 24 godzin od uzyskania wiedzy o zdarzeniu, wstępne powiadomienie należy przekazać w ciągu czterech godzin od tej późniejszej kwalifikacji. Sam upływ 24 godzin nie zwalnia z obowiązku powiadomienia.

Gdy dotrzymanie terminu jest niemożliwe, art. 5 ust. 3 zobowiązuje podmiot do poinformowania właściwego organu bez zbędnej zwłoki, nie później niż do upływu odpowiedniego terminu, wraz z podaniem przyczyn opóźnienia. W procedurach należy wyraźnie rozdzielić czas wykrycia zdarzenia, moment uzyskania o nim wiedzy i moment klasyfikacji jako poważnego.

Sprawozdanie śródokresowe i końcowe oraz dni wolne

Na podstawie art. 5 ust. 1 lit. b–c rozporządzenia 2025/301 sprawozdanie śródokresowe należy złożyć najpóźniej w ciągu 72 godzin od wstępnego powiadomienia, również gdy status zdarzenia się nie zmienił. Sprawozdanie końcowe należy złożyć nie później niż miesiąc po sprawozdaniu śródokresowym lub ostatniej jego aktualizacji. Obejmuje ono między innymi przyczyny źródłowe, rozwiązanie incydentu oraz koszty i straty.

Art. 5 ust. 4 dopuszcza w określonych przypadkach przedłożenie raportu do południa następnego dnia roboczego, jeśli termin przypada w weekend lub dzień wolny. Nie jest to zasada powszechna: zgodnie z art. 5 ust. 5 nie dotyczy wstępnych i śródokresowych raportów składanych między innymi przez instytucje kredytowe, kontrahentów centralnych, operatorów systemów obrotu i określone podmioty kluczowe lub ważne według NIS2; art. 5 ust. 6 dopuszcza dodatkowe wyłączenia decyzją właściwego organu. Przed zastosowaniem przesunięcia terminu trzeba więc ustalić kategorię podmiotu i właściwe regulacje nadzorcze.

Dostawca zewnętrzny nie zwalnia z odpowiedzialności

Incydent może rozpocząć się u dostawcy chmurowego, operatora systemu płatniczego albo innego podmiotu ICT. DORA pozwala korzystać z outsourcingu także przy obowiązkach raportowych, ale odpowiedzialność regulacyjna pozostaje po stronie podmiotu finansowego. Umowy z dostawcami powinny więc gwarantować szybki przepływ informacji i dostęp do danych potrzebnych do klasyfikacji.

Komunikacja z klientami

Jeżeli poważny incydent ma istotny wpływ na interesy finansowe klientów, podmiot powinien bez zbędnej zwłoki przekazać klientom informacje o incydencie i środkach podjętych w celu ograniczenia skutków. Warto wcześniej przygotować matrycę decyzyjną i wzory komunikatów zamiast tworzyć je od zera w trakcie kryzysu.

Logi i dokumentacja decyzji

W sytuacji incydentu ważne jest nie tylko techniczne przywrócenie usług, ale także udokumentowanie, kiedy zdarzenie wykryto, kiedy je sklasyfikowano i dlaczego przyjęto określoną kategorię. Brak takiej dokumentacji utrudnia późniejszą kontrolę regulatora.

Rola zarządu

Organ zarządzający powinien otrzymywać informacje pozwalające ocenić wpływ incydentu, reakcję oraz działania naprawcze. W praktyce oznacza to potrzebę z góry ustalonego poziomu eskalacji, wskaźników i raportowania zarządczego, a nie jedynie technicznego ticketa w systemie IT.

Przeczytaj również

• Cyberincydent a odpowiedzialność zarządu: obowiązki i nadzór nad ryzykiem
• Phishing i nieautoryzowany przelew – co zrobić i kiedy bank powinien zwrócić pieniądze?

Warto przeczytać także

• KSC i NIS2 w Polsce: obowiązki podmiotów kluczowych i ważnych w 2026 r.