Rozporządzenie DORA (Digital Operational Resilience Act) obowiązuje od ponad czternastu miesięcy — a znaczna część polskiego sektora finansowego wciąż traktuje je jak odległy problem. Tymczasem europejskie organy nadzoru zakończyły już prace nad regulacyjnymi standardami technicznymi (RTS), Komisja Nadzoru Finansowego intensyfikuje działania kontrolne, a pierwsza fala raportów o poważnych incydentach ICT trafia do nadzorców w nowym, ujednoliconym formacie.

Ten przewodnik porządkuje wymagania DORA w sposób, który pozwala na podjęcie konkretnych działań — bez zbędnego żargonu prawniczego, ale z precyzją, jakiej wymaga regulacja tej wagi.

Czym jest DORA i dlaczego zmienia podejście do ryzyka ICT

Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. — w skrócie DORA — to pierwsze w historii Unii Europejskiej rozporządzenie, które w sposób kompleksowy reguluje cyfrową odporność operacyjną sektora finansowego. Nie dyrektywa wymagająca transpozycji, lecz rozporządzenie stosowane bezpośrednio we wszystkich państwach członkowskich od 17 stycznia 2025 roku.

Dotychczas odporność cyfrowa instytucji finansowych była regulowana fragmentarycznie — wytyczne EBA dotyczące zarządzania ryzykiem ICT, rekomendacje KNF (w szczególności Rekomendacja D), wymogi outsourcingowe EIOPA dla sektora ubezpieczeń. DORA zastępuje ten patchwork jednolitymi ramami, które obejmują banki, firmy ubezpieczeniowe, fundusze inwestycyjne, instytucje płatnicze, dostawców usług kryptoaktywów i — co istotne — kluczowych dostawców usług ICT dla sektora finansowego.

Różnica między DORA a wcześniejszymi regulacjami jest fundamentalna: DORA nie ogranicza się do wymagania „odpowiednich środków". Definiuje konkretne procesy, terminy raportowania, metody testowania i ramy nadzoru nad dostawcami zewnętrznymi. To przejście od zasad ogólnych do szczegółowych wymagań operacyjnych.

Kogo dotyczy DORA — pełna lista podmiotów

Zakres podmiotowy DORA jest szerszy, niż wielu uczestników rynku zakładało. Rozporządzenie obejmuje dwadzieścia jeden kategorii podmiotów finansowych:

Podmioty objęte DORA

Instytucje kredytowe (banki), instytucje płatnicze, instytucje pieniądza elektronicznego, firmy inwestycyjne, dostawcy usług w zakresie kryptoaktywów, centralne depozyty papierów wartościowych, kontrahenci centralni (CCP), systemy obrotu, repozytoria transakcji, zarządzający alternatywnymi funduszami inwestycyjnymi (ZAFI), spółki zarządzające funduszami UCITS, zakłady ubezpieczeń i reasekuracji, pośrednicy ubezpieczeniowi i reasekuracyjni, instytucje pracowniczych programów emerytalnych, agencje ratingowe, administratorzy wskaźników referencyjnych, dostawcy usług finansowania społecznościowego, sekurytyzacyjne spółki specjalnego przeznaczenia oraz — kluczowa kategoria — kluczowi zewnętrzni dostawcy usług ICT (critical ICT third-party service providers, CTPPs).

Kryterium proporcjonalności

W odróżnieniu od NIS-2, DORA nie stosuje prostego kryterium wielkości (50 pracowników / 10 mln EUR obrotu). Zamiast tego wprowadza zasadę proporcjonalności — zakres wymagań zależy od wielkości podmiotu, profilu ryzyka, charakteru i złożoności świadczonych usług. Mikroprzedsiębiorstwa finansowe podlegają uproszczonemu reżimowi zarządzania ryzykiem ICT, ale nie są zwolnione z obowiązków raportowania incydentów.

Pięć filarów DORA — architektura cyfrowej odporności

