Jak rozumieć usługi ICT w rozporządzeniu DORA?

Zdaje sobie sprawę, choć pierwszy i przedłużony obowiązek sprawozdawczy w zakresie DORA jest już za instytucjami finansowymi, to wciąż istnieją przestrzenie rozporządzenia DORA, które wymagają szlifowania.

Tak chociażby jest z umowami, które wciąż są negocjowane, w których zmienia się przedmiot, warunki SLA, czy dodaje plany wyjścia.

Kiedy usługa jest usługą ICT?

❓I wciąż aktualne są pytania o to, czy dana usługa jest rzeczywiście usługą ICT. A jeśli jest, to czy wspiera krytyczne funkcje instytucji ❓A jeśli tak, to czy należy badać cały łańcuch dostawców ❓

Odpowiedzi na te pytania często wywołują zgrzyty praktyczne takie jak:

• Dostawca nie chce w ogóle z instytucją zawrzeć aneksu DORA, przy czym nie neguje tego, że jest dostawcą ICT.

Nie zawiera aneksu i już. Czasami przedstawia swoje gwarancje przestrzegania standardów DORA w formie ogólnodostępnej informacji. 

🧐Trudno jest  przenieść takie ujawnienia do umowy, choć czasami można. Większy problem widzę w tym, że niejednokrotnie są to oświadczenia bardzo ogólne, bez konkretnych obowiązków dostawcy.

• Dostawca przyjmuje, że jest dostawcą ICT, jednak sam decyduje, że wspiera jedynie niekrytyczne (non-CIF) funkcje biznesowe instytucji i godzi się jedynie na klauzule umowne typowe dla usług, które nie są krytyczne.

Czasami jest to narzucone, choć rzeczywiście jest to rola i odpowiedzialność podmiotu finansowego.

• Dostawca przyjmuje, że świadczy usługi ICT, zgadza się na wzorcowe klauzule DORA, jednak w wielu miejscach polega na gwarancjach swojego podwykonawcy.

Nie zawsze te gwrancje można zweryfikować. Nie może tego zrobić podmiot finansowy, ani sam dostawca.

• Dostawca nie chce zawrzeć aneksu i uważa, że w ogóle nie spełnia on definicji usługi ICT.

Dostawcy robią to, gdy mają stosunkowo niewiele klientów z sektora finansowego i nie opłaca im się dostosowywać. Niekiedy też dostawca próbuje przerzucić cały koszt dostosowania tylko na jednego klienta. Obie z tych opcji nie prowadzą zwykle do zawarcia umowy.

• Okazuje się, że reseller licencji na oprogramowanie ma marginalną usługę supportu, co skutkuje tym, że strony decydują się na rezygnację z jego usługi i wskazanie, że za dostosowanie do DORA w pełni odpowiada rzeczywisty dostawca ICT.

💡Ten ostatni przypadek może wywoływać pewne trudności w sporządzaniu rejestru informacji o klauzulach umownych (rejestru DORA), ponieważ w kosztach umowy po stronie rzeczywistego dostawcy wartość wynosić będzie “0”, a realne koszty usługi pojawią się przy resellerze, który wystawia fakturę. Pomimo, że ten reseller nie dostarcza żadnej usługi ICT.

Co mówi o definicji ICT DORA?

Zacznijmy od motywu 35, kolejno przejdziemy do definicji DORA, by skończyć na RTS 2025/2023 dotyczącym subcontractingu.

