DORA w 2026 r.: obowiązki, incydenty, TLPT i dostawcy ICT

Status prawny DORA na 29 sierpnia 2026 r.

DORA weszła w życie 16 stycznia 2023 r., lecz większość jej przepisów zaczęto stosować 17 stycznia 2025 r. Nie był to termin na rozpoczęcie projektu wdrożeniowego, tylko dzień, od którego podmioty objęte rozporządzeniem powinny wykonywać obowiązki.^[1]

Rozporządzenie podstawowe jest uzupełnione aktami poziomu drugiego. Najważniejsze dotyczą ram zarządzania ryzykiem ICT, klasyfikacji incydentów, treści i terminów zgłoszeń, polityki korzystania z usług ICT, rejestru informacji, podwykonawstwa oraz TLPT. Dlatego ocena zgodności wyłącznie z tekstem DORA jest niepełna.

Polska: ustawa z 25 czerwca 2025 r. dostosowała ustawy sektorowe i KSC, określiła kompetencje nadzorcze oraz krajowe mechanizmy egzekwowania. DORA nadal pozostaje bezpośrednią podstawą zasadniczych obowiązków podmiotów finansowych.^[2]

Kogo obejmuje DORA

Artykuł 2 ust. 1 wymienia 20 kategorii podmiotów finansowych. Należą do nich między innymi instytucje kredytowe, płatnicze i pieniądza elektronicznego, firmy inwestycyjne, dostawcy usług w zakresie kryptoaktywów objęci MiCA, infrastruktura rynków finansowych, zarządzający funduszami, zakłady ubezpieczeń i pośrednicy, instytucje pracowniczych programów emerytalnych, agencje ratingowe, dostawcy finansowania społecznościowego oraz repozytoria sekurytyzacji.^[1]

Zakresu nie wolno ustalać na podstawie samej branży albo potocznego określenia "fintech". Trzeba sprawdzić status regulacyjny konkretnego podmiotu oraz wyłączenia z art. 2 ust. 3. Zasada proporcjonalności dostosowuje sposób realizacji obowiązków do wielkości, profilu ryzyka i złożoności, lecz nie tworzy ogólnego zwolnienia dla każdej małej organizacji.

Dostawcy ICT

Zwykły dostawca ICT nie staje się przez sam kontrakt "podmiotem finansowym DORA". Jego obowiązki wynikają przede wszystkim z umowy z podmiotem finansowym. Inny status mają dostawcy wyznaczeni przez europejskie organy nadzoru jako krytyczni dostawcy zewnętrzni ICT (CTPP): podlegają unijnym ramom bezpośredniego nadzoru.

Zarządzanie ryzykiem ICT i odpowiedzialność zarządu

Organ zarządzający ponosi ostateczną odpowiedzialność za zarządzanie ryzykiem ICT. Ma zatwierdzać i nadzorować ramy zarządzania, role, strategię odporności, plany ciągłości i odtwarzania, budżet oraz politykę korzystania z usług dostawców ICT. Członkowie organu powinni utrzymywać wiedzę pozwalającą rozumieć i oceniać to ryzyko.^[1]

Ramy z art. 5-16 obejmują sześć powiązanych zdolności:

• identyfikację funkcji biznesowych, aktywów informacyjnych i ICT oraz zależności;
• ochronę i zapobieganie, w tym kontrolę dostępu, konfiguracje, zmiany i bezpieczeństwo danych;
• wykrywanie anomalii oraz incydentów;
• reagowanie i odtwarzanie z określonymi celami oraz procedurami;
• uczenie się na incydentach i testach;
• komunikację wewnętrzną i zewnętrzną.

Rozporządzenie delegowane (UE) 2024/1774 rozwija wymagania dotyczące między innymi polityk, zarządzania aktywami, kryptografii, operacji ICT, bezpieczeństwa sieci, zmian, ciągłości i raportowania. Zawiera też szczegóły uproszczonych ram przewidzianych w art. 16 DORA dla określonych kategorii podmiotów - nie dla dowolnej firmy, która uzna się za małą.^[3]

Incydenty ICT: klasyfikacja i terminy zgłoszeń

Podmiot musi rejestrować incydenty związane z ICT, zarządzać nimi według udokumentowanego procesu i klasyfikować je z użyciem kryteriów z art. 18 DORA. Progi istotności określa rozporządzenie delegowane (UE) 2024/1772. Ocenia się między innymi klientów i kontrahentów, czas trwania i przestój, zasięg geograficzny, utratę dostępności, autentyczności, integralności lub poufności danych, znaczenie dotkniętych usług oraz wpływ ekonomiczny.^[4]

Po zaklasyfikowaniu incydentu jako poważnego obowiązuje trzystopniowe raportowanie. Rozporządzenie delegowane (UE) 2025/301 określa treść i terminy, a rozporządzenie wykonawcze (UE) 2025/302 - formularze i procedury.^[5][6]