DORA opiera się na pięciu wzajemnie powiązanych filarach. Każdy z nich przekłada się na konkretne obowiązki, które instytucje finansowe muszą wdrożyć i utrzymywać.

Filar 1: Zarządzanie ryzykiem ICT (art. 5-16)

Fundament całej konstrukcji. Instytucja finansowa musi posiadać kompleksowe ramy zarządzania ryzykiem ICT, obejmujące: strategię cyfrowej odporności operacyjnej zatwierdzoną przez organ zarządzający, polityki i procedury ochrony zasobów informacyjnych i aktywów ICT, mechanizmy wykrywania anomalii i incydentów, plany reagowania i odtwarzania po zakłóceniach, a także programy komunikacji kryzysowej.

Organ zarządzający — zarząd, rada nadzorcza — ponosi ostateczną odpowiedzialność za zarządzanie ryzykiem ICT. To nie jest formalność: art. 5 ust. 2 DORA jednoznacznie stanowi, że członkowie organu zarządzającego muszą posiadać wystarczającą wiedzę i umiejętności, aby rozumieć i oceniać ryzyko ICT oraz jego wpływ na operacje podmiotu. Obowiązek obejmuje regularne szkolenia — dostosowane do ryzyka ICT podmiotu.

Filar 2: Zarządzanie incydentami ICT i raportowanie (art. 17-23)

DORA wprowadza ujednolicony proces zarządzania incydentami i raportowania, który w polskich warunkach oznacza zgłaszanie poważnych incydentów ICT do Komisji Nadzoru Finansowego:

Wstępne powiadomienie — do 4 godzin od momentu sklasyfikowania incydentu jako poważnego (i nie później niż 24 godziny od wykrycia). To najkrótszy termin raportowania spośród wszystkich europejskich regulacji cyberbezpieczeństwa — dla porównania NIS-2 daje 24 godziny, RODO — 72 godziny.

Raport pośredni — do 72 godzin od wstępnego powiadomienia. Zawiera aktualizację statusu incydentu, wstępną ocenę wpływu i podjęte działania zaradcze.

Raport końcowy — do 1 miesiąca od wstępnego powiadomienia. Pełna analiza przyczyn źródłowych, szczegółowy opis wpływu na operacje i klientów, podjęte i planowane działania naprawcze.

Incydent jest klasyfikowany jako poważny na podstawie kryteriów określonych w RTS — m.in. liczby dotkniętych klientów, czasu trwania zakłócenia, zasięgu geograficznego, wpływu na dane i transakcje finansowe.

Filar 3: Testowanie cyfrowej odporności operacyjnej (art. 24-27)

DORA wymaga regularnego testowania systemów ICT — ale rozróżnia dwa poziomy testów:

Testy podstawowe — obowiązkowe dla wszystkich podmiotów. Obejmują: testy podatności (vulnerability assessments), testy bezpieczeństwa sieci, analizę luk w oprogramowaniu (gap analysis), przeglądy kodu źródłowego (tam, gdzie to wykonalne), testy wydajnościowe oraz testy penetracyjne.

Zaawansowane testy penetracyjne TLPT (Threat-Led Penetration Testing) — obowiązkowe wyłącznie dla podmiotów zidentyfikowanych przez organy nadzoru na podstawie profilu ryzyka. TLPT to testy modelowane na rzeczywistych zagrożeniach, prowadzone zgodnie z ramami TIBER-EU. Wykonywane co trzy lata, przez niezależnych testerów posiadających odpowiednie certyfikacje. To najwyższy poziom testowania przewidziany przez regulację — i najkosztowniejszy.

Kluczowa zasada: testy muszą być prowadzone przez niezależne podmioty — wewnętrzne lub zewnętrzne, ale wolne od konfliktu interesów. W przypadku TLPT wymagany jest tester zewnętrzny.

Filar 4: Zarządzanie ryzykiem dostawców ICT (art. 28-44)

