Oprogramowanie dla finansów: co DORA, PSD2 i outsourcing ICT zmieniają w wyborze dostawcy

Departament IT średniej wielkości banku wybiera dostawcę do budowy nowej aplikacji mobilnej. Trzy oferty przeszły ocenę techniczną, wszystkie mieszczą się w budżecie, a w każdej pada to samo zdanie: „jesteśmy w pełni zgodni z DORA”. Komitet zakupowy wybiera najtańszą. Sześć tygodni później, podczas negocjacji, dział zgodności przysyła aneks z klauzulami z art. 30 rozporządzenia. Zwycięzca odmawia nieograniczonego prawa audytu, nie potrafi wskazać, gdzie jego podwykonawca przechowuje kopie zapasowe, a o udziale w testach penetracyjnych prowadzonych w oparciu o analizę zagrożeń słyszy po raz pierwszy. Projekt staje, a oferta, która wygrała ceną, okazuje się najdroższa, bo kosztuje kwartał.

Ten scenariusz nie wymaga złej woli żadnej ze stron. Wystarczy, że regulacje trafiają do procesu wyboru dostawcy na końcu, jako aneks do umowy, zamiast na początku, jako kryterium oceny ofert. Artykuł jest dla dyrektorów IT, CTO i osób odpowiedzialnych za zgodność w bankach, instytucjach płatniczych, ubezpieczycielach, domach maklerskich i firmach fintech, które kupują tworzenie oprogramowania z zewnątrz.

Teza jest taka: przy wyborze dostawcy oprogramowania dla finansów zdanie „jesteśmy zgodni z DORA” nic nie znaczy, bo DORA obowiązuje instytucję finansową, a nie software house. Liczy się to, czy umowę z dostawcą, jego łańcuch podwykonawców i sposób dostarczania da się wpisać do rejestru informacji, objąć klauzulami z art. 30 i zakończyć bez przerwy w działaniu. Dla systemów wspierających funkcje krytyczne te kryteria powinny ważyć w ocenie ofert co najmniej tyle, co kompetencje techniczne, i więcej niż cena. Wielu kupujących się z tym nie zgodzi, bo przyzwyczaili się oceniać zespoły i stawki. Spróbujemy pokazać, dlaczego to się nie opłaca.

Nie piszemy tu o testach akceptacyjnych w kontekście DORA ani o transformacji cyfrowej sektora finansowego. Te tematy omówiliśmy w osobnych tekstach: o checkliście UAT po RODO, EAA i DORA oraz o transformacji cyfrowej w finansach i open bankingu. Tutaj chodzi o jedno: jak regulacje zmieniają wybór dostawcy oprogramowania.

Dlaczego „dostawca zgodny z DORA” to obietnica bez pokrycia?