W Polsce zgłoszenia poważnych incydentów ICT i powiadomienia o znaczących cyberzagrożeniach składa się przez system SOID udostępniony przez KNF. KNF publikuje również procedurę awaryjną na wypadek niedostępności systemu; zgłoszenie przekazane kanałem zastępczym trzeba po przywróceniu usługi zarejestrować w systemie. Dane dostępowe i instrukcje należy weryfikować bezpośrednio na stronie KNF przed incydentem.^[15]

Powiadomienie o istotnym cyberzagrożeniu jest dobrowolne. Jeśli poważny incydent wpływa na interesy finansowe klientów, art. 19 ust. 3 wymaga poinformowania ich bez zbędnej zwłoki o incydencie i środkach ograniczających skutki. Jeden incydent może równocześnie uruchomić obowiązki z RODO albo innych przepisów; raport DORA nie zastępuje automatycznie innych zgłoszeń.

Testowanie odporności i TLPT

Program testów ma być oparty na ryzyku i obejmować odpowiednie techniki: od ocen podatności, skanów i przeglądów konfiguracji po testy scenariuszowe, ciągłości, wydajności, end-to-end i penetracyjne. Dla systemów i aplikacji wspierających funkcje krytyczne lub istotne DORA przewiduje regularne testowanie, a zakres powinien odpowiadać zmianom i ryzyku.

TLPT nie dotyczy automatycznie każdego podmiotu

Zaawansowane testy penetracyjne ukierunkowane przez analizę zagrożeń (TLPT) wykonują podmioty wskazane przez właściwy organ według kryteriów DORA i rozporządzenia delegowanego (UE) 2025/1190. Podstawowa częstotliwość to co najmniej raz na trzy lata, ale organ może ją zmniejszyć lub zwiększyć zależnie od profilu ryzyka i okoliczności operacyjnych. Mikroprzedsiębiorstwa i podmioty stosujące ramy z art. 16 ust. 1 są wyłączone z tego obowiązku.^[7]

TLPT obejmuje krytyczne lub istotne funkcje i systemy produkcyjne, w tym istotne zależności od dostawców. Proces zawiera ustalenie zakresu, przygotowanie analizy zagrożeń, kontrolowane działania zespołu testującego, zamknięcie testu oraz plan naprawczy. Zwykły test penetracyjny aplikacji nie staje się TLPT tylko dlatego, że wykorzystuje scenariusze ataków.

Bezpieczeństwo testu pozostaje istotne: zakres, zasady przerwania, poufność, komunikacja kryzysowa i odpowiedzialność za systemy produkcyjne muszą być uzgodnione przed rozpoczęciem działań. DORA nie uzasadnia niekontrolowanego testowania produkcji.

Dostawcy ICT, umowy i rejestr informacji

Korzystanie z zewnętrznej usługi nie przenosi odpowiedzialności regulacyjnej. Podmiot finansowy musi zarządzać ryzykiem przez cały cykl umowy: od kwalifikacji funkcji i due diligence, przez negocjacje, monitorowanie i audyt, po zakończenie współpracy oraz plan wyjścia.

Rejestr obejmuje wszystkie umowy o usługi ICT

Artykuł 28 ust. 3 wymaga prowadzenia i aktualizowania rejestru informacji o wszystkich ustaleniach umownych dotyczących usług ICT. Umowy wspierające funkcje krytyczne lub istotne trzeba wyraźnie odróżnić. Standardowe szablony i taksonomie określa rozporządzenie wykonawcze (UE) 2024/2956.^[8]

Umowa musi odzwierciedlać ryzyko

Artykuł 30 określa elementy umów, między innymi opis usług i lokalizacji, ochronę danych, wsparcie przy incydentach, obowiązki po zakończeniu umowy oraz współpracę z organami. Dla usług wspierających funkcje krytyczne lub istotne dochodzą wymagania dotyczące poziomów usług, planów ciągłości, udziału w testach, praw dostępu, inspekcji i audytu oraz strategii wyjścia. Rozporządzenie delegowane (UE) 2024/1773 rozwija treść polityki zarządzania tymi umowami.^[9]

Podwykonawcy

Rozporządzenie delegowane (UE) 2025/532 wymaga oceny łańcucha podwykonawców wspierających funkcje krytyczne lub istotne. Umowa powinna określać warunki podwykonawstwa, informowanie o istotnych zmianach, prawa kontroli i przypadki rozwiązania umowy. Oparcie się wyłącznie na ocenie przeprowadzonej przez głównego dostawcę nie znosi odpowiedzialności podmiotu finansowego.^[10]

CTPP: bezpośredni nadzór nad krytycznymi dostawcami

Europejskie Urzędy Nadzoru - EBA, EIOPA i ESMA - opublikowały 18 listopada 2025 r. pierwszą listę 19 krytycznych zewnętrznych dostawców usług ICT. Znalazły się na niej między innymi podmioty z grup Accenture, AWS, Google Cloud, IBM, Microsoft, Oracle, SAP oraz operatorzy infrastruktury telekomunikacyjnej i centrów danych. Lista ma być aktualizowana co najmniej raz w roku.^[11]