To filar, który wywołał największą dyskusję na rynku. DORA nakłada na instytucje finansowe obowiązek kompleksowego zarządzania ryzykiem związanym z zewnętrznymi dostawcami usług ICT:

Rejestr umów: Każda instytucja musi prowadzić i utrzymywać aktualny rejestr wszystkich umów z dostawcami ICT — z podziałem na usługi wspierające funkcje krytyczne i pozostałe.

Ocena ryzyka przed zawarciem umowy: Przed powierzeniem funkcji krytycznej dostawcy zewnętrznemu instytucja musi ocenić: ryzyko koncentracji (czy nie jest zbyt zależna od jednego dostawcy), możliwość substytucji (czy da się zmienić dostawcę bez zakłóceń) oraz lokalizację przetwarzania danych.

Klauzule umowne: DORA wymaga konkretnych postanowień w umowach z dostawcami ICT — m.in. prawa do audytu i inspekcji, obowiązku raportowania incydentów, warunków rozwiązania umowy, strategii wyjścia (exit strategy). To nie są „miłe by mieć" — brak wymaganych klauzul stanowi naruszenie rozporządzenia.

Ramy nadzoru nad CTPPs: Najbardziej innowacyjny element DORA. Kluczowi zewnętrzni dostawcy usług ICT (np. duże firmy chmurowe obsługujące wiele instytucji finansowych) podlegają bezpośredniemu nadzorowi europejskich organów nadzoru (ESAs). To pierwszy przypadek, gdy podmioty niefinansowe podlegają nadzorowi finansowemu — wyłącznie ze względu na ryzyko systemowe, jakie ich awaria mogłaby spowodować.

Filar 5: Wymiana informacji o zagrożeniach (art. 45)

Piąty filar zachęca — choć nie wymaga bezwzględnie — do uczestnictwa w mechanizmach wymiany informacji o cyberzagrożeniach (threat intelligence sharing). Instytucje finansowe mogą wymieniać między sobą informacje o taktykach, technikach i procedurach (TTP) stosowanych przez atakujących, wskaźniki naruszenia bezpieczeństwa (IoC) oraz informacje o podatnościach.

W praktyce oznacza to możliwość tworzenia lub przystępowania do sektorowych grup wymiany informacji — podobnych do ISAC (Information Sharing and Analysis Centers) funkcjonujących w USA. W Polsce taką rolę może pełnić Forum Cyberbezpieczeństwa przy Związku Banków Polskich.

DORA a NIS-2 — kluczowe różnice

Relacja między DORA a NIS-2 to jedno z najczęstszych źródeł konfuzji wśród instytucji finansowych. Wyjaśnijmy ją precyzyjnie.

DORA jest przepisem sektorowym (lex specialis) w stosunku do dyrektywy NIS-2. Artykuł 4 rozporządzenia DORA jednoznacznie stanowi, że w przypadku konfliktu między DORA a przepisami krajowymi transponującymi NIS-2 — stosuje się DORA. W praktyce oznacza to:

Raportowanie incydentów: instytucja finansowa raportuje incydenty ICT do KNF w schemacie DORA (4h/72h/1 miesiąc), a nie do CSIRT w schemacie NIS-2 (24h/72h/30 dni). Jeden kanał raportowania, jeden organ nadzoru.

Testowanie: instytucja stosuje ramy testowania z DORA (w tym TLPT), a nie ogólne wymagania NIS-2 dotyczące testowania bezpieczeństwa.

Zarządzanie dostawcami: DORA ma znacznie bardziej szczegółowe wymagania dotyczące dostawców ICT niż NIS-2 — i to DORA jest wiążąca dla sektora finansowego.

Uwaga: DORA nie zwalnia z obowiązku rejestracji w wykazie podmiotów kluczowych lub ważnych na mocy znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa. Jeżeli instytucja finansowa spełnia kryteria podmiotów kluczowych NIS-2, musi się zarejestrować — ale w zakresie wymagań operacyjnych stosuje DORA.

