W jednym zdaniu. Oprogramowanie DORA ma utrzymać rejestr informacji o umowach ICT w formacie wymaganym przez RTS, sklasyfikować i zaraportować poważne incydenty ICT do KNF w terminie oraz zarządzać ryzykiem dostawców zewnętrznych — a arkusze nie utrzymają rejestru przy dziesiątkach umów ICT.
Jakie oprogramowanie DORA wybrać w 2026 r.? Takie, które obsłuży trzy najbardziej pracochłonne obowiązki rozporządzenia: prowadzenie rejestru informacji o umowach ICT w ustandaryzowanym formacie (RTS), klasyfikację i raportowanie poważnych incydentów ICT do właściwego organu nadzoru (w Polsce — KNF) oraz zarządzanie ryzykiem zewnętrznych dostawców ICT. DORA obowiązuje od 17 stycznia 2025 r. i dotyczy banków, ubezpieczycieli, TFI, firm inwestycyjnych oraz fintechów z licencją KNF. Poniżej porównuję kategorie narzędzi i wskazuję, co realnie decyduje o wyborze.
Najważniejsze punkty
- Rejestr informacji o umowach ICT ma ustrukturyzowany format (RTS) — Excel przestaje działać przy dziesiątkach umów.
- Incydenty ICT klasyfikuje się według progów istotności i raportuje do KNF w twardych terminach.
- DORA obejmuje pięć filarów: zarządzanie ryzykiem ICT, incydenty, testowanie, ryzyko stron trzecich, wymiana informacji.
- Krytyczni dostawcy ICT (np. chmura) podlegają bezpośredniemu nadzorowi ESA.
- DORA jest lex specialis wobec NIS2 dla podmiotów finansowych — pierwszeństwo ma DORA.
Pięć filarów DORA, które narzędzie musi obsłużyć
DORA to nie pojedynczy obowiązek, lecz kompletny reżim odporności cyfrowej oparty na pięciu filarach. Dobre oprogramowanie odwzorowuje każdy z nich.
Zarządzanie ryzykiem ICT (art. 5–16) — ramy zarządzania, rejestr aktywów ICT, ocena ryzyka i mechanizmy ciągłości działania. To fundament, na którym opiera się reszta.
Zarządzanie incydentami ICT (art. 17–23) — proces wykrywania, klasyfikacji i raportowania. Kluczowa jest klasyfikacja: nie każdy incydent jest „poważny", a raportuje się te przekraczające progi istotności określone w RTS.
Testowanie odporności cyfrowej (art. 24–27) — od podstawowych testów po zaawansowane testy penetracyjne oparte na scenariuszach zagrożeń (TLPT) dla największych podmiotów.
Ryzyko dostawców ICT (art. 28–44) — serce operacyjne DORA. Obejmuje rejestr informacji o umowach ICT i zarządzanie ryzykiem stron trzecich. O tym niżej.
Wymiana informacji (art. 45) — dobrowolne dzielenie się informacjami o zagrożeniach i podatnościach w ramach zaufanych społeczności sektora finansowego.
Pięć filarów nie jest równie pracochłonne. Dla większości podmiotów ciężar rozkłada się nierówno: rejestr informacji o umowach ICT i raportowanie incydentów pochłaniają najwięcej bieżącej pracy, testowanie odporności jest projektem cyklicznym, a wymiana informacji pozostaje opcjonalna. Dlatego wybierając narzędzie, oceniaj je przede wszystkim przez pryzmat dwóch najcięższych filarów, a nie przez długość listy obsługiwanych funkcji.
Rejestr informacji o umowach ICT: dlaczego Excel pęka
Najbardziej pracochłonny i najczęściej niedoszacowany obowiązek DORA to rejestr informacji o umowach z dostawcami ICT. To nie jest zwykła lista kontrahentów — RTS (regulacyjne standardy techniczne) narzucają ustrukturyzowany format z dziesiątkami pól: identyfikacja dostawcy (m.in. kod LEI), rodzaj usługi ICT, powiązanie z funkcjami krytycznymi lub istotnymi, łańcuch podwykonawców, lokalizacja przetwarzania danych i wiele innych.
Przy kilku umowach arkusz jeszcze się broni. Przy kilkudziesięciu — a tyle ma typowy średni bank czy zakład ubezpieczeń — utrzymanie spójności formatu, aktualności i powiązań ręcznie staje się niewykonalne. Jeden dostawca chmurowy pociąga łańcuch podwykonawców; zmiana usługi wymaga aktualizacji wielu powiązanych rekordów. Narzędzie, które waliduje format pod RTS i utrzymuje powiązania automatycznie, jest tu różnicą między rejestrem gotowym do przekazania KNF a arkuszem, który przy pierwszej weryfikacji się sypie. Ten obowiązek jest bliski logice rejestru czynności przetwarzania z RODO — tyle że o wyższym rygorze formalnym.
Dodatkowa trudność polega na tym, że rejestr informacji nie jest dokumentem statycznym. Organ nadzoru może zażądać jego przekazania w ustalonym cyklu, a format bywa aktualizowany przez ESA wraz z nowymi wersjami standardów technicznych. To oznacza, że rejestr trzeba nie tylko raz zbudować, ale utrzymywać w zgodzie ze zmieniającym się schematem — zadanie, które w arkuszu wymaga ręcznego przemapowania kolumn przy każdej zmianie. System, który aktualizuje schemat centralnie, zdejmuje z zespołu compliance to ryzyko. Warto też pamiętać, że rejestr obejmuje wszystkie umowy ICT, a nie tylko te dotyczące funkcji krytycznych — choć dla funkcji krytycznych zakres wymaganych informacji jest szerszy.
Praktyczny błąd, który powtarza się w instytucjach, to rozpoczęcie budowy rejestru zbyt późno. Identyfikacja wszystkich dostawców ICT, zebranie kodów LEI i odtworzenie łańcucha podwykonawców to projekt na tygodnie, nie na dni. Narzędzie, które ma wbudowaną strukturę pól i prowadzi przez ich uzupełnianie, znacząco skraca ten rozruch w porównaniu z budowaniem arkusza od zera.
Klasyfikacja i raportowanie incydentów do KNF
Drugi filar operacyjny to incydenty. DORA wymaga klasyfikacji incydentu ICT według kryteriów istotności (liczba dotkniętych klientów, czas trwania, zasięg geograficzny, utrata danych, wpływ ekonomiczny) i — dla poważnych incydentów — raportowania do właściwego organu w ściśle określonych terminach: zgłoszenie wstępne, raport pośredni i raport końcowy.
W Polsce organem nadzoru jest Komisja Nadzoru Finansowego (KNF). Narzędzie powinno prowadzić przez klasyfikację (odsiewając incydenty poniżej progu od poważnych), generować treść zgłoszenia w wymaganym formacie i pilnować terminów kolejnych raportów. Sama klasyfikacja jest nietrywialna: te same kryteria istotności trzeba stosować spójnie w czasie, by uniknąć zarówno nadmiernego raportowania drobnych zdarzeń, jak i przeoczenia incydentu, który przekroczył próg. Narzędzie z wbudowaną logiką progów daje tu powtarzalność, której ręczna ocena „na wyczucie" nie zapewni. Dochodzi jeszcze wątek zagrożeń cybernetycznych: DORA przewiduje dobrowolne zgłaszanie istotnych cyberzagrożeń, nawet gdy nie doszło jeszcze do incydentu — co również warto móc udokumentować. Dokumentowanie bezpieczeństwa i reakcji na incydenty łączy się z obowiązkami RODO — zob. art. 32 RODO oraz procedurę zgłoszenia naruszenia, bo jeden incydent może wymagać zgłoszeń w obu reżimach. Sektorowy kontekst RODO opisuje przewodnik RODO w sektorze bankowym i finansowym.
Porównanie kategorii narzędzi DORA
Duże platformy GRC obsłużą DORA kompleksowo, ale ich koszt i czas wdrożenia są uzasadnione w największych instytucjach. Moduły w systemach core integrują się z operacjami, lecz rzadko dostarczają rejestr informacji ICT zgodny z RTS bez dużej konfiguracji. Narzędzia TPRM świetnie oceniają dostawców, ale nie zamkną filaru incydentów. Dla średnich podmiotów — regionalnego banku, zakładu ubezpieczeń, TFI czy licencjonowanego fintechu — najlepiej sprawdza się rozwiązanie zintegrowane łączące rejestr informacji ICT, klasyfikację incydentów i zarządzanie ryzykiem dostawców bez narzutu molocha. Relację DORA do zabezpieczeń łańcucha dostaw warto czytać razem z umowami powierzenia i implementacją NIS2 w Polsce.
DORA a NIS2: pierwszeństwo lex specialis
Podmioty finansowe często pytają, czy podlegają NIS2, czy DORA. Odpowiedź: dla zakresu ryzyka ICT DORA jest lex specialis i ma pierwszeństwo przed NIS2. To upraszcza wybór narzędzia — budujesz zgodność wokół DORA, a nie wokół obu reżimów równolegle. Polski kontekst nadzorczy i harmonogram opisuje przewodnik DORA w Polsce.
Nie znaczy to, że NIS2 znika z pola widzenia grupy kapitałowej. Jeśli w skład grupy wchodzą podmioty spoza sektora finansowego — na przykład spółka technologiczna świadcząca usługi ICT — mogą one podlegać NIS2 niezależnie i wymagać osobnego oprogramowania do zgodności z NIS2. W praktyce oznacza to konieczność mapowania, który podmiot pod jaki reżim wpada, i dobierania narzędzia tak, by obsłużyło obie ścieżki tam, gdzie faktycznie występują. Dla samej instytucji finansowej priorytetem pozostaje jednak DORA, i to jej wymogi wyznaczają zakres funkcji, których szukasz w oprogramowaniu.
Jak wybrać: kryteria zakupu
- Sprawdź rejestr informacji ICT. Czy narzędzie waliduje format pod RTS i utrzymuje łańcuch podwykonawców?
- Oceń workflow incydentów. Czy prowadzi przez klasyfikację i terminy raportów do KNF?
- Zweryfikuj zarządzanie ryzykiem dostawców. Ocena, monitoring, powiązanie z umowami.
- Uwzględnij testowanie. Czy narzędzie dokumentuje program testów odporności?
- Policz TCO. Enterprise GRC bywa niewspółmierny do potrzeb średniej instytucji — porównaj z lekkim rozwiązaniem zintegrowanym o przewidywalnym cenniku.
Kolejność wdrożenia też ma znaczenie. Zacznij od dwóch obowiązków o najkrótszym czasie do wartości: rejestru informacji ICT i procedury raportowania incydentów, bo to one są najpilniej weryfikowane przez nadzór i najtrudniejsze do odtworzenia wstecz. Testowanie odporności i pełne ramy zarządzania ryzykiem można dojrzewać etapami. Narzędzie, które pozwala uruchamiać filary stopniowo, zamiast wymagać kompletnej konfiguracji na starcie, lepiej pasuje do realiów średniej instytucji, która wdraża DORA obok bieżącej działalności.
FAQ
Czy oprogramowanie DORA jest obowiązkowe?
Nie. DORA nie nakazuje konkretnego narzędzia, ale wymaga prowadzenia rejestru informacji o umowach ICT w formacie RTS, klasyfikacji i raportowania poważnych incydentów oraz zarządzania ryzykiem dostawców. Przy dziesiątkach umów ICT utrzymanie tego w arkuszach jest praktycznie niewykonalne — dlatego podmioty finansowe sięgają po dedykowane rozwiązania.
Do kogo raportuje się incydenty ICT w Polsce?
W Polsce organem nadzoru w ramach DORA jest Komisja Nadzoru Finansowego (KNF). Poważne incydenty ICT raportuje się do KNF w trójstopniowym modelu: zgłoszenie wstępne, raport pośredni i raport końcowy, w terminach określonych przepisami wykonawczymi. Narzędzie powinno pilnować tych terminów i generować zgłoszenia w wymaganym formacie.
Czy podmiot finansowy podlega DORA, czy NIS2?
W zakresie ryzyka ICT DORA jest lex specialis i ma pierwszeństwo przed NIS2 dla podmiotów finansowych. W praktyce oznacza to, że instytucja finansowa buduje zgodność wokół DORA. To upraszcza wybór narzędzia, bo nie trzeba utrzymywać dwóch równoległych reżimów raportowania incydentów ICT.
Kogo obejmuje DORA?
DORA obejmuje szeroki katalog podmiotów finansowych: banki, SKOK-i, zakłady ubezpieczeń i reasekuracji, TFI, firmy inwestycyjne, dostawców usług płatniczych, dostawców usług w zakresie kryptoaktywów oraz — pośrednio — krytycznych zewnętrznych dostawców ICT, którzy podlegają bezpośredniemu nadzorowi europejskich organów nadzoru.
Źródła: Rozporządzenie 2022/2554 (DORA), EUR-Lex · Komisja Nadzoru Finansowego (KNF) · EIOPA.