Rozporządzenie DORA: co musi zrobić podmiot finansowy

Czym jest DORA

DORA to rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z 14 grudnia 2022 roku w sprawie operacyjnej odporności cyfrowej sektora finansowego; skrót pochodzi od angielskiej nazwy Digital Operational Resilience Act. Przepisy stosuje się od 17 stycznia 2025 roku.

Założenie jest proste: sektor finansowy opiera się na systemach informatycznych i na dostawcach tych systemów, odporność cyfrowa przestaje więc być sprawą działu IT i staje się elementem stabilności finansowej. Odpowiedzialność za nią rozporządzenie przypisuje organowi zarządzającemu, czyli w praktyce zarządowi.

Rozporządzenie stosuje się bezpośrednio, prawo krajowe ma tu jednak własną rolę: musi wskazać organ nadzoru i określić sankcje. W Polsce zrobiła to ustawa z 25 czerwca 2025 roku o zmianie niektórych ustaw w związku z zapewnieniem operacyjnej odporności cyfrowej sektora finansowego, ogłoszona 6 sierpnia i obowiązująca od 7 sierpnia 2025 roku. To ona wyposaża KNF w uprawnienia kontrolne i sankcyjne, które opisujemy niżej.

Kogo dotyczy

Zakres podmiotowy jest szeroki i obejmuje w zasadzie cały nadzorowany rynek finansowy, nad którym w Polsce czuwa Komisja Nadzoru Finansowego. Przepisy dotyczą między innymi:

• banków i instytucji kredytowych
• firm inwestycyjnych i domów maklerskich
• zakładów ubezpieczeń i reasekuracji
• instytucji płatniczych oraz instytucji pieniądza elektronicznego
• towarzystw funduszy inwestycyjnych i funduszy emerytalnych
• dostawców usług w zakresie kryptoaktywów
• zewnętrznych dostawców usług ICT obsługujących wymienione wyżej podmioty

Ostatnia pozycja bywa zaskoczeniem, ponieważ DORA sięga poza sam sektor finansowy i obejmuje dostawców technologii, którzy go obsługują. Jeżeli Twoja firma dostarcza bankom oprogramowanie lub usługi, wymagania dotyczące poziomów usług i prawa do audytu trafią do niej przez umowy, nawet jeśli sama nie podlega nadzorowi.

Pięć filarów

Wymogi porządkuje się zwykle w pięć obszarów. Podział jest praktyczny przy planowaniu wdrożenia, ponieważ każdy filar wymaga innych kompetencji i innego właściciela po stronie organizacji.

1. Zarządzanie ryzykiem ICT

Podmiot musi utrzymywać udokumentowane ramy zarządzania ryzykiem: identyfikację zasobów i zależności, ochronę, wykrywanie, reagowanie oraz odtwarzanie. Tych ram nie da się scedować na dostawcę, bo odpowiada za nie organ zarządzający, na którym spoczywa dodatkowo obowiązek utrzymywania aktualnej wiedzy o ryzyku ICT.

2. Zgłaszanie incydentów

Podmiot musi mieć proces wykrywania, klasyfikacji i zgłaszania incydentów związanych z ICT. Kryteria klasyfikacji określa rozporządzenie delegowane (UE) 2024/1772, treść zgłoszeń i terminy rozporządzenie delegowane (UE) 2025/301, a wzory formularzy rozporządzenie wykonawcze (UE) 2025/302. Same terminy omawiamy w dalszej części tekstu.

3. Testowanie odporności cyfrowej

Podmiot musi prowadzić program testów obejmujący skanowanie podatności, testy bezpieczeństwa i oceny scenariuszowe. Czym te formy weryfikacji różnią się od audytu i która z nich zamyka obowiązek ustawowy, wyjaśniamy w porównaniu audytu, pentestu i skanowania. Podmioty o istotnym znaczeniu przeprowadzają dodatkowo, w cyklu trzyletnim, zaawansowane testy penetracyjne oparte na scenariuszach zagrożeń (TLPT). Ten obszar wspieramy w ramach audytów i testów penetracyjnych. Osobną kategorią są oceny scenariuszowe dotyczące samej dostępności usługi: jak ustalić, przy jakim natężeniu ruchu infrastruktura przestaje odpowiadać, opisaliśmy przy weryfikacji odporności na atak DDoS.

4. Ryzyko dostawców zewnętrznych

Podmiot musi prowadzić rejestr umów z dostawcami ICT na wzorach z rozporządzenia wykonawczego (UE) 2024/2956, przeprowadza analizę due diligence przed podpisaniem umowy i zapewnia w niej zapisy o poziomach usług, prawie do audytu, zgłaszaniu incydentów oraz strategiach wyjścia. Dostawców uznanych za krytycznych objęto nadzorem na poziomie europejskim: pierwszą ich listę Europejskie Urzędy Nadzoru ogłosiły 18 listopada 2025 roku, i objęła ona 19 dostawców, od hiperskalerów chmurowych po operatorów telekomunikacyjnych. Podstawą oceny krytyczności były właśnie rejestry przekazane wcześniej przez podmioty finansowe.

5. Wymiana informacji o zagrożeniach

