Cyfryzacja sektora finansowego spowodowała, że usługi chmurowe stały się jednym z podstawowych elementów środowiska ICT instytucji finansowych – są wykorzystywane m.in. do utrzymania systemów transakcyjnych, kanałów zdalnych czy hurtowni danych. Rozporządzenie DORA, wraz z towarzyszącymi mu regulacyjnymi standardami technicznymi (RTS i ITS), wprost traktuje takie usługi jako usługi ICTświadczone przez zewnętrznych dostawców, podlegające określonym wymogom regulacyjnym – zarówno po stronie instytucji finansowej, jak i po stronie dostawcy.

‍

Kim jest dostawca usług ICT w rozumieniu DORA?

W art. 3 ust. 1 pkt 21 DORA wskazuje, że usługi ICT to „usługi cyfrowe oraz usługi w zakresie danych świadczone w sposób ciągły za pośrednictwem systemów ICT na rzecz co najmniej jednego użytkownika wewnętrznego lub zewnętrznego”. W praktyce chodzi o sytuacje, w których inny podmiot:

• przechowuje nasze dane,
• przetwarza nasze dane,
• udostępnia nam systemy lub aplikacje,
• monitoruje nasze systemy lub infrastrukturę,

i robi to nie incydentalnie, ale jako stałą usługę opartą na własnych systemach IT.

Z perspektywy DORA dostawcą usług ICT będzie więc m.in.:

• dostawca chmury (IaaS, PaaS, SaaS), który hostuje nasze systemy lub dane,
• dostawca gotowej aplikacji SaaS (np. CRM, narzędzie AML, moduł scoringowy),
• operator data center utrzymujący naszą infrastrukturę,
• dostawca usług bezpieczeństwa (np. SOC‑as‑a‑Service, monitoring, anty‑DDoS),
• firma, która zdalnie administruje naszymi serwerami, bazami danych czy middleware.

Definicja w DORA jest celowo szeroka - kategoryzację usługi ułatwia stwierdzenia, żę jeśli jakaś firma w sposób ciągły świadczy na naszą rzecz usługi cyfrowe lub związane z danymi przy użyciu systemów IT, to w większości przypadków będzie traktowana jako zewnętrzny dostawca usług ICT

Jeżeli instytucja finsnsowa korzysta z dostawcy SaaS, który opiera się na chmurze publicznej, to chmura, z której korzysta dostawca, jest elementem jego łańcucha podwykonawców (sub‑outsourcing), którym instytucja finansowa też musi się zainteresować – odpowiednie informacje i zasady muszą być odzwierciedlone w umowie (art. 30 ust. 2 lit. a–b DORA).

DORA w rozdziale VI (art. 31–44) wprowadza kategorię critical ICT third‑party providers (CTPP) – kluczowych zewnętrznych dostawców usług ICT. Pierwsza lista takich podmiotów (m.in. globalni dostawcy chmury i infrastruktury) została opublikowana w listopadzie 2025 r. przez EBA, ESMA i EIOPA: https://www.eiopa.europa.eu/document/download/56b1ca78-5dd2-4d36-8377-47a538eb7558_en?filename=List%20of%20designated%20CTPPs.pdf

Co to oznacza w praktyce:

• Wymienieni dostawcy są nadzorowani bezpośrednio przez ESAs, w ramach tzw. DORA Oversight Framework (kontrola governance, zarządzania ryzykiem ICT, cyberbezpieczeństwa, testów odporności), Instytucje finansowe nadal muszą spełniać wszystkie wymogi wobec swoich relacji z nimi (art. 28–30 DORA), ale mogą dodatkowo brać pod uwagę fakt, że dany dostawca jest już objęty unijnym nadzorem i pojawia się na oficjalnej liście CTPP.

Dlaczego chmura jest postrzegana jako outsourcing ICT wysokiego ryzyka

W praktyce na chmurze stoji większość funkcji krytycznych / istotnych procesów. Coraz częściej do chmury trafiają systemy płatnicze, scoringowe, główne CRM‑y czy hurtownie danych do raportowania. Pomimo iż potencjakne ryzyko operacyjne i bezpieczeństwa materializuje się u strony trzeciej, jednak wg. DORA to podmiot finansowy będzie odpowiadał przed nadzorcą.

