Czym jest DORA i kogo dotyczy? DORA to unijne rozporządzenie o operacyjnej odporności cyfrowej sektora finansowego, obowiązujące bezpośrednio od 17 sty 2025. Dotyczy nie tylko regulowanych instytucji finansowych, ale również dostawców usług ICT, którzy je obsługują – a przez łańcuch umów sięga też ich podwykonawców. Ujednolica wymogi zarządzania ryzykiem ICT, raportowania incydentów, testowania odporności i nadzoru nad dostawcami.
Definicja kanoniczna: DORA (Digital Operational Resilience Act) to rozporządzenie UE 2022/2554 ustanawiające jednolite wymogi odporności operacyjnej cyfrowej dla podmiotów finansowych i ich dostawców ICT, oparte na pięciu filarach: zarządzaniu ryzykiem ICT, raportowaniu incydentów, testowaniu odporności, zarządzaniu ryzykiem stron trzecich i wymianie informacji.
Ten artykuł wprowadza DORA od podstaw: co realnie zmienia, kto jest w zakresie (z naciskiem na często pomijanych podwykonawców), z jakich elementów prawnych i technicznych się składa oraz jak zacząć wdrożenie w formie listy działań.
DORA dla początkujących – w skrócie:
- DORA (rozporządzenie UE 2022/2554) obowiązuje bezpośrednio w całej UE od 17 sty 2025 – jako rozporządzenie nie wymaga transpozycji do prawa krajowego.
- Zakres obejmuje około 20 kategorii podmiotów finansowych oraz dostawców usług ICT, którzy je obsługują – łącznie ponad 22 000 podmiotów w UE.
- DORA sięga przez umowę do podwykonawców: dostawca ICT przenosi wymogi w dół łańcucha, a nadzór nad krytycznymi dostawcami może objąć także istotnych podwykonawców.
- Rozporządzenie stoi na pięciu filarach: zarządzanie ryzykiem ICT, raportowanie incydentów, testowanie odporności (w tym TLPT), zarządzanie ryzykiem stron trzecich i wymiana informacji.
- DORA łączy warstwę formalno-prawną (polityki, umowy, rejestr informacji) z warstwą techniczną (testy, monitoring, odtwarzanie) – to nie jest projekt wyłącznie prawny.
- Patronusec jako akredytowany QSA z zespołem pentesterów wspiera podmioty finansowe i dostawców ICT we wdrożeniu DORA – od oceny luk po testowanie odporności.
Spis treści
Co zmienia DORA w porównaniu z wcześniejszym stanem?
DORA zmienia rozproszony, sektorowy sposób zarządzania ryzykiem ICT w jeden, wspólny i wiążący reżim odporności operacyjnej dla całego sektora finansowego UE. Wcześniej wymogi odporności były rozsiane po różnych dyrektywach i wytycznych krajowych; DORA zastępuje ten patchwork jednym rozporządzeniem obowiązującym bezpośrednio.
Najważniejsza zmiana jest podwójna. Po pierwsze, ujednolicenie: zamiast różnych reguł outsourcingu i bezpieczeństwa w każdym kraju i sektorze, obowiązuje jeden zestaw wymogów. Po drugie, przesunięcie akcentu z ochrony na odporność: DORA nie pyta tylko „czy jesteś zabezpieczony”, lecz „czy potrafisz przetrwać zakłócenie ICT, odtworzyć krytyczne funkcje i to udowodnić”.
Konkretne zmiany, które odczuwa organizacja:
- Odporność jako obowiązek wykazywany. Nie wystarczy mieć zabezpieczenia; trzeba udowodnić zdolność do odtworzenia krytycznych funkcji w zdefiniowanych ramach czasowych.
- Rejestr informacji o dostawcach ICT. Podmiot finansowy prowadzi i corocznie składa rejestr wszystkich umów z dostawcami ICT – centralny obraz zależności technologicznych.
- Twarde terminy raportowania incydentów. Poważne incydenty ICT raportuje się organowi nadzoru według ściśle określonych terminów, nie według uznania.
- Nadzór nad krytycznymi dostawcami ICT. Najwięksi dostawcy (np. hyperscalerzy chmurowi) trafiają pod bezpośredni nadzór unijny – pierwszą listę 19 krytycznych dostawców ogłoszono 18 lis 2025.
DORA przenosi sektor finansowy z pytania „czy mamy zabezpieczenia” do pytania „czy udowodnimy, że przetrwamy i odtworzymy działanie” – i czyni z tej odpowiedzi obowiązek prawny, nie dobrą praktykę.
Kogo dotyczy DORA – i dlaczego także podwykonawców ICT?
DORA dotyczy około 20 kategorii podmiotów finansowych oraz dostawców usług ICT, którzy je obsługują – a przez mechanizm umowny jej wymogi sięgają również podwykonawców tych dostawców. To jeden z najczęściej pomijanych aspektów: firma, która sama nie jest instytucją finansową, może realnie podlegać wymogom DORA jako ogniwo łańcucha.
Kto jest w bezpośrednim zakresie:
- Podmioty finansowe – banki, firmy inwestycyjne, ubezpieczyciele, instytucje płatnicze, dostawcy usług w zakresie kryptoaktywów, systemy obrotu i wiele innych (około 20 kategorii). To one są adresatem obowiązków DORA.
- Dostawcy usług ICT obsługujący podmioty finansowe – dostawcy chmury, SaaS, oprogramowania, usług zarządzanych. Formalnie DORA nakłada obowiązki na podmiot finansowy, ale ten przenosi je na dostawcę przez umowę.
Dlaczego podwykonawcy są w grze? Bo DORA reguluje sposób, w jaki podmiot finansowy zarządza ryzykiem całego łańcucha ICT – a nie tylko bezpośredniego dostawcy. Dostawca ICT związany umową z podmiotem finansowym musi zapewnić przestrzeganie wymogów również tam, gdzie sam korzysta z podwykonawców. Nadzór nad krytycznymi dostawcami ICT wprost obejmuje uprawnienia dochodzeniowe i inspekcje także u istotnych podwykonawców. W praktyce oznacza to, że wymogi DORA propagują się w dół całego łańcucha dostaw technologicznych.
Ważny niuans geograficzny: dostawca ICT spoza UE (np. amerykański dostawca chmury obsługujący europejski bank) podlega tym samym obowiązkom kontraktowym co dostawca z siedzibą w UE. Liczy się to, że obsługuje podmiot finansowy działający w UE, a nie gdzie ma siedzibę.
Najczęstszy błąd początkujących w DORA to założenie „nie jesteśmy bankiem, więc nas to nie dotyczy” – tymczasem dostawca ICT i jego podwykonawca odczuwają DORA przez umowę równie realnie, co sama instytucja finansowa.
Z czego składa się DORA – wymogi prawne i techniczne?
DORA składa się z pięciu filarów, które łączą warstwę formalno-prawną (polityki, umowy, rejestry, governance) z warstwą techniczną (testy, monitoring, wykrywanie, odtwarzanie). To rozróżnienie jest kluczowe dla planowania wdrożenia: część wymogów to dokumenty i procesy, część to realna zdolność techniczna, której nie da się „napisać”.
Pięć filarów DORA:
- Zarządzanie ryzykiem ICT. Ramy zarządzania ryzykiem ICT z zaangażowaniem zarządu, identyfikacją zasobów, ochroną, wykrywaniem i odtwarzaniem. Warstwa mieszana: governance (prawne) plus mechanizmy techniczne.
- Zarządzanie i raportowanie incydentów ICT. Klasyfikacja incydentów i raportowanie poważnych incydentów organowi nadzoru w twardych terminach. Warstwa mieszana: procedura plus zdolność wykrywania.
- Testowanie odporności operacyjnej cyfrowej. Regularne testy, a dla znaczących podmiotów – zaawansowane testowanie penetracyjne oparte na zagrożeniach (TLPT). Warstwa głównie techniczna.
- Zarządzanie ryzykiem stron trzecich ICT. Rejestr informacji o dostawcach, obowiązkowe klauzule umowne, strategie wyjścia, prawa do audytu. Warstwa głównie prawno-umowna.
- Wymiana informacji. Dobrowolna wymiana informacji o cyberzagrożeniach między podmiotami. Warstwa organizacyjna.
Rozdzielenie warstw ma praktyczne konsekwencje. Wymogi formalno-prawne (polityki, klauzule umowne, rejestr informacji, strategie wyjścia) można opracować w warstwie dokumentacyjnej. Ale wymogi techniczne – testowanie odporności, TLPT, monitoring anomalii, realna zdolność odtworzenia w zadanym RTO – wymagają kompetencji technicznych i narzędzi, których dokument nie zastąpi.
Patronusec Insight: Z naszego doświadczenia projektowego wynika, że organizacje najczęściej mylą DORA z projektem czysto prawnym i zlecają całość kancelarii. Kancelaria świetnie opracuje klauzule umowne, rejestr informacji i strategie wyjścia – to realna wartość w filarze czwartym. Problem pojawia się w filarze trzecim: testowanie odporności, w tym TLPT, to zaawansowana praca techniczna wymagająca pentesterów i narzędzi, a nie interpretacji przepisów. Dokument opisujący, że „przeprowadzamy testy”, nie jest testem. Rekomendujemy od początku rozdzielić warstwę prawną od technicznej i zaplanować dla każdej właściwe kompetencje – inaczej audyt odsłoni lukę tam, gdzie zabrakło realnej zdolności technicznej.
Nie masz pewności, czy Twoja organizacja podlega DORA i od czego zacząć?
Patronusec wykonuje wstępną ocenę zakresu DORA: ustalamy, czy i jako kto jesteś w zakresie (podmiot finansowy, dostawca ICT, podwykonawca), oraz mapujemy pięć filarów na Twoją sytuację. Po bezpłatnej rozmowie otrzymujesz jasny obraz obowiązków i rekomendowaną kolejność wdrożenia.
Jak zacząć wdrożenie DORA – lista działań krok po kroku
Wdrożenie DORA zaczyna się od ustalenia zakresu i governance, przez inwentaryzację zasobów i dostawców, po zbudowanie zdolności technicznych i testowanie. Poniższa lista porządkuje pierwsze działania w logicznej kolejności – od fundamentu po weryfikację.
- Ustal, czy i jako kto jesteś w zakresie. Zidentyfikuj swoją rolę: podmiot finansowy, dostawca ICT czy podwykonawca w łańcuchu. To determinuje, które obowiązki są bezpośrednie, a które przenoszone umową.
- Osadź odpowiedzialność w zarządzie. DORA wymaga zaangażowania organu zarządzającego w ramy ryzyka ICT. Wyznacz właściciela tematu z realnym umocowaniem.
- Zinwentaryzuj zasoby ICT i funkcje krytyczne. Ustal, które funkcje są krytyczne i jakie zasoby ICT je wspierają – to podstawa całej reszty, w tym celów odtworzeniowych.
- Zbuduj rejestr informacji o dostawcach ICT. Spisz wszystkie umowy z dostawcami ICT, w tym zależności od podwykonawców. To wymóg filaru czwartego i punkt wyjścia zarządzania ryzykiem stron trzecich.
- Przejrzyj i uzupełnij umowy z dostawcami. Dostosuj klauzule umowne do wymogów DORA: prawa do audytu, bezpieczeństwo, strategie wyjścia, obsługa podwykonawców.
- Ustanów proces klasyfikacji i raportowania incydentów. Zbuduj procedurę wykrywania, klasyfikacji i raportowania poważnych incydentów w terminach wymaganych przez DORA.
- Zaplanuj program testowania odporności. Ustal regularne testy, a jeśli jesteś znaczącym podmiotem – przygotuj się na TLPT. To warstwa techniczna wymagająca kompetencji pentesterskich.
- Zweryfikuj zdolność odtworzenia (ciągłość działania). Sprawdź, czy realnie odtworzysz krytyczne funkcje w zdefiniowanych ramach czasowych – nie tylko w dokumencie, ale w teście.
- Domknij lukę kompetencyjną. Rozdziel warstwę prawną (polityki, umowy) od technicznej (testy, monitoring) i zapewnij dla każdej właściwe zasoby.
- Ustanów cykl utrzymania. DORA to obowiązek ciągły: coroczny rejestr informacji, regularne testy, aktualizacja ram ryzyka. Zaplanuj to jako proces, nie jednorazowy projekt.
Po przejściu tych kroków masz fundament, na którym można rzetelnie wykazać zgodność z DORA i utrzymać odporność operacyjną w czasie.
FAQ – DORA dla początkujących
Od kiedy obowiązuje DORA?
DORA obowiązuje bezpośrednio w całej UE od 17 sty 2025. Jako rozporządzenie (UE) 2022/2554 nie wymaga transpozycji do prawa krajowego – stosuje się jednolicie we wszystkich państwach członkowskich. Weszło w życie 16 sty 2023, a dwuletni okres przejściowy zakończył się z datą stosowania. Od 2025 roku organy nadzoru przeszły od wytycznych do egzekwowania.
Czy DORA dotyczy firm, które nie są instytucjami finansowymi?
Tak, pośrednio, a czasem bezpośrednio. Dostawcy usług ICT obsługujący podmioty finansowe odczuwają DORA przez umowy, którymi podmiot finansowy przenosi na nich wymogi. Wymogi sięgają też podwykonawców tych dostawców. Ponadto najwięksi dostawcy mogą trafić pod bezpośredni nadzór unijny jako krytyczni dostawcy ICT. „Nie jesteśmy bankiem” nie oznacza więc „nie dotyczy nas DORA”.
Jak DORA traktuje podwykonawców dostawców ICT?
DORA reguluje zarządzanie ryzykiem całego łańcucha ICT, nie tylko bezpośredniego dostawcy. Dostawca ICT musi zapewnić przestrzeganie wymogów również tam, gdzie korzysta z podwykonawców, a nadzór nad krytycznymi dostawcami obejmuje uprawnienia dochodzeniowe i inspekcje także u istotnych podwykonawców. Wymogi propagują się przez umowy w dół łańcucha dostaw technologicznych.
Czy DORA to projekt prawny czy techniczny?
Obie warstwy naraz. DORA łączy wymogi formalno-prawne (polityki, klauzule umowne, rejestr informacji, strategie wyjścia) z wymogami technicznymi (testowanie odporności, TLPT, monitoring, realna zdolność odtworzenia). Traktowanie DORA jako projektu wyłącznie prawnego zostawia lukę w warstwie technicznej, której dokument nie wypełni – i którą audyt odsłoni.
Czym jest rejestr informacji w DORA?
Rejestr informacji (Register of Information) to prowadzone przez podmiot finansowy zestawienie wszystkich umów z dostawcami usług ICT, w tym zależności od podwykonawców. Składa się go corocznie organowi nadzoru. Rejestr daje nadzorowi i samej organizacji centralny obraz zależności technologicznych i jest jednym z fundamentów zarządzania ryzykiem stron trzecich.
Jak DORA ma się do NIS2?
DORA jest lex specialis dla sektora finansowego – podmiot finansowy spełnia wymogi zarządzania ryzykiem ICT i raportowania incydentów z NIS2 poprzez DORA, zamiast wykonywać tę pracę dwukrotnie. Dla podmiotów finansowych DORA jest reżimem wiodącym w obszarze odporności cyfrowej. Organizacje spoza sektora finansowego podlegają NIS2, nie DORA.
Jak Patronusec pomaga we wdrożeniu DORA?
Zaczynamy od oceny zakresu (kim jesteś w łańcuchu i które obowiązki są bezpośrednie), następnie mapujemy pięć filarów na Twoją organizację i rozdzielamy warstwę prawną od technicznej. Jako akredytowany QSA z zespołem pentesterów wspieramy szczególnie warstwę techniczną – testowanie odporności i TLPT. Po bezpłatnej rozmowie scope-assessment przedstawiamy plan i wycenę.
Warto przeczytać
Ścieżka lektury dla tematu DORA i odporności operacyjnej:
- DORA – 5 rzeczy do zrobienia i 5 do uniknięcia przy pierwszym wdrożeniu – praktyczna lista działań i błędów.
- Plan ciągłości działania w 5 krokach – zdolność odtworzenia, której DORA wymaga w filarze pierwszym.
- NIS2 – 5 rzeczy do zrobienia i 5 do uniknięcia – pokrewny reżim dla podmiotów spoza sektora finansowego.
- Incident Response, Disaster Recovery, Business Continuity i IT Continuity – czym się różnią – pojęcia kluczowe dla filaru odtwarzania.
DORA – bezpłatna konsultacja
Patronusec jako akredytowany QSA z zespołem pentesterów wspiera podmioty finansowe i dostawców ICT we wdrożeniu DORA – od oceny zakresu, przez rozdzielenie warstwy prawnej i technicznej, po testowanie odporności i TLPT. Umów bezpłatną konsultację, aby ustalić swój zakres i kolejność wdrożenia.
Umów konsultację | DORA | Testy TLPT | BCM
