Vendor management dostaje zapotrzebowanie: senior Java do zespołu platformy płatności, rozliczenie T&M, start za dwa tygodnie. Umowa ramowa z dostawcą sprzed kilku lat ma NDA, klauzulę RODO i przeniesienie praw autorskich. Zakupy pytają o stawkę. Zespół third-party risk pyta o coś innego: czy to „usługa ICT” w rozumieniu DORA, czy wspiera funkcję krytyczną lub istotną, kto faktycznie świadczy pracę – pracownik dostawcy czy kontraktor B2B – i czy umowa zawiera postanowienia z art. 30. Jeśli odpowiedzi nie ma w dokumentach, start się przesuwa albo dostawca odpada.
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA) stosuje się od 17 stycznia 2025 r. (art. 64). Obowiązki z rozdziału V – zarządzanie ryzykiem ze strony zewnętrznych dostawców usług ICT – ciążą na podmiocie finansowym. Bank lub ubezpieczyciel pozostaje w pełni odpowiedzialny za zgodność także wtedy, gdy korzysta z usług zewnętrznych (art. 28 ust. 1 lit. a). W praktyce te obowiązki trafiają jednak do dostawcy przez umowę i due diligence. Poniżej rozkładamy je na to, co realnie zmienia się w body leasingu.
Czy body leasing to usługa ICT?
Art. 3 pkt 21 definiuje usługi ICT jako usługi cyfrowe i usługi w zakresie danych świadczone za pośrednictwem systemów ICT na rzecz użytkowników wewnętrznych lub zewnętrznych w sposób ciągły (z wyłączeniem tradycyjnych analogowych usług telefonicznych). W odpowiedzi opublikowanej w bazie Q&A EIOPA (DORA030-2999) Komisja Europejska podkreśla, że definicja celowo ma szeroki zakres, a ocenę, czy konkretna usługa jest usługą ICT, przeprowadza sam podmiot finansowy.
Praktyczną wskazówką jest zamknięta lista typów usług w załączniku III do rozporządzenia wykonawczego Komisji (UE) 2024/2956 (wzory rejestru informacji). Są na niej m.in. S01 – zarządzanie projektami ICT, S02 – rozwój ICT (analiza biznesowa, projektowanie i wytwarzanie oprogramowania, testy), S04 – zarządzanie bezpieczeństwem ICT oraz S15 – doradztwo ICT. Specjalista, który w sposób ciągły pisze, testuje lub utrzymuje oprogramowanie w systemach banku, mieści się w tych kategoriach. Forma rozliczenia – godzinowa czy ryczałtowa – nie wyłącza umowy z rozdziału V.
⚡ Dwa niezależne testy: usługa ICT i funkcja krytyczna lub istotna
Test 1 – usługa ICT (art. 3 pkt 21) decyduje, czy umowa trafia do rejestru informacji i musi zawierać minimalne postanowienia z art. 30 ust. 2. Test 2 – funkcja krytyczna lub istotna (art. 3 pkt 22: funkcja, której zakłócenie istotnie osłabiłoby wyniki finansowe, solidność lub ciągłość usług albo zgodność z warunkami zezwolenia) decyduje, czy dochodzą wymogi wzmocnione: strategia wyjścia (art. 28 ust. 8), ocena ryzyka koncentracji (art. 29) i dodatkowe klauzule z art. 30 ust. 3. Oba testy przeprowadza bank, nie dostawca.
Ten sam profil – np. senior backend developer – może trafić do dwóch różnych reżimów. Przy systemie rozliczeń płatności zwykle będzie wspierał funkcję krytyczną lub istotną, przy wewnętrznym narzędziu HR często nie. Stawka godzinowa bywa podobna (orientacyjne widełki zebraliśmy w zestawieniu stawek body leasingu IT w 2026 r.), ale pakiet umowny, zakres due diligence i wpis do rejestru już nie.
Łańcuch: kontraktor B2B → dostawca → bank
Art. 3 pkt 18 definiuje ryzyko ze strony zewnętrznych dostawców usług ICT jako ryzyko związane z usługami świadczonymi przez dostawców „lub przez ich podwykonawców”. W polskim body leasingu specjalista często nie jest pracownikiem dostawcy, tylko kontraktorem B2B. Dla banku to dodatkowe ogniwo łańcucha, które musi być widoczne.
Przy usługach wspierających funkcje krytyczne lub istotne art. 29 ust. 2 każe bankowi zważyć korzyści i ryzyka dalszego podwykonawstwa – zwłaszcza gdy podwykonawca ma siedzibę w państwie trzecim – oraz ocenić, czy długie lub złożone łańcuchy nie ograniczą monitorowania funkcji i nadzoru sprawowanego przez organ. Elementy tej oceny doprecyzowuje rozporządzenie delegowane Komisji (UE) 2025/532 (RTS w sprawie podwykonawstwa, obowiązuje od 22 lipca 2025 r.). Z kolei art. 30 ust. 2 lit. b wymaga wskazania w umowie regionów lub państw, w których usługi są świadczone i dane przetwarzane, oraz uprzedniego powiadomienia banku o planowanej zmianie. Specjalista, który zaczyna pracować zdalnie z innego kraju, to dokładnie taka zmiana.
Przed podpisaniem umowy: art. 28 i art. 29
Art. 28 ust. 4 wymaga, by przed zawarciem umowy bank: (a) ocenił, czy usługa wspiera funkcję krytyczną lub istotną, (b) sprawdził, czy spełnione są nadzorcze warunki zawarcia umowy, (c) zidentyfikował i ocenił istotne ryzyka, w tym ryzyko koncentracji, (d) przeprowadził due diligence dostawcy i upewnił się, że jest on odpowiedni, oraz (e) zidentyfikował konflikty interesów.
Art. 28 ust. 5 dopuszcza umowy wyłącznie z dostawcami stosującymi odpowiednie standardy bezpieczeństwa informacji, a przy funkcjach krytycznych lub istotnych – z należytym uwzględnieniem najbardziej aktualnych i najwyższej jakości standardów. Rozporządzenie nie wymienia z nazwy ISO/IEC 27001 ani SOC 2. Jakich dowodów oczekuje, bank określa we własnej polityce, której treść dla usług wspierających funkcje krytyczne lub istotne precyzuje rozporządzenie delegowane Komisji (UE) 2024/1773 z 13 marca 2024 r. (RTS do art. 28 ust. 10).
Art. 29 ust. 1 dodaje ocenę ryzyka koncentracji: czy dostawca jest łatwo zastępowalny i czy bank nie kumuluje wielu umów na usługi wspierające funkcje krytyczne lub istotne u jednego dostawcy albo u dostawców ściśle powiązanych. W body leasingu to bardzo praktyczne pytanie: ile ról krytycznych obsadza ten sam vendor i co się stanie, jeśli zniknie z rynku.
Rejestr informacji (art. 28 ust. 3)
Bank prowadzi i aktualizuje rejestr informacji o wszystkich ustaleniach umownych dotyczących usług ICT – nie tylko krytycznych – z rozróżnieniem umów wspierających funkcje krytyczne lub istotne i pozostałych. Co najmniej raz w roku raportuje organowi m.in. liczbę nowych ustaleń, kategorie dostawców i rodzaje umów, a pełny rejestr udostępnia na żądanie. O planowanym ustaleniu dotyczącym funkcji krytycznej lub istotnej informuje organ z odpowiednim wyprzedzeniem.
Wzory rejestru określa rozporządzenie wykonawcze Komisji (UE) 2024/2956 z 29 listopada 2024 r. W Polsce KNF wskazała LEI jako wymagany identyfikator podmiotu prowadzącego rejestr, a rejestry przekazywano formularzem SPR-PF-18 (II etap w maju 2025 r. objął m.in. podmioty, które nie złożyły rejestru do 28 kwietnia 2025 r., oraz rejestry odrzucone podczas weryfikacji po stronie EBA). Według zestawienia obowiązków sprawozdawczych KNF planowane ustalenie umowne na usługi wspierające funkcje krytyczne lub istotne zgłasza się formularzem SPR-PF-19 w terminie 14 dni przed związaniem się umową.
Dla dostawcy wynikają z tego dwie rzeczy. Kwestionariusz od banku będzie pytał o dane do rejestru: identyfikator firmy, typ usługi z listy S01–S19, lokalizacje świadczenia i przetwarzania danych oraz podwykonawców w łańcuchu. A przy rolach krytycznych „start od poniedziałku” jest nierealny, jeśli formalności nie ruszą równolegle z rekrutacją.
Strategia wyjścia (art. 28 ust. 8)
Dla usług ICT wspierających funkcje krytyczne lub istotne bank musi mieć strategie wyjścia uwzględniające m.in. awarię dostawcy, pogorszenie jakości usług, zakłócenie działalności i rozwiązanie umowy w przypadkach z art. 28 ust. 7. Wyjście ma być możliwe bez zakłócenia działalności, bez ograniczenia zgodności z wymogami regulacyjnymi i bez szkody dla ciągłości i jakości usług dla klientów. Plany wyjścia muszą być kompleksowe, udokumentowane, odpowiednio przetestowane i okresowo przeglądane.
W body leasingu ryzyko wyjścia ma bardzo konkretną postać: odejście kluczowego seniora, choroba, wypowiedzenie kontraktu B2B. Bank oczekuje więc planu zastępstwa (w jakim czasie i w jaki sposób pojawi się następca), okresu nakładania się (shadowing) i dokumentacji, która zostaje po stronie banku – w repozytorium, wiki i ticketach, a nie na laptopie specjalisty. Art. 28 ust. 8 sięga jednak dalej niż wymiana osoby: bank musi być w stanie zakończyć całą współpracę z dostawcą i przejąć prace samodzielnie albo przekazać je innemu podmiotowi.
Art. 30: co musi znaleźć się w umowie
Art. 30 ust. 1 wymaga jasnego, pisemnego podziału praw i obowiązków. Pełna umowa, łącznie z umowami o poziomie usług, ma stanowić jeden dokument – papierowy albo w innym trwałym, możliwym do pobrania formacie. Ust. 2 wymienia minimalne elementy każdej umowy na usługi ICT, a ust. 3 – elementy dodatkowe dla usług wspierających funkcje krytyczne lub istotne.
| Element | Ust. 2 – każda umowa na usługi ICT | Ust. 3 – dodatkowo przy funkcji krytycznej lub istotnej |
|---|---|---|
| Opis usług | Pełny opis funkcji i usług; informacja, czy dozwolone jest podwykonawstwo usługi wspierającej funkcję krytyczną lub istotną i na jakich warunkach (lit. a) | – |
| Lokalizacje | Regiony lub państwa świadczenia usług i przetwarzania danych, w tym przechowywania; uprzednie powiadomienie o zmianie (lit. b) | – |
| Ochrona danych | Dostępność, autentyczność, integralność i poufność danych, w tym osobowych (lit. c) | – |
| Dostęp do danych i ich zwrot | Dostęp, odzyskanie i zwrot danych w łatwo dostępnym formacie w razie niewypłacalności, restrukturyzacji lub zaprzestania działalności dostawcy albo rozwiązania umowy (lit. d) | – |
| Poziomy usług | Opisy poziomów usług wraz z aktualizacjami (lit. e) | Pełne opisy z precyzyjnymi ilościowymi i jakościowymi celami; działania naprawcze bez zbędnej zwłoki (lit. a) |
| Incydenty | Pomoc przy incydencie związanym z usługą – bez dodatkowych kosztów albo po koszcie ustalonym z góry (lit. f) | Okresy wypowiedzenia i obowiązki informacyjne dostawcy, w tym o zdarzeniach mogących istotnie wpłynąć na świadczenie usług (lit. b) |
| Organy | Pełna współpraca z właściwymi organami i organami ds. restrukturyzacji i uporządkowanej likwidacji (lit. g) | – |
| Rozwiązanie umowy | Prawa do rozwiązania umowy i minimalne okresy wypowiedzenia (lit. h) | – |
| Szkolenia | Warunki udziału dostawcy w programach podnoszenia świadomości i szkoleniach banku (lit. i, art. 13 ust. 6) | – |
| Ciągłość działania | – | Wdrożenie i testowanie planów awaryjnych oraz środków bezpieczeństwa ICT (lit. c) |
| TLPT | – | Udział i pełna współpraca w testach penetracyjnych opartych na analizie zagrożeń (lit. d, art. 26–27) |
| Audyt | – | Nieograniczone prawa dostępu, inspekcji i audytu dla banku, wyznaczonej osoby trzeciej i organu (lit. e) |
| Wyjście | – | Strategie wyjścia z obowiązkowym okresem przejściowym, w którym dostawca nadal świadczy usługi (lit. f) |
Dwie rzeczy łatwo przeoczyć. Prawo audytu z ust. 3 lit. e musi być wykonalne – nie może go ograniczać inna umowa ani wewnętrzna polityka dostawcy. Obowiązek pomocy przy incydencie (ust. 2 lit. f) dotyczy z kolei każdej umowy na usługi ICT, nie tylko krytycznych. Jak przełożyć te wymogi na umowę ramową i SOW bez utraty kontroli nad IP i kosztami, opisujemy w tekstach o negocjowaniu umów z firmami programistycznymi i transparentnym body leasingu.
Incydenty ICT: kto co zgłasza (art. 17–19)
Proces zarządzania incydentami (art. 17), ich klasyfikacja (art. 18) i zgłaszanie poważnych incydentów organowi (art. 19) to obowiązki podmiotu finansowego. Art. 19 ust. 4 przewiduje trzy etapy: wstępne powiadomienie, sprawozdanie pośrednie i sprawozdanie końcowe. Bank może zlecić raportowanie stronie trzeciej, ale nadal w pełni za nie odpowiada (art. 19 ust. 5). W Polsce poważne incydenty ICT zgłasza się przez system KNF dostępny pod adresem csirt.knf.gov.pl.
Firma body leasingowa nie zgłasza więc incydentu do KNF w imieniu banku. Jej zadaniem jest natychmiast powiadomić bank, gdy specjalista wykryje incydent związany z usługą albo się do niego przyczyni, dostarczyć fakty potrzebne do klasyfikacji i udzielić pomocy z art. 30 ust. 2 lit. f. W umowie i w onboardingu specjalisty powinna być zapisana konkretna ścieżka: kogo powiadomić, jakim kanałem i w jakim czasie. Przy rolach stricte bezpieczeństwa zob. też body leasing specjalistów cybersecurity.
Checklista due diligence dostawcy specjalistów IT
Poniższa lista porządkuje pytania, które warto zadać dostawcy przed podpisaniem umowy. To roboczy zestaw kontrolny, a nie zamiennik polityki banku.
| Co sprawdzić | Czego oczekiwać od dostawcy | Podstawa |
|---|---|---|
| Czy to usługa ICT i jakiego typu | Opis roli, systemów i trybu pracy; przypisanie do typu S01–S19 | Art. 3 pkt 21; ITS 2024/2956, zał. III |
| Czy usługa wspiera funkcję krytyczną lub istotną | Klasyfikuje bank; dostawca deklaruje gotowość przyjęcia klauzul z ust. 3 | Art. 28 ust. 4 lit. a; art. 3 pkt 22 |
| Łańcuch podwykonawstwa | Forma współpracy ze specjalistą (etat lub B2B), podmiot, kraj; zasady dalszego podzlecania | Art. 29 ust. 2; art. 30 ust. 2 lit. a; RTS 2025/532 |
| Lokalizacje | Kraj pracy i przetwarzania danych; procedura zgłaszania zmiany | Art. 30 ust. 2 lit. b |
| Bezpieczeństwo informacji | Polityka bezpieczeństwa, NDA, zasady dostępu; praca wyłącznie na środowiskach zaakceptowanych przez bank | Art. 28 ust. 5; art. 30 ust. 2 lit. c |
| Dane do rejestru | Identyfikator firmy (np. LEI), dane rejestrowe, pozycja w łańcuchu | Art. 28 ust. 3; ITS 2024/2956 |
| Incydenty | Ścieżka powiadomienia; koszt pomocy w cenie albo ustalony z góry | Art. 30 ust. 2 lit. f; art. 17–19 |
| Szkolenia | Zgoda na udział specjalistów w programach świadomości banku | Art. 13 ust. 6; art. 30 ust. 2 lit. i |
| Zastępstwo i wiedza | Plan zastępstwa, okres nakładania się, dokumentacja po stronie banku | Art. 28 ust. 8 |
| Audyt, TLPT, wyjście | Gotowość do audytu i testów; świadczenie usług w okresie przejściowym | Art. 28 ust. 6; art. 30 ust. 3 lit. d–f |
Body leasing, team leasing, outsourcing: gdzie DORA rozkłada akcenty
DORA dotyczy każdego z tych modeli. Różnią się tym, kto odpowiada za wynik pracy, jak wygląda koncentracja i co w praktyce oznacza wyjście. Szczegóły modeli opisujemy na stronach modele współpracy i leasing zespołów IT.
| Model | Kto kieruje pracą | Ryzyko koncentracji (art. 29) | Umowa (art. 30) | Wyjście w praktyce |
|---|---|---|---|---|
| Body leasing / T&M | Bank; dostawca odpowiada za osobę, łańcuch i zastępstwo | Rośnie, gdy jeden dostawca obsadza wiele ról krytycznych | Zawsze ust. 2; ust. 3, gdy rola wspiera funkcję krytyczną lub istotną | Zastępstwo osoby lub przejęcie roli przez bank |
| Team leasing | Dostawca organizuje skład i rytm pracy; bank wyznacza cele | Wyższe – wiele ról u jednego dostawcy (art. 29 ust. 1 lit. b) | Ust. 2; przy funkcji krytycznej ust. 3 (SLA, audyt, TLPT, okres przejściowy) | Przekazanie całego zespołu i wiedzy |
| Outsourcing / managed service | Dostawca odpowiada za wynik lub utrzymanie usługi | Wysokie przy niskiej zastępowalności i podwykonawcach w państwach trzecich | Ust. 2 i zwykle ust. 3 | Migracja usługi i danych do innego dostawcy lub in-house |
Anty-wzorce
- „To tylko wynajem ludzi, DORA dotyczy chmury”. Definicja z art. 3 pkt 21 i typy S01–S19 obejmują wytwarzanie oprogramowania, testy, bezpieczeństwo i doradztwo ICT. Rozliczenie T&M niczego tu nie zmienia.
- Ukryty łańcuch B2B. Agencja podpisuje umowę ramową, a na projekcie pracuje kontraktor kolejnego pośrednika. Bank nie wie, kto świadczy usługę, więc nie może rzetelnie ocenić podwykonawstwa (art. 29 ust. 2) ani poprawnie wypełnić rejestru.
- Brak planu zastępstwa. Wiedza o potoku wdrożeniowym istnieje tylko w głowie jednego seniora. Przy funkcjach krytycznych art. 28 ust. 8 oraz art. 30 ust. 3 lit. c i f wymagają planów awaryjnych i okresu przejściowego – deklaracja „dołożymy starań” ich nie zastąpi.
- Audyt tylko na papierze. Klauzula audytu jest w załączniku, ale wewnętrzna polityka dostawcy nie przewiduje wpuszczenia audytora. Art. 30 ust. 3 lit. e wymaga, by wykonywanie tych praw nie było ograniczone innymi postanowieniami.
Jak pracuje Commoditech
Commoditech od 2012 r. dostarcza specjalistów IT w modelu body leasingu i contractingu. Nie klasyfikujemy funkcji za bank i nie prowadzimy jego rejestru – to obowiązki podmiotu finansowego. Naszą rolą jest być dostawcą, którego da się rzetelnie ocenić, wpisać do rejestru i audytować:
- Jawna marża – klient wie, jaka część stawki trafia do specjalisty, a jaka do dostawcy (jak działa transparentny body leasing).
- Przeniesienie 100% autorskich praw majątkowych do wytworzonego kodu na klienta.
- Weryfikowani specjaliści – weryfikacja techniczna przed przedstawieniem profilu.
- Jawny łańcuch podwykonawstwa – informacja o formie współpracy i kraju pracy specjalisty oraz gotowość do zapisu o zakazie dalszego podzlecania bez zgody banku.
- Gotowość do klauzul z art. 30 – ust. 2 w każdej umowie, ust. 3 tam, gdzie bank zakwalifikuje usługę jako wspierającą funkcję krytyczną lub istotną.
- Plan zastępstwa i przekazania wiedzy zapisany w umowie, a nie deklarowany ustnie.
- Współpraca przy audytach i testach prowadzonych przez bank, wyznaczony przez niego podmiot lub organ nadzoru.
Nie deklarujemy certyfikatów, których nie mamy. Jeśli polityka banku wymaga od dostawcy konkretnej certyfikacji, mówimy o tym wprost na etapie kwalifikacji. Jeśli przygotowujecie zapotrzebowanie na specjalistów do środowiska objętego DORA, napiszcie do nas – zaczniemy od listy danych potrzebnych do Waszego rejestru i due diligence.
🛠️ Z praktyki: jak wygląda rozmowa o DORA przy zamówieniu specjalisty
Typowy scenariusz, bez nazw i liczb. Dział zakupów przesyła zapotrzebowanie na seniora backend do systemu, który bank klasyfikuje jako wspierający funkcję krytyczną lub istotną. Równolegle zespół third-party risk wysyła kwestionariusz: typ usługi ICT, lokalizacje świadczenia i przetwarzania danych, lista podwykonawców, ścieżka zgłaszania incydentów, prawa audytu, okres przejściowy przy wyjściu, udział w szkoleniach z bezpieczeństwa.
Odpowiedź „pracujemy w T&M, reszta jak w umowie ramowej” zwykle kończy rozmowę, zanim zacznie się weryfikacja kandydatów. Dostawca, który od razu pokazuje łańcuch (np. kontraktor B2B z Polski, bez dalszego podzlecania), miejsce pracy, gotowe klauzule z art. 30 ust. 3 i plan zastępstwa w SOW, przechodzi do właściwej oceny kompetencji. DORA nie zastępuje rozmowy technicznej – ustawia bramkę, bez której ta rozmowa się nie zaczyna.
FAQ
Czy każda umowa body leasingu IT z bankiem to usługa ICT w rozumieniu DORA?
Ocena należy do podmiotu finansowego, a definicja z art. 3 pkt 21 jest celowo szeroka. Załącznik III do ITS 2024/2956 obejmuje m.in. rozwój ICT (S02), bezpieczeństwo ICT (S04) i doradztwo ICT (S15), więc praca specjalisty w systemach banku w sposób ciągły zwykle mieści się w tej definicji.
Kiedy umowa T&M na jedną osobę wymaga klauzul z art. 30 ust. 3?
Gdy usługa wspiera funkcję krytyczną lub istotną (art. 3 pkt 22). Liczba osób nie ma znaczenia: ust. 2 obowiązuje w każdej umowie na usługi ICT, a ust. 3 dochodzi zawsze, gdy bank zakwalifikuje funkcję jako krytyczną lub istotną.
Czy kontraktor B2B dostawcy to podwykonawca, o którym bank musi wiedzieć?
Jeśli to on faktycznie świadczy usługę – tak. Art. 3 pkt 18 obejmuje ryzyko związane z podwykonawcami dostawcy, a przy funkcjach krytycznych lub istotnych art. 29 ust. 2, art. 30 ust. 2 lit. a i RTS 2025/532 wymagają oceny i uregulowania podwykonawstwa.
Kto zgłasza poważny incydent ICT do KNF – bank czy firma body leasingowa?
Podmiot finansowy (art. 19), przez system KNF pod adresem csirt.knf.gov.pl. Dostawca powiadamia bank i pomaga w obsłudze incydentu (art. 30 ust. 2 lit. f). Bank może zlecić raportowanie stronie trzeciej, ale odpowiedzialność pozostaje po jego stronie (art. 19 ust. 5).
Czy dostawca specjalistów musi mieć ISO 27001, żeby współpracować z bankiem?
DORA nie wymaga konkretnego certyfikatu. Art. 28 ust. 5 mówi o odpowiednich standardach bezpieczeństwa informacji, a szczegółowe oczekiwania określa polityka banku – może ona wymagać certyfikatu, audytu albo innych dowodów. Brak jakichkolwiek udokumentowanych zasad bezpieczeństwa i gotowości do audytu w praktyce wyklucza dostawcę.
Źródła
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA) – EUR-Lex
- Rozporządzenie wykonawcze Komisji (UE) 2024/2956 (wzory rejestru informacji, zał. III – typy usług ICT) – EUR-Lex
- Rozporządzenie delegowane Komisji (UE) 2024/1773 (RTS – polityka umów na usługi ICT wspierające funkcje krytyczne lub istotne) – EUR-Lex
- Rozporządzenie delegowane Komisji (UE) 2025/532 (RTS – podwykonawstwo usług ICT wspierających funkcje krytyczne lub istotne) – EUR-Lex; EBA
- KNF – DORA; rejestr informacji i LEI; II etap przekazywania rejestrów (SPR-PF-18); zestawienie obowiązków sprawozdawczych; systemy DORA i zgłaszanie incydentów
- EIOPA – Q&A DORA030-2999 (definicja usług ICT); DORA
- EBA – DORA
- ESMA – DORA
Artykuł ma charakter informacyjny i nie stanowi porady prawnej. Klasyfikacja usługi ICT i funkcji krytycznej lub istotnej, treść umowy oraz wpis do rejestru zależą od konkretnych okoliczności i od polityki podmiotu finansowego. Wiążący jest tekst rozporządzenia, aktów wykonawczych i stanowiska organu nadzoru (w Polsce – KNF).