Umowa outsourcingu IT zgodna z DORA – jakie postanowienia powinna zawierać?

Outsourcing IT jest obecnie jednym z podstawowych elementów funkcjonowania sektora finansowego. Banki, instytucje płatnicze, firmy inwestycyjne, zakłady ubezpieczeń, podmioty działające na rynku kryptoaktywów oraz inni uczestnicy rynku finansowego korzystają z zewnętrznych dostawców chmury obliczeniowej, hostingu, centrów danych, oprogramowania, cyberbezpieczeństwa, wsparcia technicznego, utrzymania infrastruktury oraz przetwarzania danych.

Korzystanie z zewnętrznego dostawcy nie oznacza jednak, że odpowiedzialność za bezpieczeństwo systemów, ciągłość działania i zgodność z przepisami zostaje przeniesiona na firmę informatyczną. Podmiot finansowy nadal odpowiada za prawidłowe zarządzanie ryzykiem związanym z technologiami informacyjno-komunikacyjnymi, nawet jeżeli zdecydowana większość infrastruktury technicznej znajduje się poza jego organizacją.

Od 17 stycznia 2025 r. zasady te wynikają przede wszystkim z rozporządzenia Parlamentu Europejskiego i Rady (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego, określanego jako DORA. Rozporządzenie ustanawia jednolite wymagania dotyczące zarządzania ryzykiem ICT, obsługi incydentów, testowania odporności cyfrowej oraz korzystania z usług zewnętrznych dostawców technologii.

DORA wpływa bezpośrednio na sposób przygotowywania, zawierania i wykonywania umów outsourcingu IT. Dotychczasowa umowa zawierająca jedynie ogólny opis usługi, wysokość wynagrodzenia, podstawowe parametry SLA oraz standardowe zasady odpowiedzialności może być niewystarczająca. W wielu przypadkach konieczne jest szczegółowe uregulowanie audytów, incydentów, lokalizacji danych, korzystania z podwykonawców, ciągłości działania, odzyskiwania danych, współpracy z organami nadzoru oraz bezpiecznego zakończenia współpracy.

Najbardziej rozbudowane wymagania odnoszą się do umów obejmujących usługi ICT wspierające krytyczne lub istotne funkcje podmiotu finansowego. Taka umowa powinna nie tylko określać sposób bieżącej realizacji usługi, lecz również zapewniać instytucji finansowej faktyczną możliwość kontrolowania dostawcy, reagowania na zagrożenia oraz przeniesienia usług do innego podmiotu, jeżeli dalsza współpraca stanie się niemożliwa albo niezgodna z prawem.

Czym jest DORA?

DORA, czyli Digital Operational Resilience Act, jest unijnym rozporządzeniem dotyczącym operacyjnej odporności cyfrowej sektora finansowego. Jego podstawowym celem jest zapewnienie, aby podmioty finansowe były zdolne do zapobiegania zakłóceniom technologicznym, odpowiedniego reagowania na incydenty, ograniczania ich skutków oraz szybkiego przywracania prawidłowego funkcjonowania usług.

Rozporządzenie reguluje zarządzanie ryzykiem ICT, zgłaszanie poważnych incydentów, testowanie operacyjnej odporności cyfrowej, zarządzanie ryzykiem wynikającym z korzystania z zewnętrznych dostawców usług technologicznych oraz nadzór nad dostawcami uznanymi za krytycznych dla europejskiego sektora finansowego.

DORA jest stosowana od 17 stycznia 2025 r. Oznacza to, że podmioty objęte regulacją powinny już posiadać odpowiednie ramy zarządzania ryzykiem ICT, procedury wewnętrzne, rejestry umów oraz dostosowane ustalenia kontraktowe z dostawcami technologii.

Rozporządzenie nie jest wyłącznie regulacją dotyczącą cyberataków. Obejmuje ono także awarie techniczne, błędy oprogramowania, niewłaściwe zarządzanie zmianą, niedostępność dostawcy, utratę danych, awarie centrów danych oraz inne zdarzenia mogące zakłócić świadczenie usług finansowych.

Jakich podmiotów dotyczy DORA?

Zakres podmiotowy DORA jest szeroki. Rozporządzenie obejmuje między innymi banki, instytucje płatnicze, instytucje pieniądza elektronicznego, firmy inwestycyjne, dostawców usług związanych z kryptoaktywami, zarządzających funduszami, zakłady ubezpieczeń i reasekuracji, niektórych pośredników ubezpieczeniowych, instytucje pracowniczych programów emerytalnych, agencje ratingowe, administratorów kluczowych wskaźników referencyjnych oraz dostawców usług finansowania społecznościowego.

DORA ma jednak znaczenie również dla firm technologicznych, które same nie są instytucjami finansowymi. Dostawca usług chmurowych, oprogramowania, hostingu, utrzymania systemów lub cyberbezpieczeństwa może nie być bezpośrednio objęty wszystkimi obowiązkami rozporządzenia, ale w praktyce będzie musiał zaakceptować wymagania kontraktowe narzucone przez klienta z sektora finansowego.

Właśnie dlatego DORA wpływa na cały rynek usług IT świadczonych na rzecz sektora finansowego. Firma technologiczna, która nie jest gotowa udzielić klientowi odpowiednich praw audytowych, informować o incydentach, wskazać lokalizacji przetwarzania danych albo ujawnić łańcucha podwykonawców, może mieć trudności z zawarciem umowy z regulowanym podmiotem finansowym.

Czy każda usługa IT jest outsourcingiem?

DORA posługuje się pojęciem ustaleń umownych dotyczących korzystania z usług ICT. Jest ono szersze niż tradycyjnie rozumiany outsourcing, który najczęściej kojarzony jest z przekazaniem całego procesu lub funkcji zewnętrznemu usługodawcy.

Usługą ICT może być między innymi hosting, przetwarzanie danych, przechowywanie danych w chmurze, utrzymanie systemu, wsparcie techniczne, administrowanie infrastrukturą, monitoring bezpieczeństwa, wykonywanie kopii zapasowych, rozwój aplikacji, zarządzanie tożsamością, dostarczanie oprogramowania w modelu SaaS albo świadczenie usług telekomunikacyjnych.

Nie każda umowa zakupu sprzętu lub pojedynczej licencji musi podlegać wszystkim wymaganiom DORA. Jeżeli jednak dostawca w sposób ciągły świadczy usługę technologiczną wykorzystywaną przez podmiot finansowy w jego działalności, umowa powinna zostać przeanalizowana pod kątem rozporządzenia.

O kwalifikacji prawnej nie decyduje nazwa dokumentu. Umowa nazwana licencją, zamówieniem, umową serwisową albo umową wsparcia może podlegać wymaganiom DORA, jeżeli w praktyce dostawca zapewnia usługę technologiczną, od której zależy prawidłowe funkcjonowanie podmiotu finansowego.

Funkcja krytyczna lub istotna

Szczególne znaczenie dla zakresu obowiązków umownych ma ustalenie, czy dana usługa ICT wspiera funkcję krytyczną lub istotną. Jest to funkcja, której zakłócenie w sposób istotny wpłynęłoby na wyniki finansowe podmiotu, ciągłość albo prawidłowość świadczonych przez niego usług, a także na możliwość dalszego przestrzegania warunków zezwolenia lub innych obowiązków regulacyjnych.

Do takich funkcji mogą należeć systemy bankowości elektronicznej, systemy płatnicze, platformy inwestycyjne, systemy obsługi polis, infrastruktura uwierzytelniania klientów, systemy przeciwdziałania praniu pieniędzy, systemy księgowe i rozliczeniowe, główne bazy danych klientów, usługi kopii zapasowych oraz podstawowa infrastruktura chmurowa.

Ocena znaczenia funkcji powinna być dokonywana indywidualnie. To samo rozwiązanie może pełnić rolę pomocniczą w jednej organizacji, a w innej stanowić kluczowy element procesu biznesowego. System CRM może mieć niewielkie znaczenie dla podmiotu, który wykorzystuje go wyłącznie do zarządzania kontaktami, ale może być krytyczny dla przedsiębiorstwa, którego cały proces sprzedaży, obsługi klienta i realizacji obowiązków informacyjnych opiera się na tym narzędziu.

Oceny powinien dokonać podmiot finansowy, uwzględniając własny model działalności, liczbę klientów, zależności technologiczne, możliwość zastąpienia systemu oraz skutki jego niedostępności. Nie powinien on bezkrytycznie opierać się na deklaracji dostawcy, że dana usługa nie ma charakteru krytycznego.

Odpowiedzialność pozostaje po stronie podmiotu finansowego

Jedną z podstawowych zasad DORA jest to, że zlecenie usługi zewnętrznemu dostawcy nie zwalnia podmiotu finansowego z odpowiedzialności za zgodność z regulacjami.

Zarząd instytucji finansowej nie może uznać, że skoro infrastruktura znajduje się w chmurze, to za jej bezpieczeństwo odpowiada wyłącznie dostawca. Podmiot finansowy nadal powinien rozumieć ryzyko, znać architekturę usługi w zakresie niezbędnym do zarządzania tym ryzykiem, monitorować działanie systemu, reagować na incydenty oraz posiadać realną możliwość zakończenia współpracy.

Odpowiedzialność ta obejmuje również sytuacje, w których główny dostawca korzysta z dalszych podwykonawców. Podmiot finansowy powinien posiadać wiedzę o tym, które elementy usługi są przekazywane kolejnym firmom, gdzie znajdują się dane i kto faktycznie uczestniczy w świadczeniu usługi.

Nie wystarczy zatem zawarcie rozbudowanej umowy i umieszczenie w niej deklaracji, że dostawca odpowiada za bezpieczeństwo. Podmiot finansowy musi również prowadzić bieżący monitoring i dysponować odpowiednimi zasobami umożliwiającymi nadzór nad usługą.

Analiza przed zawarciem umowy outsourcingu IT

Prawidłowe wdrożenie DORA nie zaczyna się od przygotowania wzoru umowy. Jeszcze przed wyborem dostawcy podmiot finansowy powinien dokonać oceny planowanej usługi, jej znaczenia oraz ryzyka związanego z jej powierzeniem zewnętrznemu podmiotowi.

Analiza powinna obejmować znaczenie wspieranej funkcji, ryzyko operacyjne i cybernetyczne, możliwość utraty albo ujawnienia danych, ryzyko prawne, ryzyko koncentracji, możliwość zastąpienia dostawcy oraz lokalizację świadczenia usług.

Należy również zweryfikować kondycję finansową dostawcy, jego doświadczenie, reputację, zasoby kadrowe i techniczne, sposób zarządzania bezpieczeństwem, zdolność do obsługi incydentów, stosowane standardy, posiadane certyfikaty oraz zakres korzystania z podwykonawców.

W przypadku usługi wspierającej funkcję krytyczną lub istotną analiza powinna być szczególnie dokładna. Podmiot finansowy powinien ocenić, czy dostawca posiada nie tylko odpowiednią technologię, lecz również strukturę organizacyjną, procedury, personel i mechanizmy kontroli umożliwiające ciągłe oraz bezpieczne świadczenie usługi.

Należy ponadto uwzględnić ryzyko uzależnienia od dostawcy. Rozwiązanie może być atrakcyjne cenowo, ale jednocześnie zapisywać dane w zamkniętym formacie, wykorzystywać nietypową architekturę albo wymagać wielomiesięcznej migracji. Tego rodzaju zależność powinna zostać rozpoznana jeszcze przed zawarciem umowy.

Forma i struktura umowy

Prawa i obowiązki podmiotu finansowego oraz dostawcy ICT powinny zostać jasno określone na piśmie. Nie oznacza to, że wszystkie wymagania muszą znajdować się w jednym dokumencie.

Relację stron może regulować umowa główna, opis usług, SLA, umowa powierzenia przetwarzania danych, załącznik bezpieczeństwa, procedura reagowania na incydenty, wykaz podwykonawców, plan ciągłości działania oraz plan wyjścia. Dokumenty te powinny jednak tworzyć spójną całość.

Częstym problemem jest sprzeczność pomiędzy indywidualnie wynegocjowaną umową a standardowym regulaminem dostawcy. Umowa główna może przyznawać klientowi prawo do audytu, podczas gdy regulamin wyłącza możliwość przeprowadzenia inspekcji w centrum danych. W takim przypadku niezbędne jest określenie hierarchii dokumentów i wskazanie, które postanowienia mają pierwszeństwo.

Podmiot finansowy powinien także zachować pełną dokumentację umowną. Nie powinien polegać wyłącznie na regulaminach dostępnych na stronie internetowej dostawcy, ponieważ ich treść może zostać jednostronnie zmieniona.

Dokładny opis usług ICT

Umowa powinna zawierać precyzyjny i wyczerpujący opis świadczonych usług. Ogólne sformułowanie, zgodnie z którym dostawca będzie świadczył usługi informatyczne albo zapewniał wsparcie systemu, zazwyczaj nie pozwala prawidłowo ustalić zakresu odpowiedzialności stron.

Opis powinien wskazywać, jakie systemy są objęte usługą, jakie czynności wykonuje dostawca, jakie funkcje biznesowe są wspierane, jakie dane są przetwarzane, w jakich godzinach usługa jest dostępna oraz które obowiązki pozostają po stronie klienta.

Należy również ustalić zależności pomiędzy poszczególnymi komponentami. Usługa może być prezentowana jako jedno rozwiązanie, ale w rzeczywistości składać się z infrastruktury chmurowej, zewnętrznego narzędzia do uwierzytelniania, systemu monitorowania oraz biblioteki dostarczanej przez kolejny podmiot.

Precyzyjny opis jest niezbędny do oceny ryzyka, prowadzenia rejestru informacji, monitorowania SLA, ustalenia zakresu audytu oraz przygotowania planu migracji.

Lokalizacja świadczenia usług i danych

Umowa powinna wskazywać miejsca, w których usługi są świadczone, a dane przetwarzane i przechowywane. Informacja powinna obejmować zarówno podstawowe, jak i zapasowe centra danych.

Podmiot finansowy powinien wiedzieć, czy dane znajdują się w Polsce, w innym państwie Europejskiego Obszaru Gospodarczego, czy poza EOG. Lokalizacja ma znaczenie dla oceny jurysdykcji, możliwości kontroli, ryzyka politycznego, ochrony danych osobowych, dostępu organów państw trzecich oraz ciągłości działania.

Ogólne wskazanie, że dane są przetwarzane na terenie Unii Europejskiej, może nie być wystarczające. W określonych przypadkach podmiot finansowy będzie potrzebował informacji o konkretnym państwie, regionie albo centrum danych.

Dostawca powinien być zobowiązany do informowania o planowanej zmianie lokalizacji z odpowiednim wyprzedzeniem. Termin powinien umożliwić klientowi przeprowadzenie oceny ryzyka oraz zgłoszenie sprzeciwu, jeżeli nowa lokalizacja nie spełnia wymagań regulacyjnych albo zwiększa ryzyko operacyjne.

Bezpieczeństwo danych i systemów

Umowa powinna określać wymagania dotyczące dostępności, autentyczności, integralności i poufności danych. Powinna również regulować bezpieczeństwo transmisji, zarządzanie dostępami, rejestrowanie działań administratorów, aktualizowanie systemów, zarządzanie podatnościami oraz stosowanie kopii zapasowych.

Sformułowanie, że dostawca stosuje standardowe środki bezpieczeństwa albo rozwiązania zgodne z praktyką rynkową, może być zbyt ogólne. Umowa powinna wskazywać konkretny poziom ochrony adekwatny do znaczenia usługi i rodzaju przetwarzanych danych.

W praktyce wymagania mogą dotyczyć szyfrowania, uwierzytelniania wieloskładnikowego, segmentacji sieci, zarządzania uprzywilejowanymi kontami, testów penetracyjnych, zabezpieczania logów oraz terminowego usuwania podatności.

Podmiot finansowy powinien również uzyskać prawo do weryfikowania, czy środki bezpieczeństwa są utrzymywane przez cały okres obowiązywania umowy. Certyfikat przedstawiony przy podpisywaniu kontraktu nie daje gwarancji, że po kilku latach poziom ochrony będzie nadal odpowiedni.

Dostęp do danych i ich zwrot

Jednym z najważniejszych elementów umowy jest zapewnienie dostępu do danych również w sytuacji awarii, sporu albo zakończenia współpracy.

Umowa powinna regulować sposób odzyskiwania, zwrotu i przenoszenia danych w przypadku wypowiedzenia umowy, niewypłacalności dostawcy, zaprzestania przez niego działalności, awarii infrastruktury albo poważnego incydentu bezpieczeństwa.

Należy wskazać format danych, termin ich przekazania, sposób transmisji, zakres dokumentacji, okres przechowywania kopii oraz obowiązek ich bezpiecznego usunięcia po zakończeniu migracji.

Dane powinny zostać przekazane w formacie umożliwiającym ich rzeczywiste wykorzystanie. Eksport w formacie technicznym, który wymaga zakupu dodatkowego oprogramowania dostawcy albo nie pozwala na pełne odtworzenie relacji pomiędzy danymi, może być niewystarczający.

Szczególnej uwagi wymaga możliwość blokowania danych z powodu sporu dotyczącego wynagrodzenia. Przy usługach wspierających kluczowe procesy takie uprawnienie dostawcy powinno zostać wyłączone albo istotnie ograniczone, ponieważ utrata dostępu do danych może uniemożliwić podmiotowi finansowemu wykonywanie działalności.

Poziomy usług i SLA

Umowa outsourcingu IT powinna określać mierzalne poziomy świadczenia usług. SLA może dotyczyć dostępności systemu, czasu reakcji na zgłoszenie, czasu usunięcia awarii, wydajności, częstotliwości wykonywania kopii zapasowych, czasu odtworzenia danych oraz godzin dostępności wsparcia.

Parametry powinny być dostosowane do znaczenia usługi. System pomocniczy może mieć niższy wymagany poziom dostępności niż platforma płatnicza, której awaria bezpośrednio uniemożliwia klientom wykonywanie transakcji.

Należy zwrócić uwagę na sposób obliczania dostępności. Dostawca może wyłączać z kalkulacji planowane przerwy serwisowe, awarie podwykonawców, problemy po stronie infrastruktury sieciowej albo niedostępność obejmującą tylko określoną grupę użytkowników. W rezultacie formalny poziom SLA może być spełniony, mimo że usługa nie działa prawidłowo.

Umowa powinna także określać konsekwencje naruszeń. Mogą one obejmować obniżenie wynagrodzenia, service credits, kary umowne, obowiązek przedstawienia planu naprawczego, dodatkowy audyt albo prawo wypowiedzenia umowy.

Należy unikać klauzul, zgodnie z którymi service credits stanowią wyłączny środek przysługujący klientowi. Niewielki rabat na kolejny okres rozliczeniowy nie powinien wyłączać możliwości dochodzenia odszkodowania lub rozwiązania umowy w przypadku poważnej awarii.

Zgłaszanie incydentów ICT

Podmiot finansowy podlega szczególnym obowiązkom dotyczącym klasyfikowania i raportowania poważnych incydentów ICT. Aby mógł je zrealizować, musi otrzymać od dostawcy informację wystarczająco szybko.

Umowa powinna określać, jakie zdarzenia dostawca ma obowiązek zgłaszać, w jakim terminie powinno nastąpić pierwsze powiadomienie, jakimi kanałami przekazywane są informacje oraz kto odpowiada za komunikację po obu stronach.

Termin powinien być dostosowany do obowiązków podmiotu finansowego. Ogólne sformułowanie, że dostawca poinformuje o incydencie bez zbędnej zwłoki, może być zbyt nieprecyzyjne. W przypadku kluczowych systemów zasadne może być określenie maksymalnej liczby godzin od wykrycia zdarzenia.

Pierwsze powiadomienie nie musi zawierać pełnej analizy przyczyn. Powinno jednak umożliwić podmiotowi finansowemu ocenę potencjalnego wpływu zdarzenia, podjęcie działań zabezpieczających oraz wykonanie obowiązków wobec organów nadzoru.

Dostawca powinien następnie przekazywać regularne aktualizacje oraz przygotować raport końcowy obejmujący przyczynę incydentu, jego przebieg, wpływ na dane i usługi, zastosowane środki naprawcze oraz działania mające zapobiec podobnym zdarzeniom w przyszłości.

Współpraca przy obsłudze incydentu

Samo zgłoszenie awarii albo cyberataku nie wystarcza. Dostawca powinien aktywnie współpracować przy obsłudze zdarzenia.

Umowa powinna zobowiązywać go do zabezpieczenia logów i innych dowodów, udostępnienia specjalistów technicznych, udziału w analizie przyczyn, przekazania informacji potrzebnych do klasyfikacji incydentu oraz wsparcia przy komunikacji z organami.

W razie potrzeby dostawca powinien uczestniczyć w spotkaniach zespołu kryzysowego, przygotowywać dodatkowe raporty oraz wdrażać działania naprawcze w terminach uzgodnionych z klientem.

Warto również uregulować koszty reakcji. Jeżeli incydent wynika z naruszenia obowiązków dostawcy, podmiot finansowy może oczekiwać zwrotu uzasadnionych kosztów związanych z analizą techniczną, pomocą ekspertów, odtworzeniem danych, komunikacją z klientami oraz działaniami naprawczymi.

Ciągłość działania i odtwarzanie usług

Dostawca powinien posiadać rozwiązania zapewniające ciągłość świadczenia usług również w sytuacjach kryzysowych. Plan powinien uwzględniać awarię infrastruktury, cyberatak, utratę centrum danych, niedostępność kluczowego personelu, awarię zasilania, problemy telekomunikacyjne, niewypłacalność podwykonawcy oraz inne zdarzenia mogące zakłócić realizację usługi.

W przypadku funkcji krytycznych lub istotnych umowa powinna określać parametry odtworzeniowe. Recovery Time Objective wskazuje maksymalny czas, w którym usługa powinna zostać przywrócona. Recovery Point Objective określa maksymalną dopuszczalną utratę danych wyrażoną w czasie.

Parametry te powinny odpowiadać analizie wpływu na działalność przeprowadzonej przez podmiot finansowy. Jeżeli instytucja może tolerować jedynie kilkuminutową utratę danych, umowa nie powinna przewidywać wykonywania kopii zapasowej raz na dobę.

Dostawca powinien również regularnie testować plany ciągłości działania. Klient powinien otrzymywać informacje o zakresie testów, ich wynikach, stwierdzonych nieprawidłowościach oraz działaniach naprawczych.

Prawo audytu i kontroli

Jednym z najważniejszych wymagań DORA jest zapewnienie podmiotowi finansowemu skutecznego prawa dostępu, inspekcji i audytu.

W przypadku usług wspierających funkcje krytyczne lub istotne umowa powinna umożliwiać kontrolę przez podmiot finansowy, jego audytorów, właściwe organy oraz inne uprawnione podmioty.

Prawo audytu powinno obejmować dostęp do dokumentacji, informacji, systemów i pomieszczeń w zakresie niezbędnym do oceny usługi. Powinno również umożliwiać rozmowy z personelem, analizę procedur oraz weryfikację sposobu usuwania stwierdzonych uchybień.

Dostawcy często proponują zastąpienie audytu indywidualnego certyfikatem bezpieczeństwa albo raportem niezależnego audytora. Takie dokumenty mogą być użyteczne i w wielu przypadkach mogą ograniczyć potrzebę częstych kontroli, ale nie powinny całkowicie wyłączać prawa klienta oraz organu nadzoru do przeprowadzenia dodatkowego audytu.

Umowa może regulować terminy powiadomienia, zasady ochrony informacji innych klientów oraz sposób prowadzenia audytu, ale nie powinna wprowadzać warunków, które czynią prawo kontroli iluzorycznym. Nadmiernie wysokie opłaty, bardzo długie terminy oczekiwania albo całkowite wyłączenie dostępu do infrastruktury mogą być niezgodne z celem regulacji.

Współpraca z organami nadzoru

Dostawca powinien zobowiązać się do współpracy z właściwymi organami nadzoru oraz organami zajmującymi się restrukturyzacją i uporządkowaną likwidacją.

Współpraca może obejmować udzielanie informacji, przedstawianie dokumentacji, umożliwienie inspekcji, udostępnianie systemów oraz wykonywanie zaleceń dotyczących sposobu świadczenia usługi.

Umowa nie może uzależniać dostępu organu od swobodnej zgody dostawcy ani ograniczać go wyłącznie do dokumentów, które usługodawca sam uzna za odpowiednie. Nie powinna również ustanawiać nadmiernie długiego okresu uprzedniego powiadomienia, jeżeli charakter kontroli wymaga szybkiego działania.

Brak odpowiedniej klauzuli może prowadzić do sytuacji, w której podmiot finansowy nie jest w stanie wykonać obowiązku współpracy z nadzorcą z powodu ograniczeń zawartych w umowie z firmą IT.

Testy odporności i testy penetracyjne

Niektóre podmioty finansowe są zobowiązane do przeprowadzania zaawansowanych testów penetracyjnych opartych na analizie zagrożeń. Jeżeli system lub infrastruktura dostawcy znajduje się w zakresie takiego testu, umowa powinna zapewniać możliwość jego przeprowadzenia.

Dostawca może zostać zobowiązany do udziału w planowaniu testu, zapewnienia odpowiednich zgód, współpracy z testerami, zabezpieczenia danych innych klientów oraz udziału w usuwaniu wykrytych podatności.

Bez odpowiednich postanowień umownych przeprowadzenie testu może naruszać standardowy regulamin dostawcy albo zasady dostępu do jego infrastruktury. Problem ten powinien zostać rozwiązany jeszcze na etapie negocjowania umowy, a nie dopiero w chwili rozpoczęcia testów.

Podwykonawcy dostawcy ICT

Korzystanie z podwykonawców jest jednym z najbardziej wymagających obszarów kontraktów IT. Główny dostawca może korzystać z operatorów centrów danych, dostawców chmury, firm zapewniających wsparcie, spółek z własnej grupy, dostawców narzędzi bezpieczeństwa oraz centrów pomocy działających poza Unią Europejską.

Podmiot finansowy powinien wiedzieć, czy podwykonawstwo jest dozwolone, jakiego zakresu usług dotyczy oraz na jakich zasadach dostawca może zmieniać łańcuch dostaw.

W przypadku usług wspierających funkcje krytyczne lub istotne umowa powinna szczegółowo regulować podwykonawstwo. Powinna określać, które elementy usługi mogą zostać przekazane innym podmiotom, jakie obowiązki muszą zostać na nie przeniesione oraz w jaki sposób klient będzie informowany o zmianach.

Główny dostawca powinien ponosić odpowiedzialność za działania i zaniechania swoich podwykonawców jak za własne. Nie powinien mieć możliwości powołania się na to, że awaria wystąpiła w innej firmie i pozostawała poza jego kontrolą.

Zmiana podwykonawcy

Dostawca nie powinien mieć pełnej swobody dodawania nowych podwykonawców bez wiedzy podmiotu finansowego. Planowana istotna zmiana powinna zostać zgłoszona z wyprzedzeniem umożliwiającym przeprowadzenie oceny ryzyka.

Informacja powinna obejmować nazwę podwykonawcy, zakres powierzonych mu usług, lokalizację, udział w przetwarzaniu danych oraz znaczenie dla całości rozwiązania.

Podmiot finansowy powinien mieć możliwość zgłoszenia uzasadnionego sprzeciwu, jeżeli zmiana zwiększa ryzyko, prowadzi do przetwarzania danych w niedopuszczalnej lokalizacji, ogranicza prawa audytowe albo powoduje nadmierną koncentrację.

Jeżeli strony nie są w stanie uzgodnić odpowiednich środków ograniczających ryzyko, klient powinien posiadać możliwość zakończenia umowy. Prawo to jest szczególnie istotne, gdy dostawca wprowadza podwykonawcę mimo sprzeciwu, nie dochowuje terminu powiadomienia albo powierza usługę, której podwykonawstwo zostało wyłączone.

Rejestr informacji o umowach ICT

Podmioty finansowe są zobowiązane do prowadzenia rejestru informacji dotyczących ustaleń umownych w zakresie korzystania z usług ICT. Rejestr obejmuje nie tylko umowy dotyczące funkcji krytycznych, ale co do zasady wszystkie odpowiednie relacje z dostawcami technologii.

W przypadku funkcji krytycznych lub istotnych zakres informacji jest bardziej szczegółowy. Podmiot finansowy powinien posiadać dane identyfikacyjne dostawcy, opis usługi, lokalizacje, informacje o podwykonawcach, okres obowiązywania umowy oraz wskazanie wspieranych funkcji.

Umowa powinna zobowiązywać dostawcę do przekazywania informacji niezbędnych do prowadzenia rejestru i ich aktualizowania. Klient nie powinien być zmuszony do samodzielnego wyszukiwania danych w rozproszonych regulaminach i dokumentach technicznych.

Szczególne znaczenie ma obowiązek informowania o zmianach. Rejestr, który nie uwzględnia nowego podwykonawcy, zmiany lokalizacji danych albo modyfikacji zakresu usługi, nie odzwierciedla rzeczywistego ryzyka.

Ryzyko koncentracji i uzależnienia od dostawcy

Przed zawarciem umowy podmiot finansowy powinien ocenić, czy wybór danego dostawcy nie prowadzi do nadmiernej koncentracji.

Ryzyko takie może wystąpić, gdy wiele kluczowych procesów zależy od jednej firmy, kilka podmiotów w grupie korzysta z tej samej infrastruktury, na rynku brak realnych alternatyw albo migracja do innego rozwiązania jest wyjątkowo trudna.

Szczególnym problemem jest vendor lock-in, czyli techniczne lub kontraktowe uzależnienie od dostawcy. Może ono wynikać z zamkniętego formatu danych, braku dokumentacji, niestandardowych interfejsów, wysokich opłat za eksport danych albo konieczności korzystania z własnych narzędzi producenta.

Umowa powinna ograniczać to ryzyko poprzez zapewnienie przenoszalności danych, odpowiednich formatów eksportu, dostępu do dokumentacji, wsparcia migracyjnego oraz wystarczająco długiego okresu przejściowego.

Samo korzystanie z dużego globalnego dostawcy nie jest zabronione. Podmiot finansowy powinien jednak rozumieć skalę zależności i posiadać środki pozwalające ograniczyć jej konsekwencje.

Prawo wypowiedzenia umowy

Umowa powinna przyznawać podmiotowi finansowemu możliwość zakończenia współpracy w sytuacjach, w których dalsze korzystanie z usługi prowadziłoby do nadmiernego ryzyka albo naruszenia przepisów.

Prawo wypowiedzenia powinno obejmować istotne naruszenie umowy, powtarzające się awarie, poważne słabości bezpieczeństwa, odmowę współpracy z organem, niedozwolone podwykonawstwo, zmianę kontroli nad dostawcą, brak wykonania zaleceń pokontrolnych oraz utratę wymaganych zezwoleń lub certyfikatów.

Niektóre naruszenia mogą uzasadniać wypowiedzenie natychmiastowe. W innych przypadkach właściwe będzie wyznaczenie dostawcy terminu na usunięcie problemu.

Prawo rozwiązania umowy nie może być jednak analizowane w oderwaniu od ciągłości działania. Natychmiastowe wypowiedzenie kontraktu na kluczowy system może wyrządzić podmiotowi finansowemu więcej szkody niż czasowe kontynuowanie współpracy przy jednoczesnym uruchomieniu planu migracji.

Dlatego mechanizm wypowiedzenia powinien być powiązany z okresem przejściowym oraz obowiązkiem dalszego świadczenia usług przez czas niezbędny do bezpiecznego przeniesienia danych i procesów.

Strategia wyjścia

Strategia wyjścia powinna umożliwiać zakończenie korzystania z usługi bez zakłócenia działalności, utraty danych, naruszenia obowiązków regulacyjnych oraz pogorszenia jakości usług świadczonych klientom.

Plan powinien uwzględniać zarówno planowe zakończenie umowy, jak i sytuacje nagłe, takie jak niewypłacalność dostawcy, poważny cyberatak, utrata centrum danych, zakaz dalszego korzystania z usługi albo zaprzestanie wspierania określonej technologii.

Umowa powinna zobowiązywać dostawcę do przekazania danych, dokumentacji, konfiguracji, logów, informacji o interfejsach oraz innych materiałów potrzebnych do migracji.

Należy również uregulować obowiązek współpracy z nowym dostawcą albo zespołem klienta. Dotychczasowy usługodawca nie powinien utrudniać przejęcia systemu, opóźniać przekazywania informacji ani wykorzystywać sytuacji do narzucania nieuzasadnionych opłat.

W przypadku rozbudowanych systemów okres przejściowy może trwać wiele miesięcy. Kilkunastodniowy termin na migrację może być niewykonalny, zwłaszcza gdy konieczne jest przeniesienie dużej ilości danych, przeprowadzenie testów i uzyskanie zgód regulacyjnych.

Zmiany w usłudze

Usługi technologiczne podlegają ciągłym zmianom. Dostawcy aktualizują oprogramowanie, modyfikują architekturę, wprowadzają nowych podwykonawców, zmieniają centra danych oraz wycofują starsze wersje produktów.

Umowa powinna określać, które zmiany wymagają uprzedniego powiadomienia oraz jaki termin powinien zostać zachowany.

Szczególnego znaczenia nabierają zmiany lokalizacji danych, modelu bezpieczeństwa, sposobu uwierzytelniania, głównych komponentów systemu, podwykonawców oraz technologii wykorzystywanej do świadczenia usługi.

Podmiot finansowy powinien mieć możliwość przeprowadzenia oceny wpływu zmiany na ryzyko. Jeżeli zmiana powoduje istotne pogorszenie bezpieczeństwa, ograniczenie audytowalności albo brak zgodności z przepisami, klient powinien móc zgłosić sprzeciw lub zakończyć umowę.

Dostawca nie powinien mieć prawa do jednostronnego wprowadzania zmian, które uniemożliwiają podmiotowi finansowemu przestrzeganie DORA.

Odpowiedzialność dostawcy

DORA nie reguluje w sposób kompleksowy cywilnoprawnej odpowiedzialności stron, dlatego kwestia ta powinna zostać dokładnie opisana w umowie.

Dostawcy często proponują bardzo niskie limity odpowiedzialności, przykładowo ograniczone do wynagrodzenia zapłaconego w okresie kilku miesięcy. Przy systemie wspierającym krytyczną funkcję taki limit może być całkowicie nieadekwatny do potencjalnej szkody.

Podczas negocjacji należy uwzględnić odpowiedzialność za utratę danych, naruszenie poufności, brak dostępności, incydent cyberbezpieczeństwa, niewykonanie planu wyjścia, naruszenie obowiązków regulacyjnych, działania podwykonawców oraz brak współpracy z organem nadzoru.

Możliwe jest wprowadzenie kilku poziomów odpowiedzialności. Ogólny limit może obowiązywać w przypadku zwykłych naruszeń, natomiast wyższy limit albo brak ograniczenia może dotyczyć naruszenia poufności, ochrony danych, umyślnego działania, rażącego niedbalstwa lub naruszenia praw własności intelektualnej.

Warto również wskazać, czy kary umowne i service credits wyłączają możliwość dochodzenia dalszego odszkodowania. Z punktu widzenia klienta korzystne jest zachowanie prawa do dochodzenia szkody przewyższającej wysokość zastrzeżonej kary.

Ubezpieczenie dostawcy

Umowa może zobowiązywać dostawcę do utrzymywania odpowiedniego ubezpieczenia odpowiedzialności cywilnej, zawodowej albo cybernetycznej.

Zakres i suma ubezpieczenia powinny odpowiadać rodzajowi usługi, ilości przetwarzanych danych oraz potencjalnym skutkom awarii. Przy kluczowej platformie finansowej standardowa polisa o niskiej sumie gwarancyjnej może nie stanowić realnego zabezpieczenia.

Dostawca powinien przedstawiać dokumenty potwierdzające ochronę i informować o jej wygaśnięciu albo istotnej zmianie warunków.

Posiadanie ubezpieczenia nie powinno jednak ograniczać odpowiedzialności kontraktowej usługodawcy. Polisa jest dodatkowym źródłem zabezpieczenia, a nie podstawą do uznania, że odpowiedzialność dostawcy kończy się na kwocie wypłaconej przez ubezpieczyciela.

DORA a RODO

Jeżeli dostawca przetwarza dane osobowe w imieniu podmiotu finansowego, strony powinny również uregulować powierzenie przetwarzania zgodnie z art. 28 RODO.

Umowa outsourcingu i umowa powierzenia powinny być ze sobą spójne, zwłaszcza w zakresie lokalizacji danych, podwykonawców, środków bezpieczeństwa, incydentów, audytów, usuwania danych oraz transferów poza Europejski Obszar Gospodarczy.

Należy unikać sytuacji, w której umowa główna pozwala dostawcy dowolnie zmieniać podwykonawców, natomiast umowa powierzenia wymaga uprzedniej zgody administratora. Podobny problem może wystąpić, gdy umowa DORA przyznaje szerokie prawo audytu, a załącznik dotyczący danych ogranicza audyt wyłącznie do wglądu w certyfikat.

DORA i RODO mają odrębne cele, ale w praktyce wiele ich wymagań się uzupełnia. Zgodność z jednym rozporządzeniem nie oznacza automatycznie zgodności z drugim.

DORA a NIS2

DORA jest sektorową regulacją dotyczącą odporności cyfrowej podmiotów finansowych. W wielu obszarach pełni funkcję przepisów szczególnych wobec regulacji wynikających z NIS2.

Nie oznacza to jednak, że przepisy dotyczące cyberbezpieczeństwa nie mają znaczenia dla dostawców technologii. Firma IT może sama podlegać regulacjom wdrażającym NIS2, jeżeli spełnia odpowiednie kryteria.

W praktyce jedna umowa może zatem uwzględniać wymagania DORA, RODO, przepisów o cyberbezpieczeństwie, tajemnicy zawodowej oraz szczególnych regulacji sektorowych.

Umowy zawarte przed rozpoczęciem stosowania DORA

Fakt, że umowa została zawarta przed 17 stycznia 2025 r., nie oznacza, że nie trzeba jej dostosować.

Podmiot finansowy powinien przeanalizować istniejące kontrakty i zweryfikować, czy zawierają one wymagane postanowienia dotyczące usług, danych, lokalizacji, incydentów, SLA, audytów, organów nadzoru, podwykonawstwa, ciągłości działania, zwrotu danych i planu wyjścia.

Jeżeli umowa nie spełnia wymagań, konieczne może być zawarcie aneksu. Zakres zmian powinien odpowiadać charakterowi usługi. Umowa dotycząca prostego narzędzia pomocniczego nie wymaga tak samo rozbudowanych postanowień jak kontrakt na główną platformę transakcyjną.

Samo przesłanie dostawcy standardowego aneksu DORA może być niewystarczające. Dokument powinien zostać dopasowany do konkretnego modelu świadczenia usług, architektury rozwiązania, łańcucha podwykonawców oraz znaczenia systemu.

Co zrobić, gdy dostawca odmawia negocjacji?

Problem braku możliwości negocjowania warunków często dotyczy globalnych dostawców chmurowych oraz producentów standardowego oprogramowania.

DORA nie znosi przewagi negocjacyjnej dużych firm technologicznych. Podmiot finansowy nie może jednak uzasadniać braku zgodności wyłącznie tym, że dostawca odmówił zmiany regulaminu.

Konieczna jest analiza standardowej dokumentacji, załączników regulacyjnych, certyfikatów, raportów audytowych, polityk bezpieczeństwa oraz narzędzi oferowanych klientom sektora finansowego.

Jeżeli część wymagań nie jest spełniona, podmiot finansowy powinien ocenić, czy ryzyko można ograniczyć poprzez dodatkowe zabezpieczenia, rozwiązania organizacyjne, kopie danych, alternatywnego dostawcę lub odrębny plan ciągłości działania.

Brak możliwości uzyskania kluczowych praw, takich jak dostęp do danych, współpraca z organem, skuteczny audyt albo prawo wyjścia, może oznaczać, że dany dostawca nie powinien obsługiwać funkcji krytycznej lub istotnej.

Monitorowanie umowy po jej zawarciu

Podpisanie umowy nie kończy obowiązków związanych z DORA. Podmiot finansowy powinien monitorować sposób świadczenia usługi przez cały okres współpracy.

Kontrola powinna obejmować realizację SLA, incydenty, zmiany podwykonawców, zmiany lokalizacji danych, wyniki audytów, testy ciągłości działania, aktualność certyfikatów oraz kondycję finansową usługodawcy.

W przypadku stwierdzenia uchybień dostawca powinien przygotować i wykonać plan naprawczy. Podmiot finansowy powinien następnie zweryfikować, czy nieprawidłowości zostały rzeczywiście usunięte.

Monitoring powinien być udokumentowany. Raporty dostawcy, protokoły spotkań, wyniki audytów, informacje o incydentach i decyzje dotyczące akceptacji ryzyka mogą być istotne podczas kontroli organu nadzoru.

Szczególnej uwagi wymagają zmiany, które z pozoru mają charakter techniczny, ale faktycznie wpływają na ryzyko. Przeniesienie systemu do innego centrum danych, zmiana dostawcy infrastruktury albo zakończenie wsparcia dla określonej wersji oprogramowania mogą wymagać ponownej oceny całego rozwiązania.

Najczęstsze błędy w umowach outsourcingu IT

Jednym z najczęściej spotykanych problemów jest zbyt ogólny opis usług. Jeżeli umowa nie wskazuje, co dokładnie robi dostawca i które procesy wspiera, trudno prawidłowo ustalić SLA, zakres audytu oraz odpowiedzialność.

Kolejnym błędem jest brak pełnej informacji o lokalizacji danych i podwykonawcach. Podmiot finansowy może formalnie zawrzeć umowę z europejską spółką, podczas gdy wsparcie techniczne albo część przetwarzania odbywa się w państwie trzecim.

Częstą nieprawidłowością jest również niedostateczne prawo audytu. Klient otrzymuje wyłącznie możliwość wglądu w certyfikat, bez prawa do zadawania pytań, żądania wyjaśnień lub przeprowadzenia kontroli po incydencie.

Problematyczne są także zbyt długie terminy zgłaszania incydentów, dowolna zmiana podwykonawców, brak obowiązku współpracy z organem oraz brak realnego planu wyjścia.

Innym błędem jest uznanie, że załącznik DORA rozwiązuje wszystkie problemy. Nawet rozbudowana klauzula nie zapewnia zgodności, jeżeli nie jest spójna z SLA, umową powierzenia, regulaminem dostawcy i dokumentacją techniczną.

Niebezpieczne są również zbyt niskie limity odpowiedzialności oraz postanowienia uznające service credits za jedyne roszczenie klienta. W razie poważnej awarii rekompensata w wysokości części miesięcznego abonamentu może być nieproporcjonalna do rzeczywistej szkody.

Audyt umowy pod kątem DORA

Audyt umowy outsourcingu IT powinien obejmować zarówno treść dokumentów, jak i rzeczywisty sposób świadczenia usługi.

W pierwszej kolejności należy ustalić, czy umowa dotyczy usługi ICT oraz czy wspiera ona funkcję krytyczną lub istotną. Następnie trzeba zweryfikować, czy dostawca został prawidłowo oceniony, czy znany jest łańcuch podwykonawców oraz czy dostępne są informacje potrzebne do rejestru.

Analiza powinna obejmować opis usługi, lokalizację danych, bezpieczeństwo, ciągłość działania, incydenty, SLA, audyty, współpracę z organami, prawa wypowiedzenia, plan wyjścia, odpowiedzialność i zasady migracji.

Należy także zbadać spójność pomiędzy poszczególnymi dokumentami. Prawo audytu zapisane w umowie głównej może być ograniczone w regulaminie. Zasady zmiany podwykonawców mogą różnić się w umowie DORA i umowie powierzenia danych.

Efektem audytu powinna być konkretna lista braków, ich ocena oraz rekomendacje dotyczące aneksowania umowy, zmiany procedur, zastosowania dodatkowych zabezpieczeń albo wyboru innego dostawcy.

Podsumowanie

Umowa outsourcingu IT zgodna z DORA nie może ograniczać się do opisu usługi, wynagrodzenia oraz standardowego SLA. Powinna regulować cały cykl korzystania z zewnętrznej usługi ICT, począwszy od oceny dostawcy, przez bieżące monitorowanie, obsługę incydentów i audyty, aż po bezpieczne zakończenie współpracy.

Podmiot finansowy powinien posiadać realną możliwość monitorowania usługi, uzyskiwania informacji o incydentach, kontrolowania podwykonawców, audytowania dostawcy, współpracy z organami, odzyskania danych i przeniesienia systemu do innego środowiska.

Szczególnej uwagi wymagają usługi wspierające funkcje krytyczne lub istotne. W ich przypadku umowa powinna zawierać precyzyjne parametry, szerokie prawa kontrolne oraz realny plan wyjścia.

Samo podpisanie aneksu DORA nie zapewnia zgodności. Konieczne jest również prowadzenie rejestru, bieżące monitorowanie dostawcy, analizowanie zmian, dokumentowanie incydentów i okresowe testowanie ciągłości działania.

Z kolei firmy IT świadczące usługi na rzecz sektora finansowego powinny przygotować własny standard dokumentacji DORA. Dostawca, który nie potrafi przedstawić informacji o bezpieczeństwie, lokalizacji danych, podwykonawcach, testach i planach awaryjnych, może mieć trudności z pozyskaniem klientów działających na regulowanym rynku finansowym.