DORA dla firm ICT: jak przygotować się na wymagania klientów finansowych

DORA obowiązuje od 17 stycznia 2025 i sprawia, że banki, ubezpieczyciele i fintechy muszą dużo ostrzej weryfikować dostawców usług ICT. Jeśli sprzedajesz usługi IT do sektora finansowego, przygotuj „pakiet dowodów”, procedury obsługi incydentów i gotowe zapisy umowne — inaczej utkniesz na etapie due diligence.

Czym jest DORA i dlaczego dotyka firm ICT, nawet jeśli nie jesteś „firmą finansową”?

DORA (Digital Operational Resilience Act) to unijne rozporządzenie o operacyjnej odporności cyfrowej sektora finansowego. Wprost reguluje obowiązki podmiotów finansowych, ale w praktyce wciąga też ich dostawców usług ICT, bo firmy finansowe muszą umieć udowodnić, że kontrolują ryzyko dostawcy, mają prawo do audytu, znają łańcuch podwykonawców i potrafią wyjść z usługi bez katastrofy.

Z mojego doświadczenia (projekty dla firm obsługujących banki, płatności i ubezpieczenia) wygląda to zawsze tak samo: przez lata wystarczały certyfikat ISO, „mamy backup” i ogólna polityka bezpieczeństwa. Po DORA dostajesz ankietę na kilkadziesiąt stron, żądanie mapy podwykonawców, wymóg testów BCP/DR i zapis w umowie dający klientowi prawo do audytu. I nagle marketing przestaje mieć znaczenie — liczą się dowody.

Jakie wymagania DORA najczęściej spadają na dostawcę usług ICT?

Najczęściej uderzą w Ciebie trzy obszary:

1. Umowy i prawa nadzoru: klient finansowy będzie wymagał zapisów o prawie do audytu, dostępie do informacji, wsparciu testów odporności (w tym TLPT tam, gdzie ma to zastosowanie) i obowiązkach w zakresie BCP. (Digital Operational Resilience Act)
2. Łańcuch dostaw i podwykonawcy: klient musi kontrolować podwykonawstwo i ryzyko koncentracji, więc Ty musisz umieć pokazać, kto Cię wspiera i na jakich zasadach. (EUR-Lex)
3. Incydenty i dowody operacyjne: firmy finansowe muszą raportować incydenty zgodnie z DORA, więc oczekują od dostawców jasnej klasyfikacji, terminów, kanałów komunikacji i logów pozwalających odtworzyć przebieg zdarzeń. (Europejski Urząd Nadzoru Bankowego)

Wskazówka praktyczna: nie zaczynaj od pytania „czy DORA dotyczy mnie”. Zacznij od: czy moi klienci finansowi będą wymagać zarządzania dostawcami zgodnego z DORA? Jeśli tak, i tak przejdziesz przez ten proces.

Jak wygląda typowy scenariusz wdrożeniowy — co naprawdę dzieje się po stronie klienta?

Historia z życia, bez bajek.

Poniedziałek, 9:17. Dostajesz maila od działu zakupów banku: „Prosimy o uzupełnienie kwestionariusza DORA i odesłanie go w ciągu 5 dni roboczych”. Załączniki: ankieta ryzyka ICT, wymagane polityki, lista dowodów z testów BCP, prośba o dane podwykonawców, pytania o lokalizację danych, retencję logów, RTO/RPO, szyfrowanie i zarządzanie podatnościami.

Jeśli nie masz gotowego „pakietu dostawcy”, zaczyna się gaszenie pożaru: IT szuka dokumentów, dział prawny pyta o zapisy umowne, a zarząd dowiaduje się, że w umowie musi się teraz znaleźć prawo do audytu i scenariusz wyjścia. I nagle 5 dni robi się drogą przez mękę.

Możesz przerwać ten cykl: przygotuj pakiet raz, aktualizuj go co kwartał i sprzedawaj jak produkt.

Jak przygotować „DORA Vendor Pack”, który skraca due diligence z tygodni do godzin?