Aby utrzymać wysoki poziom operacyjnej odporności cyfrowej całego sektora finansowego, a jednocześnie dotrzymać kroku rozwojowi technologicznemu, niniejsze rozporządzenie powinno zwalczać ryzyko wynikające ze wszystkich rodzajów usług ICT. W tym celu definicję usług ICT w kontekście niniejszego rozporządzenia należy rozumieć szeroko jako obejmującą usługi cyfrowe i usługi w zakresie danych świadczone w sposób ciągły za pośrednictwem systemów ICT na rzecz co najmniej jednego użytkownika wewnętrznego lub zewnętrznego. Definicja ta powinna na przykład obejmować tzw. usługi OTT, które należą do kategorii usług łączności elektronicznej. Powinna wyłączać jedynie ograniczoną kategorię tradycyjnych usług telefonii analogowej kwalifikujących się jako usługi publicznej komutowanej sieci telefonicznej (PSTN), usługi z wykorzystaniem linii naziemnej, podstawowej usługi telefonicznej (POTS) lub usługi telefonii stacjonarnej.

Według tego motywu DORA wnioskujemy, że definicja jest szeroka i wyłączeni są z niej dostawcy telefonii analogowej. To jest również potwierdzone w definicjach zawartych w art. 3 DORA.

Sięgnijmy teraz usług ICT z rozporządzenia DORA

“usługi ICT” oznaczają usługi cyfrowe i usługi w zakresie danych świadczone w sposób ciągły za pośrednictwem systemów ICT na rzecz co najmniej jednego użytkownika wewnętrznego lub zewnętrznego, łącznie ze sprzętem komputerowym jako usługą i usługami w zakresie sprzętu komputerowego obejmującymi zapewnianie wsparcia technicznego za pośrednictwem aktualizacji oprogramowania lub oprogramowania układowego przez dostawcę sprzętu, z wyłączeniem tradycyjnych usług telefonii analogowej.

A zatem mamy:

1. usługę cyfrową,
2. usługę ciągłą,
3. system ICT
4. co najmniej jednego usera,
5. także sprzęt komputerowy rozumiany jako usługa (HaaS)

DORA a sprzęt komputerowy

Punkt piąty w praktyce wywołujei zagwozdki. Czy  z niego wynika, że z kategorii dostawców powinniśmy wyłączyć dostawców sprzętu?

Niekoniecznie – jeśli spojrzymy na to w kontekście definicji usługi ICT oraz praktyki rynku.

Kiedy będziemy mieć dostawcę, który przychodzi do nas z urządzeniami, na których zainstalowany jest firmware – trudno będzie mówić o wyłączeniu tej usługi spod DORA.

Podobnie będzie – jeśli ten sprzęt zostanie nam zaoferowany z usługą jego serwisu, w tym aktualizacji oprogramowania – tutaj również pojawi się usługa ICT.

Za to inaczej będzie jeśli umówimy się po prostu na dostawę sprzętu. Moim zdaniem taka umowa nie ma: [1] charakteru cyfrowej, [2] nie jest ciągła, [3] nie potrzebny jest do niej system ICT, [4] nie identyfikujemy w jej przypadku userów systemów. Nie ma tam po prostu usługi ICT.

A co na to ITS dot. rejestru informacji (2024/2956)

Załącznik III tego ITS – wskazuje, tzw. 19 “eSek” – identyfikatorów z usługami ICT.

Ten katalog oczywiście jest również pomocny w kwalifikowaniu usług ICT. Nie jestem jednak zdania, że jest on absolutny. To znaczy, że w przypadku, kiedy dostawca upierałby się, że jego usługa nie pasuje do żadnego rodzaju z 19 S, to instytucja finansowa nie jest zwolniona jest z samodzielnej oceny usług dostawcy. Uważam, że mogą istnieć usługi, które spełniać będą definicję usługi ICT, będą wymagały zarządzania od strony ryzyka ze strony dostawców ICT i jednocześnie mogą nie pasować do żadnego typu rodzaju usług z ITS.

Poniżej uproszczona tabela wygenerowana w Perplexity:

A teraz uwaga, czy sytuacja może być odwrotna?

Powyżej stwierdziłem, że może dochodzić do sytuacji, kiedy dana usługa spełnia definicję z 3 (21) DORA, a jednocześnie nie pasuje do żadnej usługi z ITS. Kiedy jednak przyjrzymy się rodzajom usług, które wymieniono w ITS – może okazać się, że ITS ten jest jeszcze szerszy niż definicja z DORA.

