DORA standardy instytucji dla dostawców IT

W tym artykule zastanowimy się nad wyzwaniami, jakie spotkają dostawcę IT współpracującego z sektorem finansowym.

Definicja zewnętrznego dostawcy ICT

Jeśli potrzebujesz: [1] więcej informacji na temat definicji zewnętrznego dostawcy IT, [2] dlaczego DORA tylko pośrednio dotyczy dostawców i [3] co dostawca może zrobić, aby być gotowym, to zerknij do tekstu Rozporządzenie DORA a dostawca ICT.

Dostarczasz usługi IT instytucjom finansowym?

Katalog tych usług jest szeroki – może być to zarządzanie projektami, zarządzanie cyberbezpieczeństwem, rozwiązanie SaaS, a nawet konsulting w zakresie IT?

Grunt, by było to na bazie stałej umowy i z wykorzystaniem systemów IT.

🧐No i ma to sens, bo jeśli działasz jako PM bez dostępu do systemów, to chyba niespecjalnie generuje to ryzyko IT?

Szczegółowy wykaz tzw. 19S (dziewiętnastu usług IT zidentyfikowanych przez DORA) znajdziecie w ITS o numerze 2024/2956 w odniesieniu do standardowych wzorów na potrzeby rejestru informacji. To ten sam katalog usług, który znajduje się w sprawozdaniu KNF, które Twoi klienci muszą wypełniać i przesyłac organowi nadzoru.

Te 19 usług można też wygooglować albo wyciągnąć z GPT. Pozwólcie mi tego nie wklejać tutaj.

Warto zapamiętać, że zarządzanie projektami bez systemów, czy jednorazowe zamówienie na dostawę sprzętu (bez utrzymania) albo testy podatności raczej nie są usługami ICT w rozumieniu DORY? Dlaczego? Bo albo nie są to usługi ciągłe albo nie są wykorzystywane do nich systemy IT.

Kiedy współpracowałeś z instytucją finansową przed DORA

Wyobraźmy sobie taki scenariusz: pewnego dnia przychodzi do Ciebie klient. Niech to będzie Krajowa Instytucja Płatnicza (KIP) i  mówi: hej nasza umowa to nieco za mało.

Compliance mówi, że brakuje tam 4 różnych załączników. A poza tym, to programiści nie mogą pracować z zagranicy, ani na swoich laptopach (taką mają klauzulę umowną).

CISO mówi, że upadliśmy na głowę współpracując w takim obszarze – bez przeprowadzenia solidnego DD, bez zbadania waszych standardów bezpieczeństwa, czy macie podwykonawców i na jakich zasadach współpracujecie z programistami, których rozwijają nasze oprogramowanie.

Co z tym zrobić?

W pierwszej kolejności, warto upewnić się, że w ogóle świadczycie usługi ICT w rozumieniu DORY.

W kolejnym kroku ustal, czy te usługi wspierają krytyczne funkcje Waszego klienta, czy nie. Od odpowiedzi na to pytania zależy, jaki standard umowy powinien zostać zastosowany i co można negocjować.

Według definicja DORA funkcja krytyczna to taka:

Mamy zatem wpływ na:

1. wyniki finansowe,
2. bezpieczeństwo lub
3. ciągłość usług i działalność instytucji.

Mamy zatem wpływ na wykonywanie warunków zezwolenia albo obowiązków prawnych.

Dlaczego podkreśliłem słowo niekorzystnie? Bo to niuans dla geeków, który wynika ze sprostowania tłumaczenia.

W EN jest “materially impair”.

Negocjacje standardu DORA

Warto przygotować się do tego, że poza umową – będzie trzeba przejść ankietę weryfikującą dla dostawcy. Będą tam pytania o procedury wewnętrzne, dlatego bezpieczeństwo informacji oraz ciągłość działania powinny się u Was wygodnie i na dłużej zagościć.

Czy kontrakt z instytucją zawsze się opłaca?