Rozporządzenie (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego, znane jako DORA, jest stosowane od 17 stycznia 2025 roku. Jego adresatem są podmioty finansowe wymienione w art. 2: banki, instytucje płatnicze i instytucje pieniądza elektronicznego, firmy inwestycyjne, zakłady ubezpieczeń, dostawcy usług kryptoaktywów i kilkanaście innych kategorii. Dostawca oprogramowania nie znajduje się na tej liście. Wynika to wprost z art. 28 ust. 1: podmiot finansowy, który korzysta z usług zewnętrznych dostawców ICT, pozostaje w pełni odpowiedzialny za przestrzeganie wszystkich obowiązków wynikających z rozporządzenia i przepisów sektorowych.

Jest jeden wyjątek. Dostawcy wyznaczeni jako kluczowi (critical ICT third-party providers, CTPP) podlegają bezpośredniemu nadzorowi europejskich urzędów nadzoru. 18 listopada 2025 roku EBA, EIOPA i ESMA opublikowały pierwszą listę 19 takich dostawców. Znalazły się na niej europejskie spółki takich firm jak Amazon Web Services, Google Cloud, Microsoft, IBM, Bloomberg czy London Stock Exchange Group. Wobec CTPP wiodący organ nadzoru może nałożyć okresową karę pieniężną do 1% średniego dziennego światowego obrotu, naliczaną codziennie przez maksymalnie sześć miesięcy (art. 35 ust. 8). Software house realizujący projekt dla jednego banku nie jest i nie będzie CTPP.

Co więc znaczy zdanie „jesteśmy zgodni z DORA” w ofercie zwykłego dostawcy? W najlepszym razie skrót myślowy: „mamy procesy, które pozwolą wam spełnić wasze obowiązki”. W najgorszym: hasło marketingowe, za którym nie stoi nic, co da się sprawdzić. Ani jedno, ani drugie nie jest kryterium oceny oferty. Kryterium jest to, czy dostawca przyjmie konkretne klauzule, dostarczy konkretne dane i weźmie udział w konkretnych procesach. To da się zweryfikować przed wyborem, a nie po nim.

Druga konsekwencja jest mniej oczywista. Skoro odpowiedzialność zostaje po stronie instytucji finansowej, to instytucja musi umieć ją udźwignąć na podstawie dowodów od dostawcy. Certyfikat ISO/IEC 27001 czy raport SOC 2 jest takim dowodem tylko częściowo: mówi o systemie zarządzania bezpieczeństwem dostawcy, a nie o tym, czy umowa pozwala wam przeprowadzić audyt, wyjść z niej w kontrolowany sposób albo dowiedzieć się o incydencie w czasie, który pozwoli zgłosić go nadzorowi. Art. 28 ust. 5 wymaga, by dostawca stosował odpowiednie standardy bezpieczeństwa informacji, ale certyfikat jest warunkiem wejścia do rozmowy, a nie jej wynikiem.

Kiedy software house staje się dostawcą usług ICT w rozumieniu DORA?

To pytanie słyszymy najczęściej, bo od odpowiedzi zależy, czy umowa w ogóle trafia do rejestru informacji i czy obejmują ją wymagania z art. 28–30. Art. 3 pkt 21 DORA definiuje usługi ICT jako usługi cyfrowe i usługi w zakresie danych świadczone za pośrednictwem systemów ICT jednemu lub większej liczbie użytkowników wewnętrznych lub zewnętrznych na bieżąco. Kluczowe są dwa ostatnie słowa.

Katalog typów usług, którym podmioty finansowe posługują się w rejestrze, zawiera załącznik III do rozporządzenia wykonawczego Komisji (UE) 2024/2956. Wymienia dziewiętnaście kategorii. Dla firm wytwarzających oprogramowanie znaczenie mają przede wszystkim:

• S02 „ICT development”: analiza biznesowa, projektowanie i wytwarzanie oprogramowania, testowanie,
• S01 „ICT project management”: wsparcie biura projektów,
• S14 „ICT operation management”: konfiguracja, utrzymanie, instalacja, zarządzanie pojemnością i ciągłością działania, z wyraźnym wskazaniem dostawców usług zarządzanych,
• S15 „ICT consulting”: doradztwo eksperckie,
• S19 „Cloud services: SaaS”, jeśli dostawca udostępnia własny produkt w modelu usługowym.

Granicę wyznacza warunek świadczenia na bieżąco. W odpowiedzi na pytanie DORA 215-3300 europejskie urzędy nadzoru wskazały, że odsprzedawca, który dostarcza wyłącznie licencje bez bieżących usług ICT, nie jest dostawcą usług ICT w rozumieniu definicji. Wcześniejsze pytanie (DORA130-3174), w którym rynek prosił o potwierdzenie, że jednorazowe dostawy są poza zakresem art. 28–30, zostało odrzucone z odesłaniem właśnie do warunku z definicji. Wniosek z obu odpowiedzi jest taki, że o zakresie decyduje bieżący charakter usługi, a nie nazwa umowy.

Praktyczny wniosek dla kupującego: projekt budowy oprogramowania połączony z utrzymaniem, wsparciem, gwarancją realizowaną przez zespół dostawcy, stałym zespołem rozwojowym albo hostingiem jest usługą ICT. Teoretycznie można próbować tak ułożyć zamówienie, żeby wyglądało na jednorazową dostawę kodu bez bieżących usług, i w ten sposób wyjść poza rejestr. Odradzamy to z dwóch powodów. Po pierwsze, system, który wspiera działalność finansową, prawie zawsze wymaga utrzymania, a jeśli nie robi tego dostawca, robi to ktoś inny, kto wtedy trafia do rejestru. Po drugie, nadzorca ocenia treść relacji, a nie tytuł umowy. Konstrukcja, która formalnie omija rejestr, a w praktyce opiera się na bieżących usługach jednego dostawcy, jest ryzykiem regulacyjnym, a nie oszczędnością.

Osobną sprawą jest body leasing, czyli udostępnianie specjalistów pracujących w zespole klienta. Tu klasyfikacja zależy od tego, czy dostawca świadczy usługę (odpowiada za wynik albo za utrzymanie ciągłości zespołu), czy tylko udostępnia osoby pod pełnym kierownictwem klienta. Bezpieczniejsze założenie to wpisanie takiej umowy do rejestru jako S02 albo S15 i objęcie jej klauzulami z art. 30 ust. 2, bo specjaliści dostawcy zwykle pracują w systemach wspierających działalność finansową i mają do nich bieżący dostęp. To ocena, którą warto uzgodnić z działem zgodności przed wysłaniem zapytania ofertowego, a nie po podpisaniu umowy.

Co zmienia klasyfikacja funkcji krytycznej lub istotnej?

DORA nie traktuje wszystkich usług ICT jednakowo. Zasadnicza linia podziału przebiega między usługami, które wspierają funkcje krytyczne lub istotne, a pozostałymi. Funkcja krytyczna lub istotna to, w uproszczeniu, taka, której zakłócenie istotnie osłabiłoby wyniki finansowe podmiotu, ciągłość jego działalności albo zgodność z warunkami zezwolenia i przepisami (art. 3 pkt 22). Od tej klasyfikacji zależy zakres klauzul umownych, obowiązek strategii wyjścia, zgłaszanie planowanych umów do nadzoru i intensywność monitorowania.

Tu leży pierwszy praktyczny wniosek dla wyboru dostawcy: o wymaganiach decyduje funkcja, którą wspiera oprogramowanie, a nie wielkość dostawcy ani wartość kontraktu. Mały zespół budujący moduł autoryzacji transakcji wspiera funkcję krytyczną. Duża firma budująca intranetowy portal z ogłoszeniami dla pracowników nie. Rozporządzenie delegowane Komisji (UE) 2024/1773 wymaga, by polityka podmiotu dotycząca usług wspierających funkcje krytyczne lub istotne zawierała metodykę ustalania, które usługi je wspierają, oraz określała, kiedy ta ocena jest przeprowadzana i weryfikowana.

Ta ocena powinna zostać wykonana przed zapytaniem ofertowym, a nie po wyborze dostawcy. Art. 28 ust. 4 wymaga, by przed zawarciem umowy podmiot finansowy ocenił, czy umowa obejmuje usługi wspierające funkcję krytyczną lub istotną, sprawdził warunki nadzorcze, zidentyfikował ryzyka, w tym ryzyko koncentracji, przeprowadził należytą staranność wobec dostawcy i zidentyfikował konflikty interesów. Jeśli klasyfikacja zostanie zrobiona dopiero po wyborze, okaże się, że oferty oceniano według kryteriów, które nie odpowiadały rzeczywistym wymaganiom.

Klasyfikacja ma też konsekwencję, o której kupujący często zapominają. Jeśli usługa wspiera funkcję krytyczną lub istotną, podmiot finansowy musi w odpowiednim czasie informować organ nadzoru o planowanych umowach (art. 28 ust. 3). W Polsce jest nim KNF. Harmonogram wyboru dostawcy, który nie uwzględnia tego kroku, jest harmonogramem nierealistycznym.

Warto też pamiętać o ryzyku koncentracji (art. 29). Jeśli dostawca, którego rozważacie, obsługuje już inne funkcje krytyczne w waszej organizacji albo opiera się na tym samym dostawcy chmury co reszta waszego krajobrazu, nowa umowa może zwiększyć zależność od jednego podmiotu w sposób, który nadzorca zakwestionuje. To nie jest powód, by odrzucać takiego dostawcę, ale jest powodem, by tę ocenę udokumentować przed decyzją.

Czego art. 30 DORA wymaga w każdej umowie z dostawcą ICT?

Art. 30 ust. 1 wymaga, by prawa i obowiązki stron były jasno przypisane i spisane, a cała umowa, łącznie z umowami o poziomie usług, znajdowała się w jednym dokumencie pisemnym dostępnym dla obu stron. Już to bywa problemem: umowy ramowe, zamówienia, załączniki techniczne i SLA rozproszone w kilkunastu plikach o różnych datach nie spełniają tego warunku bez uporządkowania.

Art. 30 ust. 2 wymienia elementy, które musi zawierać każda umowa na usługi ICT, niezależnie od tego, czy wspiera funkcję krytyczną:

1. pełny opis usług, z informacją, czy dopuszczalne jest podwykonawstwo usług wspierających funkcję krytyczną lub istotną, i na jakich warunkach,
2. lokalizacje (regiony lub państwa), w których usługi są świadczone, a dane przetwarzane i przechowywane, wraz z obowiązkiem uprzedniego powiadomienia o planowanej zmianie,
3. postanowienia o dostępności, autentyczności, integralności i poufności danych, w tym danych osobowych,
4. zapewnienie dostępu do danych, ich odzyskania i zwrotu w łatwo dostępnym formacie w przypadku niewypłacalności, restrukturyzacji, zaprzestania działalności dostawcy lub zakończenia umowy,
5. opisy poziomów usług, wraz z aktualizacjami,
6. obowiązek pomocy przy incydentach ICT związanych z usługą, bez dodatkowych kosztów albo za koszt ustalony z góry,
7. obowiązek pełnej współpracy z właściwymi organami i organami restrukturyzacji,
8. prawa wypowiedzenia i minimalne okresy wypowiedzenia,
9. warunki udziału dostawcy w programach podnoszenia świadomości bezpieczeństwa ICT i szkoleniach z odporności cyfrowej.

Dla dostawcy oprogramowania kilka z tych punktów wymaga konkretnych odpowiedzi, a nie deklaracji. Punkt drugi oznacza, że dostawca musi znać lokalizacje wszystkich miejsc, w których dane klienta mogą się znaleźć: repozytoriów kodu z danymi testowymi, narzędzi do zgłaszania błędów, środowisk testowych, laptopów programistów, kopii zapasowych. Punkt czwarty oznacza, że kod, dokumentacja i dane muszą być możliwe do przekazania w formacie, z którego da się skorzystać bez dostawcy. Punkt szósty ustala z góry, ile kosztuje pomoc przy incydencie, co eliminuje sytuację, w której w środku awarii toczy się negocjacja stawki.

Art. 30 ust. 4 zachęca strony do rozważenia standardowych klauzul umownych opracowanych przez organy publiczne dla konkretnych usług. Dla kupującego to dobra wiadomość: nie trzeba wymyślać tych postanowień od zera, a dostawca, który zna takie wzorce, szybciej przejdzie przez negocjacje.

Jakie klauzule dochodzą, gdy oprogramowanie wspiera funkcję krytyczną?

Art. 30 ust. 3 dodaje sześć grup postanowień dla usług wspierających funkcje krytyczne lub istotne. To one najczęściej zatrzymują negocjacje, bo wymagają od dostawcy zmian w sposobie działania, a nie tylko podpisu.

Pełne opisy poziomów usług z precyzyjnymi celami ilościowymi i jakościowymi, które pozwalają monitorować usługę i podejmować działania naprawcze, gdy cele nie są osiągane. Dla zespołu rozwojowego to oznacza coś więcej niż czas reakcji na zgłoszenie: także czas naprawy błędów krytycznych, dostępność środowisk, terminy wydawania poprawek bezpieczeństwa.

Okresy wypowiedzenia i obowiązki sprawozdawcze dostawcy, w tym obowiązek powiadamiania o wszystkim, co może istotnie wpłynąć na jego zdolność do świadczenia usług. Zmiana właściciela, utrata kluczowych osób, zmiana podwykonawcy, problemy finansowe.

Wdrożone i testowane plany ciągłości działania oraz środki bezpieczeństwa ICT odpowiednie do ram regulacyjnych podmiotu. Dostawca musi pokazać plan, a nie tylko zapewnić, że go ma, i umieć wykazać, że był testowany.

Udział w testach penetracyjnych prowadzonych w oparciu o analizę zagrożeń (TLPT) na podstawie art. 26 i 27. Podmioty wskazane przez nadzór przeprowadzają je co najmniej co trzy lata, a jeśli zakres obejmuje systemy budowane lub utrzymywane przez dostawcę, ten musi w nich uczestniczyć.

Prawa do bieżącego monitorowania: nieograniczone prawa dostępu, kontroli i audytu dla podmiotu finansowego, wyznaczonej przez niego strony trzeciej i organu nadzoru, prawo do sporządzania kopii dokumentów na miejscu, uzgodnione alternatywne poziomy zapewnienia, jeśli audyt mógłby naruszyć prawa innych klientów dostawcy, oraz obowiązek współpracy podczas inspekcji.

Strategie wyjścia, w szczególności obowiązkowy, odpowiedni okres przejściowy, w którym dostawca nadal świadczy usługi, a podmiot może przenieść je do innego dostawcy albo do siebie.

Najwięcej oporu budzą zwykle dwa postanowienia: nieograniczone prawa audytu i okres przejściowy przy wyjściu, bo oba kosztują dostawcę realną pracę i ograniczają jego swobodę. Dostawca, który zgadza się na nie bez dyskusji, prawdopodobnie nie przeczytał umowy. Dostawca, który odmawia ich wprost, nie nadaje się do systemów krytycznych. Najlepszy sygnał to dostawca, który przychodzi z konkretną propozycją: jak przeprowadzić audyt, nie naruszając poufności innych klientów, i jak wygląda jego standardowy plan przekazania systemu.

Jak rejestr informacji zmienia przebieg wyboru dostawcy?

Art. 28 ust. 3 zobowiązuje podmioty finansowe do prowadzenia rejestru informacji o wszystkich umowach dotyczących korzystania z usług ICT świadczonych przez zewnętrznych dostawców, z rozróżnieniem umów wspierających funkcje krytyczne lub istotne. Wzory rejestru określa rozporządzenie wykonawcze (UE) 2024/2956. Rejestr jest przekazywany nadzorowi co najmniej raz w roku. W Polsce KNF wyznaczyła termin pierwszego przekazania na 23 kwietnia 2025 roku, według stanu na 31 marca 2025 roku, przez System Sprawozdawczości DORA na formularzu SPR-PF-18.

Rejestr to nie formalność. Europejskie urzędy nadzoru wykorzystały dane z rejestrów do oceny, którzy dostawcy są kluczowi dla rynku, i na tej podstawie wyznaczyły pierwszych CTPP. Rejestr jest więc źródłem danych, na którym nadzór buduje obraz zależności całego sektora.

Dla wyboru dostawcy rejestr ma trzy praktyczne skutki.

Po pierwsze, dostawca musi dostarczyć dane, które trafią do rejestru: dane identyfikacyjne (w tym identyfikator LEI, jeśli go ma), lokalizacje świadczenia usług i przetwarzania danych, typ usług według katalogu z załącznika III, a dla usług wspierających funkcje krytyczne także informacje o podwykonawcach w łańcuchu dostaw. Dostawca, który nie potrafi tych danych dostarczyć na etapie oferty, nie dostarczy ich też później.

Po drugie, rejestr wymusza myślenie o łańcuchu dostaw już przy zakupie. Jeśli zwycięski dostawca korzysta z podwykonawcy, a ten z kolejnego dostawcy chmury, każdy z tych podmiotów może trafić do szablonów rejestru dotyczących łańcucha. Odpowiedź ESA na pytanie DORA 215-3300 pokazuje logikę: gdy nie macie bezpośredniej umowy z faktycznym dostawcą usługi, w rejestrze wpisujecie umowę z pośrednikiem i uzupełniacie ją informacjami o faktycznym dostawcy jako podwykonawcy.

Po trzecie, każda zmiana dostawcy albo jego podwykonawców to zmiana w rejestrze. Dostawca, który rotuje podwykonawców między projektami, generuje pracę po stronie waszego działu zgodności. To koszt, który warto uwzględnić w ocenie ofert, a którego nie widać w stawce dziennej.

Prosty test na etapie zapytania ofertowego: poproś o wypełnienie uproszczonej wersji szablonów rejestru dla proponowanej usługi. To godzina pracy dla dostawcy, który ma porządek w swoich umowach, i tydzień dla takiego, który go nie ma. Różnica w czasie odpowiedzi powie wam więcej niż deklaracje w ofercie.

Gdzie w tym wszystkim są PSD2, wytyczne EBA i polskie przepisy o outsourcingu?

DORA nie działa w próżni. Kupujący oprogramowanie dla finansów musi pamiętać o co najmniej trzech innych warstwach regulacji, które nakładają się na wybór dostawcy.

PSD2. Dyrektywa (UE) 2015/2366 o usługach płatniczych ma dwa punkty styku z wyborem dostawcy. Pierwszy to outsourcing: art. 19 ust. 6 wymaga, by instytucja płatnicza, która zamierza powierzyć zewnętrznie funkcje operacyjne usług płatniczych, poinformowała o tym organ nadzoru, a powierzenie ważnych funkcji operacyjnych nie może istotnie pogorszyć jakości kontroli wewnętrznej ani możliwości monitorowania zgodności przez nadzór. Drugi to wymagania produktowe: silne uwierzytelnianie klienta i interfejsy dla dostawców trzecich według rozporządzenia delegowanego (UE) 2018/389. Dostawca oprogramowania płatniczego musi te wymagania znać z praktyki, a nie z prezentacji. Jedna zmiana uprościła sytuację: dyrektywa (UE) 2022/2556, towarzysząca DORA, sprawiła, że podmioty objęte DORA raportują incydenty operacyjne i bezpieczeństwa związane z płatnościami w jednym, zharmonizowanym reżimie DORA.

Na horyzoncie jest pakiet PSD3 i rozporządzenie PSR. Parlament Europejski i Rada osiągnęły porozumienie polityczne 27 listopada 2025 roku, a teksty kompromisowe zatwierdził w kwietniu 2026 roku Komitet Stałych Przedstawicieli. Według analiz kancelarii większość przepisów PSR ma być stosowana około 21 miesięcy po publikacji. Dla wyboru dostawcy dziś oznacza to jedno: jeśli budujecie system płatniczy, który będzie działał w 2028 roku, zapytajcie dostawcę, jak planuje dostosowanie do PSR, w szczególności w obszarze przeciwdziałania oszustwom i open bankingu.

Wytyczne EBA w sprawie outsourcingu. Wytyczne EBA/GL/2019/02 stosowane od 30 września 2019 roku przez lata były głównym punktem odniesienia dla umów outsourcingowych w bankach i instytucjach płatniczych. Po wejściu DORA usługi ICT są regulowane przez rozporządzenie, a EBA od 8 lipca do 8 października 2025 roku konsultowała projekt nowych wytycznych dotyczących zarządzania ryzykiem stron trzecich w odniesieniu do usług innych niż ICT, które mają zastąpić wytyczne z 2019 roku. Dla dostawcy oprogramowania wniosek jest taki, że jego usługa będzie oceniana według DORA, ale jeśli obejmuje także elementy niebędące usługami ICT, na przykład obsługę procesu biznesowego, część relacji może podlegać wytycznym EBA.

Polskie przepisy i stanowiska KNF. Prawo bankowe w art. 6a–6d reguluje powierzanie przez banki wykonywania czynności przedsiębiorcom, czyli outsourcing bankowy, a art. 6d przewiduje zawiadomienie KNF o zamiarze zawarcia umowy z przedsiębiorcą zagranicznym. To, czy umowa na wytwarzanie i utrzymanie oprogramowania jest jednocześnie outsourcingiem w rozumieniu Prawa bankowego, zależy od tego, czy dostawca wykonuje czynności związane z działalnością bankową. To ocena prawna, którą warto zlecić przed wyborem dostawcy, bo wpływa na harmonogram. Do tego dochodzi komunikat UKNF z 23 stycznia 2020 roku dotyczący przetwarzania informacji w chmurze obliczeniowej publicznej lub hybrydowej. W grudniu 2024 roku UKNF zapowiedział jego uchylenie, wskazując, że jego przedmiot pokrywa się z obowiązkami z DORA i aktów wykonawczych, a termin uchylenia miał zostać podany w odrębnej informacji.

Wniosek z tej sekcji jest prosty: zapytanie ofertowe na oprogramowanie dla instytucji finansowej powinno powstać we współpracy działu IT, zgodności i prawnego, bo żadna z tych funkcji w pojedynkę nie widzi wszystkich warstw. Więcej o tym, jak regulacje wpływają na całość zgodności z regulacjami w IT, piszemy w słowniku.

Jak sprawdzić podwykonawców i łańcuch dostaw dostawcy?

Podwykonawstwo to obszar, w którym regulacje zmieniły się najbardziej w ostatnich miesiącach. Rozporządzenie delegowane Komisji (UE) 2025/532, określające elementy, które podmiot finansowy musi ustalić i ocenić przy podwykonawstwie usług ICT wspierających funkcje krytyczne lub istotne, zostało opublikowane w Dzienniku Urzędowym 2 lipca 2025 roku i weszło w życie 22 lipca 2025 roku. Jego historia jest pouczająca: Komisja w styczniu 2025 roku odrzuciła pierwszy projekt ESA, a w wersji ostatecznej usunięto kontrowersyjny przepis o kontroli całego łańcucha podwykonawców.

Dla wyboru dostawcy oprogramowania z tego rozporządzenia i z art. 30 ust. 2 lit. a wynika kilka pytań, które warto zadać przed podpisaniem umowy.

Kto faktycznie będzie pisał kod? W branży software house’ów często spotyka się model, w którym część zespołu to podwykonawcy, freelancerzy albo pracownicy firm partnerskich. Dla funkcji krytycznej musicie wiedzieć, czy dostawca korzysta z podwykonawców, w jakim zakresie i na jakich warunkach, oraz mieć prawo do sprzeciwu wobec zmiany istotnego podwykonawcy.

Na czym działa infrastruktura projektu? Repozytorium kodu, system CI/CD, środowiska testowe, narzędzia do zarządzania zadaniami. Każde z nich jest usługą, z której korzysta dostawca, i każde może przechowywać dane klienta. Lokalizacje tych usług trafiają do umowy na mocy art. 30 ust. 2 lit. b.

Czy warunki z waszej umowy przechodzą w dół łańcucha? Prawa audytu, obowiązki powiadamiania o incydentach i zasady ochrony danych są niewiele warte, jeśli kończą się na pierwszym ogniwie. Umowa z dostawcą powinna wymagać, by istotne obowiązki zostały przeniesione do umów z jego podwykonawcami.

Co się stanie, gdy podwykonawca zniknie? Dostawca powinien mieć plan zastąpienia kluczowego podwykonawcy, a w przypadku zespołów, także plan zastąpienia kluczowych osób. To wiąże się z ciągłością działania, którą DORA traktuje jako obowiązek, a nie dobrą praktykę.

Przy okazji: jeśli rozważany dostawca twierdzi, że w ogóle nie korzysta z podwykonawców, zapytajcie o narzędzia, na których pracuje. Prawie każdy zespół korzysta z usług chmurowych, a te są częścią łańcucha dostaw usług ICT, nawet jeśli nikt nie myśli o nich jak o podwykonawcach.

Co musi umieć dostawca, gdy dojdzie do poważnego incydentu?

DORA wprowadziła zharmonizowane terminy zgłaszania poważnych incydentów związanych z ICT. Według rozporządzenia delegowanego (UE) 2025/301 powiadomienie wstępne trzeba przekazać nadzorowi w ciągu czterech godzin od zaklasyfikowania incydentu jako poważnego, ale nie później niż 24 godziny od momentu, w którym podmiot dowiedział się o incydencie. Raport pośredni przekazuje się w ciągu 72 godzin od powiadomienia wstępnego, a raport końcowy nie później niż miesiąc po ostatnim raporcie pośrednim.

Te terminy biegną po stronie instytucji finansowej, ale ich dotrzymanie zależy od dostawcy. Jeśli incydent zaczyna się w systemie, który dostawca buduje lub utrzymuje, to dostawca często dowie się o nim pierwszy. Jeśli umowa wymaga od niego powiadomienia „niezwłocznie” bez dalszego określenia, w praktyce może to oznaczać następny dzień roboczy, a wtedy wasze cztery godziny na klasyfikację i zgłoszenie są już przeszłością.

Przy wyborze dostawcy oprogramowania warto sprawdzić cztery rzeczy.

Czas powiadomienia w umowie. Konkretna liczba godzin od wykrycia, z kanałem kontaktu dostępnym poza godzinami pracy. Dla systemów krytycznych mierzymy to w godzinach, nie w dniach.

Zawartość powiadomienia. Informacje, których potrzebujecie do klasyfikacji incydentu według kryteriów z rozporządzenia delegowanego (UE) 2024/1772: liczba dotkniętych klientów, czas trwania, dotknięte dane, zasięg geograficzny. Dostawca, który przekaże tylko „mamy awarię”, nie pomoże wam zakwalifikować incydentu.

Pomoc przy incydencie i jej koszt. Art. 30 ust. 2 lit. f wymaga, by pomoc przy incydentach była świadczona bez dodatkowych kosztów albo za koszt ustalony z góry. Ustalcie stawkę przed podpisaniem umowy.

Gotowość do udziału w testach. Jeśli wasza instytucja przeprowadza testy TLPT, a zakres obejmuje system dostawcy, ten musi w nich uczestniczyć. Zapytajcie, czy dostawca brał już udział w takich testach i jak wyglądała jego rola. Pytanie o to, jak organizuje zarządzanie ryzykiem w projektach IT, da odpowiedź na to, czy myśli o incydentach z wyprzedzeniem.

Dobrym ćwiczeniem przed wyborem jest wspólna symulacja incydentu: dwie godziny, scenariusz wycieku danych z środowiska testowego dostawcy, i obserwacja, kto, kiedy i z jakimi informacjami się odzywa. To mówi o dostawcy więcej niż dziesięć stron opisu procesów.

Jak zaprojektować strategię wyjścia, zanim podpiszesz umowę?

Art. 28 ust. 8 wymaga, by dla usług wspierających funkcje krytyczne lub istotne podmiot finansowy miał strategie wyjścia, które uwzględniają upadłość dostawcy, pogorszenie jakości usług, zakłócenia działalności i wypowiedzenie umowy. Wyjście musi być możliwe bez zakłócenia działalności, bez ograniczenia zgodności z przepisami i bez szkody dla ciągłości i jakości usług dla klientów. Plany wyjścia mają być kompleksowe, udokumentowane, wystarczająco przetestowane i okresowo przeglądane.

Art. 28 ust. 7 wymienia sytuacje, w których umowa musi dać się wypowiedzieć: istotne naruszenie przepisów lub warunków umowy, okoliczności wykryte w ramach monitorowania, które mogą zmienić sposób świadczenia usług, wykazane słabości w zarządzaniu ryzykiem ICT u dostawcy oraz sytuacja, w której nadzór nie może już skutecznie nadzorować podmiotu z powodu tej umowy.

W przypadku oprogramowania wytwarzanego na zamówienie strategia wyjścia ma trzy warstwy, i każdą trzeba zapisać w umowie przed wyborem dostawcy, nie po nim.

Prawa. Kto jest właścicielem kodu, dokumentacji, danych testowych, skryptów infrastruktury, konfiguracji? Jeśli dostawca zachowuje prawa do komponentów, które wnosi do projektu, na jakich warunkach możecie z nich korzystać po zakończeniu umowy? To pytanie łączy się z problemem, który opisaliśmy w tekście o unikaniu vendor lock-in: zależność od dostawcy powstaje częściej z konstrukcji umowy niż z technologii.

Wiedza. Kod bez dokumentacji architektury, decyzji projektowych i procedur wdrożeniowych da się przejąć, ale kosztownie. Umowa powinna określać, jaka dokumentacja jest utrzymywana przez cały czas trwania współpracy, a nie wytwarzana dopiero przy wyjściu, kiedy dostawca nie ma już motywacji.

Czas. Art. 30 ust. 3 lit. f wymaga okresu przejściowego, w którym dostawca nadal świadczy usługi. Jego długość zależy od złożoności systemu. Okres wypowiedzenia w umowie powinien być spójny z realistycznym czasem przejęcia systemu przez innego dostawcę albo zespół wewnętrzny.

Jak sprawdzić, czy strategia wyjścia jest wykonalna? Najlepszy test to niezależny przegląd kodu i dokumentacji przez trzecią stronę, przeprowadzony w trakcie współpracy, a nie dopiero przy wyjściu. Jeśli zewnętrzny zespół nie potrafi w rozsądnym czasie zrozumieć systemu, plan wyjścia istnieje tylko na papierze. Elementy takiego przeglądu opisujemy w liście kontrolnej technical due diligence.

Jak ułożyć kryteria oceny ofert, żeby regulacje ważyły tyle, ile powinny?

Tu wracamy do tezy. W typowym zapytaniu ofertowym na oprogramowanie kryteria oceny wyglądają mniej więcej tak: kompetencje techniczne i doświadczenie zespołu, metodyka, cena, czasem referencje. Wymagania regulacyjne pojawiają się jako warunek formalny („oferent oświadcza, że spełnia wymagania DORA”) albo jako aneks do umowy po wyborze. To układ, który nagradza dostawców deklarujących zgodność i karze tych, którzy rzetelnie wyceniają koszt spełnienia wymagań.

Proponujemy inny układ dla systemów wspierających funkcje krytyczne lub istotne. Wagi są naszą rekomendacją wynikającą z logiki ryzyka, a nie wymogiem przepisów. Każda organizacja powinna je dostosować do swojej polityki z rozporządzenia 2024/1773.

Kryterium	Waga (funkcja krytyczna)	Waga (funkcja niekrytyczna)	Jak weryfikować przed wyborem
Kompetencje techniczne i domenowe zespołu	35%	45%	Rozmowy techniczne, zadanie próbne, doświadczenie z PSD2/SCA, systemami płatniczymi
Akceptacja klauzul z art. 30 ust. 2 i 3	15%	10%	Komentarze dostawcy do projektu umowy dołączonego do zapytania
Łańcuch podwykonawców i lokalizacje danych	10%	5%	Wypełnione uproszczone szablony rejestru informacji, lista podwykonawców i usług chmurowych
Gotowość na incydenty i testy	10%	5%	Czas powiadomienia w umowie, symulacja incydentu, doświadczenie z TLPT
Wykonalność wyjścia	10%	5%	Plan przekazania systemu, standard dokumentacji, prawa do kodu i komponentów
Cena i model rozliczenia	20%	30%	Całkowity koszt z uwzględnieniem kosztów zgodności i zmian w rejestrze

Kryteria regulacyjne ważą tu łącznie 45% dla funkcji krytycznej, czyli więcej niż kompetencje techniczne i ponad dwa razy więcej niż cena. Dla funkcji niekrytycznej spadają do 25%, ale nie znikają, bo art. 30 ust. 2 obowiązuje każdą umowę na usługi ICT.

Najważniejsza zmiana nie dotyczy jednak wag, tylko momentu. Projekt umowy z klauzulami z art. 30 powinien być częścią zapytania ofertowego. Dostawca komentuje go w ofercie, a jego komentarze są oceniane. Wtedy cena w ofercie obejmuje koszt spełnienia wymagań, a nie jest ceną, która wzrośnie po negocjacjach. Więcej o tym, jak ocenić dostawców w sposób porównywalny, piszemy w tekście o pytaniach do dostawcy usług IT.

Kompetentny czytelnik może zaoponować: przecież dobry zespół techniczny jest najważniejszym zabezpieczeniem przed incydentem, a umowa niczego nie zbuduje. To prawda w odniesieniu do jakości kodu. Ale DORA nie pyta, czy system jest dobry, tylko czy instytucja kontroluje ryzyko związane z dostawcą i potrafi wykazać to nadzorowi. Dostawca o najlepszym zespole, który nie przyjmie praw audytu, jest dla funkcji krytycznej dostawcą, z którym nie wolno podpisać umowy. Nie da się tego zrekompensować punktami za kompetencje.

Jakie błędy popełniają instytucje finansowe przy wyborze dostawcy oprogramowania?

Większość typowych błędów nie wynika z braku wiedzy o DORA, tylko z kolejności działań. Poniższe wzorce wynikają wprost z konstrukcji przepisów: każdy z nich pojawia się wtedy, gdy wymagania regulacyjne trafiają do procesu za późno albo zastępują ocenę merytoryczną.

Klasyfikacja funkcji po wyborze dostawcy. Zespół projektowy wybiera dostawcę, a dział zgodności dopiero potem ocenia, czy usługa wspiera funkcję krytyczną. Jeśli tak, okazuje się, że oferty były oceniane bez kryteriów, które powinny decydować.

Aneks DORA jako formalność. Klauzule z art. 30 trafiają do aneksu, który dostawca podpisuje bez zmian, bo i tak wygrał przetarg. Rok później, przy pierwszym audycie, okazuje się, że dostawca nie jest w stanie wykonać tego, co podpisał, bo nie zmienił żadnego procesu.

Utożsamianie certyfikatu ze zgodnością. ISO/IEC 27001 jest wartościowym sygnałem dojrzałości dostawcy, ale nie zastępuje klauzul umownych, praw audytu ani planu wyjścia. Certyfikat dotyczy systemu zarządzania dostawcy, a DORA dotyczy waszej relacji z nim.

Pomijanie zespołów udostępnianych. Specjaliści w modelu body leasingu pracują w waszych systemach, często z szerokim dostępem, ale umowa z ich dostawcą bywa traktowana jak umowa kadrowa, a nie umowa na usługi ICT. To luka, którą nadzór łatwo zauważy w rejestrze.

Niedoszacowanie ruchu w rejestrze. Każda zmiana podwykonawcy, lokalizacji danych czy zakresu usług to aktualizacja rejestru. Dostawca z niestabilnym łańcuchem dostaw generuje stały koszt administracyjny, którego nie widać w stawce.

Ignorowanie kompetencji domenowych. Odwrotny błąd: tak duży nacisk na umowę, że dostawca bez doświadczenia z systemami finansowymi wygrywa, bo zgodził się na wszystkie klauzule. Dostawca, który nie wie, czym jest silne uwierzytelnianie klienta, wytworzy system, który spełni wymagania umowne i nie spełni produktowych. Dlatego w naszej tabeli kompetencje techniczne nadal są największym pojedynczym kryterium.

Jak uniknąć tych błędów: sekwencja przed zapytaniem ofertowym

Jeśli wybór dostawcy oprogramowania dla instytucji finansowej jest przed wami, proponujemy sekwencję, którą da się przeprowadzić w kilka tygodni przed wysłaniem zapytania ofertowego.

Tydzień pierwszy: klasyfikacja. Ustalcie, czy oprogramowanie będzie wspierać funkcję krytyczną lub istotną, według metodyki z waszej polityki. Zapiszcie uzasadnienie. Sprawdźcie, czy nowa umowa nie zwiększa ryzyka koncentracji.

Tydzień drugi: warstwy regulacyjne. Z działem prawnym ustalcie, czy umowa będzie także outsourcingiem w rozumieniu Prawa bankowego albo PSD2, czy wymaga zawiadomienia KNF i czy obejmuje elementy niebędące usługami ICT.

Tydzień trzeci: projekt umowy. Przygotujcie projekt umowy z klauzulami z art. 30 ust. 2, a dla funkcji krytycznej także z ust. 3. Określcie konkretne liczby: czas powiadomienia o incydencie, długość okresu przejściowego, zakres praw audytu.

Tydzień czwarty: zapytanie ofertowe. Dołączcie projekt umowy, uproszczone szablony rejestru do wypełnienia i kryteria oceny z wagami. Zaplanujcie w harmonogramie czas na zgłoszenie planowanej umowy do nadzoru, jeśli dotyczy funkcji krytycznej.

Po wyborze: weryfikacja w trakcie. Zaplanujcie pierwszy audyt dostawcy, pierwszy test planu ciągłości działania i pierwszy niezależny przegląd kodu i dokumentacji, który sprawdzi wykonalność wyjścia. Art. 28 ust. 6 wymaga, by częstotliwość i zakres audytów były ustalone z wyprzedzeniem, na podstawie oceny ryzyka.

Ta sekwencja wydłuża przygotowanie zapytania o kilka tygodni. Skraca natomiast negocjacje, eliminuje dostawców, którzy nie spełnią wymagań, zanim zainwestujecie w nich czas, i sprawia, że cena w ofercie jest ceną ostateczną.

Jakie są kluczowe wnioski przed wyborem dostawcy oprogramowania dla finansów?

DORA nie zmieniła tego, czego potrzebuje dobry system finansowy: kompetentnego zespołu, który rozumie domenę. Zmieniła natomiast to, co trzeba sprawdzić, zanim taki zespół zostanie wybrany, i kiedy trzeba to zrobić. Zgodność z rozporządzeniem jest obowiązkiem instytucji finansowej, a nie cechą dostawcy, więc zapewnienie „jesteśmy zgodni z DORA” nie jest argumentem w ocenie ofert.

Zapamiętaj sześć rzeczy. Po pierwsze, sklasyfikuj funkcję, którą wspiera oprogramowanie, zanim napiszesz zapytanie ofertowe, bo od tego zależy zakres wymagań. Po drugie, traktuj projekt rozwojowy połączony z utrzymaniem lub stałym zespołem jako usługę ICT, która trafia do rejestru. Po trzecie, dołącz projekt umowy z klauzulami z art. 30 do zapytania ofertowego i oceniaj komentarze dostawców. Po czwarte, poproś o dane do rejestru informacji i listę podwykonawców na etapie oferty. Po piąte, zapisz w umowie konkretny czas powiadomienia o incydencie, spójny z terminami z rozporządzenia 2025/301. Po szóste, zaprojektuj wyjście przed podpisaniem umowy i sprawdzaj jego wykonalność w trakcie współpracy.

Jeśli przygotowujesz wybór dostawcy dla systemu finansowego i chcesz porozmawiać o tym, jak dostawca może wpisać się w wasze wymagania, zobacz, jak pracujemy w tworzeniu oprogramowania na zamówienie i w zespołach specjalistów IT dla fintech i bankowości, albo umów rozmowę. Chętnie odniesiemy się do waszego projektu umowy jeszcze przed zapytaniem ofertowym.