Jeśli weźmiemy np. S15 – ICT consulting (doradztwo w zakresie ICT), które wprost jest określone jako świadczenie usług intelektualnych, to nie mam wątpliwości, że tego typu usługa może nie spełniać wszystkich cech z przywoływanej definicji usługi ICT w DORA. 

A mimo to jest ona wprost wymieniona w ITS, a zatem jako taka nadająca się do oceny i wskazania w rejestrze informacji DORA.

Podobnie będzie z S01, czyli usługą PMO (zarządzanie projektami ICT).

W mojej ocenie to ma znaczenie dla właścicieli umów i wymaga szczególnego dostosowania.

Wedle ITSu usługi konsultanta, do których przypominam: nie potrzebujemy systemu ICT, nie identyfikujemy użytkownika, nie musimy nawet identyfikować elementu cyfrowego – powinniśmy zakwalifikować jako usługi ICT.  To znaczy, że będzie to wymagało szczegółowego opisania w umowie i dostosowania wzorcowych klauzul. Trudno będzie przecież wymagać od konsultanta – warunków SLA jak dla rozwiązania SaaS, czy też wprowadzania określonych mechanizmów bezpieczeństwa w toku świadczenia usługi.

Czy istnieje trzecia droga?

Tak. Dla tych, którzy mają większy apetyt na to, by ograniczyć krąg dostawców ICT – można zastanowić się nad innym sposobem interpretacji. A mianowicie mógłby on polegać na tym, że: dostawca ICT po pierwsze musi mieścić się w zakresie definicji usług ICT z art. 3 (21) DORA i jednocześnie w jednym z rodzajów z usług z ITS. Taka interpretacja ma też wymiar praktyczny, bo jeśli usługa jest typowa intelektualna, to trudno od takiego dostawcy racjonalnie wymagać spełnienia większości wymogów DORA.

💡przy tym pamiętam jednak, że wejście nawet z poziomu konsultingu do systemów klienta, jak najbardziej może uzasadniać wyświetlenie ryzyka ICT po stronie klienta i decyzję o traktowaniu takeigo dostawcy jak dostawcę usług ICT.

Taka interpretacja w praktyce oznaczałaby, że wspomniane wcześniej usługi ICT obejmujące aspekt intelektualny (konsulting) nie są usługami ICT w rozumieniu DORY, o ile nie są świadczone cyfrowo za pośrednictwem systemu IT.

Zakładam, że mogą one mieć znaczenie dla oceny ryzyka ICT z uwagi na samą materię, której dotyczą. Choć drugi wilk we mnie nakazuje dostrzeć pewną nieracjonalność wprowadzania standardu DORA do typowej usługi konsultingu. Zostaję przy tym przykładzie, ponieważ łatwo mi sobie wyobrazić taką usługę (nawet jeśli dotyczy IT, czy zarządzania ryzykiem ICT) całkowicie bez elementu cyfrowego. Trudniej mi zaś ją sobie wyobrazić przy roli PMO, choć i w tym przypadku wystąpić może sytuacja, kiedy ten PMO będzie miał jedynie dostęp do systemów zarządzanych przez instytucję. A zatem jego obecność w systemach i dostęp do danych chroniony tajemnicą – oczywiście może mieć wpływ na ryzyko ICT, choć i tym razem trudno wymagać od takiego dostawcy standardu SLA, czy wdrażania mechanizmów bezpieczeństwa.

Element IT usługi jest tylko pomocniczy dla usługi regulowanej

Identyfikując usługi ICT warto również pamiętać o pojęciu digital-backed financial services, które było promowane jeszcze zanim pojawiło się stanowisko EIOPY w sprawie interpretacji usług ICT. Wtedy to oczekiwano, aby Komisja Europejska wyjaśniła, że usługi świadczone przez podmioty finansowe na rzecz innych podmiotów finansowych nie są usługami ICT w rozumieniu DORA. Chodziło o to, żeby standardy odpowiadały praktyce tych usług, i by nie powielać reżimu regulacyjnego.

