Krótka odpowiedź (TL;DR)
DORA obowiązuje bezpośrednio od 17 stycznia 2025 r. i wymaga od podmiotów finansowych klasyfikowania, obsługi oraz raportowania istotnych incydentów ICT według jednolitych zasad. Najważniejsze jest nie tylko samo zgłoszenie, lecz także zdolność wykazania, jak incydent został wykryty, oceniony, eskalowany i usunięty.
1. Incydent musi przejść przez klasyfikację
DORA nie traktuje każdego błędu technicznego tak samo. Instytucja finansowa powinna mieć kryteria istotności: liczba klientów, czas niedostępności, wpływ na transakcje, utrata danych, naruszenie integralności, skutki reputacyjne i możliwy wpływ transgraniczny. Dopiero taka klasyfikacja decyduje, czy incydent jest raportowany jako major ICT-related incident.
W polskim orzecznictwie administracyjnym często wraca ciężar dowodu. NSA w „ciężar dowodu, w zakresie wykazania wymienionych okoliczności, spoczywa na wnioskodawcy" → II FZ 314/17 mówił o wstrzymaniu wykonania decyzji, ale sens jest szerszy: podmiot, który powołuje się na określone skutki, musi je udokumentować. W DORA dotyczy to osi czasu incydentu.
2. Raportowanie to kilka etapów, nie jeden mail
Regulacyjne standardy wykonawcze przewidują formularze i procedury obejmujące wstępne powiadomienie, raport pośredni i raport końcowy. Organizacja musi więc mieć dane o początku incydentu, czasie wykrycia, usługach dotkniętych awarią, zastosowanych środkach i przyczynie źródłowej. Jeśli root cause nie jest znany, trzeba jasno pokazać, co ustalono, a co pozostaje w analizie.
To zmienia pracę zespołów prawnych i IT. Prawnik nie może dostać gotowego opisu po wszystkim; powinien współprojektować słownik incydentów, matrycę eskalacji i decyzje o powiadomieniu.
3. Sankcja zależy od procesu, nie tylko od skutku
Regulator będzie patrzył na powtarzalność i dojrzałość procesu. DORA wymaga zarządzania ryzykiem ICT, testów odporności, ciągłości działania i uczenia się z incydentów. Brak procesu może być poważniejszy niż sam incydent, zwłaszcza gdy instytucja nie potrafi pokazać, kto podjął decyzję i na podstawie jakich danych.
Podobną myśl widać w sprawach VAT, gdzie sądy odróżniają sankcję od podatku. W „w istocie jest sankcją administracyjną" → I FSK 1367/07 NSA wskazywał charakter dodatkowego zobowiązania. W DORA sankcje nadzorcze również będą oceniane przez pryzmat naruszenia obowiązku organizacyjnego.
4. Najciekawszy take: DORA robi z logów materiał dowodowy
Logi, alerty, zapisy komunikacji kryzysowej i decyzje o eskalacji przestają być tylko artefaktem technicznym. Stają się dowodem należytego działania. Instytucje, które nie potrafią odtworzyć przebiegu incydentu, będą miały problem nawet wtedy, gdy usługa szybko wróciła do działania.
Praktyczna lista kontrolna
- zdefiniuj progi istotności incydentu w języku prawnym, biznesowym i technicznym.
- ustal dyżury decyzyjne: kto klasyfikuje incydent, kto raportuje, kto kontaktuje się z nadzorem.
- przygotuj szablony wstępnego, pośredniego i końcowego raportu z listą danych źródłowych.
- łącz logi techniczne z decyzjami menedżerskimi, aby dało się odtworzyć oś czasu.
- po każdym incydencie zapisuj lessons learned, działania naprawcze i właściciela terminu.
Najczęstszy błąd
Najczęstszy błąd to traktowanie raportowania jako zadania compliance po zakończeniu awarii. DORA wymaga danych zbieranych w trakcie incydentu, kiedy decyzje są najtrudniejsze i najbardziej podatne na chaos.
Źródła
Rozporządzenie DORA 2022/2554; standardy wykonawcze dotyczące klasyfikacji i raportowania incydentów ICT; orzecznictwo administracyjne o ciężarze dowodu i sankcjach administracyjnych.