4crypto.eu
Bezpłatna konsultacja
Compliance · Rozporządzenie UE · 2026

DORA w 2026 r. - rozporządzenie 2022/2554, odporność operacyjna sektora finansowego, TLPT, CTPP

Autor: dr inż. Adam Czubak Czas czytania: 15 min Aktualizacja: 2026-05-15

Ratio legis

DORA jest odpowiedzią Unii na obserwację, że sektor finansowy stał się w pełni cyfrowy, a awaria systemu IT pojedynczego banku, kontrahenta centralnego czy infrastruktury rynkowej może zachwiać stabilnością całego rynku finansowego strefy euro. Ratio legis łączy ochronę konsumentów z ochroną stabilności systemowej - tworząc jednolite, ostre wymogi odporności operacyjnej cyfrowej i, po raz pierwszy w europejskim prawie, bezpośredni nadzór ESA nad krytycznymi dostawcami ICT spoza sektora finansowego. Konkluzja regulatora jest jasna: w erze cloud[20] i SaaS bezpieczeństwo banku nie kończy się na jego perimecie.

DORA [1] (Digital Operational Resilience Act, rozporządzenie Parlamentu Europejskiego i Rady UE 2022/2554 z 14 grudnia 2022 r.) to najbardziej kompleksowa europejska regulacja cyberbezpieczeństwa sektora finansowego. Stosowana od 17 stycznia 2025 r., DORA jest lex specialis wobec dyrektywy NIS2 [5] - dla banków, ubezpieczycieli, instytucji płatniczych, funduszy i innych 20 kategorii podmiotów finansowych wprowadza spójny zbiór wymagań na pięciu filarach: zarządzanie ryzykiem ICT, zarządzanie incydentami ICT, testowanie odporności (w tym Threat-Led Penetration Testing), zarządzanie ryzykiem trzeciej strony oraz wymiana informacji.

DORA wprowadza również Oversight Framework[10] dla Critical Third-Party Providers (CTPP) - dostawców ICT krytycznych dla stabilności sektora finansowego (hyperscalers chmurowi, SWIFT, sieci kart, główni data center providers). To pierwsza w europejskim prawie regulacja, która obejmuje bezpośrednim nadzorem firmy spoza sektora finansowego, mając na uwadze ich systemowe znaczenie dla rynku.

Artykuł porządkuje strukturę DORA, omawia 5 filarów, opisuje TLPT, zarządzanie dostawcami ICT, terminy zgłaszania incydentów oraz mapping do NIS2, KSC [6] i Rekomendacji D KNF [6].

Czym jest DORA - geneza i struktura

Pełna nazwa: Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. w sprawie operacyjnej odporności cyfrowej sektora finansowego oraz zmiany rozporządzeń [1]. Towarzyszy mu dyrektywa 2022/2556 [2] - drobne zmiany w dyrektywach sektorowych (CRD, Solvency II, MiFID itp.) dla spójności z DORA.

Geneza

Sektor finansowy od lat był przedmiotem regulacji cyberbezpieczeństwa, ale były one fragmentaryczne i nierówne:

  • Bankowość - wytyczne EBA, w Polsce Rekomendacja D KNF [6].
  • Ubezpieczenia - Solvency II, wytyczne EIOPA, w Polsce Rekomendacja Z KNF.
  • Rynki kapitałowe - MiFID II, ESMA Guidelines on ICT outsourcing.
  • NIS - ogólne wymagania cybersec dla banków jako OUK.

Komisja Europejska zidentyfikowała potrzebę spójnej regulacji horyzontalnej obejmującej wszystkie podmioty finansowe. DORA jest odpowiedzią - jeden tekst, jeden zestaw zasad, jeden reżim nadzoru.

Kalendarium DORA

  • 14 grudnia 2022 - przyjęcie rozporządzenia przez PE i Radę UE.
  • 27 grudnia 2022 - publikacja w Dz.U. UE L 333.
  • 16 stycznia 2023 - wejście w życie.
  • 17 stycznia 2025 - stosowanie (z dwuletnim odroczeniem). To data, od której podmioty muszą faktycznie spełnić DORA.
  • 2024 - ESA publikują RTS i ITS [3] doprecyzowujące techniczne aspekty.
  • 2025-2026 - pierwsze cykle TLPT, wyznaczanie CTPP.

Struktura rozporządzenia

DORA składa się z 9 rozdziałów (64 artykuły):

  • Rozdział I (art. 1-4) - przepisy ogólne, zakres, definicje.
  • Rozdział II (art. 5-16) - ICT risk management framework (Filar 1).
  • Rozdział III (art. 17-23) - zarządzanie incydentami ICT (Filar 2).
  • Rozdział IV (art. 24-27) - testowanie odporności i TLPT (Filar 3).
  • Rozdział V (art. 28-44) - zarządzanie ryzykiem trzeciej strony (Filar 4), w tym Oversight Framework dla CTPP.
  • Rozdział VI (art. 45-50) - wymiana informacji (Filar 5).
  • Rozdział VII-IX (art. 51-64) - właściwe organy, kary, przepisy końcowe.

Rozporządzenia delegowane (RTS i ITS)

DORA jest uzupełniana przez kilkanaście Regulatory Technical Standards i Implementing Technical Standards, przyjętych przez ESA i KE w 2024 r. [3] Najważniejsze:

  • RTS on ICT risk management framework - szczegółowe wymagania techniczne dla Filara 1.
  • RTS on TLPT - metodologia testów, kryteria wyboru testerów, wymogi raportowania.
  • RTS on ICT outsourcing - klauzule umowne (art. 30), warunki subcontractingu.
  • ITS on register of information - format rejestru dostawców ICT.
  • RTS on incident classification - kryteria znaczących incydentów ICT, terminy.

Zakres podmiotowy - 20 kategorii

Art. 2 DORA wymienia 20 kategorii podmiotów finansowych objętych rozporządzeniem:

Sektor bankowy

  1. Instytucje kredytowe (banki) wg dyrektywy CRR.
  2. Instytucje płatnicze (PI) wg PSD2.
  3. Instytucje pieniądza elektronicznego (EMI).
  4. Account information service providers (AISP) - dostawcy usług informacji o rachunku.

