DORA w praktyce w 2026 r. – obowiązki podmiotów finansowych i dostawców ICT krok po kroku

Kogo obejmuje DORA i dlaczego kwalifikacja jest pierwszym krokiem?

DORA ustanawia jednolite zasady cyfrowej odporności operacyjnej dla szerokiej grupy podmiotów finansowych. Zakres zależy od rodzaju regulowanej działalności. Nie należy przenosić obowiązków na każdą spółkę korzystającą z usług finansowych tylko dlatego, że używa systemów ICT.

Po stronie grup kapitałowych trzeba dodatkowo ustalić, które jednostki są objęte rozporządzeniem bezpośrednio, jakie usługi są współdzielone oraz kto odpowiada za procesy grupowe. Dopiero wtedy można zaprojektować rejestry, raportowanie i umowy wewnątrzgrupowe.

Governance i odpowiedzialność organu zarządzającego

Cyfrowa odporność operacyjna nie jest wyłącznie zadaniem CISO lub działu IT. Organ zarządzający zatwierdza ramy zarządzania ryzykiem ICT, powinien otrzymywać adekwatne informacje i rozumieć najważniejsze zależności technologiczne. Decyzje o akceptacji ryzyka muszą być możliwe do odtworzenia.

W praktyce potrzebny jest podział ról między bezpieczeństwem, IT, compliance, prawnikiem, zakupami i właścicielami biznesowymi usług. Brak takiego podziału ujawnia się szczególnie podczas awarii, gdy nikt nie ma jasnego mandatu do kwalifikacji incydentu lub uruchomienia planu ciągłości.

Ramy zarządzania ryzykiem ICT – od aktywów do scenariuszy awarii

Podmiot powinien znać systemy, dane, interfejsy, infrastrukturę i dostawców, od których zależą funkcje biznesowe. Inwentaryzacja pozwala ocenić ryzyko, dobrać zabezpieczenia oraz określić, które usługi wymagają szczególnie rygorystycznego nadzoru.

Ocena ryzyka nie może być statyczną tabelą. Zmiana dostawcy, migracja do chmury, wdrożenie nowego API albo reorganizacja procesu powinna uruchamiać ponowną ocenę. To samo dotyczy istotnego incydentu i wniosków z testów odporności.

Klasyfikacja i raportowanie incydentów ICT

DORA wprowadza ramy klasyfikacji i raportowania poważnych incydentów związanych z ICT. Organizacja potrzebuje mechanizmu, który od pierwszych minut gromadzi dane o wpływie zdarzenia, usługach, klientach, czasie trwania i przyczynie, aby możliwe było prawidłowe zastosowanie kryteriów regulacyjnych.

Procedura powinna być skoordynowana z RODO, KSC/NIS2 i obowiązkami kontraktowymi. Ta sama awaria może mieć kilka kwalifikacji prawnych. Wspólna chronologia oraz kontrola wersji zgłoszeń zmniejszają ryzyko rozbieżności między informacją przekazaną nadzorcy, klientom i ubezpieczycielowi.

Testy odporności – liczy się zdolność do odtworzenia, nie sam plan

Program testów powinien odpowiadać profilowi ryzyka i krytyczności systemów. Obejmuje między innymi testowanie planów ciągłości, kopii zapasowych, scenariuszy awarii, podatności i innych mechanizmów technicznych. Dla wybranych podmiotów znaczenie mają również zaawansowane testy typu TLPT.

Najcenniejszym wynikiem ćwiczenia jest lista konkretnych luk: brak kontaktu do dostawcy, niedziałająca kopia, zbyt długi czas odtworzenia albo niewłaściwe uprawnienia. Wnioski powinny mieć właściciela i zostać zweryfikowane w kolejnym teście.

Ryzyko dostawców ICT – cloud, SaaS, centra danych i usługi zarządzane

DORA wymaga zarządzania ryzykiem wynikającym z korzystania z zewnętrznych usług ICT. Podmiot finansowy powinien oceniać koncentrację, zastępowalność, lokalizację danych, podwykonawstwo, ciągłość działania i możliwości wyjścia z usługi. Największy problem powstaje, gdy jedna krytyczna funkcja zależy od dostawcy, którego nie da się szybko zastąpić.

Ocena powinna poprzedzać podpisanie umowy. Próba uzyskania prawa audytu, obowiązku współpracy z nadzorem i rozsądnego exit planu dopiero po zawarciu wieloletniego kontraktu zwykle istotnie osłabia pozycję negocjacyjną podmiotu finansowego.

