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. Nazwa pochodzi od angielskiego Digital Operational Resilience Act. Stosuje się je od 17 stycznia 2025 roku.

Podstawowe założenie jest proste. Sektor finansowy stoi na systemach informatycznych i na dostawcach tych systemów, więc odporność cyfrowa przestaje być sprawą działu IT, a staje się elementem stabilności finansowej. DORA przenosi odpowiedzialność za nią na organ zarządzający, czyli w praktyce na zarząd.

Kogo dotyczy

Zakres jest szeroki i obejmuje w zasadzie cały nadzorowany rynek finansowy. W Polsce nadzór sprawuje 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 powyższe podmioty

Ostatnia pozycja bywa zaskoczeniem. DORA sięga poza sam sektor finansowy i obejmuje dostawców technologii, którzy go obsługują. Jeśli Twoja firma dostarcza oprogramowanie albo usługi bankom, wymagania z umów o poziom usług i audyt trafią do Ciebie niezależnie od tego, że sama nie jest podmiotem nadzorowanym.

Pięć filarów

Wymogi porządkuje się zwykle w pięć obszarów. Podział przydaje się przy planowaniu wdrożenia, bo każdy filar wymaga innych kompetencji.

1. Zarządzanie ryzykiem ICT

Potrzebne są udokumentowane ramy zarządzania ryzykiem: identyfikacja zasobów i zależności, ochrona, wykrywanie, reagowanie i odtwarzanie. Odpowiedzialność spoczywa na organie zarządzającym i nie da się jej scedować na dostawcę. Zarząd ma też obowiązek utrzymywać wiedzę o ryzyku ICT na bieżąco.

2. Zgłaszanie incydentów

Trzeba mieć proces wykrywania, klasyfikacji i zgłaszania incydentów związanych z ICT. Kryteria klasyfikacji określa RTS 2024/1772, a treść zgłoszeń i szablony odpowiednio RTS 2025/301 oraz ITS 2025/302. Terminy opisujemy niżej.

3. Testowanie odporności cyfrowej

Wymagany jest program testów obejmujący skanowanie podatności, testy bezpieczeństwa i oceny scenariuszowe. Podmioty o istotnym znaczeniu przeprowadzają dodatkowo zaawansowane testy penetracyjne oparte na scenariuszach zagrożeń, czyli TLPT, w cyklu trzyletnim. To obszar, w którym pomagamy w ramach audytów i testów penetracyjnych.

4. Ryzyko dostawców zewnętrznych

Konieczny jest rejestr umów z dostawcami ICT, analiza due diligence przed podpisaniem i zapisy umowne o poziomach usług, prawie do audytu, zgłaszaniu incydentów i strategiach wyjścia. Dla dostawców uznanych za krytycznych wprowadzono nadzór na poziomie europejskim.

5. Wymiana informacji o zagrożeniach

Ten filar jest dobrowolny. DORA zachęca do udziału w mechanizmach wymiany informacji o cyberzagrożeniach między podmiotami finansowymi, przy zachowaniu ochrony danych i reguł konkurencji.

Terminy zgłaszania poważnych incydentów

To pytanie pada najczęściej, więc rozpiszmy je konkretnie. Zgłoszenie poważnego incydentu ICT ma trzy etapy:

Cztery godziny brzmią rozsądnie na papierze i zupełnie inaczej w nocy z soboty na niedzielę. Największym problemem w praktyce nie jest sam formularz, tylko 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, ten zegar zaczyna biec, zanim ktokolwiek zdąży zauważyć zdarzenie.

Czego oczekuje KNF

Komisja Nadzoru Finansowego prowadzi dedykowaną sekcję poświęconą DORA, publikuje odpowiedzi na pytania i wskazuje systemy sprawozdawcze. Z praktycznego punktu widzenia warto pamiętać o kilku rzeczach:

• Zgłoszenia incydentów odbywają się elektronicznie, przez systemy wskazane przez KNF
• KNF oczekuje kompletu: zgłoszenia wstępnego, raportu śródokresowego i końcowego
• Rejestr umów z dostawcami ICT podlega raportowaniu i musi być aktualny
• Pytania interpretacyjne można kierować na adres konsultacja.dora@knf.gov.pl
• Mniejsze podmioty mogą stosować uproszczone ramy zarządzania ryzykiem ICT, ale nie zwalnia ich to ze zgłaszania incydentów

Sankcje

Za naruszenie przepisów przewidziano kary sięgające 2% całkowitego rocznego obrotu podmiotu finansowego. Dla dostawców ICT uznanych za krytycznych kary mogą wynieść do 5 milionów euro. Warto jednak zauważyć, że w praktyce dotkliwszy bywa inny skutek, czyli decyzje nadzorcze ograniczające działalność albo nakazujące rozwiązanie umowy z dostawcą.

Od czego zacząć w praktyce

Jeśli wdrożenie jest opóźnione, kolejność ma znaczenie. Te kroki dają najwięcej przy najmniejszym nakładzie:

• Zinwentaryzuj dostawców ICT i uzupełnij rejestr umów, bo od tego zwykle zaczyna się kontrola
• Ustal, kto i na jakiej podstawie klasyfikuje incydent jako poważny, oraz kto zgłasza go w 4 godziny
• Sprawdź, czy umowy z kluczowymi dostawcami mają zapisy o audycie, poziomach usług i strategii wyjścia
• Zapewnij wykrywanie zdarzeń całą dobę, na przykład przez SOC-as-a-Service, bo bez tego terminy są nierealne
• Zaplanuj program testów, w tym testy penetracyjne, a dla podmiotów istotnych także TLPT
• Monitoruj wycieki danych logowania, bo ekspozycja w stealer logach to wprost ryzyko ICT w rozumieniu artykułu 8
• Jeśli brakuje kompetencji na poziomie zarządu, rozważ wirtualnego CISO zamiast wakatu trwającego rok

DORA a NIS2

Oba akty dotyczą odporności cyfrowej i bywają mylone. Różnica jest prosta: DORA jest przepisem sektorowym dla finansów i ma pierwszeństwo przed NIS2 tam, gdzie zakresy się pokrywają. Podmiot finansowy stosuje więc DORA, a nie NIS2, choć w grupach kapitałowych z działalnością poza sektorem finansowym mogą obowiązywać oba reżimy jednocześnie.

Podsumowanie

DORA nie wprowadza wymagań technicznych, których nie znałby żaden zespół bezpieczeństwa. Nowe jest to, że przypisuje je konkretnym osobom, wyznacza terminy liczone w godzinach i wiąże z sankcjami. Największe braki, jakie widujemy, nie dotyczą technologii, tylko 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ć.