Kary i sankcje — co grozi za brak zgodności

DORA nie określa samodzielnie kwot kar — deleguje to do regulatorów krajowych. W Polsce organem nadzoru dla większości podmiotów finansowych jest Komisja Nadzoru Finansowego, która dysponuje szerokim arsenałem sankcji na mocy ustawy o nadzorze nad rynkiem finansowym i ustaw sektorowych.

W praktyce sankcje mogą obejmować: nakazy zaprzestania naruszenia, okresowy zakaz pełnienia funkcji zarządczych, kary pieniężne — których górna granica zależy od sektora (np. dla banków wynika z Prawa bankowego, dla firm inwestycyjnych z ustawy o obrocie instrumentami finansowymi) oraz publiczne ogłoszenie informacji o naruszeniu i nałożonej sankcji.

Co istotne, DORA wymaga od państw członkowskich zapewnienia, by kary były „skuteczne, proporcjonalne i odstraszające". Biorąc pod uwagę dotychczasową praktykę KNF — który nie stroni od nakładania istotnych kar finansowych — instytucje finansowe powinny traktować zgodność z DORA z najwyższą powagą.

Regulacyjne standardy techniczne — szczegóły, które mają znaczenie

Europejskie Urzędy Nadzoru (ESAs — EBA, EIOPA, ESMA) opracowały pakiet regulacyjnych standardów technicznych (RTS) i wykonawczych standardów technicznych (ITS), które uszczegóławiają wymagania DORA:

RTS dotyczące zarządzania ryzykiem ICT — szczegółowe wymogi dotyczące polityk bezpieczeństwa ICT, zarządzania tożsamością i dostępem, zarządzania zmianami, zarządzania ciągłością działania ICT, szyfrowania danych, bezpieczeństwa sieci.

RTS dotyczące klasyfikacji incydentów ICT — kryteria klasyfikacji poważnych incydentów ICT oraz znaczących cyberzagrożeń, progi materiałowe (liczba klientów, czas trwania, wpływ na transakcje), format raportowania.

RTS dotyczące testowania TLPT — wymagania wobec testerów, zakres testów, sposób raportowania wyników, rola zespołu kontroli zagrożeń (threat intelligence team).

RTS dotyczące dostawców ICT — elementy rejestru informacji o umowach z dostawcami, kryteria identyfikacji kluczowych dostawców, zakres raportowania o poddostawcach (subcontracting).

Wszystkie RTS i ITS weszły w życie wraz z DORA lub w pierwszych miesiącach 2025 roku. Instytucje, które wdrożyły DORA „na poziomie ogólnym", czeka teraz dopasowanie do szczegółowych wymagań standardów technicznych.

DORA a ISO 27001 — ile już masz, ile musisz dorobić

Instytucja finansowa posiadająca wdrożony i certyfikowany SZBI zgodny z ISO 27001:2022 ma solidny punkt startowy — ale nie pełną zgodność z DORA. Oto mapa pokrycia:

Co ISO 27001 pokrywa: zarządzanie ryzykiem (klauzula 6.1 + Annex A), zarządzanie incydentami (A.5.24-5.28), zarządzanie ciągłością działania (A.5.29-5.30), bezpieczeństwo dostawców (A.5.19-5.23), kontrola dostępu i kryptografia (A.8), bezpieczeństwo sieci (A.8.20-8.22).

Czego ISO 27001 nie pokrywa: raportowanie incydentów w schemacie DORA (4h/72h/1 miesiąc) z wymaganym formatem, rejestr umów z dostawcami ICT w formacie wymaganym przez RTS, testy TLPT (Threat-Led Penetration Testing), specyficzne wymagania dotyczące strategii wyjścia z umów z dostawcami, ramy nadzoru nad kluczowymi dostawcami ICT (CTPPs) — choć to obowiązek nadzorcy, instytucja musi współpracować.

