Rozporządzenie DORA nie nakłada obowiązków bezpośrednio na software house ani na usługę SaaS, ale klient z sektora finansowego ma obowiązek przenieść jej wymogi na dostawcę w umowie. W konsekwencji to umowa staje się narzędziem zgodności dla klienta, a dostawca ponosi jej ciężar. Przy analizie i negocjowaniu takich kontraktów znaczenie ma również odpowiednia obsługa prawna FinTech.
Najważniejsze punkty:
- dostawca IT, SaaS lub software house zwykle nie jest podmiotem finansowym, nie podlega DORA wprost.
- ciężar dostosowania usługi i tak spada na dostawcę, – klient wpisuje do umowy obowiązkowe klauzule z art. 30 DORA (SLA, incydenty, audyt, strategia wyjścia).
- zakres klauzul zależy od tego, czy usługa wspiera „funkcje krytyczne lub istotne” (art. 30 ust. 3), czy nie (art. 30 ust. 2).
- art. 30 ust. 3 wymusza m.in. nieograniczone prawo audytu (lit. e) oraz strategię wyjścia z obowiązkowym okresem przejściowym (lit. f).
- największe ryzyko dla dostawcy to dodatkowe kary umowne, których DORA nie przewiduje oraz obowiązek nieodpłatnej pomocy dla klienta w sytuacji, w której DORA dopuszcza pomoc odpłatną.
Twój software house od lat rozwija aplikację dla instytucji płatniczej. Klient przysyła aneks: pięć stron nowych obowiązków, nieograniczone prawo do audytu „w dowolnym momencie”, dodatkowe kary umowne, wymóg przeprowadzenia „strategii wyjścia” na koszt dostawcy, nieodpłatna pomoc przy incydentach. Klienci z sektora finansowego – co pokazuje praktyka stosowania DORA – mają tendencję do nakładania pod pretekstem DORA obowiązków, których przepisy prawa nie wymagają.
To nie jest hipotetyczny scenariusz, ale codzienność każdego dostawcy IT, chmury i SaaS obsługującego sektor finansowy po wejściu DORA. Dobra wiadomość jest taka, że większość tych klauzul da się przyjąć bez paraliżowania Twojej firmy – pod warunkiem, że wiesz, które z nich są twarde, a które podlegają negocjacji.
Sprawdź również, jak wygląda obsługa prawna firm IT przy analizie i audycie umów IT do wymagań sektora finansowego.
Dlaczego DORA zmienia zasady gry w umowach IT dla fintechu
DORA przenosi odpowiedzialność za odporność cyfrową z pojedynczej instytucji na cały łańcuch jej dostawców, robiąc to za pomocą umowy. Dla podmiotu finansowego (banku, instytucji płatniczej, firmy inwestycyjnej) zgodność z DORA nie kończy się na jego własnych systemach. Regulacja wymaga, aby ryzyko po stronie dostawców ICT było kontrolowane kontraktowo.
W praktyce oznacza to, że klient z sektora finansowego nie może już podpisać „zwykłej” umowy IT. Po wejściu w życie DORA, umowa musi zawierać co najmniej katalog wymagań, który wynika z art. 30 DORA. W przeciwnym razie np. bank naraża się na zarzut naruszenia przepisów DORA.
Dla dostawcy oznacza to, że: rośnie liczba obowiązków, które muszą zostać realnie wykonane, np. raportowanie incydentów, gotowość do audytu, plan migracji. Ponadto, rośnie ryzyko kontraktowe i finansowe dostawcy IT, bo obowiązki są zwykle obwarowane karami umownymi oraz oznaczają dodatkowe działania, za które ktoś musi zapłacić. Dlatego kluczem jest oddzielenie tego, co wynika wprost z DORA, od tego, co klient dokłada „przy okazji” DORA.
Kogo dotyczy DORA: podmiot finansowy, dostawca ICT?
DORA wiąże wprost tylko podmioty finansowe, – rozporządzenie wymienia zamknięty katalog podmiotów finansowych: instytucje kredytowe, instytucje płatnicze, instytucje pieniądza elektronicznego, firmy inwestycyjne, dostawców usług w zakresie kryptoaktywów i kilkanaście innych. To ich obciąża bezpośrednio regulacja DORA.
- Jesteś producentem produktu fintech? Jeśli masz licencję instytucji płatniczej, pieniądza elektronicznego lub firmy inwestycyjnej, jesteś podmiotem finansowym i DORA obowiązuje wprost, wraz z obowiązkiem narzucenia klauzul własnym poddostawcom.
- Sprzedajesz oprogramowanie lub SaaS do sektora? Jesteś zewnętrznym dostawcą usług ICT. DORA nie obowiązuje dostawcy bezpośrednio, ale dosięga go przez umowę z klientem.
- Jesteś software house’em realizującym projekty? Tak samo posiadasz status dostawcy ICT, a ciężar DORA będzie wynikać z zawartej umowy.
Wskazane rozróżnienie ma realne konsekwencje. Podmiot finansowy odpowiada przed KNF i to on ponosi karę administracyjną za braki w spełnieniu wymagań DORA. Dostawca odpowiada przed klientem na podstawie umowy, przez co jego odpowiedzialność jest tak szeroka, jak wynika z aneksu lub umowy. To powoduje, że dla dostawcy IT,umowa albo stanowi realną barierę przed przerzuceniem całego ryzyka przez podmiot finansowy, albo jest bramą do tego, żeby podmiot finansowy to ryzyko przeniósł na dostawcę.
Przy bardziej złożonych kontraktach technologicznych sprawdź również, w jakim zakresie może pomóc prawnik nowe technologie.
Klauzule z art. 30 DORA, które klient wpisze do umowy
Katalog obowiązków można podzielić na dwa poziomy: art. 30 ust. 2 wymienia postanowienia wymagane w każdej umowie ICT z podmiotem finansowym, natomiast art. 30 ust. 3 dokłada dodatkowe, znacznie surowsze wymogi, jeżeli dostawca poprzez swoją usługę wspiera „funkcje krytyczne lub istotne” klienta.
Dlatego pierwsze pytanie w negocjacjach brzmi „czy usługa jest krytyczna lub istotna dla klienta”. Decyzję o kwalifikacji podejmuje jednak podmiot finansowy, więc ta sama usługa świadczona dla różnych klientów może być inaczej kwalifikowana. Ponadto, praktyka rynkowa pokazuje, że część podmiotów finansowych idzie tzw. „trzecią drogą”, i niezależnie od klasyfikacji usługi proponuje jeden model klauzul, które odpowiadają wymogom usługi wspierającej funkcje krytyczne.
Najważniejsze różnice:
- SLA. Przy zwykłej usłudze wystarczy opis gwarantowanych poziomów. Przy funkcjach krytycznych – dokładne cele ilościowe i jakościowe oraz działania naprawcze.
- Prawo audytu. Przy zwykłej usłudze – tylko podstawowa kontrola. Przy funkcjach krytycznych – nieograniczone prawo dostępu, kontroli i audytu, ale tutaj uwaga, bo klienci finansowi mają tendencję do tego, aby pełne prawo audytu rozciągać na wszystkich dostawców,.
- Strategia wyjścia. Przy zwykłej usłudze – zwrot i odzyskanie danych. Przy funkcjach krytycznych – obowiązkowy okres przejściowy i migracja, trzeba jednak uważać, gdyż klient finansowy oczekuje tych usług nieodpłatnie, a DORA nie nakłada na dostawcę obowiązku świadczenia usług nieodpłatnie.
- Testy penetracyjne (TLPT). Nie dotyczą zwykłych usług. Przy funkcjach krytycznych występuje obowiązek pełnej współpracy w zakresie testów.
- Lista podwykonawców. W przypadku usługi kluczowej istnieje obowiązek ujawnienia pełnego łańcucha dostaw, podmioty finansowe starają się jednak nakładać ten obowiązek na każdego dostawcę, co wprost nie wynika z DORA.
Wniosek praktyczny: zanim zaczniesz negocjować pojedyncze zapisy, ustal z klientem klasyfikację usługi. Zbyt pochopne przyznanie, że usługa jest „krytyczna”, ogranicza możliwość szerszego negocjowania umowy w zakresie postanowień DORA.
Najczęściej zadawane pytania (FAQ)
Czy DORA dotyczy dostawców IT?
Nie wprost, dostawca IT zwykle nie jest podmiotem finansowym, więc DORA nie nakłada na niego obowiązków bezpośrednio. DORA dotyka najczęściej dostawcy IT przez umowę: klient z sektora finansowego ma obowiązek przenieść na dostawcę klauzule z art. 30 DORA.
Czym różni się usługa zwykła od usługi wspierającej funkcje krytyczne i istotne?
Art. 30 ust. 2 wymienia klauzule wymagane w każdej umowie ICT z podmiotem finansowym, a ust. 3 dokłada surowsze wymogi, gdy usługa wspiera „funkcje krytyczne lub istotne” klienta. To rozróżnienie decyduje o ciężarze umowy. Dla usługi krytycznej DORA wprowadza nieograniczone prawo audytu, obowiązkową strategię wyjścia i udział w testach penetracyjnych. Dlatego pierwszym krokiem w negocjacjach jest ustalenie klasyfikacji usługi z klientem z sektora finansowego.
Czy muszę zgodzić się na nieograniczony audyt DORA?
Nie na audyt „bez zapowiedzi i bez ram”, DORA daje klientowi szerokie prawo audytu, ale wprost wymaga, aby strony ustaliły jego częstotliwość i obszary. Możesz więc uzgodnić rozsądne uprzedzenie (np. 14 dni) i zakres kontroli. Tryb natychmiastowy zostaw dla żądań organu nadzoru – tu zwłoka nie wchodzi w grę.
Kto zgłasza incydent do KNF, klient czy dostawca IT?
Incydent do KNF zgłasza klient jako podmiot finansowy, to jego obowiązek regulacyjny, który wynika z DORA. Rolą dostawcy IT jest to, aby zgłosić zdarzenie klientowi na tyle sprawnie, aby zdążył on dotrzymać własnych terminów raportowych wobec organu. W umowie należy zadbać, aby termin zgłoszenia był powiązany z terminami klienta, a nie oderwany od nich.
Czy można ograniczyć swoją odpowiedzialność w umowie z fintechem?
Tak, DORA nie zakazuje ograniczenia odpowiedzialności w umowie. Możesz wprowadzić cap kwotowy łącznej odpowiedzialności (typowo 80–100% rocznego wynagrodzenia) oraz osobny dla kar umownych. Możesz też wyłączyć szkody w postaci utraconych korzyści.
Co grozi za brak strategii wyjścia w umowie?
Brak strategii wyjścia to przede wszystkim ryzyko podmiotu finansowego, – przy usługach krytycznych narusza on przepisy DORA i naraża się na zarzut niezgodności wobec KNF. Dla dostawcy IT oznacza to nowe obowiązki, które należy realnie wycenić. Lepiej uregulować okres przejściowy, format przekazania danych.
Czy DORA zmusza do zawarcia umów od nowa?
Nie, DORA nie wymaga napisania umowy od nowa, ale klient z sektora finansowego na pewno zaproponuje aneks do już zawartej umowy. Jeśli dopiero negocjujesz umowę z klientem z sektora finansowego, otrzymasz dodatkowy załącznik do umowy z wymaganiami DORA.
Podsumowanie
DORA nie czyni z dostawcy IT podmiotu finansowego, ale sprawia, że umowa staje się narzędziem zgodności dla klienta z sektora finansowego. Katalog wymagań jest dosyć rozbudowany, ale sformułowany na tyle ogólnie, że daje pole do negocjacji. Należy jednak uważać, aby nie wziąć na siebie za dużo obowiązków, których przepisy DORA nie nakładają na dostawcę, ale które chce nałożyć na dostawcę IT klient z rynku finansowego.
