DORA i umowy z dostawcami ICT: rejestr informacji, klauzule audytowe i realny plan wyjścia

DORA reguluje odpowiedzialność instytucji, a nie tylko zachowanie dostawcy

Rozporządzenie (UE) 2022/2554 (DORA) stosuje się od 17 stycznia 2025 r. do kategorii podmiotów finansowych wskazanych w art. 2, z przewidzianymi w nim wyłączeniami i zasadą proporcjonalności. Nie można więc zakładać, że każdy przedsiębiorca kupujący usługi IT jest bezpośrednio adresatem wszystkich obowiązków DORA. Art. 28 ust. 1 lit. a podkreśla, że podmiot finansowy zachowuje pełną odpowiedzialność za wypełnianie swoich obowiązków nawet po zawarciu umowy z zewnętrznym dostawcą ICT. W praktyce outsourcing technologii nie oznacza outsourcingu odpowiedzialności regulacyjnej. Punkt wyjścia stanowi prawidłowe zmapowanie funkcji biznesowych, zasobów cyfrowych oraz zależności od dostawców.

Rejestr informacji to strukturalny obowiązek, nie zwykły wykaz umów

Art. 28 ust. 3 DORA nakłada obowiązek prowadzenia i aktualizacji rejestru informacji dotyczących ustaleń umownych z zewnętrznymi dostawcami usług ICT. Szczegółowy model danych określa rozporządzenie wykonawcze Komisji (UE) 2024/2956. Rejestr obejmuje określone kategorie danych o podmiotach, umowach, funkcjach, usługach i łańcuchu dostaw. Dane należy utrzymywać w spójnej strukturze na poziomie właściwym dla pojedynczego podmiotu i — jeżeli ma to zastosowanie — grupy. Zestawienie plików PDF w folderze „IT Contracts” nie jest tym samym co rejestr spełniający formalne wzory i wymagania jakości danych. Szczególne znaczenie ma poprawność identyfikatorów, w tym LEI oraz powiązań między rekordami.

Usługi wspierające funkcje krytyczne lub istotne

DORA odróżnia zwykłe usługi ICT od takich, które wspierają funkcje krytyczne lub istotne. W drugim przypadku wymagania dotyczące umów, oceny dostawców i planów wyjścia stają się bardziej rygorystyczne. Sam dział IT nie powinien dowolnie decydować, czy system jest krytyczny: potrzebna jest ocena wpływu przerwy na świadczenie usług klientom, zgodność regulacyjną, bezpieczeństwo danych i ciągłość działalności. Wynik powinien być udokumentowany i aktualizowany w razie zmiany funkcji systemu, dostawcy lub modelu podwykonawstwa. To rozróżnienie pozwala stosować kontrolę proporcjonalnie zamiast traktować każdą umowę licencyjną jak outsourcing bankowego systemu transakcyjnego.

Klauzule z art. 30: przedmiot, lokalizacje, dostęp i pomoc

Art. 30 DORA określa minimalne postanowienia umowne. Kontrakt powinien w szczególności opisywać usługi, zasady dalszego podwykonawstwa, lokalizacje świadczenia i przetwarzania danych, dostępność, autentyczność, integralność i poufność danych, warunki pomocy w razie incydentu oraz prawa wypowiedzenia i zakończenia współpracy. Dla funkcji krytycznych lub istotnych dochodzą dalsze wymagania, w tym odpowiednie prawa dostępu, kontroli i audytu oraz szczegółowe kwestie poziomu usług, monitorowania i współpracy z organami nadzoru. Gotowa umowa dostawcy spoza sektora finansowego nie musi uwzględniać tych elementów. Przed podpisaniem trzeba sprawdzić, czy zobowiązania są rzeczywiście wykonalne.

Podwykonawcy, usługi grupowe i ryzyko koncentracji

Usługa ICT może opierać się na wielopoziomowym łańcuchu podmiotów, w tym operatorach infrastruktury i centrach danych, których klient nie widzi wprost. Umowa powinna zapewniać odpowiedni poziom przejrzystości tego łańcucha i mechanizmy kontroli zmian, szczególnie gdy usługa wspiera funkcję krytyczną lub istotną. Nie należy automatycznie zakładać, że podmiot świadczący usługę wewnątrz tej samej grupy kapitałowej jest poza regulacją: DORA obejmuje również odpowiednio zorganizowane usługi wewnątrzgrupowe. Podmiot finansowy powinien badać także koncentrację ryzyka, np. zależność wielu funkcji od jednej technologii, regionu infrastruktury lub jednego dostawcy.

Plan wyjścia: kiedy przejście jest realne, a nie wyłącznie możliwe w teorii

Art. 28 DORA nakazuje opracowanie odpowiednich planów wyjścia w odniesieniu do usług ICT wspierających funkcje krytyczne lub istotne. Regulacyjny standard techniczny 2024/1773 doprecyzowuje politykę dotyczącą takich umów. Plan powinien zawierać realistyczne scenariusze niepowodzenia dostawcy, sposób pobrania danych i odzyskania funkcji, alternatywne rozwiązania, harmonogram oraz mierzalne kryteria powodzenia. Nie wystarczy deklaracja „po rozwiązaniu umowy klient otrzyma eksport”. Istotne są format, zasoby niezbędne do uruchomienia, uprawnienia administracyjne, dokumentacja API, odtworzenie kopii i prawa do komponentów zależnych. Plan powinien podlegać odpowiednim testom i aktualizacjom.

Audyt dostawcy a tajemnica handlowa i bezpieczeństwo