Szacujemy, że ISO 27001 pokrywa 60-70% wymagań DORA w zakresie zarządzania ryzykiem ICT. Pozostałe 30-40% to wymagania specyficzne dla sektora finansowego, których nie da się spełnić ogólnymi kontrolami bezpieczeństwa informacji.

Jak się przygotować — plan działania na 2026

DORA obowiązuje od 17 stycznia 2025. Jeśli Twoja instytucja nie osiągnęła jeszcze pełnej zgodności, każdy miesiąc zwłoki zwiększa ryzyko — zarówno regulacyjne, jak i operacyjne. Proponujemy podejście w trzech krokach:

Krok 1: Ocena luki (gap analysis)

Porównanie obecnego stanu z wymaganiami DORA i odpowiednimi RTS/ITS. Obejmuje: przegląd ram zarządzania ryzykiem ICT, ocenę zdolności raportowania incydentów (czy instytucja jest w stanie spełnić wymóg 4 godzin?), inwentaryzację umów z dostawcami ICT, przegląd programu testowania bezpieczeństwa oraz ocenę gotowości dokumentacji do kontroli KNF.

Krok 2: Wdrożenie priorytetowe

Na podstawie gap analysis — wdrożenie brakujących elementów w kolejności priorytetów. Najwyższy priorytet mają: proces raportowania incydentów (bo 4-godzinny termin nie zostawia marginesu na improwizację), rejestr umów z dostawcami ICT (bo KNF może go zażądać w każdej chwili), ramy zarządzania ryzykiem ICT zatwierdzone przez zarząd (bo to fundament, na którym opierają się wszystkie pozostałe elementy).

Krok 3: Testowanie i doskonalenie

Przeprowadzenie testów penetracyjnych i testów ciągłości działania, weryfikacja procedur raportowania incydentów (symulacja), przegląd klauzul umownych z dostawcami krytycznymi, przegląd zarządzania z udziałem organu zarządzającego. Dla instytucji wyznaczonych do TLPT — zaplanowanie i budżetowanie zaawansowanych testów (koszt: od kilkuset tysięcy złotych).

Najczęściej zadawane pytania o DORA

Czy DORA dotyczy małych banków spółdzielczych?

Tak. DORA obejmuje wszystkie instytucje kredytowe, niezależnie od wielkości. Banki spółdzielcze podlegają jednak zasadzie proporcjonalności — zakres wymagań jest dostosowany do ich profilu ryzyka, skali działalności i złożoności usług. W praktyce oznacza to uproszczone ramy zarządzania ryzykiem ICT, ale pełne obowiązki raportowania incydentów.

Czy DORA dotyczy fintechów i dostawców usług płatniczych?

Tak. Instytucje płatnicze, instytucje pieniądza elektronicznego i dostawcy usług w zakresie kryptoaktywów objęci licencją MiCA podlegają DORA na równi z bankami. Dla wielu fintechów, które dotychczas operowały w relatywnie luźnym reżimie regulacyjnym, DORA stanowi fundamentalną zmianę.

Czy moja firma IT, która obsługuje banki, podlega DORA?

Jeśli Twoja firma jest kluczowym dostawcą usług ICT dla instytucji finansowych — potencjalnie tak. Europejskie organy nadzoru identyfikują kluczowych dostawców (CTPPs) na podstawie kryteriów określonych w DORA (art. 31) — m.in. systemowego znaczenia usług, stopnia koncentracji i możliwości substytucji. CTPPs podlegają bezpośredniemu nadzorowi ESAs. Niezależnie od statusu CTPP, Twoi klienci finansowi będą wymagać od Ciebie spełnienia klauzul umownych wynikających z DORA — to efekt domina w łańcuchu dostaw.

Czym różni się raportowanie incydentów DORA od RODO?