Ten filar jest jako jedyny dobrowolny. DORA zachęca podmioty finansowe do udziału w mechanizmach wymiany informacji o cyberzagrożeniach, z zastrzeżeniem ochrony danych i reguł konkurencji.

Terminy zgłaszania poważnych incydentów

To pytanie pada najczęściej, warto więc rozpisać je szczegółowo. Raporty są trzy, ale zegar rusza wcześniej: od chwili zaklasyfikowania incydentu jako poważny.

Cztery godziny brzmią rozsądnie na papierze i zupełnie inaczej w nocy z soboty na niedzielę. W praktyce problemem nie jest sam formularz, lecz ustalenie w tym czasie, czy incydent w ogóle spełnia kryteria poważnego. Bez całodobowego monitoringu, na przykład w modelu SOC-as-a-Service, zegar zaczyna biec, zanim ktokolwiek zdąży zauważyć zdarzenie.

Co zmieni pojedynczy punkt zgłoszeń

Komisja Europejska zaproponowała 19 listopada 2025 roku pakiet Digital Omnibus, a w nim pojedynczy punkt zgłoszeń incydentów prowadzony przez ENISA. Docelowo jedno zgłoszenie ma zaspokajać obowiązki wynikające naraz z DORA, NIS2, RODO, rozporządzenia eIDAS, dyrektywy CER oraz rozporządzenia o cyberodporności produktów. Dla podmiotu finansowego, który przy jednym zdarzeniu melduje się dziś w SOID, a przy naruszeniu danych osobowych osobno w UODO, byłoby to realne uproszczenie.

Do zmiany jest jednak daleko. Część pakietu dotycząca sztucznej inteligencji została wydzielona i przyjęta jako rozporządzenie (UE) 2026/1744, natomiast część obejmująca RODO, NIS2 i DORA wciąż jest przedmiotem negocjacji. Sam punkt zgłoszeń ma ruszyć dopiero 18 miesięcy po wejściu przepisów w życie, z możliwością przedłużenia o kolejne pół roku. Do tego czasu obowiązują dotychczasowe kanały, a terminy z rozporządzenia 2022/2554 pozostają bez zmian. Proces zgłoszeń na 2026 i 2027 rok trzeba więc zaprojektować tak, jakby pojedynczego punktu nie było.

Czego oczekuje KNF

Komisja Nadzoru Finansowego prowadzi sekcję poświęconą DORA, a co istotniejsze w codziennej pracy, uruchomiła dwa odrębne systemy sprawozdawcze. Pomylenie ich kosztuje godziny dokładnie wtedy, gdy godzin brakuje:

• Poważne incydenty ICT i znaczące cyberzagrożenia zgłasza się w Systemie Obsługi Incydentów DORA (SOID) pod adresem csirt.knf.gov.pl
• Gdy SOID jest niedostępny, zgłoszenie kieruje się na adres incydenty.dora@knf.gov.pl, na formularzu opublikowanym przez KNF
• Pozostała sprawozdawczość DORA, w tym rejestr umów z dostawcami ICT, przechodzi przez System Sprawozdawczości DORA (SSD) pod adresem crp.knf.gov.pl
• KNF oczekuje kompletu dokumentów: zgłoszenia wstępnego oraz raportu śródokresowego i końcowego
• Rejestr umów przekazywany jest cyklicznie, a termin każdej tury KNF ogłasza osobno w aktualnościach DORA
• Pytania interpretacyjne można kierować na adres konsultacje.dora@knf.gov.pl
• Mniejsze podmioty mogą stosować uproszczone ramy zarządzania ryzykiem ICT, co nie zwalnia ich jednak ze zgłaszania incydentów

Sankcje

Wokół tego tematu krąży najwięcej błędnych liczb, uporządkujmy je więc po kolei. Sama DORA nie wskazuje kwot dla podmiotów finansowych: artykuł 50 zobowiązuje państwa członkowskie do ustanowienia kar skutecznych, proporcjonalnych i odstraszających, a ich wysokość pozostawia prawu krajowemu. W Polsce określa ją artykuł 18zm ustawy o nadzorze nad rynkiem finansowym, dodany ustawą z 25 czerwca 2025 roku. KNF może nałożyć karę do 20 869 500 złotych, do 10% przychodu wykazanego w ostatnim zatwierdzonym sprawozdaniu finansowym albo do dwukrotności uzyskanej korzyści, a wobec członka zarządu odpowiedzialnego za naruszenie do 3 042 410 złotych.

Po stronie dostawców zasady wyglądają inaczej. Krytyczny zewnętrzny dostawca usług ICT podlega nadzorowi europejskiemu, a wiodący organ nadzorczy może na podstawie artykułu 35 ust. 6 nakładać okresowe kary pieniężne do 1% średniego dziennego światowego obrotu z poprzedniego roku, naliczane codziennie przez maksymalnie sześć miesięcy. Nie jest to kwota jednorazowa i nie ma nic wspólnego z liczbą 5 milionów euro, która krąży po branżowych prezentacjach.