Umowne prawo audytu musi być skonstruowane tak, aby umożliwiało ocenę zgodności i bezpieczeństwa, ale nie oznaczało dowolnego dostępu pracowników klienta do wszystkich danych innych odbiorców usługi. Zależnie od architektury możliwe są audyty wspólne, raporty niezależnych podmiotów, testy uzgodnione oraz kontrole wykonywane przez uprawnione organy. Kluczowe jest uzgodnienie, jakie dowody zapewnia dostawca, z jaką częstotliwością, w jakim terminie po incydencie i jak dokumentuje usunięcie stwierdzonych niezgodności. Odmowa jakiegokolwiek prawa weryfikacji przy usłudze krytycznej może uczynić kontrakt trudnym do obrony regulacyjnie.

Przykład: operator finansowy korzystający z chmury transakcyjnej

Instytucja finansowa zawiera umowę na utrzymanie systemu obsługi klientów, klasyfikuje tę usługę jako wspierającą funkcję istotną i wpisuje ją do rejestru informacji. Po roku dostawca zmienia podwykonawcę infrastruktury, a próba odtworzenia danych ujawnia brak dokumentacji interfejsów. Audyt nie powinien poprzestać na znalezieniu podpisanego aneksu. Trzeba ustalić wpływ zmiany na ryzyko koncentracji, prawa kontroli, harmonogram aktualizacji rejestru i możliwość rzeczywistego zakończenia współpracy. Dopiero zestawienie umowy, dowodów technicznych i testu migracji pozwala mówić o funkcjonującym modelu odporności cyfrowej.

Matryca kontroli kontraktu ICT przed podpisaniem

Przy przeglądzie umowy warto zastosować macierz o czterech kolumnach: obowiązek DORA, odpowiadająca mu klauzula, dowód wykonania i ryzyko pozostałe. Klauzula o dostępności usługi powinna przekładać się na mierzalny SLA, procedurę powiadomień, sposób eskalacji i udokumentowane wyniki testów. Klauzula dotycząca bezpieczeństwa powinna być powiązana z kontrolą dostępu, logowaniem, zarządzaniem poprawkami i prawami klienta do otrzymania informacji o zdarzeniu. Postanowienia o podwykonawcach wymagają mechanizmu zgłaszania istotnych zmian oraz sposobu oceny ich skutków. Dobre ujęcie umowne nie polega na dodaniu do kontraktu deklaracji o „pełnej zgodności z DORA”, lecz na sprawdzalnym przypisaniu obowiązków obu stronom.

Jakość danych w rejestrze informacji i nadzór korporacyjny

Rejestr informacji powinien mieć właściciela biznesowego oraz jasno przydzielone role w zakresie aktualizacji i akceptacji danych. Nieprawidłowe LEI, niespójny identyfikator kontraktu czy niezmapowany podwykonawca mogą utrudnić sporządzenie danych wymaganych przez nadzór. Rozporządzenie 2024/2956 operuje szczegółowymi szablonami, a ich pola i relacje trzeba kontrolować na poziomie jakości, nie jedynie kompletności wizualnej arkusza. Zarząd powinien otrzymywać raport o kluczowych brakach, nieaktualnych umowach, niespełnionych wymaganiach krytycznych usług i odsetku przetestowanych planów wyjścia. Nie da się wiarygodnie zarządzać ryzykiem grupy, jeżeli poszczególne spółki stosują sprzeczne nazwy lub identyfikatory tych samych dostawców.

Współistnienie DORA, RODO i innych obowiązków

DORA nie eliminuje obowiązków ochrony danych osobowych ani nie przejmuje całej regulacji outsourcingu sektorowego. Jeżeli zewnętrzny dostawca ICT przetwarza dane osobowe w imieniu instytucji finansowej, należy odrębnie zweryfikować art. 28 RODO, role administratora i procesora, transfery poza EOG oraz mechanizmy realizacji praw osób. Incydent ICT nie jest zawsze naruszeniem ochrony danych, a naruszenie ochrony danych nie musi odpowiadać kryteriom głównego incydentu ICT według DORA. Klauzule umowne powinny rozdzielać te reżimy, przewidywać równoległe obowiązki informacyjne i unikać chaosu kompetencyjnego. Dotyczy to zwłaszcza scenariusza, w którym to samo zdarzenie wymaga reakcji jednostki bezpieczeństwa, inspektora ochrony danych i osób odpowiedzialnych za kontakt z nadzorem finansowym.

Wniosek dla praktyki

DORA traktuje odporność cyfrową jako element ładu i kontroli podmiotu finansowego. Dopiero połączenie klasyfikacji usług, jakości rejestru informacji, egzekwowalnych klauzul z art. 30 oraz przetestowanego planu wyjścia tworzy model nadający się do wykazania nadzorowi. Sama deklaracja dostawcy o zgodności z regulacją nie zapewnia możliwości odzyskania kontroli nad krytyczną usługą.

Źródła urzędowe i materiały pomocnicze

• DORA, rozporządzenie (UE) 2022/2554, art. 2, 28 i 30: https://eur-lex.europa.eu/eli/reg/2022/2554/oj/pol
• Rozporządzenie wykonawcze (UE) 2024/2956 — wzory rejestru informacji: https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj/pol
• Rozporządzenie delegowane (UE) 2024/1773 — polityka umów krytycznych ICT: https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32024R1773
• Komisja Nadzoru Finansowego — informacja o rejestrze informacji: https://www.knf.gov.pl/dla_rynku/dora/aktualnosci/rozporzadzenie_wykonawcze_UE_dotyczace_standardowych_wzorow_na_potrzeby_rejestru_informacji?articleId=91651&p_id=18

Opracowanie ma charakter informacyjny i nie zastępuje analizy konkretnego stanu faktycznego.