DORA i RODO to dwa odrębne reżimy raportowania. DORA wymaga zgłoszenia każdego poważnego incydentu ICT do KNF — niezależnie od tego, czy dotyczy danych osobowych. RODO wymaga zgłoszenia naruszenia ochrony danych osobowych do PUODO — ale tylko gdy incydent dotyczy danych osobowych. Terminy: DORA daje 4 godziny na wstępne powiadomienie, RODO — 72 godziny. Atak ransomware na system bankowy, który zakłóca usługi i szyfruje dane klientów, podlega obu regulacjom jednocześnie — osobne zgłoszenia do KNF i PUODO.

Czy posiadanie certyfikatu ISO 27001 zwalnia z DORA?

Nie. ISO 27001 nie jest substytutem DORA. Jest natomiast solidnym fundamentem — instytucja z wdrożonym SZBI zgodnym z ISO 27001 ma pokryte 60-70% wymagań DORA w zakresie zarządzania ryzykiem ICT. Pozostałe wymogi (raportowanie w schemacie 4h, rejestr dostawców, TLPT, klauzule umowne) wymagają dodatkowej pracy.

Co to jest TLPT i czy moja instytucja musi go przeprowadzić?

TLPT (Threat-Led Penetration Testing) to zaawansowana forma testowania bezpieczeństwa, oparta na rzeczywistych scenariuszach zagrożeń i prowadzona zgodnie z ramami TIBER-EU. Obowiązkowy jest tylko dla podmiotów wskazanych przez organ nadzoru — typowo dla dużych banków, ubezpieczycieli i infrastruktury rynku finansowego. Koszt TLPT to zazwyczaj kilkaset tysięcy złotych i 3-6 miesięcy realizacji. Mniejsze instytucje realizują „zwykłe" testy penetracyjne, co również spełnia wymagania DORA.

Jaki jest status wdrożenia DORA w Polsce w marcu 2026?

DORA obowiązuje bezpośrednio od 17 stycznia 2025 — nie wymaga transpozycji. KNF opublikowała wytyczne dotyczące raportowania incydentów ICT i prowadzi konsultacje z sektorem w zakresie identyfikacji podmiotów podlegających TLPT. Trwają również prace nad dostosowaniem krajowych regulacji sektorowych (Prawo bankowe, ustawa o obrocie instrumentami finansowymi) do wymagań DORA w zakresie sankcji.

Jak Fib.Code może pomóc

Zespół Fib.Code od ponad sześciu lat wspiera organizacje we wdrażaniu systemów zarządzania bezpieczeństwem informacji — w tym instytucje z sektora finansowego, które muszą jednocześnie spełniać wymagania DORA, NIS-2 i RODO. Zrealizowaliśmy ponad 500 projektów obejmujących wdrożenia ISO 27001, audyty bezpieczeństwa, budowę procesów zarządzania incydentami i outsourcing funkcji bezpieczeństwa.

W kontekście DORA oferujemy: gap analysis — ocenę zgodności z wymaganiami rozporządzenia i standardami technicznymi RTS/ITS, wdrożenie lub rozbudowę ram zarządzania ryzykiem ICT, budowę procesu raportowania incydentów w schemacie 4h/72h/1 miesiąc, inwentaryzację i przegląd umów z dostawcami ICT pod kątem wymaganych klauzul, przeprowadzenie testów penetracyjnych i analiz podatności, szkolenia dla zarządu i kadry kierowniczej z zakresu ryzyka ICT oraz bieżące wsparcie jako zewnętrzny doradca ds. cyfrowej odporności operacyjnej.

Każdy projekt rozpoczynamy od rozmowy — nie od oferty. Chętnie porozmawiamy o tym, co DORA oznacza konkretnie dla Twojej instytucji.

Umów bezpłatną konsultację: l.grabowski@fibcode.com | fibcode.com

Artykuł odzwierciedla stan prawny na dzień 14 marca 2026 roku. Rozporządzenie DORA (UE) 2022/2554 obowiązuje bezpośrednio od 17 stycznia 2025 roku.