DORA wpływa nie tylko na wewnętrzne procesy banku. Zmienia również sposób, w jaki instytucje finansowe oceniają, kontraktują i nadzorują dostawców usług ICT.
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 sposób zarządzania ryzykiem ICT oraz relacjami z zewnętrznymi dostawcami usług ICT.
W praktyce oznacza to większe znaczenie governance, KPI/SLA, audytowalności, zasad obsługi incydentów, kontroli podwykonawców, BCP/DR — jeśli ma zastosowanie – oraz planu wyjścia ze współpracy.
Odpowiedzialność za zgodność z wymaganiami DORA pozostaje po stronie instytucji finansowej. Dostawca ICT powinien jednak umożliwiać bankowi realizację odpowiednich wymagań w zakresie świadczonej usługi — poprzez właściwe procesy, informacje, dowody, sposób raportowania i organizację współpracy.
Dlatego wybór partnera IT dla banku nie powinien sprowadzać się wyłącznie do porównania stawek i dostępności specjalistów. Istotne jest również to, czy współpraca będzie kontrolowalna, przewidywalna i możliwa do audytowania.
Ten artykuł to praktyczna checklista dla zespołów Vendor Management, Procurement, IT, Security i PMO. Możesz wykorzystać ją przy RFP/RFQ, due diligence, vendor review oraz przy ustalaniu governance współpracy z dostawcą ICT.
Ważne: materiał ma charakter informacyjny. Nie jest poradą prawną ani interpretacją regulacyjną. Finalna ocena zgodności oraz wymagania kontraktowe powinny zostać zweryfikowane przez zespoły prawne i compliance instytucji finansowej.
TL;DR: co bank zwykle chce mieć „pod kontrolą” przy outsourcingu IT po DORA?
Niezależnie od modelu współpracy — Staff Augmentation, Dedicated Team czy Managed Services — bank będzie dążył do tego, aby mieć:
- jasny zakres usługi i odpowiedzialności,
- governance — KPI/SLA, raportowanie i ścieżki eskalacji,
- możliwość wglądu i audytu oraz dostęp do odpowiednich dowodów (evidence),
- ustalone zasady obsługi incydentów i współpracy informacyjnej,
- kontrolę subcontractingu i zmian w łańcuchu dostaw,
- BCP/DR i podejście do testów adekwatne do krytyczności usługi,
- exit plan pozwalający ograniczyć vendor lock-in i ryzyko utraty wiedzy,
- spójne dane do rejestru informacji o umowach z dostawcami ICT (register of information).
Nie oznacza to jednak, że wymagania będą identyczne wobec każdego dostawcy. Zakres kontroli powinien odpowiadać rodzajowi usługi, odpowiedzialności dostawcy, dostępowi do systemów i danych oraz znaczeniu wspieranego procesu.
Co DORA zmienia w outsourcingu IT w banku?
Najbardziej praktyczna zmiana polega na tym, że zarządzanie ryzykiem dostawcy ICT powinno być traktowane jako proces ciągły, a nie jednorazowa weryfikacja przed podpisaniem umowy.
Rośnie znaczenie:
- zarządzania ryzykiem dostawców ICT,
- kontroli łańcucha dostaw i podwykonawców,
- wymogów dowodowych — polityk, procedur, raportów, logów czy wyników testów, odpowiednio do zakresu usługi,
- umów i governance umożliwiających realny nadzór nad współpracą,
- monitorowania dostawcy również w trakcie realizacji usługi.
Bank powinien więc wiedzieć nie tylko, kogo wybiera, ale również jak będzie kontrolował współpracę po podpisaniu umowy.
Due diligence odpowiada na pytanie: „czy możemy rozpocząć współpracę?”. Governance i vendor review pomagają odpowiedzieć: „czy nadal możemy ją bezpiecznie kontynuować?”.
Jednocześnie zakres kontroli powinien być proporcjonalny do ryzyka i znaczenia usługi ICT. Innych mechanizmów można oczekiwać od specjalisty dołączającego do istniejącego zespołu klienta, a innych od dostawcy odpowiedzialnego end-to-end za utrzymanie krytycznej usługi.
Krok 0: klasyfikacja – jak „krytyczna” jest usługa lub współpraca?
Zanim bank zastosuje checklistę wobec dostawcy, powinien określić kontekst współpracy.
Czy usługa ICT wspiera funkcję krytyczną lub istotną?
Jeżeli tak, można oczekiwać bardziej rygorystycznego podejścia: większej liczby kontroli, większej audytowalności, przejrzystości w zakresie podwykonawców i bardziej szczegółowego planu wyjścia.
Kluczowa jest jednak jeszcze jedna zasada: sam model współpracy nie przesądza o poziomie ryzyka.
Znaczenie ma realny wpływ pracy dostawcy na systemy, dane i procesy banku. Specjalista pracujący w modelu Staff Augmentation może pracować przy kanale cyfrowym, integracji, systemie płatniczym, danych lub procesach AML. Formalnie dostawca zapewnia kompetencje, ale wykonywana praca nadal może mieć znaczenie dla ryzyka operacyjnego banku.
Staff Augmentation, Dedicated Team i Managed Services – dlaczego wymagania mogą się różnić?
| Model | Typowy podział odpowiedzialności | Co może mieć znaczenie dla banku? |
|---|---|---|
| Staff Augmentation | Specjaliści dostawcy dołączają do zespołu klienta i pracują w jego procesach oraz narzędziach. | Onboarding, dostęp, offboarding, kompetencje, ciągłość specjalistów, bezpieczeństwo i zgodność z procesami banku. |
| Dedicated Team | Dedykowany zespół realizuje określony zakres projektu i jest zintegrowany z organizacją klienta. | Governance zespołu, odpowiedzialności, raportowanie, delivery, dokumentacja, transfer wiedzy i zastępowalność. |
| Managed Services | Dostawca może odpowiadać za szerszy zakres usługi i jej parametry operacyjne. | SLA, monitoring, incydenty, BCP/DR, odpowiedzialność operacyjna, audytowalność, subcontracting i exit plan. |
To rozróżnienie jest istotne również biznesowo. Stosowanie identycznego zestawu wymagań do każdego modelu może prowadzić albo do niedoszacowania ryzyka, albo do tworzenia kontroli nieadekwatnych do rzeczywistego zakresu odpowiedzialności dostawcy.
Więcej o projektach IT realizowanych dla instytucji finansowych można znaleźć na stronie IT w bankowości i finansach.
Checklista DORA: wymagania wobec dostawcy ICT
Poniższa checklista ma charakter operacyjny i może być wykorzystana jako zestaw pytań do dostawcy ICT, element scorecard lub punkt wyjścia do zebrania dowodów podczas due diligence i vendor review.
A) Due diligence – minimum informacyjne i dowodowe
Bank powinien sprawdzić m.in.:
- czy dostawca ma udokumentowane podejście do bezpieczeństwa informacji — polityki, role, szkolenia i przeglądy,
- jak wygląda zarządzanie ryzykiem w organizacji,
- jak dostawca zarządza dostępami — ich nadawaniem, zmianą, przeglądami i odbieraniem,
- jak podchodzi do podatności i aktualizacji w zakresie odpowiednim do usługi,
- czy posiada proces obsługi i eskalacji incydentów,
- czy posiada podejście do BCP/DR i testów, jeżeli ma ono zastosowanie do świadczonej usługi.
Deklaracja dostawcy nie zawsze jest wystarczająca. W zależności od ryzyka bank może potrzebować konkretnych dowodów potwierdzających działanie procesów — np. polityk, procedur, wyników przeglądów, raportów, certyfikatów lub innych uzgodnionych evidence.
Uwaga praktyczna: celem nie powinno być sprawdzenie, czy dostawca korzysta z jednej konkretnej technologii lub narzędzia. Ważniejsze jest to, czy odpowiednia kontrola istnieje, działa i jest adekwatna do ryzyka.
B) Governance współpracy – mierzalność i przewidywalność delivery
Dostawca powinien potrafić wyjaśnić:
- jak wygląda onboarding — dostępy, środowiska, wymagania i zasady pracy,
- jak działa raportowanie — rytm, format i odpowiedzialności,
- jak wyglądają ścieżki eskalacji operacyjnej i managementowej,
- jak definiowane i mierzone są KPI/SLA, jeśli mają zastosowanie,
- jak zapewniana jest ciągłość zespołu i zastępowalność,
- kto odpowiada za poszczególne elementy delivery.
Governance powinno odpowiadać modelowi współpracy. W Staff Augmentation większa część zarządzania backlogiem i delivery może pozostawać po stronie banku. W Dedicated Team zakres odpowiedzialności dostawcy za organizację pracy zespołu może być szerszy. Przy Managed Services rośnie natomiast znaczenie parametrów usługi, SLA, monitoringu i odpowiedzialności operacyjnej.
To właśnie governance pomaga odróżnić samo „dostarczenie ludzi” od współpracy, w której bank ma jasno określone odpowiedzialności, przepływ informacji i przewidywalny sposób realizacji usługi.
C) Audytowalność i dostęp do informacji
Jedno z podstawowych pytań brzmi: czy bank ma realny dostęp do informacji i dowodów potrzebnych do kontroli ryzyka dostawcy?
W praktyce warto ustalić:
- jakie informacje i dowody dostawca może udostępniać standardowo,
- w jaki sposób obsługiwane są zapytania audytowe,
- kto odpowiada za zebranie i przekazanie evidence,
- jak wygląda wsparcie podczas audytu lub vendor review,
- jak wygląda współpraca informacyjna w sytuacji nadzwyczajnej.
Nie chodzi o pełny dostęp banku do wszystkich informacji wewnętrznych dostawcy. Zakres powinien odpowiadać ryzyku, charakterowi usługi i uzgodnionym zasadom współpracy. Dobrą praktyką jest jednak ustalenie tego procesu zanim pojawi się pierwsze zapytanie audytowe.
D) Incydenty ICT – eskalacja, współpraca i dane
W relacji bank–dostawca ICT istotne jest, aby dostawca miał:
- proces obsługi incydentów oraz określone role i odpowiedzialności,
- ustalone zasady eskalacji do banku,
- praktykę RCA (root cause analysis),
- proces działań korygujących,
- gotowość do przekazania uzgodnionych informacji dotyczących zdarzenia, osi czasu i wpływu.
Rolą dostawcy jest sprawna współpraca informacyjna w zakresie swojej usługi. Formalne obowiązki regulacyjne banku i raportowanie do właściwych organów pozostają odrębną kwestią.
E) Podwykonawcy i łańcuch dostaw
Subcontracting jest szczególnie istotny tam, gdzie w realizacji usługi uczestniczą kolejne podmioty. Z perspektywy banku kluczowa jest transparentność.
Warto ustalić:
- czy dostawca korzysta z podwykonawców i w jakim zakresie,
- jak bank jest informowany o zmianach w łańcuchu dostaw,
- czy bank może ocenić ryzyko istotnych podwykonawców w uzgodnionym zakresie,
- jak wymagania dotyczące bezpieczeństwa i współpracy są uwzględniane dalej w łańcuchu dostaw.
Bank powinien wiedzieć, jakie podmioty realnie uczestniczą w świadczeniu usługi i w których jej elementach. Im bardziej krytyczny zakres współpracy, tym większe znaczenie ma przejrzystość tego łańcucha.
F) Ciągłość działania – BCP/DR i testy
W zależności od charakteru usługi bank może sprawdzać:
- czy dostawca posiada odpowiednie BCP/DR,
- jak definiuje i testuje RTO/RPO, jeżeli dotyczy to jego odpowiedzialności,
- jak wygląda komunikacja i podział odpowiedzialności w sytuacji awaryjnej.
Kluczowa jest proporcjonalność. W Staff Augmentation odpowiedzialność dostawcy za BCP/DR całego systemu może być znacznie mniejsza niż w Managed Services, gdzie dostawca odpowiada za określone parametry operacyjne usługi.
Wymaganie powinno więc wynikać z faktycznego zakresu odpowiedzialności, a nie wyłącznie z etykiety „outsourcing IT”.
G) Exit plan – jak zakończyć współpracę bez lock-inu i utraty wiedzy?
Exit plan nie powinien powstawać dopiero w momencie wypowiedzenia umowy. Sposób zakończenia współpracy warto ustalić już na początku.
Powinien uwzględniać m.in.:
- transfer wiedzy,
- aktualną dokumentację i runbooki,
- onboarding zespołu przejmującego usługę,
- transition assistance w uzgodnionym okresie,
- zamknięcie dostępów, kont, kluczy i tokenów,
- uporządkowanie informacji i odpowiedzialności po zakończeniu współpracy.
Dobry exit plan ogranicza dwa ryzyka jednocześnie: vendor lock-in i utratę wiedzy krytycznej dla dalszego działania systemu.
H) Rejestr informacji (register of information)
DORA wiąże się również z utrzymywaniem przez podmioty finansowe rejestru informacji dotyczących umów z dostawcami usług ICT. Dla rejestru przyjęto standardowe szablony w Implementing Regulation (EU) 2024/2956.
Po stronie dostawcy pomocna jest możliwość przekazania bankowi spójnych informacji dotyczących m.in.:
- danych identyfikacyjnych podmiotu,
- opisu i zakresu świadczonej usługi,
- lokalizacji świadczenia usługi, jeśli ma zastosowanie,
- subcontractingu w istotnym zakresie,
- podstawowych informacji kontraktowych i operacyjnych.
Gotowiec do RFP: 25 pytań kontrolnych do dostawcy ICT
Poniższe pytania są celowo operacyjne. Mogą być wykorzystane zarówno podczas RFP/RFQ, jak i w due diligence lub okresowym vendor review. Ich celem jest sprawdzenie, czy współpraca będzie kontrolowalna, audytowalna i dopasowana do wymagań organizacji.
- Jak opisujecie zakres usługi i granice odpowiedzialności (RACI)?
- Jak wygląda governance: raportowanie, rytm współpracy i eskalacje?
- Jakie KPI/SLA stosujecie i jak je raportujecie?
- Jak wygląda onboarding do środowiska regulowanego?
- Jak zarządzacie nadawaniem, zmianą, przeglądem i odbieraniem dostępów?
- Jakie macie podejście do bezpieczeństwa informacji i szkoleń?
- Jak wygląda proces obsługi incydentów i eskalacji do klienta?
- Jak wygląda RCA i realizacja działań korygujących?
- Jak podchodzicie do BCP/DR, jeżeli dotyczy to zakresu usługi?
- Jak często testujecie odpowiednie procedury awaryjne?
- Czy możecie uczestniczyć w ćwiczeniach incydentowych klienta w uzgodnionym zakresie?
- Jak zarządzacie zmianą dla krytycznych elementów współpracy?
- Jak zarządzacie dokumentacją, runbookami i wiedzą projektową?
- Jak zapewniacie ciągłość zespołu, zastępowalność i transfer wiedzy?
- Czy korzystacie z podwykonawców? Jeżeli tak, w jakim zakresie?
- Jak informujecie klienta o zmianach w subcontractingu?
- Jak klient może ocenić ryzyko istotnych podwykonawców?
- Jak zapewniacie utrzymanie uzgodnionych wymagań bezpieczeństwa w łańcuchu dostaw?
- Jak wygląda auditability — jakie dowody możecie dostarczyć standardowo?
- Jak wspieracie audyty i vendor reviews klienta?
- Jak wygląda komunikacja kryzysowa — kanały, role i czasy reakcji?
- Jak wygląda exit plan oraz wsparcie przy migracji i transferze wiedzy?
- Jak zamykacie dostępy i porządkujecie uprawnienia po zakończeniu współpracy?
- Jakie informacje możecie dostarczyć do register of information banku?
- Jakie są granice waszej odpowiedzialności i gdzie wymagane jest działanie po stronie klienta?
Szerzej o kryteriach oceny partnera technologicznego piszemy również w materiale jak oceniać firmy outsourcingu specjalistów IT dla sektora finansowego.
Najczęstsze pułapki w outsourcingu IT dla banku
| Pułapka | Konsekwencja |
|---|---|
| Brak governance | Praca jest realizowana, ale bank nie ma spójnego rytmu raportowania, eskalacji i mierników. |
| Subcontracting „w cieniu” | Bank zbyt późno dowiaduje się, jakie podmioty uczestniczą w realizacji usługi. |
| Chaos podczas incydentu | Niejasne role, brak spójnej osi czasu, opóźniona eskalacja i problemy z RCA. |
| Exit plan na dwa zdania | Ryzyko vendor lock-in, utraty wiedzy i kosztownego przejęcia usługi. |
| Deklaracje bez evidence | Dostawca deklaruje procesy i bezpieczeństwo, ale nie jest przygotowany do przedstawienia uzgodnionych dowodów. |
| Te same wymagania dla każdego modelu | Staff Augmentation jest oceniany jak Managed Services albo odwrotnie — wymagania przestają odpowiadać realnemu zakresowi odpowiedzialności i ryzyka. |
Wspólnym mianownikiem tych problemów jest brak dopasowania kontroli do rzeczywistego sposobu realizacji usługi. DORA zwiększa znaczenie formalizacji współpracy, ale sama liczba procedur nie zastąpi jasnego podziału odpowiedzialności i działających procesów.
Jak Edge One Solutions może wspierać projekty IT w środowisku regulowanym?
Bank potrzebuje nie tylko odpowiednich kompetencji technologicznych. Potrzebuje również partnera, który potrafi pracować w określonym governance, respektować wymagania bezpieczeństwa klienta i dostarczać informacje potrzebne do nadzorowania współpracy.
Edge One Solutions wspiera organizacje z sektora bankowości i finansów, realizując projekty technologiczne w środowiskach, w których znaczenie mają bezpieczeństwo, stabilność procesów i uporządkowany model współpracy.
W zależności od potrzeb klienta współpraca może zostać zorganizowana m.in. jako Staff Augmentation lub Dedicated Team.
| STAFF AUGMENTATION Wzmocnienie istniejącego zespołu Specjaliści Edge1S dołączają do zespołu klienta i pracują zgodnie z jego procesami, narzędziami, zasadami dostępu i governance. | DEDICATED TEAM Dedykowany zespół projektowy Zespół jest budowany wokół konkretnego zakresu i może zostać zintegrowany z procesami, wymaganiami bezpieczeństwa i sposobem raportowania organizacji. |
W praktyce oznacza to możliwość pracy zgodnie z ustalonym onboardingiem, zasadami dostępu, NDA i poufności, procesami klienta oraz uzgodnionym sposobem raportowania i eskalacji. Zakres dokumentacji, audytowalności oraz wsparcia podczas vendor reviews może zostać dopasowany do charakteru współpracy i wymagań organizacji.
Przykładem doświadczenia Edge1S w sektorze finansowym jest współpraca z Bankiem Pekao przy rozwoju rozwiązań bankowych.
Edge One Solutions nie świadczy doradztwa prawnego ani nie odpowiada za zgodność banku z DORA. Rolą partnera technologicznego jest natomiast taki sposób organizacji swojej części współpracy, aby bank mógł skutecznie zarządzać dostawcą, ryzykiem i wymaganiami dotyczącymi świadczonej usługi.
Edge One Solutions
Potrzebujesz specjalistów lub dedykowanego zespołu IT do projektu w sektorze finansowym?
Porozmawiajmy o modelu współpracy dopasowanym do Twojego governance, wymagań bezpieczeństwa i zakresu odpowiedzialności — od Staff Augmentation po Dedicated Team.
