Krótka odpowiedź (TL;DR)
DORA wymaga, aby podmioty finansowe kontrolowały ryzyko dostawców ICT, zwłaszcza gdy usługa wspiera funkcje krytyczne lub istotne. Umowa powinna regulować opis usług, lokalizację danych, bezpieczeństwo, audyt, podwykonawców, raportowanie incydentów, ciągłość działania, testy i realny plan wyjścia.
1. Rejestr informacji zaczyna się od dobrej umowy
DORA nakazuje prowadzić register of information dotyczący umów ICT. Jeżeli umowa nie mówi jasno, jaką usługę kupiono, gdzie działa, kto ją podzleca i jakie dane przetwarza, późniejszy rejestr będzie fikcją. Dlatego załączniki techniczne są równie ważne jak część prawna.
SN w „powinna dokładnie wskazywać czynniki usprawiedliwiające zmianę oprocentowania" → I CSK 46/11 wymagał precyzji przy mechanizmie umownym. W DORA analogicznie: postanowienie "dostawca zapewnia bezpieczeństwo zgodnie z najlepszymi praktykami" jest za mało konkretne, jeśli nie wiadomo, jakie kontrole, raporty i czasy reakcji są wymagane.
2. Podwykonawstwo nie może być czarną skrzynką
Najtrudniejsze umowy ICT mają kilka warstw: dostawca aplikacji, hosting, monitoring, support, narzędzia komunikacji, model AI, dostawca kopii zapasowej. DORA wymaga oceny ryzyka suboutsourcingu, zwłaszcza dla funkcji krytycznych. Klient powinien mieć prawo do informacji, sprzeciwu lub co najmniej oceny istotnych zmian w łańcuchu dostaw.
W praktyce warto żądać mapy podwykonawców, lokalizacji przetwarzania, minimalnych wymagań bezpieczeństwa i procedury zmian. To nie jest formalizm: przy incydencie trzeba wiedzieć, kto faktycznie dotyka systemu.
3. Exit plan powinien być testowalny
Plan wyjścia nie może polegać na zdaniu "strony współpracują przy migracji". Powinien określać format danych, wsparcie, terminy, kopie zapasowe, usunięcie danych, utrzymanie usługi przez okres przejściowy i koszty. Jeżeli funkcja jest krytyczna, brak testowalnego exit planu może oznaczać realną zależność od dostawcy.
Ciężar wykazania skutków w sytuacjach procesowych spoczywa na stronie, co dobrze oddaje II FZ 314/17. Pod DORA instytucja finansowa musi wykazać, że rozumiała ryzyko i miała plan, zanim ryzyko się zmaterializowało.
4. Najciekawszy take: negocjacja DORA jest testem zarządzania
Jeżeli dostawca odmawia audytu, informacji o podwykonawcach albo exit planu, to nie jest tylko problem zakupowy. To sygnał ryzyka operacyjnego. DORA przesuwa negocjacje ICT z poziomu "cena i SLA" na poziom odporności instytucji.
Praktyczna lista kontrolna
- uzupełnij register of information o wszystkie umowy ICT, także mniejsze narzędzia SaaS.
- w umowach krytycznych wpisz audyt, lokalizację danych, suboutsourcing i obowiązki incydentowe.
- wymagaj informacji o zmianach podwykonawców, które mogą wpływać na funkcję krytyczną.
- opisz exit plan w załączniku operacyjnym, a nie tylko jako ogólną deklarację współpracy.
- sprawdź, czy dostawca akceptuje testy ciągłości i realne czasy odtworzenia usługi.
Najczęstszy błąd
Najczęstszy błąd to dopisywanie wymogów DORA do umowy bez sprawdzenia, czy dostawca operacyjnie potrafi je wykonać. Klauzula audytu, której dostawca nie umie obsłużyć, nie daje realnej odporności.
Źródła
DORA, rozporządzenie 2022/2554, art. 28-30; akty wykonawcze ESMA/EBA/EIOPA dotyczące rejestru informacji, podwykonawstwa i raportowania; orzecznictwo o precyzji mechanizmów umownych.