To mój ulubiony trik, bo naprawdę działa w realnym biznesie. „Vendor Pack” to uporządkowany zestaw dowodów, który wysyłasz klientowi zamiast 80 maili.

Minimalny pakiet dla firmy ICT:

1) Opis usług i granice odpowiedzialności

• lista usług (SaaS, hosting, SOC, utrzymanie, integracje)
• co jest funkcją krytyczną po stronie klienta, a co „wspierającą”
• model wsparcia i godziny dostępności

2) Architektura i bezpieczeństwo techniczne

• diagram ogólny (bez tajemnic): strefy, kontrola dostępu, segmentacja
• szyfrowanie danych w spoczynku i w transmisji
• IAM: MFA, role, konta uprzywilejowane, proces onboardingu/offboardingu

3) Incydenty i komunikacja

• definicje, klasy krytyczności
• czasy reakcji, kanał 24/7 dla klientów finansowych
• co dostarczasz w raporcie: oś czasu, IOC, logi, RCA (analiza przyczyny źródłowej)

4) BCP/DR, RTO/RPO i testy

• Twoje cele RTO/RPO (realne, zmierzone)
• wyniki testów odtworzeniowych i ćwiczeń (data, zakres, wnioski)
• plan awaryjny na wypadek awarii dostawcy chmury

5) Podwykonawcy i ryzyko dostawców

• lista krytycznych podwykonawców i ich rola (hosting, poczta, monitoring, helpdesk)
• zasady oceny podwykonawców i wymagania bezpieczeństwa
• procedura zmiany podwykonawcy i informowania klienta

6) Audyty i zgodność

• co już masz: ISO 27001, SOC 2, testy, raporty
• jeśli nie masz certyfikacji: opisz swoje mechanizmy kontrolne i pokaż dowody

To podejście jest spójne z tym, że DORA znacząco wzmacnia nadzór nad relacją z dostawcą usług ICT i wymaga, aby umowy i polityki obejmowały cały cykl życia współpracy.

Jakie zapisy umowne będą od Ciebie wymagane i jak się na nie przygotować bez wojny z prawnikami?

DORA wprost wskazuje, że umowy z dostawcami usług ICT muszą obejmować m.in. kwestie bezpieczeństwa, plany ciągłości działania, udział w testach oraz prawa dostępu, inspekcji i audytu dla klienta i organów nadzoru.

W praktyce przygotuj się na:

• prawo do audytu (na miejscu lub zdalnie, czasem przez stronę trzecią)
• wymóg współpracy z organami nadzoru (za pośrednictwem klienta)
• wymóg BCP/DR i testów oraz dostarczania ich wyników
• plan wyjścia (exit plan): przeniesienie usługi, dane, wsparcie migracji, terminy
• podwykonawstwo: zasady korzystania z podwykonawców i informowania o zmianach

Pro tip z realnych wdrożeń: zamiast walczyć w stylu „nie zgodzimy się na audyt”, zbuduj warstwowy model audytu:

• warstwa 1: raporty, dowody, wyniki testów, polityki
• warstwa 2: zdalny przegląd audytowy (walkthrough)
• warstwa 3: audyt na miejscu tylko dla usług krytycznych i po uzgodnieniu zakresu

To zwykle domyka negocjacje i nie rozwala Twojego bezpieczeństwa operacyjnego.

Jak przygotować się na pytania o „krytycznych zewnętrznych dostawców usług ICT” i nadzór ESA?

DORA wprowadza ogólnounijne ramy nadzoru nad krytycznymi dostawcami usług ICT (CTPP). Nie każdy dostawca zostanie tak wyznaczony, ale duzi gracze i dostawcy o wysokim ryzyku koncentracji mogą podlegać ocenie i nadzorowi.

Co to oznacza dla mniejszych firm ICT?

• Twoi klienci będą pytać o ryzyko koncentracji i zależności, nawet jeśli Ty sam nie jesteś „krytyczny”.
• Jeśli opierasz się na dużym dostawcy chmury, klient może chcieć zobaczyć, jak ograniczasz ryzyko vendor lock-in.
• Pojawi się presja na przejrzystość w zakresie podwykonawców i na plan wyjścia.