Dla każdego CTPP wyznacza się wiodący organ nadzorczy. Ocenia on zarządzanie ryzykiem, może prowadzić kontrole i wydawać zalecenia. Wyznaczenie dostawcy jako CTPP nie jest certyfikatem bezpieczeństwa i nie zwalnia podmiotu finansowego z due diligence, monitorowania koncentracji ani przygotowania strategii wyjścia.^[12]

Jeżeli CTPP nie współpracuje przy wykonywaniu uprawnień nadzorczych, wiodący organ może nałożyć okresową karę pieniężną równą 1 % średniego dziennego światowego obrotu dostawcy z poprzedniego roku obrotowego za każdy dzień naruszenia, maksymalnie przez sześć miesięcy. Nie jest to ogólna taryfa kary dla podmiotów finansowych.^[1]

Dobrowolna wymiana informacji

Artykuł 45 pozwala podmiotom finansowym wymieniać informacje i analizy dotyczące cyberzagrożeń w zaufanych społecznościach, jeżeli celem jest zwiększenie odporności, a ustalenia chronią poufność, dane osobowe i tajemnicę przedsiębiorstwa. To możliwość, nie obowiązek przekazywania całych zbiorów logów. Organizacja powinna z góry ustalić podstawę prawną, klasyfikację danych, minimalizację i zasady dalszego udostępniania.

DORA, NIS2, KSC i RODO

DORA i NIS2

Dyrektywa NIS2 traktuje DORA jako sektorowy akt Unii o skutku co najmniej równoważnym w zakresie zarządzania ryzykiem ICT i zgłaszania poważnych incydentów przez objęte podmioty finansowe. Nie oznacza to, że każda kwestia prawna dotycząca organizacji finansowej jest regulowana wyłącznie przez DORA. Trzeba porównać zakres podmiotowy, przedmiotowy i przepisy krajowe.^[13]

DORA i polski KSC

Ustawa z 2025 r. wprowadziła do KSC art. 16a, który ograniczył dublowanie określonych obowiązków operatorów usług kluczowych w sektorze bankowym i infrastruktury rynków finansowych w zakresie objętym DORA. Nowelizacja KSC z 2026 r. wdrażająca NIS2 nie zmienia zasady, że kwalifikację i obowiązki trzeba oceniać według aktualnego tekstu obu reżimów.

DORA i RODO

DORA chroni odporność operacyjną i obejmuje incydenty ICT; RODO reguluje przetwarzanie danych osobowych i naruszenia ich ochrony. To różne testy prawne. Incydent może wymagać zgłoszenia w obu trybach, w jednym albo w żadnym - zależnie od klasyfikacji DORA oraz ryzyka dla praw i wolności osób.^[14]

Jak zorganizować wdrożenie i dowody

1. Potwierdź zakres. Ustal status regulacyjny podmiotów i oddziałów, wyłączenia oraz właściwe organy.
2. Zidentyfikuj funkcje. Wskaż funkcje krytyczne lub istotne, procesy, właścicieli i tolerancję zakłóceń.
3. Zmapuj zależności. Połącz funkcje z aktywami, danymi, aplikacjami, lokalizacjami i dostawcami ICT.
4. Oceń ramy ryzyka. Zweryfikuj decyzje zarządu, polityki, role, zasoby, wskaźniki i raportowanie.
5. Przetestuj incydenty. Przećwicz klasyfikację, dwa zegary powiadomienia wstępnego, formularze, komunikację i inne reżimy zgłoszeniowe.
6. Uporządkuj rejestr. Uzgodnij identyfikatory, taksonomie, kompletność umów i kontrolę jakości danych.
7. Napraw umowy. Priorytetowo potraktuj usługi wspierające funkcje krytyczne lub istotne oraz łańcuchy podwykonawców.
8. Zbuduj program testów. Powiąż testy z ryzykiem, zmianami i funkcjami; przygotuj TLPT tylko wtedy, gdy podmiot podlega temu obowiązkowi.
9. Zachowuj dowody. Uchwała, raport, log, wynik testu i zaakceptowany wyjątek powinny wskazywać zakres, datę, właściciela i działanie następcze.

Nie istnieje uniwersalny koszt ani harmonogram wdrożenia DORA. Zależą od modelu licencyjnego, architektury, stanu umów, liczby dostawców, jakości inwentaryzacji i dojrzałości procesu incydentowego. Gotowa polityka bez wykonania i dowodów nie zamyka luki.

Najczęstsze błędy

• ograniczenie programu do działu bezpieczeństwa bez właścicieli biznesowych i zarządu;
• traktowanie każdej umowy jako outsourcingu albo, przeciwnie, pomijanie usług ICT kupowanych jako część większej usługi;
• prowadzenie rejestru wyłącznie dla dostawców funkcji krytycznych lub istotnych;
• brak całodobowej zdolności klasyfikacji i zatwierdzenia zgłoszenia incydentu;
• uznanie zwykłego pentestu za TLPT;
• akceptowanie raportu dostawcy jako zamiennika własnej oceny ryzyka;
• brak realnej strategii wyjścia oraz testów odtworzenia usługi;
• założenie, że zgodność z ISO/IEC 27001 automatycznie dowodzi zgodności z DORA.