Raport DORA w terminie, dane do poprawki

Incydent rozpoznany i sklasyfikowany jako poważny. Zgłoszenie wstępne wysłane w ciągu czterech godzin od klasyfikacji. Dla zespołu to sukces. Dla nadzoru ten sam raport może być mało użyteczny, bo kwota jest w złej skali, identyfikator zmienił się między wersjami, a raport końcowy nigdy nie dotarł.

16 września 2026 r. europejskie urzędy nadzoru (ESA) opublikowały „DORA Incident Reporting – Operational Instructions”. To 14 krótkich uwag o tym, jak podmioty w praktyce wypełniają formularze z ITS 2025/302. Prawie żadna nie dotyczy tego, czy incydent zgłosić. Niemal wszystkie dotyczą tego, jak to zrobić.

Poprawki do pierwszego roku

W czerwcu ESA opublikowały pierwszy raport o poważnych incydentach ICT za 2025 r. Około 15% zgłoszeń wypadło z analizy, bo w terminie nie wpłynął raport końcowy. Blisko 40% incydentów wykazano z zerowymi kosztami. Autorzy sami przyznali, że praktyki raportowe się rozjeżdżają.

Wrześniowe instrukcje czyta się jak listę poprawek do tamtych danych. Jedna uwaga dotyczy brakujących raportów końcowych. Ostatnia dotyczy wpływu ekonomicznego i odsyła do Q&A EBA o kosztach personelu.

Formalnie to dokument pracowników ESA, przygotowany na zasadzie „best efforts”, a nie wykładnia prawa. Powstał jednak po to, by wspierać organy nadzoru w rozmowach z podmiotami. Został z nimi uzgodniony i będzie aktualizowany, więc trudno go odłożyć na półkę. Raport nadal składa się właściwemu organowi krajowemu, jego kanałem i w jego formacie.

Czternaście uwag w czterech grupach

Ciągłość. Identyfikatory incydentu (pola 1.3a, 1.3b i 2.1) nie mogą się zmieniać od zgłoszenia wstępnego do raportu końcowego, bo wtedy zdarzenie liczy się podwójnie. Korekta to nowa, kompletna wersja ostatniego raportu, a nie plik z jednym poprawionym polem. Jeśli incydent się przeciąga, nadzór oczekuje co najmniej jednego raportu pośredniego miesięcznie, aż do raportu końcowego.

Format. Kwoty w polach 3.11, 4.13 i 4.14 podaje się w tysiącach, w walucie z pola 1.15. Przykładowo 2 500 EUR to „3” albo „2,5”. Nieobowiązkowe pole, które nie ma zastosowania, zostaje puste, bez „N/A” i „nie dotyczy”. Do ESA dane trafiają w angielskich szablonach, więc wartości z list zamkniętych muszą jednoznacznie odpowiadać angielskiej wersji ITS.

Klasyfikacja. Incydent jest poważny, gdy dotknął usług krytycznych i spełniony jest jeden z dwóch warunków. Pierwszy to złośliwy, nieuprawniony dostęp grożący utratą danych. Drugi to przekroczenie progów co najmniej dwóch innych kryteriów. Dlatego „usługi krytyczne” mają zawsze figurować w polu 2.5. Pole 2.6 nie obejmuje państwa macierzystego. Pole 3.17 mówi, czy czas trwania i przestoju to wartości rzeczywiste, czy szacunek. Wypełnia się je w każdym raporcie pośrednim i końcowym. Pola 4.10 i 4.11 dla organów resolution wypełnia się tylko wtedy, gdy ocena wykazała ryzyko.

Dostawca i koszty. Pole 2.8 ma stały format, rozdzielony średnikami: pełna nazwa prawna, kod, typ kodu (LEI lub EUID) i informacja dodatkowa. Jeżeli wpływ ekonomiczny był kryterium klasyfikacji, pole 4.12 w raporcie końcowym trzeba wypełnić zawsze.

Formularz wypełnia jedna osoba, dane mają właścicieli w całej firmie

Lista potwierdza to, co widać przy każdym ćwiczeniu: raport DORA nie jest produktem zespołu bezpieczeństwa. Czas przestoju zna właściciel usługi, liczbę klientów operacje, a koszty finanse. LEI dostawcy powinien być w rejestrze informacji. Compliance składa to w całość, zwykle pod presją zegara, dzwoniąc do ludzi, którzy o incydencie dowiedzieli się godzinę temu. Jeśli kwota trafia do raportu w złej skali, formularz tylko to ujawnia. Przyczyna leży wcześniej.

Co zrobić teraz

• Przejrzeć roboczy formularz i procedurę pod kątem 14 uwag. To kilka godzin pracy, nie projekt.
• Przypisać każdemu polu z danymi biznesowymi i finansowymi właściciela i źródło. Dane dostawcy pobierać z rejestru informacji.
• Zacząć liczyć koszty w dniu wykrycia, łącznie z czasem pracy własnego zespołu.
• Przećwiczyć pełny cykl: zgłoszenie, raport pośredni, korektę i raport końcowy. Pierwsze zgłoszenie zwykle wychodzi dobrze. Kłopoty zaczynają się przy trzeciej wersji.

Kolejny raport roczny ESA znów powstanie z danych przekazanych przez podmioty. Lepiej, żeby tym razem Państwa zgłoszeń nie trzeba było z niego wykluczać.

Źródła

• European Supervisory Authorities, DORA Incident Reporting – Operational Instructions, 16.09.2026: https://www.esma.europa.eu/sites/default/files/2026-09/DORA_Incident_reporting_-_Operational_instructions.pdf
• ESAs, pierwszy raport o poważnych incydentach ICT na podstawie DORA: https://www.esma.europa.eu/press-news/esma-news/esas-publish-first-report-dora-major-ict-related-incidents
• Rozporządzenie (UE) 2022/2554 (DORA): https://eur-lex.europa.eu/eli/reg/2022/2554/oj
• Rozporządzenie delegowane Komisji (UE) 2024/1772 (klasyfikacja incydentów i progi istotności): https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj
• Rozporządzenie delegowane Komisji (UE) 2025/301 (treść i terminy raportów): https://eur-lex.europa.eu/eli/reg_del/2025/301/oj
• Rozporządzenie wykonawcze Komisji (UE) 2025/302 (formularze i procedury raportowania): https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj
• EBA, Q&A 2025_7439 (Staff costs)

Grzegorz Bielecki

vCISO, vCIO i certyfikowany ekspert ds. bezpieczeństwa (CISM, CDPSE, CEH, ISO 27001 Lead Auditor). Od ponad 15 lat wspiera głównie sektor finansowy w budowaniu odporności cyfrowej. Architekt wdrożeń DORA, NIS2\UKSC oraz norm ISO 27001 (SZBI) i ISO 22301 (SZCD). Posiada doświadczenie w projektach zgodności IT przy pozyskiwaniu licencji KIP KNF. Członek ISSA Polska.