Poza tym to jak zawsze wątek opłacalności kontraktu. Warto dobrze ustalić jakie i za ile usługi się sprzedaje, czy wszystkie wspierają funkcje biznesowe klienta oraz czy w ogóle wszystkie usługi są na pewno usługami IT.

Nowy standard umowny może wiązać się z bardziej wyśrubowanym raportowaniem, SLA, weryfikacją postępów, audtem i wreszcie karami umownymi. W związku z tym upewnijcie się, że warunki biznesowe pozwalają Wam przyjąć nowe zobowiązania i większe ryzyko kontraktowe.

Podwykonawcy

Zarówno na etapie badania DD, jak i w umowie będziecie musieli oświadczyć różne rzeczy na temat poddostawców. Przede wszystkim to, że za nich odpowiadacie oraz, że wspieracie instytucję w ich monitoringu. Upewnijcie się, że macie kontrolę nad podwykonawcami. Ponadto Wasza umowa z podwykonawcami pewnie też będzie wymagała aneksowania. Trudno przecież obiecać coś, czego samemu się nie ma, prawda?

O wymaganiach, jakie instytucja finansowa musi postawić przed podwykonawcami napisałem w tekście Podwykonawcy usług IT – obowiązki instytucji finansowych.

Zanim zaczniesz negocjować

No i na koniec prawniczy banał, przed rozpoczęciem negocjacji kontraktu – upewnijcie się, czy aneks rzeczywiście w Waszym przypadku jest konieczny. Jeśli jest to, w jakim kształcie (czy dla usług krytycznych czy niekrytycznych). Przygotujcie również wcześniej postanowienia, które można negocjować i podzielcie je na te, które negocjować musicie oraz te, których nie musicie. Te nienegocjowalne warto ująć w warunkach biznesowych. Jednak rozsądnie. Z punktu widzenia instytucji finansowych trudno będzie zaakceptować postawę dostawcy, który powie, że na wszystko się zgadza, ale wszystko to osobno wyceniona usługa lub feature. Nawet obowiązek wsparcia w zakresie incydentów po stronie dostawcy.

Dostawca SaaS nie zawsze się dostosuje

Czasami rozpoczęcie rozmowy o aneksie DORA z dostawcą kończy się tym, że odchodzi on od stołu. To szczególne w wystandaryzowanych SaaS. Tutaj to już każdy dostawca musi odpowiedzieć sobie na pytanie, czy klienci regulowani go interesują. A nawet jeśli nie, to reputacja w razie wycieku cierpi – niezależnie od tego, dla jakich klientów się pracuje. Może więc warto wykorzystać regulacje do uporządkowania standardów bezpieczeństwa własnych usług?

Czego lepiej nie robić w czasie uzgodnień umowy?

Nie podpisywać standardu DORA wychodząc z założenia, że nie da się go negocjować. No to znowu będzie ten prawniczy banał – lepiej zaangażować doradcę jeszcze przed negocjacjami i ustalić wspólną strategię niż w momencie, kiedy klient będzie potrącał Wam kary z wynagrodzenia.

Standardy pod DORA i w ogóle outsourcingowe bywają bardzo zaawansowane i rzadko kiedy dopasowane są do konkretnej sytuacji.

Może zdarzyć się, że dział bezpieczeństwa dużej organizacji przyjdzie ze swoimi środkami bezpieczeństwa oraz sprzętem dla klienta. Wtedy nie do końca sensowne jest to, by dostawca deklarował stosowanie swoich środkach bezpieczeństwa. Tym bardziej, że mogłyby one okazać się niekompatybilne ze standardem klienta.

Na co jeszcze uważać?

Uwaga na zaawansowane obowiązki raportowe, na KPI, kary umowne i korporacyjne standardy. Niektóre nie są wprost rozwiązaniami pochodzącymi z przepisów, a służą raczej jako dodatkowe mechanizmy zabezpieczające wykonanie Waszych obowiązków.

Wówczas warto zapytać, jakie ryzyko one rzeczywiście zabezpieczają i czy są adekwatne do Waszych usług.