Jak przygotować rejestr informacji umownych, by był zgodny z DORA?

0
1489

Wiemy, że DORA będzie stosowana od 17 stycznia 2025 r. Wprowadzenie DORA to wyzwanie, ale także szansa na zbudowanie silniejszych, bardziej odpornych na zagrożenia struktur operacyjnych.

W dobie wysokiego skomplikowania usług ICT oraz częstego outsourcingu nawet krytyczne funkcje podmiotów finansowych i ubezpieczeniowych są realizowane przez dostawców zewnętrznych. DORA znacząco zmienia relację między podmiotem finansowym a jego dostawcami ICT. Nakłada m.in. obowiązek prowadzenia rejestru umów z dostawcami ICT, by zwiększyć świadomość organów sprawujących nadzór nad zależnością podmiotów finansowych od zewnętrznych dostawców usług ICT.

– Rejestr informacji, który obejmuje ustalenia umowne, dostarcza organom sprawującym nadzór kompleksowy obraz relacji między instytucjami finansowymi a dostawcami usług ICT. Ułatwia monitorowanie, analizowanie i ocenę ryzyka związanego z zależnościami od dostawców ICT oraz podejmowanie odpowiednich działań kontrolnych, wspierając tym samym ogólną odporność sektora finansowego na incydenty związane z technologią – wyjaśnia Mikołaj Otmianowski, ekspert firmy DAPR oferującej oprogramowanie GRC dla instytucji finansowych i dostawców ICT do zarządzania DORA.

Do rozporządzenia DORA opublikowane zostały regulacyjne standardy techniczne (RTS). Jednym z RTS jest wykonawczy standard techniczny (ITS) dotyczący rejestru postanowień umownych (JC 2023 85). Określa on szablony informacji, jakie powinny być utrzymywane i aktualizowane przez podmioty finansowe w kontekście ich umów z zewnętrznymi dostawcami usług ICT. To konkretne narzędzie w implementacji DORA, wspomaga podmioty finansowe w osiągnięciu wysokiego stopnia świadomości w zakresie korzystania z zewnętrznych usług ICT.

Co należy zawrzeć w rejestrze umów z dostawcami ICT

Rejestr ten obejmuje takie informacje, jak ogólne dane o podmiocie finansowym, identyfikację jednostek w zakresie konsolidacji grupy kapitałowej, szczegółowe informacje dotyczące umów świadczenia usług ICT, w tym także pomiędzy podmiotami w ramach grupy, szczegółową identyfikację łańcuchów dostaw usług ICT oraz ocenę stopnia zależności od usług ICT, które wspierają funkcje krytyczne lub istotne. Szczegółowy zakres i formularze zostały określone w odpowiednich szablonach wzoru rejestru.

Przykładowo, w kontekście umów z dostawcami usług ICT – wytyczne wymagają wskazania ich rodzaju (np. umowy ramowe czy implementacyjne). W praktyce oznacza to, że w przypadku umów, które obejmują wiele usług ICT wspierających różne funkcje finansowego podmiotu, każdy z tych elementów powinien być ujęty w formie oddzielnego wiersza w szablonie rejestru. To podejście ma na celu utrzymanie maksymalnej przejrzystości.

– Stworzenie rejestru, który holistycznie opisuje zagadnienie współpracy z dostawcami ICT, który równocześnie będzie responsywny, pozwalający na częste aktualizacje, nie jest łatwe. Warto rozważyć przeznaczone do tego narzędzia informatyczne. W tym celu rozwijamy RIG DORA, oprogramowanie, które pomoże w zapewnieniu zgodności z DORA także w tym zakresie – dodaje Mikołaj Otmianowski.  

Wyzwania dla ubezpieczycieli

Rodzaje działalności. Dzisiejsze produkty ubezpieczeniowe często obejmują kilka kategorii jednocześnie. Tymczasem rodzaje działalności wymienione jako zamknięta lista we wzorze rejestru opisują pojedyncze kategorie ubezpieczeń według dyrektywy Solvency II. Przykładowo pakiet ubezpieczeniowy dla lekarzy może obejmować aż cztery:

  • Non-Life Insurance: Classes 1 and 2: Accident and Health Insurance
  • Non-Life Insurance: Classes 8 and 9: Insurance against Fire and other Damage to Property”
  • Non-Life Insurance: Classes 10, 11, 12 and 13: Liability Insurance
  • Non-Life Insurance: All classes, at the choice of the Member States, which shall notify the other Member States and the Commission of their choice.

W rezultacie pakiet ten i wspierające go procesy oraz zasoby ICT muszą być uwzględnione w co najmniej czterech funkcjach zakładki RT.06 rejestru.

Zmapowanie w ten sposób całej firmowej architektury produktów i procesów z pewnością stanowić będzie duże wyzwanie, zwłaszcza że kategorie ubezpieczeń niemajątkowych podane we wzorze rejestru w sposób połączony, według dyrektywy Solvency II nie przekładają się 1:1 na polski podział według ustawy z 11 września 2015 r. o działalności ubezpieczeniowej i reasekuracyjnej, w której grupy te są w pełni rozwinięte – mówi Otmianowski.

Spójność z raportowaniem do KNF. Biorąc pod uwagę powyższe, produkty i wynikające z nich rodzaje działalności wymienione w rejestrze mogą nie być w pełni zgodne z tymi raportowanymi obecnie cyklicznie do KNF.

Należy tutaj dokonać odpowiedniego przeglądu i ustalić, jak produkty będą miały się do siebie w obu ujęciach. W przypadku niespójności organ prawdopodobnie poleci skorygować rejestr.

Relacje z dostawcami usług ICT. Pewnym wyzwaniem będzie również fakt, że nie wszystkie relacje z dostawcami usług ICT, jakie posiada organizacja, będą wspierać funkcje związane ze świadczeniem usług ubezpieczeniowych. W firmach mogą występować zasoby ICT, które wspierają inne obszary działalności, np. rekrutację czy obsługę księgową. Zgodnie z wytycznymi technicznymi JC 85, takie zasoby powinny być przypisane do kategorii Support functions. Niestety, na zamkniętej liście działalności do wyboru nie ma takiej pozycji.

Automatyzacja procesów zarządzania ryzykiem

Zapewnienie zgodności z regulacjami DORA wymaga dużych nakładów pracy przy zgromadzeniu wymaganych informacji oraz wykorzystania odpowiednich narzędzi GRC, np. RIG DORA, bez których stworzenie i aktualizowanie dokumentacji tak rozbudowanej sieci zależności wydaje się niemal niewykonalne.

Narzędzie to ułatwia zarówno tworzenie samej dokumentacji, w tym w/w rejestru, ale także zarządzanie ryzykiem ICT w wymaganym zakresie, we współpracy pomiędzy różnymi działami firmy.

RIG DORA przyjmuje metodykę oceny ryzyka według podejścia opartego na aktywach (Asset Based Approach), zgodną z DORA, a także RODO i NIS2.