W praktyce dotkliwsze bywają jednak inne skutki: decyzje nadzorcze ograniczające działalność lub nakazujące rozwiązanie umowy z dostawcą. Karę płaci się raz, a wypowiedzenie umowy z dostawcą systemu core bankingowego to projekt na kwartały.

Od czego zacząć w praktyce

Jeżeli wdrożenie jest opóźnione, kolejność działań ma większe znaczenie niż tempo. Poniżej kroki w takiej kolejności, w jakiej dają najwięcej przy najmniejszym nakładzie, wraz z tym, kto zwykle je prowadzi:

1. Tydzień 1Zakupy i IT
   Zamknij rejestr umów z dostawcami ICT

   Kontrola zaczyna się zwykle od rejestru, bo to jedyny dokument pokazujący zależności podmiotu w całości. Zakres pól narzuca rozporządzenie 2024/2956, a rejestr przekazuje się cyklicznie przez System Sprawozdawczości DORA. To także dane, na podstawie których Europejskie Urzędy Nadzoru oceniają, którzy dostawcy są krytyczni.

2. Tydzień 1–2Zarząd i CISO
   Wskaż osobę, która klasyfikuje incydent

   Zegar czterech godzin rusza od klasyfikacji, więc nazwisko i zastępstwo muszą być ustalone wcześniej niż incydent. Trzeba przesądzić, kto podejmuje decyzję w sobotę w nocy i kto podpisuje zgłoszenie w SOID. Jak wygląda taka pierwsza godzina w praktyce, rozpisaliśmy w runbooku po ataku ransomware.

3. Tydzień 2–4Dział prawny
   Przejrzyj umowy z kluczowymi dostawcami

   Sprawdzasz cztery rzeczy: poziomy usług, prawo do audytu, obowiązek zgłaszania incydentów i strategię wyjścia. Renegocjacja trwa miesiącami, więc zaczyna się od umów wspierających funkcje krytyczne, a nie od tych, które akurat wygasają najwcześniej.

4. Kwartał 1Bezpieczeństwo
   Uruchom wykrywanie w trybie całodobowym

   Bez tego terminy z rozporządzenia pozostają teoretyczne, bo incydent zauważony w poniedziałek rano nie mieści się w żadnym z nich. Jeżeli własny zespół nie pracuje 24/7, rozwiązaniem jest SOC-as-a-Service. Monitoringiem warto objąć również wyciek danych logowania, bo ekspozycja w stealer logach jest ryzykiem ICT w rozumieniu artykułu 8.

5. Kwartał 1–2Bezpieczeństwo i zarząd
   Zaplanuj program testów, a dla podmiotów istotnych TLPT

   Program obejmuje skanowanie podatności, testy penetracyjne i oceny scenariuszowe. Zaawansowane testy TLPT wykonuje się w cyklu trzyletnim, wymagają zewnętrznego wykonawcy i uzgodnień z nadzorem, więc planuje się je z wyprzedzeniem liczonym w kwartałach, nie w tygodniach.

6. Na stałeZarząd
   Utrzymuj wiedzę o ryzyku ICT na poziomie zarządu

   Rozporządzenie nakłada ten obowiązek wprost na organ zarządzający i nie da się go scedować ani na dostawcę, ani na dział IT. Jeżeli w organizacji brakuje kompetencji na tym poziomie, wirtualny CISO zamyka lukę szybciej niż roczna rekrutacja.

DORA a NIS2

Oba akty dotyczą odporności cyfrowej i bywają mylone. Różnica jest prosta: DORA to regulacja sektorowa dla finansów i ma pierwszeństwo przed NIS2 wszędzie tam, gdzie zakresy się pokrywają. Podmiot finansowy stosuje zatem DORA, choć w grupach kapitałowych prowadzących działalność również poza sektorem finansowym oba reżimy potrafią obowiązywać jednocześnie.

Pomyłka ma tu wymierny koszt. Limit 2% światowego obrotu albo 10 milionów euro dla podmiotów kluczowych pochodzi z NIS2, nie z DORA. Mimo to regularnie trafia do materiałów o DORA, gdzie nie ma zastosowania, i prowadzi do oceny ryzyka opartej na błędnej podstawie. Różnią się także zegary: NIS2 daje 24 godziny na wczesne ostrzeżenie, licząc od powzięcia wiedzy o incydencie, DORA 4 godziny od jego klasyfikacji. Jeżeli grupa prowadzi działalność również poza finansami, druga ścieżka biegnie z ustawy o KSC. Kogo obejmuje i w jakich terminach, rozpisaliśmy w osobnym tekście o NIS2 i ustawie o krajowym systemie cyberbezpieczeństwa.

Najczęstsze pytania

Podsumowanie

DORA nie wprowadza wymagań technicznych nieznanych zespołom bezpieczeństwa. Nowe jest to, że przypisuje je konkretnym osobom, wyznacza terminy liczone w godzinach i wiąże z sankcjami. Największe braki, które widujemy, nie dotyczą technologii, lecz tego, kto podejmuje decyzję o klasyfikacji incydentu w sobotę o drugiej w nocy.

Cztery godziny na zgłoszenie zaczynają biec od klasyfikacji incydentu. Problem w tym, że najpierw ktoś musi go zauważyć.