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

DORA obowiązuje od 17.01.2025 i sprawia, że banki, ubezpieczyciele i fintechy muszą dużo ostrzej weryfikować dostawców ICT. Jeśli sprzedajesz usługi IT do sektora finansowego, przygotuj „pakiet dowodów”, procedury 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ś „finansówką”?

DORA (Digital Operational Resilience Act) to unijne rozporządzenie o odporności cyfrowej sektora finansowego. Ono wprost reguluje obowiązki podmiotów finansowych, ale w praktyce „wciąga” też ich dostawców ICT, bo finansówka musi umieć udowodnić, że kontroluje ryzyko dostawcy, ma prawo do audytu, zna łańcuch podwykonawców i potrafi wyjść z usługi bez katastrofy.

Z mojego doświadczenia (projekty dla firm, które obsługują banki, płatności i ubezpieczenia) to wygląda zawsze podobnie: przez lata wystarczały 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, że klient ma prawo wejść z audytem. I nagle marketing przestaje mieć znaczenie, liczą się dowody.

Jakie wymagania DORA najczęściej „spadają” na dostawcę ICT?

Najczęściej uderzą w Ciebie trzy obszary:

1. Umowa i prawa nadzoru: klient finansowy będzie wymagał zapisów o audycie, dostępie do informacji, wsparciu testów odporności (w tym TLPT tam, gdzie dotyczy) i obowiązkach w BCP. (Digital Operational Resilience Act)
2. Łańcuch dostaw i podwykonawcy: klient musi kontrolować subcontracting i ryzyka koncentracji, więc Ty musisz umieć pokazać, kto Cię wspiera i na jakich zasadach. (EUR-Lex)
3. Incydenty i dowody operacyjne: finansówka musi raportować incydenty według DORA, więc oczekuje od dostawcy 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 „czy DORA dotyczy mnie”. Zacznij od pytania: czy moi klienci finansowi będą wymagać DORA-ready vendor management? Jeśli tak, to i tak przechodzisz przez ten proces.

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

Storytelling z życia, tylko bez bajek.

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

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

Da się to odczarować: przygotuj pakiet raz, aktualizuj kwartalnie i sprzedawaj go jak produkt.

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

To jest mój ulubiony hack, bo 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ące”
• model wsparcia i godziny dostępności

2) Architektura i bezpieczeństwo techniczne

• diagram high-level (bez sekretów): strefy, kontrola dostępu, segmentacja
• szyfrowanie danych w spoczynku i w transmisji
• IAM: MFA, role, konta uprzywilejowane, proces onboard/offboard

3) Incydenty i komunikacja

• definicje, klasy krytyczności
• czasy reakcji, kanał 24/7 dla klientów finansowych
• co dostarczasz w raporcie: timeline, IOC, logi, RCA (root cause analysis)

4) BCP/DR, RTO/RPO i testy

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

5) Podwykonawcy i ryzyko dostawców

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

6) Audyty i zgodność

• to, co masz: ISO 27001, SOC 2, testy, raporty
• jeśli nie masz certyfikacji: opisz kontrolki i pokaż dowody

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

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

DORA wprost wskazuje, że w umowach z dostawcami ICT mają się pojawić m.in. kwestie bezpieczeństwa, planów ciągłości, udziału w testach oraz prawa dostępu, inspekcji i audytu dla klienta i organów.

W praktyce przygotuj się na:

• prawo audytu (on-site lub zdalnie, czasem przez stronę trzecią)
• wymóg współpracy z organami nadzoru (przez klienta)
• wymóg BCP/DR i testów plus dostarczenie wyników
• exit plan: przeniesienie usługi, dane, wsparcie migracji, terminy
• subcontracting: zasady korzystania z podwykonawców i informowania o zmianach

Pro tip z wdrożeń: zamiast walczyć „nie damy audytu”, zrób model audytu warstwowego:

• warstwa 1: raporty, dowody, wyniki testów, polityki
• warstwa 2: zdalny audit walkthrough
• warstwa 3: on-site tylko dla usług krytycznych i po ustaleniu zakresu

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

Jak przygotować się na pytania o „critical ICT third-party providers” i nadzór ESAs?

DORA wprowadza unijny framework nadzoru nad krytycznymi dostawcami ICT (CTPP). Nie każdy dostawca nim zostanie, ale duzi gracze i dostawcy o wysokiej 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 nie jesteś „critical”.
• Jeżeli opierasz się na dużym dostawcy chmury, klient może chcieć zobaczyć, jak ograniczasz ryzyko vendor lock-in.
• Będzie presja na przejrzystość podwykonawców i na plan wyjścia.

Jak zbudować proces incydentowy, który pasuje do DORA i oczekiwań finansówki?

Nie musisz kopiować procesów banku. Musisz dostarczyć coś, co bank da radę wpiąć w swoje raportowanie.

Twoje minimum:

1. Kanał zgłoszeń 24/7 dla klientów regulowanych
2. Kryteria klasyfikacji: co jest „major”, co jest „degradation”, co jest „security incident”
3. SLA komunikacji: pierwsza informacja w X minut, update co Y godzin
4. Dowody: logi, metryki, RCA, działania korygujące, lista IOC (jeśli dotyczy)

EBA i ESAs publikują i porządkują standardy i 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 tym porządkiem i spójnych danych.

Jakie „dowody” są najbardziej przekonujące przy ocenie dostawcy ICT?

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

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

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

Z perspektywy klienta finansowego to są puzzle do ułożenia ich własnej zgodności.

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

Plan na miesiąc, praktyczny, „do odhaczenia”:

Tydzień 1: Pakiet i odpowiedzialności

• właściciel DORA vendor management po Twojej stronie
• wersjonowany Vendor Pack
• lista klientów regulowanych i ich wymagania specyficzne

Tydzień 2: Incydenty i dowody operacyjne

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

Tydzień 3: Podwykonawcy i umowy

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

Tydzień 4: Testy

• tabletop incident
• test odtworzeniowy
• szybki przegląd konfiguracji i hardening krytycznych systemów

Podsumowanie: co ma zrobić firma ICT, żeby „przechodzić DORA” bez bólu?

Jeśli dostarczasz ICT do finansówki, przestań traktować bezpieczeństwo jako „cechę”, a zacznij jako produkt z dowodami. DORA obowiązuje od 17 stycznia 2025, a standardy i materiały ESAs/EBA układają oczekiwania rynku w bardzo konkretny zestaw pytań i zapisów umownych.

Twoje trzy priorytety na start:

1. DORA Vendor Pack
2. proces incydentów i dowody (logi, testy, RCA)
3. umowy i podwykonawcy (audyt, exit, subcontracting)

To jest różnica między „sprzedajemy IT” a „jesteśmy dostawcą, któremu finansówka ufa i którego audyt nie paraliżuje”.