DORA: co naprawdę wymaga od firm finansowych

DORA (Digital Operational Resilience Act) obowiązuje w całej UE od 17 stycznia 2025 — bez okresu przejściowego i bez potrzeby polskiej ustawy wdrażającej, bo to rozporządzenie stosowane wprost. Półtora roku później nadzorcy zakończyli fazę „zbierania mapy” i przeszli do egzekwowania: pierwsze wezwania do uzupełnienia rejestrów umów ICT i pytania o wyniki testów odporności już trafiły do polskich podmiotów. To dobry moment na uporządkowaną odpowiedź na pytanie: co DORA naprawdę oznacza w praktyce — także jeśli nie jesteś bankiem, tylko jego dostawcą.

Kogo dotyczy DORA

Lista jest długa — ponad 20 kategorii podmiotów finansowych, m.in.: banki, firmy inwestycyjne, zakłady ubezpieczeń i pośrednicy ubezpieczeniowi, instytucje płatnicze i pieniądza elektronicznego, TFI i fundusze, dostawcy usług w zakresie kryptoaktywów, giełdy i izby rozliczeniowe. Zasada proporcjonalności łagodzi wymogi dla mniejszych podmiotów, ale nie wyłącza ich spod rozporządzenia.

Drugą grupą objętą DORA — i często tym zaskoczoną — są zewnętrzni dostawcy usług ICT dla sektora finansowego: software house utrzymujący system dla banku, dostawca SaaS dla ubezpieczyciela, firma hostingowa obsługująca instytucję płatniczą. DORA działa na nich przez umowy: instytucja finansowa musi wymusić na dostawcy konkretne zapisy (audyt, raportowanie incydentów, strategie wyjścia), a najwięksi dostawcy krytyczni podlegają bezpośredniemu nadzorowi europejskiemu.

Pięć filarów DORA w praktyce

1. Zarządzanie ryzykiem ICT. Udokumentowane ramy zarządzania ryzykiem: inwentaryzacja systemów i funkcji krytycznych, analiza ryzyka, zabezpieczenia, ciągłość działania i kopie zapasowe z testami odtwarzania. Odpowiedzialność spoczywa wprost na organie zarządzającym — zarząd zatwierdza strategię, przegląda ją i ma obowiązek rozumieć ryzyka ICT (szkolenia dla zarządu to wymóg, nie opcja).

2. Zgłaszanie incydentów. Ujednolicona klasyfikacja incydentów ICT i twarde terminy raportowania poważnych incydentów do nadzoru (w Polsce: KNF): wstępne powiadomienie do 4 godzin od klasyfikacji (i 24 h od wykrycia), raport pośredni do 72 godzin, raport końcowy w ciągu miesiąca. Te terminy są nie do dotrzymania bez gotowego procesu — tego samego, który opisujemy przy reagowaniu na wycieki, tylko z ostrzejszym zegarem.

3. Testowanie operacyjnej odporności cyfrowej. DORA jako pierwsza regulacja tej rangi nakazuje testy bezpieczeństwa: wszystkie podmioty muszą mieć program testowania (skany podatności, oceny bezpieczeństwa, testy penetracyjne) wykonywany co najmniej raz w roku dla systemów krytycznych. Podmioty wskazane przez nadzór przechodzą dodatkowo TLPT (threat-led penetration testing — testy w konwencji red team wg ram TIBER-EU) co trzy lata, prowadzone przez niezależnych, wykwalifikowanych testerów.

4. Zarządzanie ryzykiem zewnętrznych dostawców ICT. Pełny rejestr informacji o wszystkich umowach ICT (wzór narzucony standardem technicznym), ocena ryzyka koncentracji, obowiązkowe klauzule umowne (prawo audytu, SLA, raportowanie incydentów, plany wyjścia) oraz strategia na wypadek upadku kluczowego dostawcy. To filar, który generuje najwięcej pracy operacyjnej — i najwięcej pytań nadzoru. Szerzej o zarządzaniu dostawcami piszemy w tekście o TPRM.

5. Wymiana informacji. Zachęta (nie obowiązek) do udziału w mechanizmach wymiany informacji o zagrożeniach w ramach sektora.

DORA a NIS2: czym się różnią

Częste pytanie firm, które łapią się na obie regulacje. Zasada kolizyjna jest prosta: DORA jako lex specialis ma pierwszeństwo dla podmiotów finansowych — w zakresie, który reguluje, zastępuje wymogi NIS2. Praktyczne różnice: DORA jest bardziej szczegółowa (konkretne terminy, wzory rejestrów, obowiązkowe testy), obowiązuje wprost bez ustawy krajowej i kładzie znacznie większy nacisk na dostawców zewnętrznych. Jeśli budujesz zgodność z oboma — zacznij od DORA, a NIS2 „dostaniesz” w dużej mierze przy okazji.