Rynki kapitałowe

  1. Firmy inwestycyjne (investment firms) wg MiFID II.
  2. Fundusze inwestycyjne i zarządzający (UCITS, AIFM) - towarzystwa funduszy inwestycyjnych (TFI).
  3. Trading venues - rynki regulowane (giełdy), MTF, OTF.
  4. Central Counterparties (CCP) - kontrahenci centralni (KDPW_CCP).
  5. Central Securities Depositories (CSD) - centralne depozyty papierów wartościowych (KDPW).
  6. Trade repositories - repozytoria transakcji.

Ubezpieczenia

  1. Zakłady ubezpieczeń i reasekuracji wg Solvency II.
  2. Dystrybutorzy ubezpieczeń (brokerzy, agenci) - w pewnym zakresie.
  3. Pension scheme providers - fundusze emerytalne, w Polsce OFE i PPK.

Inne podmioty rynkowe

  1. Credit rating agencies - agencje ratingowe (S&P, Moody's, Fitch, EuroRating).
  2. Audytorzy ustawowi - w pewnym zakresie.
  3. Crypto-asset service providers (CASP) po MiCA (rozporządzenie 2023/1114).
  4. Issuers of asset-referenced tokens - emitenci stablecoinów.
  5. Crowdfunding service providers.
  6. Securitisation repositories.
  7. Administratorzy benchmarków wg BMR.

Wyłączenia

Mikropodmioty w pełnym zakresie nie są wyłączone, ale mają znacznie uproszczone wymagania (art. 16 - zasada proporcjonalności). DORA stosuje się również do oddziałów podmiotów spoza UE oferujących usługi w UE.

Skala

W Polsce DORA dotyczy:

  • Około 30 banków komercyjnych + 500 banków spółdzielczych.
  • Około 40 zakładów ubezpieczeń.
  • 20+ TFI.
  • Kilkadziesiąt instytucji płatniczych.
  • GPW, KDPW, BondSpot, KDPW_CCP - infrastruktura rynkowa.
  • Setki firm inwestycyjnych.
  • Sektor crypto po MiCA (gwałtownie rosnący).

Łącznie - ponad 1000 podmiotów.

5 filarów DORA

DORA strukturyzuje wymagania w pięciu filarach:

  1. ICT Risk Management Framework (Filar 1, art. 5-16) - kompleksowe ramy zarządzania ryzykiem ICT, governance, polityki, środki bezpieczeństwa.
  2. ICT Incident Management and Reporting (Filar 2, art. 17-23) - klasyfikacja, zarządzanie, raportowanie znaczących incydentów ICT.
  3. Digital Operational Resilience Testing (Filar 3, art. 24-27) - testowanie odporności, w tym TLPT dla największych.
  4. ICT Third-Party Risk Management (Filar 4, art. 28-44) - zarządzanie dostawcami ICT, klauzule umowne, koncentracja, Oversight Framework dla CTPP.
  5. Information and Intelligence Sharing (Filar 5, art. 45-50) - dobrowolna wymiana informacji o cyberzagrożeniach między podmiotami finansowymi.

Każdy filar omówiony szczegółowo poniżej.

Filar 1 - ICT Risk Management Framework

Rozdział II DORA (art. 5-16) wprowadza kompleksowy framework zarządzania ryzykiem ICT.

Governance (art. 5)

Rola organu zarządzającego (zarządu i rady nadzorczej):

  • Zatwierdzanie strategii ICT i polityk ryzyka ICT.
  • Nadzór nad implementacją.
  • Regularne raportowanie (minimum raz na rok do zarządu, kwartalnie dla największych).
  • Obowiązkowe szkolenia członków organów - 4-8 godzin rocznie, udokumentowane.

To analogiczne do art. 20 NIS2 - członkowie zarządu mają osobistą odpowiedzialność za nadzór nad cyberbezpieczeństwem.

ICT Risk Management Framework (art. 6)

Sercem Filara 1 jest udokumentowany framework obejmujący:

  1. Strategia ICT - cele, ramy organizacyjne, zasoby, KPI.
  2. Polityka bezpieczeństwa informacji - high-level dokument zatwierdzony przez zarząd.
  3. Polityki szczegółowe - kryptografia, kontrola dostępu, kopie zapasowe, zarządzanie konfiguracją, zarządzanie zmianą, zarządzanie podatnościami, zarządzanie incydentami.
  4. Metodologia ryzyka - identyfikacja, ocena, postępowanie, monitoring.
  5. Klasyfikacja aktywów - lista, krytyczność, zależności.
  6. Plan ciągłości działania (BCP) z RTO/RPO dla każdej krytycznej funkcji.
  7. Plan odzyskiwania po awarii (DRP).
  8. Plan zarządzania kryzysowego.

Identyfikacja (art. 8)

Podmiot finansowy identyfikuje wszystkie funkcje, aktywa i procesy ICT:

  • Inwentarz aktywów ICT z klasyfikacją.
  • BIA (Business Impact Analysis) dla wszystkich funkcji.
  • Mapowanie zależności między aktywami.
  • Identyfikacja krytycznych lub ważnych funkcji (Critical Or Important Functions, CIF) - specyficzny dla DORA termin.

Ochrona i prewencja (art. 9)

Środki techniczne i organizacyjne:

  • Kontrola dostępu - RBAC, zasada minimalnych uprawnień, MFA wszędzie.
  • Kryptografia - polityka, zarządzanie kluczami (HSM/KMS), TLS 1.3, AES-256.
  • Bezpieczeństwo sieci - segmentacja, firewall, NDR.
  • Hardening systemów - zob. Hardening.
  • Zarządzanie zmianą - controlled deployment, rollback procedures.
  • Bezpieczeństwo developmentu - SDLC, code review, SAST, DAST.
  • Bezpieczeństwo fizyczne - data center, biura.
  • Bezpieczeństwo personelu - background checks, szkolenia, NDA.

Detekcja (art. 10)

  • SOC[14] 24/7 (zob. SOC 24/7).
  • SIEM z retencją min. 12 miesięcy.
  • EDR/XDR na końcówkach.
  • Network Detection and Response (NDR).
  • Threat intelligence - dostęp do feedów (CERT Polska, FinCERT, komercyjne).
  • Mechanizmy automatycznego alarmowania i eskalacji.

Odpowiedź i odzyskiwanie (art. 11-12)

  • Incident response procedures - playbooki dla każdego typu incydentu.
  • BCP/DRP z określonymi RTO i RPO.
  • Strategie kopii zapasowych - 3-2-1, regularne testy odzyskiwania.
  • Plan komunikacji kryzysowej - wewnętrznej i zewnętrznej.
  • Tryby pracy awaryjnej - jak bank funkcjonuje w razie awarii core banking.

Lessons learned (art. 13)

Po incydencie - obowiązkowa analiza post-incident, dokumentacja wniosków, zmiany w politykach i procedurach.

Komunikacja (art. 14)

Plan komunikacji z klientami, partnerami, organami nadzoru (KNF), CSIRT, mediami w razie incydentu.

Skrócone ramy dla mniejszych (art. 16)

Mikropodmioty i małe firmy finansowe mają uproszczone wymagania - bez wymaganego CISO etatowego, bez TLPT, uproszczone raportowanie. Niezależnie - wszystkie podmioty muszą mieć podstawowe ICT controls[12].

Filar 2 - zarządzanie incydentami ICT

Rozdział III (art. 17-23) reguluje zarządzanie i raportowanie incydentów ICT.

Klasyfikacja incydentów

Trzy kategorie:

  • ICT incident - każde naruszenie integralności, poufności, dostępności systemów ICT.
  • Significant ICT incident (znaczący) - wpływ na krytyczne lub ważne funkcje (CIF), próg progowy zdefiniowany w RTS.
  • Major ICT-related incident (poważny) - dotyczy operacyjnej ciągłości na poziomie systemowym, transgranicznym.

Progi znaczącego incydentu

RTS na klasyfikację incydentów [3] definiuje progi:

  • Liczba klientów dotkniętych - powyżej 10% lub 100 tys.
  • Czas niedostępności - powyżej 2 godzin dla CIF lub powyżej 8 godzin łącznie.
  • Wartość finansowa - powyżej określonych progów.
  • Wpływ geograficzny - dotykający więcej niż jednego państwa członkowskiego.
  • Wpływ reputacyjny - krytyczne pokrycie medialne.

Trójstopniowe raportowanie

Art. 19 DORA wprowadza terminy:

  • Wstępne powiadomienie (initial notification) - 4 godziny od klasyfikacji jako significant; nie później niż 24h od stwierdzenia.
  • Klasyfikacja i ocena (intermediate report) - 72 godziny od initial notification.
  • Raport końcowy (final report) - 1 miesiąc od initial notification.

Adresat zgłoszenia

Zgłoszenie do krajowego organu nadzoru (w Polsce - KNF dla banków, ubezpieczycieli, TFI; UKNF dla obsługi formalnej). KNF następnie propaguje informacje do ESA (EBA, EIOPA, ESMA), ENISA, CSIRTs Network.

Dla incydentów transgranicznych - automatyczna eskalacja do organów innych państw członkowskich.

Powiadomienie klientów (art. 19 ust. 3)

Gdy incydent dotyka klientów - obowiązek poinformowania klientów bez zbędnej zwłoki:

  • O charakterze incydentu.
  • O środkach zaradczych dostępnych dla klienta.
  • O kontakcie obsługi.

Klasyfikacja istotnych ataków cybernetycznych (art. 18)

Specjalna kategoria - significant cyber threat. Podmioty finansowe mogą zgłaszać poważne zagrożenia cybernetyczne (np. zaobserwowane skuteczne kampanie phishingowe przeciwko sektorowi), nawet jeśli incydent jeszcze nie zaistniał. Dobrowolne, ale zalecane.

Filar 3 - testowanie odporności i TLPT

Rozdział IV (art. 24-27) wprowadza obowiązkowe testowanie odporności cyfrowej.

Podstawowe testy (art. 25)

Wszystkie podmioty finansowe (z uwzględnieniem proporcjonalności) prowadzą:

  • Skanowanie podatności - co kwartał (zob. Skanowanie podatności).
  • Testy bezpieczeństwa aplikacji - przy każdym istotnym uruchomieniu (SAST, DAST).
  • Testy oparte na scenariuszach - tabletop exercises, BCP/DRP rehearsals.
  • Testy penetracyjne - okresowe, dla krytycznych systemów (zob. Testy penetracyjne).

Threat-Led Penetration Testing (TLPT) - art. 26-27

Zaawansowany red-team test oparty na rzeczywistych scenariuszach zagrożeń. Obowiązkowy dla:

  • Podmiotów wyznaczonych przez krajowy organ nadzoru jako duże i ważne (KNF wyznaczy listę w Polsce).
  • Cykl: raz na 3 lata.

Metodologia TLPT - TIBER-EU

TLPT bazuje na ramach TIBER-EU [4] (Threat Intelligence-based Ethical Red Teaming) Europejskiego Banku Centralnego. Trzy fazy:

Faza 1: Preparation (4-8 tygodni)

  • Wybór testera - akredytowana firma z certyfikowanymi specjalistami.
  • Threat Intelligence Provider (TIP) przygotowuje threat intelligence-led scoping - jakie scenariusze są najbardziej prawdopodobne dla danego podmiotu.
  • Definicja celów testu - krytyczne lub ważne funkcje (CIF).
  • Komunikacja z organem nadzoru, agencjami wywiadu finansowego.

Faza 2: Red Team Test (10-12 tygodni)

  • Faktyczny atak na produkcyjne systemy podmiotu.
  • Atakujący naśladują rzeczywiste TTP[18] (Tactics, Techniques, Procedures) zaobserwowanych grup APT.
  • Cel: dotarcie do CIF i wykonanie określonych operacji.
  • Test prowadzony w trybie nieświadomości - większość zespołu IT nie wie o testu (testowanie również SOC i procedur incident response).

Faza 3: Closure (2-4 tygodnie)

  • Debrief - prezentacja wyników zarządowi i zespołom technicznym.
  • Raport końcowy - szczegółowe stwierdzenia, klasyfikacja, rekomendacje.
  • Plan naprawczy - timeline usunięcia luk.
  • Pokontrolne raportowanie do organu nadzoru.

Koszt TLPT

  • Średni bank: 200-500 tys. EUR.
  • Duży bank, hyperscaler CTPP: 1-2 mln EUR.
  • Pokrywa koszt testerów, TIP, koordynacji, dokumentacji.

Certyfikacja testerów TLPT

RTS na TLPT precyzują wymagania kompetencyjne dla zespołów testowych:

  • Minimum 4-osobowy zespół.
  • Certyfikaty: OSCP, CRTO, GXPN, CRTM dla red teamerów.
  • Doświadczenie w sektorze finansowym.
  • Akredytacja krajowa lub europejska.

Filar 4 - zarządzanie ryzykiem trzeciej strony

Rozdział V (art. 28-44) - najobszerniejszy rozdział DORA - reguluje zarządzanie dostawcami ICT.

Polityka zarządzania ryzykiem trzeciej strony (art. 28)

Podmiot finansowy ma udokumentowaną politykę obejmującą:

  • Identyfikację i klasyfikację dostawców ICT.
  • Ocenę ryzyka przed zawarciem umowy.
  • Monitoring w trakcie trwania umowy.
  • Procedury exit strategy.
  • Specjalne zasady dla CIF (Critical or Important Functions).

Ocena przed zawarciem umowy (art. 29)

Przed zawarciem umowy z dostawcą ICT:

  • Due diligence dostawcy - reputacja, finanse, technologie.
  • Ocena ryzyka, w tym ryzyka koncentracji (concentration risk).
  • Ocena, czy usługa dotyczy CIF.
  • Plan exit strategy.

Klauzule umowne (art. 30) - obowiązkowe minimum

Art. 30 DORA definiuje minimalny obowiązkowy katalog klauzul w umowach z dostawcami ICT. Dla dostawców CIF - lista rozszerzona. Klauzule obejmują m.in.:

  1. Opisy świadczonych usług - precyzyjne, SLA, KPI.
  2. Lokalizacje przetwarzania i przechowywania danych.
  3. Bezpieczeństwo danych - środki techniczne i organizacyjne, w tym szyfrowanie.
  4. Zgłaszanie incydentów - terminy, kanały.
  5. Współpraca w incident response.
  6. Prawo do audytu - klienta oraz organu nadzoru.
  7. Cooperation z organami nadzoru - bezpośrednio (nie tylko przez klienta).
  8. Zarządzanie podwykonawcami (subcontracting) - notification, prawo veto.
  9. Plan exit strategy - jak migrować dane i procesy.
  10. Klauzule terminacji - prawa, terminy, koszty.
  11. Insurance - cyber insurance dostawcy.
  12. Continuity - BCP/DRP dostawcy.

Concentration risk (art. 29)

Trzy poziomy ryzyka koncentracji:

  • Wewnątrz podmiotu - czy bank zbyt mocno polega na jednym dostawcy chmury.
  • Sektorowa - czy znaczna część podmiotów finansowych UE używa tego samego dostawcy.
  • Geograficzna - dane / przetwarzanie w państwach o specyficznym ryzyku.

Rejestr informacji o dostawcach ICT (art. 28 ust. 3)

Podmiot finansowy prowadzi rejestr wszystkich umów z dostawcami ICT - format zdefiniowany w ITS. Rejestr zawiera m.in.:

  • Identyfikator dostawcy (LEI - Legal Entity Identifier).
  • Opis usługi.
  • Czy dotyczy CIF.
  • Lokalizacje.
  • Podwykonawców.
  • Klasyfikację ryzyka.

Rejestr jest cyklicznie raportowany do KNF/ESA.

Filar 5 - wymiana informacji

Rozdział VI (art. 45-50) reguluje dobrowolną wymianę informacji o cyberzagrożeniach.

Cel wymiany

Wymiana indicators of compromise (IoC), TTP grup APT, scenariuszy ataków, lessons learned z incydentów - między podmiotami finansowymi UE. Ma na celu szybsze wykrywanie i odpowiadanie na zagrożenia.

Platformy wymiany

  • FS-ISAC (Financial Services Information Sharing and Analysis Center) - globalna platforma.
  • FinCERT.pl - polski sektorowy CSIRT bankowy (Związek Banków Polskich).
  • MISP (Malware Information Sharing Platform) - otwarte oprogramowanie używane przez ENISA.
  • EU-CyCLONe - sieć NIS2.

Zachęty regulacyjne

DORA zachęca, ale nie wymaga uczestnictwa. Podmioty uczestniczące mają:

  • Dostęp do aktualnych threat intelligence.
  • Sygnalizowanie znaczących zagrożeń przed materializacją.
  • Korzystanie z dobrych praktyk innych podmiotów.

RODO i wymiana danych

Wymiana danych musi być zgodna z RODO [7]. DORA art. 45 wprowadza specyficzną podstawę prawną (interes publiczny art. 6 ust. 1 lit. e RODO) dla wymiany IoC. Dane osobowe powinny być pseudonimizowane lub anonimizowane przed wymianą.

Oversight Framework dla CTPP

Art. 31-44 DORA wprowadzają bezpośredni nadzór ESA nad Critical Third-Party Providers (CTPP) - dostawcami ICT krytycznymi dla stabilności sektora finansowego UE. To fundamentalna nowość - regulacja sięga poza podmioty regulowane.

Kryteria wyznaczenia CTPP (art. 31)

ESA wyznacza CTPP na podstawie:

  • Wpływ systemowy - czy awaria dostawcy zaburzy sektor finansowy UE.
  • Liczba obsługiwanych podmiotów finansowych.
  • Wartość krytyczna usługi - czy dotyczy CIF.
  • Koncentracja - czy dostawca dominuje na rynku.
  • Alternatywne źródła - czy są zastępniki.

Spodziewani CTPP

  • Hyperscalers chmurowi - AWS, Microsoft Azure, Google Cloud.
  • SWIFT - komunikacja międzybankowa.
  • Visa, Mastercard - sieci płatności kartowych.
  • Główni providerzy danych rynkowych - Bloomberg, Refinitiv (LSEG).
  • Duże data center providers.

Lead Overseer

Każdy CTPP ma wyznaczony Lead Overseer spośród ESA (EBA, EIOPA, ESMA) - jeden organ odpowiedzialny za nadzór nad konkretnym CTPP. Decyzja na podstawie sektora, którego dotyczy najwięcej usług.

Uprawnienia nadzoru

Lead Overseer może:

  • Żądać informacji i dokumentów.
  • Przeprowadzać ogólne inspekcje i kontrole on-site.
  • Audytować data center, kod, procesy.
  • Wydawać rekomendacje - z obowiązkiem realizacji.
  • Współpracować z organami trzecimi państw, w których CTPP ma siedzibę (np. USA dla AWS).

Sankcje dla CTPP (art. 35)

Okresowa kara pieniężna do 1% średniego dziennego światowego obrotu CTPP, naliczana co tydzień przez okres do 6 miesięcy, do czasu usunięcia naruszenia.

Dla dużej hyperscaler firmy (np. AWS, obrót setki mld USD) to mogą być setki milionów EUR. To pierwsza w europejskim prawie regulacja, która bezpośrednio nakłada kary na duże firmy technologiczne spoza sektora finansowego.

Konsekwencje dla rynku

Hyperscalers już przygotowują dedykowane European sovereign cloud oferty (AWS European Sovereign Cloud, Microsoft EU Data Boundary, Google Sovereign Cloud) z separacją danych UE i ograniczeniem dostępu z państw trzecich - by sprostać wymogom DORA i NIS2.

Sankcje i nadzór KNF

Sankcje dla podmiotów finansowych

DORA deleguje wysokość kar do prawa krajowego, wymagając tylko, by były skuteczne, proporcjonalne i odstraszające. W polskim prawie kary dla sektora finansowego są regulowane:

  • Ustawa o nadzorze nad rynkiem finansowym.
  • Sektorowe ustawy (Prawo bankowe, ustawa o działalności ubezpieczeniowej, ustawa o funduszach inwestycyjnych).

Praktyczne kary:

  • Kara administracyjna - do kilkudziesięciu mln zł dla największych podmiotów (zależnie od sektora).
  • Czasowe wstrzymanie funkcji kierowniczych dla osób odpowiedzialnych.
  • Cofnięcie zezwolenia / licencji w skrajnych przypadkach.
  • Publikacja decyzji - reputation damage.

Inspekcje KNF

KNF jest polskim organem właściwym dla DORA w sektorach: bankowość, kapitałowy, ubezpieczenia. Inspekcje obejmują:

  • Weryfikację ICT Risk Management Framework.
  • Audyt zgłoszeń znaczących incydentów ICT.
  • Weryfikację umów z dostawcami ICT.
  • Sprawdzenie planów exit strategy.
  • Ocena gotowości do TLPT (dla podmiotów wybranych).

Rekomendacja D KNF a DORA

Polska Rekomendacja D KNF [6] dotyczyła zarządzania technologią informacyjną i bezpieczeństwa środowiska teleinformatycznego w bankach. Większość wymagań Rekomendacji D jest kompatybilna z DORA, ale DORA wprowadza bardziej szczegółowe wymagania (TLPT, klauzule umowne, CTPP).

Po pełnym wdrożeniu DORA Rekomendacja D może zostać uchylona lub zaktualizowana w zakresach nieobjętych DORA.

Mapping do NIS2, KSC, RODO

DORA vs NIS2

DORA jest lex specialis wobec NIS2 dla sektora finansowego (zob. artykuł o NIS2). Bank pozostaje formalnie podmiotem NIS2, ale w obszarach pokrywających się DORA ma pierwszeństwo:

  • ICT risk management - DORA.
  • Incident management - DORA + KNF + opcjonalnie CSIRT.
  • Testowanie odporności (TLPT) - DORA.
  • Third-party risk - DORA.
  • Information sharing - DORA + opcjonalnie EU-CyCLONe.

DORA vs KSC

Bank w Polsce był OUK (Operator Usługi Kluczowej) w KSC. Po wdrożeniu DORA + transpozycji NIS2 do KSC - kompleks regulacji wymagający koordynacji:

  • DORA - główny framework dla cybersecurity banku.
  • KSC/NIS2 - wymagania, których nie pokrywa DORA (np. niektóre aspekty współpracy z CSIRT).
  • Rekomendacja D - kompatybilna, możliwe uchylenie po DORA.

Zob. artykuł o KSC.

DORA vs RODO

Komplementarne. DORA chroni systemy ICT banku, RODO chroni dane osobowe klientów banku. W razie incydentu z udziałem danych klientów - podwójne zgłoszenie:

  • Do KNF (DORA, 4h initial).
  • Do PUODO (RODO, 72h).

Zob. artykuł o RODO.

DORA vs MiCA

MiCA (rozporządzenie 2023/1114) reguluje rynek krypto. CASP (Crypto-Asset Service Providers) są objęci DORA - to spore wyzwanie dla nowego sektora.

Wdrożenie DORA - praktyka

Dla typowego banku średniej wielkości pełne wdrożenie DORA to projekt 18-24 miesięcy.

Etapy wdrożenia

  1. Gap analysis (2-3 miesiące) - mapping stanu obecnego (Rekomendacja D, NIS) vs wymagania DORA. Identyfikacja luk.
  2. Governance setup (1-2 miesiące) - decyzje zarządu, alokacja budżetu, wyznaczenie CISO i komórki DORA, szkolenie zarządu.
  3. ICT Risk Management Framework (6-9 miesięcy) - polityki, procedury, klasyfikacja CIF, BIA, BCP/DRP.
  4. Wdrożenia techniczne (12-18 miesięcy) - SOC, SIEM, EDR, hardening, MFA, kryptografia, monitoring, exit strategy dla dostawców.
  5. Aktualizacja umów z dostawcami (6-12 miesięcy) - renegocjacja klauzul z art. 30 dla wszystkich dostawców ICT.
  6. Procedury incident management (2-3 miesiące) - playbooki, kanały zgłaszania, testy procedur.
  7. Pierwszy TLPT (jeśli dotyczy, 4-6 miesięcy) - dla podmiotów wyznaczonych.
  8. Audyt i utrzymanie - cykliczne audyty, doskonalenie.

Koszty wdrożenia

  • Mały bank lub TFI: 500 tys. - 1 mln zł.
  • Średni bank lub ubezpieczyciel: 2-5 mln zł.
  • Duży bank krajowy: 10-30 mln zł.
  • TLPT: dodatkowo 200-500 tys. EUR raz na 3 lata.
  • Bieżące koszty operacyjne: 20-40% kosztów wdrożenia rocznie.

Najczęstsze błędy

  1. Założenie, że Rekomendacja D wystarczy. Większość się pokrywa, ale są obszary unikalne dla DORA (TLPT, klauzule z art. 30, exit strategy).
  2. Brak zaangażowania biznesu. CIF nie są pojęciem czysto IT - wymagają współpracy z biznesem.
  3. Niedoszacowanie pracy z dostawcami. Renegocjacja umów to ogromny wysiłek dla zespołów prawnych.
  4. Pominięcie exit strategy. Wymaga rzeczywistego planu, nie pustego dokumentu.
  5. Brak testów. BCP/DRP, procedury incident response - jeśli nie testowane, nie działają.

Checklist: 10 punktów gotowości DORA

Lista high-impact dla podmiotów finansowych objętych DORA. Bez tych elementów ryzyko stwierdzenia niezgodności w inspekcji KNF jest znaczne.

  1. Klasyfikacja podmiotu. Czy jesteś podmiotem DORA? Mikro / mała / średnia / duża firma? Skrócone ramy art. 16 stosują się?
  2. ICT Risk Management Framework zatwierdzony przez zarząd, udokumentowany, aktualizowany rocznie.
  3. Krytyczne lub ważne funkcje (CIF) zidentyfikowane, BIA przeprowadzona, RTO/RPO określone.
  4. Polityki ICT - kryptografia, kontrola dostępu, zarządzanie incydentami, zarządzanie zmianą, zarządzanie podatnościami.
  5. SOC 24/7 z SIEM (retencja 12 miesięcy), EDR/XDR. Zob. SOC 24/7.
  6. Plan ciągłości działania i DR z testami min. raz w roku (tabletop + technical).
  7. Rejestr dostawców ICT w formacie ITS, klasyfikacja, ocena ryzyka, klauzule z art. 30 w umowach, plany exit strategy.
  8. Procedura zgłaszania incydentów ICT - 4h / 72h / 1 miesiąc, kanały do KNF, szablony, testy.
  9. Testowanie odporności - skanowanie podatności (kwartalnie), pentesty (rocznie), tabletop (rocznie). TLPT raz na 3 lata dla wyznaczonych.
  10. Szkolenia zarządu - 4-8h rocznie, udokumentowane. Pierwsze szkolenie po wyznaczeniu nowych członków.

Najczęściej zadawane pytania

Kogo dotyczy DORA?

Art. 2 DORA obejmuje 20 kategorii podmiotów finansowych: banki krajowe i banki spółdzielcze, instytucje płatnicze i instytucje pieniądza elektronicznego, firmy inwestycyjne, fundusze inwestycyjne i ich zarządzający (TFI), ubezpieczyciele i reasekuratorzy, fundusze emerytalne, OFE, dystrybutorów ubezpieczeń, agencje ratingowe, CCP (centralne kontrahenci), CSD (centralne depozyty papierów wartościowych), trading venues (giełdy), repozytoria transakcji, audytorów rynkowych, providerów usług kryptowalutowych (po MiCA).

Wyłączeni mikropodmioty wg definicji UE (poniżej 10 osób i 2 mln EUR).

Dodatkowo Oversight Framework dotyczy Critical Third-Party Providers (CTPP) - dostawców ICT krytycznych dla sektora finansowego.

Co to TLPT?

Threat-Led Penetration Testing (TLPT) to zaawansowany test penetracyjny inspirowany rzeczywistymi scenariuszami zagrożeń. DORA wprowadza obowiązkowe TLPT dla największych podmiotów finansowych raz na 3 lata.

TLPT jest oparte na ramach TIBER-EU Europejskiego Banku Centralnego. Składa się z trzech faz:

  1. Preparation - threat intelligence-led scoping.
  2. Red team test - faktyczny atak na produkcyjne systemy.
  3. Closure - debrief, raport, plan naprawczy.

Test obejmuje krytyczne funkcje, trwa typowo 12-15 tygodni. Koszt: 200-500 tys. EUR dla średniego banku, ponad 1 mln EUR dla dużego.

Czy fintech 5 osobowy podlega DORA?

Zależy od rodzaju działalności. DORA art. 16 przewiduje skrócone ramy proporcjonalne dla małych i mikrofirm finansowych.

Konkretnie:

  • Mikrofirma (poniżej 10 osób i 2 mln EUR) - uproszczone wymagania ICT risk management, bez wymaganego CISO etatowego, bez TLPT, uproszczone raportowanie.
  • Mała firma (poniżej 50 osób) - uproszczenia, ale więcej niż mikrofirma.
  • Średnia/duża firma - pełne wymagania.

Niezależnie - wszystkie podlegają zgłaszaniu incydentów ICT, zarządzaniu dostawcami ICT, podstawowemu testowaniu. Fintech 5-osobowy spełnia kryteria mikrofirmy i ma znacznie uproszczone obowiązki.

DORA vs NIS2 - co ma pierwszeństwo?

DORA jest lex specialis wobec NIS2 dla sektora finansowego. Recital 28 DORA jasno wskazuje, że w zakresie pokrywającym się DORA stosuje się zamiast NIS2.

Bank pozostaje formalnie podmiotem NIS2 (jest na liście załącznika I), ale w obszarach:

  • ICT risk management,
  • Incident management,
  • Digital operational resilience testing,
  • Third-party risk,
  • Information sharing,

stosuje DORA. NIS2 nadal obowiązuje banku w obszarach NIE pokrytych DORA. Praktyczne zalecenie: bank mapuje DORA jako podstawowy framework cyberbezpieczeństwa, NIS2 jako uzupełnienie.

Co to CTPP?

Critical Third-Party Providers (CTPP) - dostawcy ICT krytyczni dla stabilności sektora finansowego UE. Wyznaczani przez European Supervisory Authorities (ESAs: EBA, EIOPA, ESMA) na podstawie kryteriów (art. 31 DORA): wartość krytyczna usługi, wpływ awarii na rynek, liczba obsługiwanych podmiotów finansowych, koncentracja na rynku, alternatywne źródła.

Spodziewani CTPP: AWS, Microsoft Azure, Google Cloud (hyperscalers), SWIFT (komunikacja międzybankowa), Visa/Mastercard (płatności kartowe), główni providerzy danych rynkowych (Bloomberg, Refinitiv), duże data center providers.

CTPP podlegają specjalnemu Oversight Framework prowadzonemu przez ESA - audyty, rekomendacje, kary do 1% rocznego obrotu CTPP.

Jakie kary za naruszenie DORA?

DORA przewiduje dwa reżimy kar:

Dla podmiotów finansowych - kary nakładane przez krajowy organ nadzoru (w Polsce - KNF). Wysokość kar jest delegowana do prawa krajowego, ale musi być skuteczna, proporcjonalna i odstraszająca. W polskiej ustawie o nadzorze nad rynkiem finansowym kary mogą sięgać 10-20% obrotu rocznego dla najpoważniejszych naruszeń.

Dla CTPP - DORA art. 35 wprowadza okresową karę pieniężną do 1% średniego dziennego światowego obrotu CTPP, naliczaną co tydzień przez okres do 6 miesięcy. Dla dużej hyperscaler firmy to mogą być setki milionów EUR.

Dodatkowo: środki naprawcze, publikacja decyzji, zalecenia korygujące.

Kiedy DORA weszło w życie?

DORA został przyjęty 14 grudnia 2022 r., opublikowany 27 grudnia 2022 r. Wszedł w życie 16 stycznia 2023 r., ale jego stosowanie zostało odroczone do 17 stycznia 2025 r. - to data, od której podmioty finansowe muszą faktycznie spełnić wymagania.

W tym 2-letnim okresie przejściowym: ESA przygotowały RTS i ITS, KE przyjęła rozporządzenia delegowane, podmioty finansowe miały czas na wdrożenie.

Na maj 2026 r. - DORA obowiązuje pełnoprawnie, KNF prowadzi inspekcje, ESA wyznaczają pierwszych CTPP. Pierwsze cykle TLPT są w toku dla największych banków UE.

ICT third-party concentration risk - co to znaczy?

Ryzyko koncentracji dostawców ICT - sytuacja, w której podmiot finansowy jest zbyt zależny od jednego dostawcy ICT, którego awaria zagraża zdolności świadczenia usług. DORA art. 29 wymaga oceny i zarządzania tym ryzykiem na trzech poziomach:

  1. Koncentracja wewnątrz podmiotu - czy bank zbyt mocno polega na jednym dostawcy chmury.
  2. Koncentracja sektorowa - czy znaczna część podmiotów finansowych w UE używa tego samego dostawcy.
  3. Koncentracja geograficzna - czy dane / przetwarzanie odbywają się w państwach o specyficznym ryzyku.

Wymagania: udokumentowana ocena koncentracji, plan exit strategy, monitoring zmian w portfolio dostawców. Praktyka: większość banków obecnie używa multi-cloud (AWS + Azure) jako mitygacja koncentracji.

Czy SaaS dla banku podlega DORA?

Bezpośrednio - nie, chyba że SaaS jest sam podmiotem finansowym. Pośrednio - tak, przez umowy z bankiem (klient DORA).

Bank jako podmiot DORA musi:

  1. Mapować dostawcę SaaS jako third-party ICT, ocenić ryzyko.
  2. Zawrzeć umowę spełniającą wymogi art. 30 DORA - obowiązkowe klauzule.
  3. Monitorować dostawcę przez cały cykl umowy.

W praktyce SaaS obsługujący banki musi spełnić wymagania kontraktowe DORA i często wymaga certyfikacji ISO 27001, SOC 2 typ II. Najwięksi SaaS mogą zostać wyznaczeni przez ESA jako CTPP - wtedy podlegają bezpośredniemu nadzorowi.

Jakie procesy ICT risk management musi mieć bank pod DORA?

DORA art. 6 i RTS wymagają udokumentowanego ICT Risk Management Framework obejmującego:

  1. Strategia i polityka ICT risk management - zatwierdzona przez zarząd.
  2. Identyfikacja - rejestr aktywów ICT, klasyfikacja, mapowanie zależności (BIA).
  3. Ochrona i prewencja - kontrola dostępu, kryptografia, hardening, backup.
  4. Detekcja - SIEM, EDR, monitoring 24/7.
  5. Odpowiedź i odzyskiwanie - procedury incident response, BCP, DRP.
  6. Nauka i ewolucja - lessons learned, doskonalenie.
  7. Komunikacja - raportowanie do zarządu (minimum kwartalne).

ICT Risk Management Framework musi być integralną częścią Enterprise Risk Management (ERM) banku. Wdrożenie zwykle wymaga wsparcia konsultantów - koszt 500 tys. - 2 mln zł dla średniego banku.

Współpraca z KNF w ramach DORA - jak wygląda?

KNF jest polskim organem nadzoru DORA dla sektora bankowego, kapitałowego i ubezpieczeniowego. Obowiązki banku wobec KNF:

  1. Zgłaszanie znaczących incydentów ICT - 4h wstępne, 72h klasyfikacja, 1 miesiąc raport końcowy.
  2. Roczna ocena ryzyka ICT do KNF.
  3. Plan TLPT przed startem testu.
  4. Raport po TLPT z wnioskami i planem naprawczym.
  5. Wykaz CTPP używanych przez bank.
  6. Współpraca przy inspekcjach KNF.

KNF stosuje również Rekomendację D w zakresie technologii informacyjnej i bezpieczeństwa - praktycznie wszystkie wymagania D są kompatybilne z DORA. Po pełnym wdrożeniu DORA Rekomendacja D może zostać uchylona lub zaktualizowana.

Skrócone ramy dla mniejszych podmiotów - co konkretnie?

DORA art. 16 wprowadza zasadę proporcjonalności i skrócone ramy ICT risk management dla mikropodmiotów i małych podmiotów finansowych.

Konkretnie:

  • Mikropodmiot finansowy (poniżej 10 osób i 2 mln EUR) - nie musi wyznaczać CISO etatowego, można połączyć role; uproszczone ICT risk management framework; brak TLPT; uproszczone raportowanie.
  • Mały podmiot (poniżej 50 osób) - więcej obowiązków niż mikropodmiot, ale wciąż uproszczenia.

Mimo skróconych ram, wszystkie podmioty muszą: zgłaszać znaczące incydenty ICT, prowadzić zarządzanie dostawcami ICT z umowami spełniającymi art. 30, mieć podstawowe ICT controls (MFA, szyfrowanie, backup, antywirus).

Potrzebujesz konsultacji w zakresie DORA?

Bezpłatna 30-60 minutowa konsultacja. Bez zobowiązań. Sprawdzamy status DORA, mapujemy 5 filarów, identyfikujemy luki przed inspekcją KNF.

Zadzwoń: +48 691 122 312 office@4crypto.eu

Powiązane treści

Compliance i regulacje

Usługi związane

Bibliografia i źródła

Wszystkie cytowane źródła są publicznie dostępne. Rozporządzenia UE, RTS/ITS ESA i wytyczne ECB odsyłają do oryginałów w EUR-Lex, ESA i ECB.

  1. [1]regulationParlament Europejski, Rada UE (2022). Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. w sprawie operacyjnej odporności cyfrowej sektora finansowego oraz zmiany rozporządzeń (DORA). Dz.U. UE L 333, 27.12.2022 · https://eur-lex.europa.eu/eli/reg/2022/2554/oj
  2. [2]regulationParlament Europejski, Rada UE (2022). Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2556 z dnia 14 grudnia 2022 r. zmieniająca dyrektywy w odniesieniu do operacyjnej odporności cyfrowej sektora finansowego. Dz.U. UE L 333, 27.12.2022 · https://eur-lex.europa.eu/eli/dir/2022/2556/oj
  3. [3]regulationEuropean Supervisory Authorities (EBA, EIOPA, ESMA) (2024). Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) on DORA - ICT risk management framework, TLPT, incident classification, register of information, contractual requirements · https://www.eba.europa.eu/regulation-and-policy/operational-resilience-and-ict
  4. [4]guidelineEuropean Central Bank (ECB) (2018). TIBER-EU framework - Threat Intelligence-based Ethical Red Teaming. ECB · https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
  5. [5]regulationParlament Europejski, Rada UE (2022). Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2). Dz.U. UE L 333, 27.12.2022 · https://eur-lex.europa.eu/eli/dir/2022/2555/oj
  6. [6]regulationKomisja Nadzoru Finansowego (2013, akt. 2020). Rekomendacja D dotycząca zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach · https://www.knf.gov.pl/dla_rynku/regulacje_i_praktyka/rekomendacje_i_wytyczne
  7. [7]regulationParlament Europejski, Rada UE (2016). Rozporządzenie (UE) 2016/679 (RODO). Dz.U. UE L 119, 4.5.2016 · https://eur-lex.europa.eu/eli/reg/2016/679/oj
  8. [8]standardISO/IEC (2022). ISO/IEC 27001:2022 - Information security management systems · https://www.iso.org/standard/27001
  9. [9]reportEuropean Union Agency for Cybersecurity (ENISA) (2024). ENISA Threat Landscape 2024. ENISA, Heraklion. DOI: 10.2824/0710888 · https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024
  10. [10]standardNational Institute of Standards and Technology (NIST) (2024). NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, February 2024. DOI: 10.6028/NIST.CSWP.29 · https://doi.org/10.6028/NIST.CSWP.29
  11. [11]standardJoint Task Force (2020). NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. NIST. DOI: 10.6028/NIST.SP.800-53r5 · https://doi.org/10.6028/NIST.SP.800-53r5
  12. [12]standardInternational Organization for Standardization (2022). ISO/IEC 27002:2022 - Information security controls. ISO/IEC · https://www.iso.org/standard/75652.html
  13. [13]standardInternational Organization for Standardization (2023). ISO/IEC 27035-1:2023 - Information security incident management - Part 1: Principles and process. ISO/IEC · https://www.iso.org/standard/78973.html
  14. [14]peer-reviewedVielberth, M., B�hm, F., Fichtinger, I., Pernul, G. (2020). Security Operations Center: A Systematic Study and Open Challenges. IEEE Access, vol. 8, pp. 227756-227779. DOI: 10.1109/ACCESS.2020.3045514 · https://doi.org/10.1109/ACCESS.2020.3045514
  15. [15]reportVerizon Business (2024). 2024 Data Breach Investigations Report (DBIR). Verizon, 17th edition · https://www.verizon.com/business/resources/reports/dbir/
  16. [16]reportIBM Security, Ponemon Institute (2024). Cost of a Data Breach Report 2024. IBM Corporation · https://www.ibm.com/reports/data-breach
  17. [17]reportMandiant (Google Cloud) (2024). M-Trends 2024 Special Report. Mandiant · https://services.google.com/fh/files/misc/m-trends-2024.pdf
  18. [18]reportCrowdStrike (2024). 2024 CrowdStrike Global Threat Report. CrowdStrike · https://www.crowdstrike.com/global-threat-report/
  19. [19]standardMITRE Corporation (2024). MITRE ATT&CK Framework v15 (Enterprise, Mobile, ICS). MITRE · https://attack.mitre.org/
  20. [20]standardCloud Security Alliance (2024). Cloud Controls Matrix (CCM) v4. CSA · https://cloudsecurityalliance.org/research/cloud-controls-matrix/