Klauzule DORA w umowach ICT

Zakres wymaganych postanowień zależy od rodzaju usługi i tego, czy wspiera funkcję krytyczną lub istotną. Umowa powinna jasno określać usługi, lokalizację przetwarzania, dostępność danych, bezpieczeństwo, raportowanie incydentów, współpracę, audyt, podwykonawców i warunki zakończenia.

Nie wystarcza aneks nazwany „DORA addendum”, jeżeli jego postanowienia nie współgrają z główną umową, SLA i polityką dostawcy. W audycie kontraktu trzeba sprawdzić także hierarchię dokumentów oraz to, czy dostawca może jednostronnie zmienić warunki kluczowe dla zgodności.

Rejestr informacji o umowach ICT

DORA wymaga uporządkowanej informacji o relacjach z dostawcami ICT. Rejestr nie powinien być budowany ręcznie dopiero na żądanie organu. Dane o dostawcy, usłudze, funkcji, podwykonawcach i umowie warto utrzymywać w procesie zakupowym oraz aktualizować przy każdej zmianie.

Spójność rejestru z rzeczywistą architekturą jest równie ważna jak kompletność pól. Jeżeli system biznesowy korzysta z kolejnych usług w łańcuchu, a rejestr pokazuje tylko bezpośredniego kontrahenta, organizacja może nie dostrzegać koncentracji i zależności operacyjnych.

Jak uporządkować DORA bez produkowania dokumentacji dla samej dokumentacji?

Najlepszy punkt startu to mapa funkcji biznesowych i usług ICT. Następnie łączy się ją z ryzykiem, incydentami, testami i umowami. Dzięki temu każdy dokument odpowiada konkretnemu elementowi infrastruktury i ma właściciela procesowego.

Wsparcie w audycie umów, governance i relacji z dostawcami opisuję na stronie Prawo nowych technologii. W organizacjach objętych równolegle KSC/NIS2 warto budować wspólny katalog zabezpieczeń i dowodów, zachowując osobne wymagania obu reżimów.

Ciągłość działania ICT i plany odtwarzania

Plan ciągłości powinien wskazywać funkcje, które trzeba utrzymać lub odtworzyć w pierwszej kolejności, oraz zależne systemy i dostawców. RTO i RPO mają sens tylko wtedy, gdy zostały uzgodnione z biznesem i sprawdzone w realistycznym teście.

W środowisku finansowym awaria jednego systemu może wpływać na kilka regulowanych procesów. Dlatego test powinien obejmować przepływ end-to-end, a nie tylko pojedynczy serwer. Wynik ćwiczenia należy przekładać na korekty architektury i umów.

Ryzyko koncentracji i zależność od jednego dostawcy

Organizacja może mieć wielu dostawców na papierze, a mimo to opierać większość krytycznych funkcji na jednej chmurze, jednym dostawcy tożsamości lub jednym centrum danych. To koncentracja, której nie widać w prostym rejestrze kontrahentów.

Ocena powinna analizować wspólne zależności, podwykonawców i realną zastępowalność. Jeżeli migracja wymaga wielu miesięcy, plan wyjścia powinien być przygotowany wcześniej i uwzględniać dostęp do danych, kompetencji i infrastruktury alternatywnej.

Proporcjonalność nie oznacza rezygnacji z podstawowych kontroli

DORA pozwala dostosowywać sposób wdrożenia do wielkości, profilu ryzyka i charakteru działalności. Nie oznacza to jednak, że mniejszy podmiot może pominąć podstawowe elementy zarządzania ryzykiem, incydentami i dostawcami.

Proporcjonalność warto dokumentować. Jeżeli organizacja wybiera prostszy środek, powinna umieć wyjaśnić, dlaczego jest wystarczający dla danego ryzyka. Takie uzasadnienie jest bardziej wiarygodne niż ogólne powołanie się na małą skalę działalności.

Checklista audytu DORA – jakie pytania zadać organizacji?

Audyt powinien sprawdzić: właścicieli funkcji i systemów, ramy ryzyka ICT, rejestr incydentów, program testów, krytyczność usług, rejestr dostawców, klauzule umowne i exit plany. Następnie porównuje się dokumentację z konfiguracją i dowodami wykonania.

Najważniejsze luki często pojawiają się na styku działów. Zakupy mają umowę, IT zna architekturę, compliance prowadzi rejestr, ale dane nie są ze sobą powiązane. Właśnie dlatego wdrożenie powinno mieć jednego właściciela programu i wspólny model informacji.

Najczęstsze pytania