DORA (stosowane od 17.01.2025) wpływa na to, jak bank ocenia i nadzoruje dostawców usług ICT w outsourcingu IT. W praktyce bank będzie wymagał: governance (KPI/SLA), audytowalności, zasad incydentów, kontroli podwykonawców, BCP/DR (jeśli dotyczy) oraz planu wyjścia (exit).
DORA (Digital Operational Resilience Act) to unijne rozporządzenie dotyczące odporności cyfrowej sektora finansowego. Jest stosowane od 17 stycznia 2025 r. i wpływa m.in. na to, jak banki zarządzają ryzykiem ICT oraz relacjami z dostawcami usług ICT (outsourcing).
Ten artykuł to praktyczna checklista dla banków i zespołów: Vendor Management / Procurement / IT / Security / PMO. Możesz wykorzystać ją w:
RFP/RFQ dla outsourcingu specjalistów IT (staff augmentation),
zapytaniu o dedykowany zespół (dedicated team),
przeglądach cyklicznych dostawców (vendor reviews),
dopinaniu governance i „audytowalności” współpracy.
Ważne: to materiał informacyjny, nie porada prawna ani interpretacja regulacyjna. Finalną ocenę zgodności i wymagania kontraktowe zawsze powinny przejść przez prawników/compliance banku.
TL;DR: co bank zwykle chce mieć „pod kontrolą” przy outsourcingu IT po DORA
Niezależnie od modelu (staff augmentation / dedicated team / managed services), w praktyce bank będzie dążył do tego, aby mieć:
jasny zakres usługi i odpowiedzialności,
governance (KPI/SLA, raportowanie, eskalacje),
możliwość wglądu/audytu i dostęp do dowodów (evidence),
ustalone zasady obsługi incydentów i współpracy informacyjnej,
kontrolę subcontractingu (podwykonawców i zmian w łańcuchu dostaw),
BCP/DR i podejście do testów (adekwatnie do krytyczności),
exit plan (wyjście bez lock-inu i utraty wiedzy),
spójne dane do rejestru informacji o umowach z dostawcami ICT (register of information).
Co DORA zmienia w outsourcingu IT w banku?
Najbardziej „praktyczna” zmiana jest taka, że rośnie znaczenie:
zarządzania ryzykiem dostawców ICT jako stałego procesu (nie jednorazowego audytu),
łańcucha dostaw (także podwykonawców),
wymogów dowodowych (polityki, procedury, logi, raporty, testy — proporcjonalnie do ryzyka),
umów i governance, które mają umożliwić realną kontrolę (a nie tylko „ładne zapisy”).
DORA wzmacnia wagę tych tematów w kontekście odporności operacyjnej sektora finansowego.
Krok 0: klasyfikacja – jak „krytyczna” jest usługa / współpraca?
Zanim odpalisz checklistę, ustal kontekst:
Czy to, co zlecasz (usługa ICT), wspiera funkcję krytyczną lub istotną?
Jeśli tak, bank zwykle oczekuje bardziej rygorystycznego podejścia: więcej kontroli, większej audytowalności, większej przejrzystości w subcontractingu oraz solidniejszego planu wyjścia.
Jak myśleć o tym w staff augmentation / dedicated team?
Nawet jeśli formalnie „dostarczasz ludzi”, to ryzyko ocenia się przez wpływ pracy na procesy i systemy banku (np. kanały cyfrowe, integracje, core, płatności, dane, AML). Wtedy dostawca staje się elementem ryzyka operacyjnego.
Checklista DORA: wymagania wobec dostawcy ICT (outsourcing IT dla banku)
Poniżej masz checklistę w układzie „RFP-friendly”. Każdy punkt możesz traktować jako:
pytanie do dostawcy,
element scorecard,
listę dowodów do due diligence.
A) Due diligence (przed podpisaniem umowy): minimum informacyjne i dowodowe
Co bank zwykle sprawdza / o co pyta:
Czy dostawca ma udokumentowane podejście do bezpieczeństwa informacji (polityki, role, szkolenia, przeglądy)?
Jak wygląda zarządzanie ryzykiem w organizacji (rejestr ryzyk, przeglądy, akceptacje)?
Jak wygląda zarządzanie dostępami (np. proces nadawania/odbierania uprawnień, przeglądy, MFA — jeśli dotyczy)?
Jak dostawca podchodzi do podatności i aktualizacji (Vulnerability/Patch Management — w zakresie odpowiednim do usługi)?
Czy istnieje proces obsługi incydentów (kto, jak, w jakim czasie eskaluje)?
Czy jest podejście do ciągłości działania (BCP/DR) i testów (jeśli dotyczy zakresu usług)?
Uwaga praktyczna: część punktów (np. MDM, konkretne narzędzia) to przykłady dobrych praktyk. Bank zwykle ocenia „czy kontrola istnieje i jest adekwatna”, a nie czy jest dokładnie w tej jednej technologii.
B) Governance współpracy: mierzalność i przewidywalność delivery
W modelach outsourcingowych banki zazwyczaj oczekują, że dostawca pokaże:
jak wygląda onboarding (dostępy, środowiska, zasady pracy),
jak działa raportowanie (rytm, format, statusy),
jakie są ścieżki eskalacji (operacyjne i management),
jak mierzyć pracę (KPI/SLA — adekwatnie do modelu i krytyczności).
To jest krytyczne zwłaszcza przy obiekcji „kolejny body leasing” — governance oddziela „dostarczenie ludzi” od „przewidywalnego dowożenia”.
C) Audytowalność i dostęp do informacji (auditability)
W outsourcingu IT dla banku warto upewnić się, że da się odpowiedzieć na pytanie:
„Czy bank ma realny dostęp do informacji i dowodów potrzebnych do kontroli ryzyka dostawcy?”
W praktyce bank może oczekiwać:
określenia, jakie informacje/dowody dostawca udostępnia standardowo,
wsparcia w trybie audytu (np. Q&A, dostarczanie evidence),
jasnego trybu współpracy w sytuacjach nadzwyczajnych (np. incydent).
Nie chodzi o „pełny wgląd we wszystko”, tylko o adekwatność do ryzyka i zakresu usługi.
D) Incydenty ICT: eskalacja, współpraca, dane
W relacjach bank–dostawca ważne jest, aby dostawca miał:
proces obsługi incydentów oraz role/odpowiedzialności,
zasady eskalacji do banku (kiedy i jak informować),
praktykę RCA (root cause analysis) i działań korygujących,
gotowość do współpracy informacyjnej (dane, oś czasu, wpływ).
To wspiera bank w realizacji obowiązków związanych z zarządzaniem incydentami i raportowaniem.
E) Podwykonawcy i łańcuch dostaw (subcontracting)
To jeden z najbardziej „wrażliwych” obszarów w bankowości.
Co warto mieć jasno:
czy dostawca korzysta z podwykonawców i w jakim zakresie,
jak bank jest informowany o zmianach w łańcuchu (notyfikacja / kontrola zmian),
czy i w jakim trybie bank może ocenić ryzyko podwykonawców (w zakresie materialnym),
jak dostawca zapewnia, że zobowiązania bezpieczeństwa są „przenoszone” w dół łańcucha.
Europejskie organy nadzoru przygotowały standardy techniczne dotyczące podoutsourcingu usług ICT wspierających funkcje krytyczne/istotne; w praktyce warto je uwzględniać przy ocenie dostawcy i zapisach współpracy.
F) Ciągłość działania (BCP/DR) i testy – adekwatnie do ryzyka
Bank zwykle będzie pytał:
czy dostawca ma BCP/DR (jeśli dotyczy usługi),
jak definiuje i testuje odtworzenie (RTO/RPO – jeśli dotyczy),
jak wygląda komunikacja w sytuacji awaryjnej.
Klucz: adekwatność do tego, co realnie dostarczacie (inaczej dla managed services, inaczej dla staff augmentation).
G) Exit plan: jak zakończyć współpracę bez ryzyka lock-inu i utraty wiedzy
Z perspektywy banku ważne jest, aby dostawca miał z góry określone:
zasady przekazania wiedzy (dokumentacja, runbooki, onboarding następcy),
wsparcie w okresie przejściowym (transition assistance),
proces zamknięcia dostępów i uporządkowania informacji.
To nie jest „plan na rozwód” – to standard w środowisku regulowanym.
H) Rejestr informacji (register of information): dane, które bank może potrzebować od dostawcy
DORA wiąże się także z utrzymywaniem rejestru informacji o umowach z dostawcami ICT. Dla rejestru przyjęto standardowe szablony w akcie wykonawczym Komisji (Implementing Regulation (EU) 2024/2956).
Co praktycznie pomaga bankowi po stronie dostawcy:
spójne dane identyfikacyjne (nazwa prawna, kraj, dane rejestrowe),
opis usługi i zakres,
lokalizacje świadczenia/realizacji (jeśli dotyczy),
informacje o subcontractingu (w zakresie istotnym),
dane kontraktowe (czas trwania, istotne warunki operacyjne).
Gotowiec do RFP: 25 pytań kontrolnych do dostawcy IT (outsourcing w banku)
Poniższe pytania są celowo „operacyjne” – nie zakładają, że dostawca jest kancelarią od DORA. Mają sprawdzić, czy współpraca będzie kontrolowalna i audytowalna.
Jak opisujecie zakres usługi i granice odpowiedzialności (RACI)?
Jak wygląda governance: raportowanie, rytm, eskalacje?
Jakie KPI/SLA stosujecie (przykłady) i jak je raportujecie?
Jak wygląda onboarding do środowiska regulowanego (dostępy, zasady, wymagania klienta)?
Jak zarządzacie dostępami (nadawanie/odbieranie, przeglądy) — w zakresie swojej organizacji?
Jakie macie podejście do bezpieczeństwa informacji (polityki/zasady, szkolenia)?
Jak wygląda proces obsługi incydentów i eskalacji do klienta?
Jak wygląda RCA i działania korygujące po incydencie?
Jak podchodzicie do ciągłości działania (BCP/DR) — jeśli dotyczy waszej usługi?
Jak często testujecie procedury awaryjne (jeśli dotyczy)?
Czy możecie uczestniczyć w ćwiczeniach incydentowych klienta (w uzgodnionym zakresie)?
Jak zarządzacie zmianą (change management) dla krytycznych elementów współpracy?
Jak zarządzacie dokumentacją (architektura/runbooki/procedury) w trakcie projektu?
Jak zapewniacie ciągłość zespołu (backup, zastępowalność, przekazanie wiedzy)?
Czy korzystacie z podwykonawców? Jeśli tak, w jakim zakresie?
Jak informujecie o zmianach w subcontractingu?
Jak klient może ocenić ryzyko istotnych podwykonawców (w uzgodnionym zakresie)?
Jak zapewniacie, że wymagania bezpieczeństwa są utrzymane w łańcuchu dostaw?
Jak wygląda „auditability”: jakie dowody możecie dostarczyć w standardzie?
Czy wspieracie audyty klienta (w uzgodnionym zakresie)?
Jak wygląda komunikacja w sytuacji kryzysowej (kanały, role, czasy reakcji)?
Jak wygląda exit plan i wsparcie w migracji/transferze wiedzy?
Jak zamykacie dostępy i porządkujecie uprawnienia po zakończeniu współpracy?
Jakie informacje możecie dostarczyć do rejestru informacji banku (register of information)?
Jakie są wasze ograniczenia (czego nie robicie / gdzie potrzebujecie wsparcia klienta)?
Najczęstsze pułapki w outsourcingu IT dla banku (i jak ich uniknąć)
Brak governance: praca „dzieje się”, ale bez rytmu raportowania, eskalacji i mierników.
Subcontracting w cieniu: bank dowiaduje się o podwykonawcach za późno (albo wcale).
Incydenty bez jasnej współpracy informacyjnej: brak spójnej osi czasu, brak RCA, chaos komunikacyjny.
Exit plan „na dwa zdania”: brak procedury przekazania wiedzy i wsparcia przejściowego.
Zbyt ogólne deklaracje bezpieczeństwa bez możliwości przedstawienia dowodów.
FAQ
Czy DORA dotyczy outsourcingu IT i staff augmentation w banku?
DORA dotyczy odporności cyfrowej sektora finansowego i obejmuje m.in. zarządzanie ryzykiem związanym z usługami ICT świadczonymi przez podmioty trzecie. W praktyce banki uwzględniają DORA również w relacjach outsourcingowych, zależnie od krytyczności usługi.
Czym jest „register of information” i co to zmienia dla dostawcy?
To rejestr informacji o umowach i zależnościach z dostawcami usług ICT. Dla rejestru zostały przyjęte standardowe szablony, co ułatwia porządkowanie danych o relacjach z dostawcami.
Czy standardy dot. subcontractingu mają znaczenie w wyborze dostawcy?
Tak – europejskie organy nadzoru publikują standardy techniczne dot. podoutsourcingu usług ICT wspierających funkcje krytyczne/istotne, co w praktyce wzmacnia znaczenie kontroli łańcucha dostaw.
7) Jak Edge One Solutions może pomóc
Jeśli rozważasz outsourcing specjalistów IT lub dedykowany zespół do pracy w środowisku regulowanym, możemy wesprzeć Cię w obszarach, które są po naszej stronie: delivery, organizacja współpracy i standardy pracy zespołu.
Dedicated Teams – budujemy i prowadzimy dedykowane zespoły projektowe.
Staff Augmentation / outsourcing specjalistów IT – dostarczamy specjalistów do zespołów klienta, z uporządkowanym procesem doboru i onboardingiem pod zasady organizacji.
Nasze zespoły pracują zgodnie z uzgodnionymi zasadami bezpieczeństwa i wymaganiami klienta (np. NDA/poufność, onboarding, zasady dostępu do środowisk, praca w narzędziach i procesach po stronie organizacji). Nie świadczymy usług doradztwa prawnego ani „wdrożeń DORA” — natomiast pomagamy działać w modelu współpracy, który jest uporządkowany, mierzalny i łatwiejszy do nadzoru po stronie banku.