Stanowisko EIOPY w zasadzie wyjaśniło rolę instytucji finansowych, które wykorzystują systemy IT. W skrócie wynika z niego, że jeśli instytucja regulowana wykorzystuje do swojej usługi regulowanej – elementy IT, to nie staje się ona z automatu dostawcą ICT. 

Problem wróci jedynie w przypadku, kiedy instytucja finansowa zaoferuje usługę ICT jako coś extra. Wówczas najprawdopodobniej powinno dojść do kwalifikacji takiej instytucji jako dostawcy ICT. 

Jeśli potrzebujesz więcej informacji na temat instytucji finansowych w kontekście świadczenia usług IC, to pisałem o tym również na linkedin w ramach newslettera The Essence.

A co z poddostawcami?

Jeśli idzie o poddostawców, to pozostaje mi jedynie zaakcentować, że to również będzie wychodziło w temacie kwalifikacji usług ICT pod DORA. Szczególnie w modelu resellingu – tam może okazać się, że reseller zostanie zakwalifikowany jako dostawca usług ICT (np. w ramach pierwszej linii supportu), ale główny komponent usługi będzie po stronie poddostawcy resellera. I na taki wypadek przewidziany został wydany w lipcu 2025 – RTS dotyczący subcontractingu.

Z tego RTSa wynika przede wszystkim, że instytucje powinny badać cały łańcuch dostaw oraz przeprowadzać badanie DD poddostawcy, który wspiera krytyczne funkcje instytucji.

Z RTS 2025/523 wynikają również określone wymagania umowne. Instytucje od dostawców powinny wymagać:

1. jasnego wskazania, którego usługi będą wspierane przez poddostawcę,
2. informacji o pełnym łańcuchu subdostawców, którzy dotykają funkcji krytycznych,
3. obowiązku notyfikacji przed dodaniem poddostawcy do łańcucha,(znacie przypadki, kiedy dostawca się na to zgodzi ❓ 😏
4. gwarancji co do obowiązków raportowania, monitoringu oraz ciągłości działania,
5. wskazania miejsca przetwarzania danych przez poddostawcę,
6. prawa wypowiedzenia oraz planu wyjścia.

Jaki jest obowiązek dostawcy ICT względem poddostawcy?

I choć to instytucja finansowa odpowiada za zarządzanie ryzykiem ICT, a w tym kontrolę łańcucha dostaw, to jednak dostawca powinien mieć możliwości, wiedzę i odpowiednie zasoby (finansowe, w ludziach i techniczne) do monitorowania ryzyka ICT na poziomie poddostawców.

Podsumowanie

1. Klasyfikacja usług ICT nie jest uniwersalna, należy rozpoczynać od definicji z art. 3 DORA, kolejno z ITS dotyczącego rejestru informacji oraz wspierać się wewnętrzną oceną w zakresie wspieranych przez usługę funkcji biznesowych.
2. Jeśli dostawca IT świadczy usługi ICT w ramach działalności regulowanej – posiada określone prawem zezwolenie lub wpis do rejestru i jednocześnie z przepisów wynikają obowiązki zarządzania ryzykiem, w tym ryzykiem ICT, to nie ma obowiązku powielenia standardu i traktowania go jak dostawcy ICT w rozumieniu DORA.
3. Jeśli dostawca IT świadczy usługi na rzecz kontrahenta, który nie jest podmiotem regulowanym, to nie ma obowiązku stosowania rozporządzenia DORA. Choć inaczej może być w sytuacji, kiedy klient kupuje usługi również dla podmiotu nadzorowanego w ramach jednej grupy kapitałowej.
4. Jeśli dostawca SaaS albo chmury uważa się, że nie świadczy usług IT, to zwiększa swoją uważność.