Jak zbudować proces obsługi incydentów pasujący do DORA i oczekiwań sektora finansowego?

Nie musisz kopiować procesów banku. Musisz dostarczyć coś, co bank będzie mógł wpiąć we własne raportowanie.

Twoje minimum:

1. Kanał zgłoszeń 24/7 dla klientów regulowanych
2. Kryteria klasyfikacji: co jest „poważnym incydentem”, co „degradacją”, a co „incydentem bezpieczeństwa”
3. SLA komunikacji: pierwsza informacja w ciągu X minut, aktualizacje co Y godzin
4. Dowody: logi, metryki, RCA, działania korygujące, lista IOC (jeśli dotyczy)

EBA i ESA publikują i porządkują standardy oraz materiały do DORA, w tym dotyczące raportowania i klasyfikacji incydentów oraz zarządzania ryzykiem ICT. W praktyce klient będzie oczekiwał zgodności z tymi ramami i spójnych danych.

Jakie „dowody” są najbardziej przekonujące, gdy klient ocenia dostawcę usług ICT?

W due diligence nie wygrywa ten, kto ma najładniejszy PDF — wygrywa ten, kto ma mierzalne dowody.

Top 10 dowodów, które realnie robią robotę:

1. wyniki testów odtworzenia backupu (z datą i wnioskami)
2. raport z ćwiczenia incydentowego typu tabletop
3. wykaz kontroli dostępu i MFA (zrzuty ekranu lub eksport)
4. polityka patchowania plus ostatnie wdrożenia krytycznych aktualizacji
5. źródła logów i retencja (co logujesz, jak długo, gdzie)
6. proces zarządzania podatnościami i wyjątkami
7. lista krytycznych podwykonawców plus zasady ich oceny
8. RTO/RPO dla kluczowych komponentów usługi
9. procedura offboardingu i usuwania danych
10. wyniki testów bezpieczeństwa aplikacji lub infrastruktury (choćby podstawowych)

Z perspektywy klienta finansowego to elementy układanki, z których składa on własną zgodność.

Jak w 30 dni przygotować się do pierwszego audytu DORA u klienta finansowego?

Praktyczny plan na miesiąc, do odhaczenia:

Tydzień 1: Pakiet i odpowiedzialność

• właściciel zarządzania dostawcami w ramach DORA po Twojej stronie
• wersjonowany Vendor Pack
• lista klientów regulowanych i ich specyficznych wymagań

Tydzień 2: Incydenty i dowody operacyjne

• kanał 24/7, szablony raportów, runbooki
• lista logów i okresów retencji
• definicje RTO/RPO i sposób ich pomiaru

Tydzień 3: Podwykonawcy i umowy

• mapa podwykonawców i zależności
• standardowe załączniki do umów: bezpieczeństwo, audyt, plan wyjścia
• zasady podwykonawstwa i proces informowania o zmianach

Tydzień 4: Testy

• ćwiczenie incydentowe typu tabletop
• test odtworzeniowy
• szybki przegląd konfiguracji i hardening krytycznych systemów

Podsumowanie: co powinna zrobić firma ICT, żeby „przejść DORA” bez bólu?

Jeśli dostarczasz usługi ICT do sektora finansowego, przestań traktować bezpieczeństwo jako „funkcję”, a zacznij jako produkt z dowodami. DORA obowiązuje od 17 stycznia 2025, a standardy i materiały ESA/EBA zamieniają oczekiwania rynku w bardzo konkretny zestaw pytań i zapisów umownych.

Twoje trzy priorytety na start:

1. DORA Vendor Pack
2. proces obsługi incydentów i dowody (logi, testy, RCA)
3. umowy i podwykonawcy (audyt, wyjście, podwykonawstwo)

To jest różnica między „sprzedajemy IT” a „jesteśmy dostawcą, któremu ufają instytucje finansowe i którego audyty nie paraliżują”.