Od czego zacząć: plan na pierwsze 90 dni

1. Mapowanie — lista funkcji krytycznych i wspierających je systemów oraz dostawców; bez tej mapy żaden filar nie zadziała.
2. Rejestr umów ICT — inwentaryzacja wszystkich umów z dostawcami ICT według wymaganego wzoru; przegląd klauzul pod kątem wymogów DORA (audyt, incydenty, wyjście).
3. Proces incydentowy — klasyfikacja, progi istotności, szablony zgłoszeń do KNF, ćwiczenie na sucho z zegarem 4/24/72 h.
4. Program testów — harmonogram skanów i testów penetracyjnych dla systemów krytycznych; pierwsze testy z raportem, który obroni się przed nadzorem.
5. Dokumentacja i zarząd — strategia odporności cyfrowej zatwierdzona przez zarząd, szkolenie zarządu, przypisanie ról.

Jeśli jesteś dostawcą ICT dla finansów

Przygotuj się, że klienci z sektora zaczną wymagać: zapisów umownych (audyt, raportowanie incydentów w godzinach, plany wyjścia i wsparcie migracji), dowodów bezpieczeństwa (wyniki testów penetracyjnych, certyfikacje, polityki) oraz udziału w ich ćwiczeniach. Firmy, które mają te elementy gotowe, wygrywają przetargi — bo skracają klientowi proces due diligence z miesięcy do dni. Regularny test penetracyjny z raportem przygotowanym pod wymogi klientów finansowych to dziś standardowy element oferty dla tego sektora.

Najczęstsze pytania (FAQ)

Czy DORA wymaga od nas czerwonych zespołów (TLPT)? Tylko jeśli nadzór Cię wskaże — kryteria to skala, krytyczność i profil ryzyka; w praktyce dotyczy to największych graczy. Cała reszta ma „zwykły” obowiązek programu testów, w tym corocznych testów systemów krytycznych. Uwaga: nadzorca może rozszerzać listę TLPT — warto mieć dojrzałość testową zanim zapuka.

Jesteśmy małym pośrednikiem ubezpieczeniowym. Czy DORA nas obejmuje? Najmniejsi pośrednicy (mikroprzedsiębiorcy) są wyłączeni, a zasada proporcjonalności łagodzi wymogi dla małych podmiotów — ale nie znosi podstaw: zarządzania ryzykiem, obsługi incydentów i kontroli dostawców. Sprawdź swoją kategorię u prawnika; od strony technicznej podstawy i tak warto mieć.

Co grozi za brak zgodności? KNF dysponuje środkami nadzorczymi i sankcjami administracyjnymi (z karami finansowymi włącznie), ale w praktyce pierwszym kosztem jest operacyjny: wezwania, zalecenia, konieczność szybkiego uzupełniania braków pod presją. Drugi koszt to biznesowy — instytucje finansowe odsiewają dostawców bez zgodności już na etapie zakupów.

Czym różni się test penetracyjny „pod DORA” od zwykłego? Zakresem i dokumentacją: test musi pokrywać systemy wspierające funkcje krytyczne, być prowadzony przez wykwalifikowanych testerów, a raport — nadawać się jako dowód dla nadzoru (metodyka, zakres, ryzyka, plan naprawczy, retest). Prowadzimy takie testy i pomagamy ułożyć cały roczny program — porozmawiajmy.

Czy chmura publiczna jest zgodna z DORA? Sama w sobie — to złe pytanie. DORA nie zakazuje chmury; wymaga, żebyś rozumiał ryzyko koncentracji, miał odpowiednie klauzule umowne, plan wyjścia i nadzór nad dostawcą. Najwięksi dostawcy chmurowi zostali objęci bezpośrednim nadzorem UE jako dostawcy krytyczni, co porządkuje część tematów — ale obowiązki po Twojej stronie zostają.

Podsumowanie

DORA przenosi bezpieczeństwo z kategorii „dobre praktyki” do kategorii „obowiązek prawny z terminami i wzorami dokumentów”. Pięć filarów — ryzyko ICT, incydenty, testy, dostawcy, wymiana informacji — układa się w spójny program, który i tak warto mieć: rozporządzenie tylko dodaje mu rygor. Jeśli potrzebujesz wsparcia w części technicznej — od programu testów, przez testy penetracyjne, po przygotowanie procesu incydentowego — odezwij się. Pomagamy zarówno instytucjom finansowym, jak i ich dostawcom ICT.

Artykuł nie stanowi porady prawnej. Źródła: Rozporządzenie (UE) 2022/2554 (DORA), komunikaty KNF i EBA/ESMA/EIOPA.