Dodatkowo poziom ryzyka zwiększa także:

1. Efekt koncentracji – jeden dostawca = wielu klientów = ryzyko systemowe
   Hyperscaler (dostawca chmury publicznej z gigantyczną infrastrukturą (np. AWS, Microsoft Azure, Google Cloud) obsługuje jednocześnie setki instytucji finansowych na całym świecie. Awaria, poważny incydent czy błąd aktualizacji może w jednym momencie zakłócić funkcjonowanie rynku finansowego w Europie. DORA patrzy nie tylko na ryzyko jednego banku, lecz także na ryzyko koncentracji – a to w przypadku chmury publicznej jest dość wysokie.
2. Złożony łańcuch podwykonawców i utrudniony nadzór techniczny
   Dostawca chmury opiera się na własnym łańcuchu vendorów (hardware, łącza, usługi zarządzane, poddostawcy). Podmiot finansowy zobowiązany jest sprawować nadzór nir nie tylko nad głównym dostawcą, ale – przynajmniej w części – jego krytycznych podwykonawców, co jest zdecydowanie trudniejsze niż przy prostym outsourcingu jednego systemu.
3. Wyjście z chmury jest projektowo trudniejsze niż wejście
   Migracja z chmury do innego dostawcy albo z powrotem on‑prem wymaga czasu, budżetu i wiąże się z ryzykiem technicznym (formaty danych, integracje, różnice w usługach). Dlatego DORA wymusza na instytucjach posiadanie realnego „exit planu” dla usług ICT wspierających funkcje krytyczne/istotne – a nie tylko teoretycznej deklaracji w umowie.

Umowa z dostawcąICT: art. 30 DORA + RTS 2024/1773

Co powinno znaleźć się w umowie z dostawcą ICT, jeżeli świadczona usługa wspiera funkcje krytyczne lub istotne:

Kluczowe obszary:

SLA i parametry świadczenia usługi
Na podstawie art. 30 ust. 2 lit. d–e DORA umowa powinna określać:

• zakres usługi i funkcji objętych umową,
• poziomy świadczenia usług (SLA), w tym wskaźniki wydajności i dostępności oraz sposób ich pomiaru,
• wartości RTO/RPO dla usług wspierających funkcje krytyczne lub istotne,
• mechanizmy monitorowania tych parametrów oraz zasady raportowania naruszeń.

RTS 2024/1773 doprecyzowuje szczegółową treść tych postanowień.

Bezpieczeństwo i kontrola dostępu
Wymogi art. 9 DORA (bezpieczeństwo ICT) w powiązaniu z art. 30 ust. 2 lit. c DORA oznaczają konieczność ujęcia w umowie co najmniej:

• stosowanych metod uwierzytelniania i autoryzacji (IAM),
• wymogów dotyczących szyfrowania danych w spoczynku i w tranzycie,
• zakresu, retencji i sposobu udostępniania logów,
• zasad monitorowania bezpieczeństwa oraz obsługi incydentów związanych z ICT.ey+1

RTS dotyczące ram zarządzania ryzykiem ICT oraz RTS 2024/1773 wymagają, aby dla usług wspierających funkcje krytyczne/istotne postanowienia te były odpowiednio uszczegółowione.

Sub‑outsourcing (łańcuch dostaw)
Zgodnie z art. 30 ust. 2 lit. a–b DORA umowa powinna:

• wskazywać, czy dopuszczalne jest korzystanie z podwykonawców w odniesieniu do usług wspierających funkcje krytyczne/istotne,
• określać zakres dopuszczalnego podwykonawstwa,
• ustanawiać zasady informowania podmiotu finansowego o zmianach w łańcuchu podwykonawców oraz ewentualne prawo sprzeciwu.rsplegal+1

RTS przyjęte do art. 30 ust. 5 DORA doprecyzowują kryteria oceny podwykonawstwa usług ICT.

Prawo audytu i dostęp do informacji
Na podstawie art. 30 ust. 2 lit. f–g DORA umowa powinna zapewniać:

• prawo do przeprowadzenia audytu (bezpośredniego lub w oparciu o raporty niezależnych audytorów, np. SOC/ISAE),
• dostęp do informacji niezbędnych do oceny bezpieczeństwa i zgodności, w tym dokumentacji, logów oraz danych metrycznych.

RTS 2024/1773 precyzuje, że postanowienia te powinny wskazywać tryb, terminy i zakres udostępniania takich informacji.

Exit plan i migracja danych
Zgodnie z art. 28 ust. 7 oraz art. 30 ust. 2 lit. h DORA umowa powinna regulować:

• zasady zakończenia współpracy oraz przenoszalności usług i danych do innego dostawcy lub do infrastruktury własnej,
• format, zakres i terminy przekazania danych,
• zasady i terminy usunięcia danych po stronie dostawcy oraz sposób potwierdzenia tego usunięcia,
• ewentualny okres przejściowy na czas migracji.

RTS dotyczące polityki usług ICT dla funkcji krytycznych/istotnych (art. 28 ust. 10 DORA) wymagają, aby scenariusze exit były przewidziane i okresowo weryfikowane.

Po wdrożeniu: obowiązek monitorowania oraz testowania (art. 17–27 DORA + RTS/ITS)

• Art. 17–23 DORA oraz odpowiadające im RTS/ITS określają zasady zarządzania incydentami ICT, ich klasyfikacji i raportowania do właściwych organów (w tym kryteria incydentów poważnych).
• Art. 24–27 DORA oraz RTS TLPT regulują testy odporności operacyjnej, w tym threat‑led penetration testing (TLPT) dla wybranych podmiotów i funkcji.
• Art. 26–27 DORA nakładają obowiązek bieżącego monitorowania ryzyka związanego z usługami ICT, przeglądu umów oraz dostosowywania konfiguracji technicznej.

Instytucja jest ponadto zobowiązana do:

• prowadzenia aktualnego rejestru usług ICT i dostawców zgodnie z art. 28 ust. 3–5 DORA oraz właściwymi ITS (rejestr informacji),
• cyklicznej oceny ryzyka związanego z usługami ICT, w tym chmurowymi,
• dokumentowania historii incydentów, parametrów SLA, testów DR/TLPT oraz zmian w konfiguracji i umowach.

Z punktu widzenia zewnętrznego dostawcy usług chmurowych wymogi DORA przekładają się na trzy zasadnicze płaszczyzny odpowiedzialności:

1. Płaszczyzna techniczna
   Dostawca powinien zapewnić, aby jego środowisko spełniało wymagania art. 9 DORA oraz właściwych RTS w zakresie bezpieczeństwa i odporności ICT, w szczególności w obszarach: zarządzania tożsamością i dostępem (IAM), stosowania odpowiednich mechanizmów uwierzytelniania, szyfrowania danych, zapewnienia wysokiej dostępności i planów odtwarzania (DR), a także monitorowania i obsługi incydentów związanych z ICT.
2. Płaszczyzna kontraktowa
   Wzorce umów oferowane podmiotom finansowym powinny odpowiadać minimalnym wymaganiom art. 30 DORA oraz rozporządzenia delegowanego 2024/1773, obejmując w szczególności: precyzyjne postanowienia dotyczące zakresu usług i parametrów SLA, kluczowych wymogów w zakresie bezpieczeństwa, zasad korzystania z podwykonawców (sub‑outsourcing), praw dostępu i audytu po stronie klienta oraz warunków zakończenia współpracy i migracji usług (exit).
3. Płaszczyzna dokumentacyjna i informacyjna
   Dostawca powinien być przygotowany do przekazywania podmiotom finansowym informacji niezbędnych do wypełnienia ich obowiązków regulacyjnych, w szczególności: danych do rejestru umów z dostawcami usług ICT, informacji wykorzystywanych w procesie oceny ryzyka (w tym danych o podwykonawcach), informacji związanych z incydentami ICT oraz materiałów potwierdzających przeprowadzenie testów odporności.

‍