20 sie 2026

Umowa chroni dostawcę. A kto chroni bank?

Umowa chroni dostawcę. A kto chroni bank?
Umowa chroni dostawcę. A kto chroni bank?

UMOWA CHRONI DOSTAWCĘ. A KTO CHRONI BANK?

Projekt umowy trafia do banku.

Dostawca mówi:

„To nasz standardowy wzór.”

Brzmi uspokajająco.

Ale standardowy wzór dostawcy nie zawsze oznacza dobrą umowę dla banku.

Umowa z dostawcą ICT w banku powinna być oceniana nie tylko pod kątem ceny i zakresu usługi, ale również pod kątem:

  • ryzyka ICT,
  • ciągłości działania,
  • incydentów,
  • podwykonawstwa,
  • ochrony danych,
  • prawa audytu,
  • możliwości wyjścia ze współpracy.

Najważniejsze pytanie brzmi:

jakie ryzyko bank zaakceptuje w chwili podpisania tej umowy?

Najpierw usługa. Dopiero potem zapisy umowy

Zanim bank zacznie analizować paragrafy, powinien wiedzieć:

  • jaki proces wspiera usługa,
  • czy proces jest krytyczny,
  • jakie systemy ICT są wykorzystywane,
  • jakie dane będą przetwarzane,
  • jak silna będzie zależność od dostawcy.

To BIA i analiza ryzyka powinny określać, jak wymagająca musi być umowa.

Im ważniejsza usługa dla banku, tym mniej miejsca powinno być na ogólne zapisy.

Czy SLA naprawdę chroni bank?

SLA 99,9% wygląda dobrze.

Ale sama liczba niewiele mówi.

Bank powinien sprawdzić:

  • kiedy rozpoczyna się pomiar awarii,
  • jaki jest czas reakcji,
  • jaki jest czas przywrócenia usługi,
  • czy SLA odpowiada RTO/RPO z BIA,
  • jakie są konsekwencje przekroczenia parametrów.

Najważniejsze pytanie:

czy parametry dostawcy są zgodne z rzeczywistymi potrzebami procesu banku?

Jeżeli BIA wymaga odtworzenia w 4 godziny, a dostawca gwarantuje 8 godzin, problem istnieje już w momencie podpisania umowy.

Kiedy bank dowie się o incydencie?

Podczas incydentu liczą się minuty.

Dlatego zapis:

„Dostawca poinformuje bank bez zbędnej zwłoki”

może być zbyt ogólny.

Umowa powinna określać:

  • kiedy ZDU informuje bank,
  • kto uruchamia eskalację,
  • jaki kanał komunikacji obowiązuje,
  • jakie informacje bank otrzyma,
  • jak często aktualizowany będzie status,
  • kiedy bank otrzyma raport końcowy.

Bank musi mieć informację wystarczająco wcześnie, aby uruchomić własne procedury.

Kto naprawdę świadczy usługę?

Bank podpisuje umowę z jednym podmiotem.

Ale za usługą mogą stać:

  • podwykonawcy,
  • centra danych,
  • dostawcy chmurowi,
  • operatorzy sieci,
  • firmy serwisowe.

Dlatego warto ustalić:

kto faktycznie posiada dostęp do danych, systemów i infrastruktury banku?

Łańcuch podwykonawców może być jednym z największych źródeł ryzyka ICT.

Gdzie są dane i co stanie się z nimi po zakończeniu umowy?

Umowa powinna jasno określać:

  • gdzie dane są przetwarzane,
  • kto ma do nich dostęp,
  • gdzie powstają kopie,
  • jak długo są przechowywane,
  • jak zostaną zwrócone bankowi,
  • kiedy zostaną usunięte,
  • w jaki sposób dostawca potwierdzi usunięcie.

To szczególnie ważne przy usługach chmurowych i podwykonawstwie.

Czy dostawca wykorzystuje AI?

Coraz więcej usług ICT wykorzystuje mechanizmy sztucznej inteligencji.

Bank powinien wiedzieć:

  • czy AI jest elementem usługi,
  • jakie dane trafiają do modelu,
  • czy dane mogą służyć do trenowania,
  • gdzie odbywa się przetwarzanie,
  • kto odpowiada za wyniki działania AI.

Brak informacji o wykorzystaniu AI może oznaczać, że bank nie zna pełnego sposobu przetwarzania własnych danych.

Czy bank naprawdę ma prawo audytu?

Dostawca może zapewniać:

„Spełniamy wszystkie wymagania bezpieczeństwa.”

Bank powinien móc odpowiedzieć:

„Proszę to wykazać.”

Dlatego umowa powinna zapewniać odpowiednie możliwości:

  • audytu,
  • kontroli,
  • dostępu do raportów,
  • weryfikacji testów,
  • uzyskania dowodów skuteczności zabezpieczeń,
  • kontroli realizacji działań naprawczych.

Prawo audytu, którego praktycznie nie można wykorzystać, ma ograniczoną wartość.

A co, jeśli bank chce odejść od dostawcy?

To jedno z najczęściej pomijanych pytań.

Bank powinien wiedzieć:

  • jak odzyska dane,
  • w jakim formacie,
  • jak długo potrwa migracja,
  • kto wesprze przejście do nowego rozwiązania,
  • jak długo dostawca będzie zobowiązany współpracować,
  • co stanie się z danymi po zakończeniu współpracy.

Strategia wyjścia powinna powstać przed kryzysem, nie wtedy, gdy relacja z dostawcą już nie działa.

8 pytań przed podpisaniem umowy z ZDU

Przed podpisaniem warto odpowiedzieć:

  1. Czy wiemy, jaki proces wspiera usługa?
  2. Czy SLA odpowiada RTO/RPO z BIA?
  3. Jak szybko dowiemy się o incydencie?
  4. Kto faktycznie świadczy usługę?
  5. Gdzie znajdują się dane banku?
  6. Czy dostawca wykorzystuje AI?
  7. Czy mamy realne prawo audytu?
  8. Czy wiemy, jak zakończyć współpracę i odzyskać dane?

Jeżeli choć jedna odpowiedź brzmi:

„trzeba sprawdzić”

– właśnie znaleziono element, który warto wyjaśnić przed podpisaniem.

Co powinien wiedzieć Zarząd?

Zarząd nie potrzebuje analizy każdego paragrafu.

Potrzebuje krótkiego podsumowania:

co kupujemy → jak ważna jest usługa → jakie ryzyko pozostaje → czego brakuje w umowie → co rekomendujemy.

Praktyczna rekomendacja powinna kończyć się jednym z trzech wariantów:

AKCEPTOWAĆ

AKCEPTOWAĆ PO SPEŁNIENIU WARUNKÓW

NIE AKCEPTOWAĆ

To jest informacja umożliwiająca podjęcie decyzji.

Podsumowanie

Dobra umowa z dostawcą ICT powinna zapewniać bankowi:

kontrolę → informację → ciągłość → dowody → możliwość reakcji → możliwość wyjścia.

Największe ryzyko często nie znajduje się w zapisach, które są w umowie.

Znajduje się w tych, których w niej zabrakło.

Pytania i odpowiedzi

Co bank powinien sprawdzić przed podpisaniem umowy z dostawcą ICT?

Krytyczność usługi, SLA, RTO/RPO, obowiązki podczas incydentów, podwykonawców, lokalizację danych, AI, prawo audytu i warunki zakończenia współpracy.

Czy standardowy wzór umowy dostawcy wystarczy?

Nie. Powinien zostać oceniony w kontekście konkretnej usługi, procesu oraz ryzyka banku.

Dlaczego BIA jest ważna przy analizie umowy?

Pozwala określić wymagania dotyczące dostępności, ciągłości, RTO/RPO oraz krytyczności usługi.

Czy bank powinien znać podwykonawców?

Tak, szczególnie jeżeli uczestniczą w przetwarzaniu danych lub świadczeniu usług istotnych dla ciągłości działania.

Czy wykorzystanie AI przez ZDU powinno być ujawnione?

Jeżeli AI jest elementem usługi lub przetwarza dane banku, bank powinien znać sposób wykorzystania danych i związane z tym ryzyka.

Czy prawo audytu jest ważne?

Tak. Bank powinien mieć możliwość pozyskania dowodów potwierdzających skuteczność zabezpieczeń i realizację obowiązków dostawcy.

Dlaczego strategia wyjścia jest ważna?

Ponieważ bank powinien wiedzieć, jak odzyska dane i utrzymać ciągłość, jeżeli współpraca z dostawcą zostanie zakończona.

Czy wiesz, jakie ryzyko podpisze Zarząd razem z najbliższą umową?

To warto ustalić zanim pojawi się podpis.

Jeżeli chcesz zweryfikować projekt umowy z dostawcą ICT pod kątem DORA, BIA, SLA, RTO/RPO, incydentów, podwykonawstwa, RODO, AI i strategii wyjścia, skontaktuj się bezpośrednio ze specjalistami Servus Comp Kraków.

Pomagamy bankom spółdzielczym w:

  • analizie projektów umów z ZDU,
  • ocenie krytyczności usług,
  • analizie ryzyka ICT,
  • weryfikacji SLA i RTO/RPO,
  • analizie incydentów i eskalacji,
  • ocenie podwykonawstwa,
  • analizie przetwarzania danych i AI,
  • weryfikacji praw audytowych,
  • przygotowaniu strategii wyjścia,
  • opracowaniu rekomendacji dla Zarządu.

Servus Comp Kraków
Bezpieczeństwo • Odporność • Ryzyko ICT • Zgodność

Umowę najlepiej sprawdzić wtedy, kiedy można ją jeszcze zmienić.

Polecane wpisy dla banków spółdzielczych

Zapraszamy również do zapoznania się z innymi materiałami przygotowanymi z myślą o Zarządach i pracownikach banków spółdzielczych, osobach odpowiedzialnych za bezpieczeństwo informacji, ICT, DORA, zgodność i zarządzanie ryzykiem.

    1. AUDYT ZA PARĘ SREBRNIKÓW CZY AUDYT, KTÓRY WYTRZYMA PYTANIA SOZ, KNF I BIEGŁEGO REWIDENTA?
    2. SOC nie widzi wszystkiego. Czy bank zna swoje ślepe punkty?
    3. Awaria już trwa – co bank odtwarza jako pierwsze i kto o tym decyduje?
    4. Zostałeś ABI. I co teraz?
    5. „ATAKUJĄ BANKI”. THREAT INTELLIGENCE OSTRZEGA – CO ROBI BANK?
    6. DORA, RTS, EBA, KNF – Jak nie pogubić się w wytycznych i wiedzieć, co naprawdę wdrożyć?
    7. Bank ma procedury. Audytor pyta: „proszę pokazać, że one działają”.
    8. Dostawca nie działa. Bank też. Czy tak miało być?
    9. Exit plan dostawcy a exit plan banku – czy strategia wyjścia naprawdę chroni interes banku?
    10. Umowa chroni dostawcę. A kto chroni bank?
    11. Backup mówi „SUCCESS”. Ransomware mówi „SPRAWDZAM”
    12. Podatność jest critical. Ale czy naprawdę jest najważniejsza?
    13. SOC widzi alert. Ale czy wie, co jest ważne dla banku?
    14. Prezesie, proszę pilnie zatwierdzić przelew. Głos brzmi dokładnie jak głos członka zarządu. To deepfake.
    15. Ocena ryzyka ICT przez KNF wypadła słabo. Co teraz?
    16. Ransomware w banku i inne kryzysy – testy stolikowe i scenariuszowe: czy bank naprawdę potrafi działać?
    17. INCYDENT O 15:47. PREZES PYTA: „CO ROBIMY?” – KTO W BANKU ZNA ODPOWIEDŹ?
    18. DORA I RTS bez BIA to nie wdrożenie. To chaos bez priorytetów.
    19. BIA w banku spółdzielczym – jak przygotować analizę krok po kroku?
    20. Zarząd pyta IT: „Czy jesteśmy bezpieczni?” – czy odpowiedź „tak” cokolwiek znaczy?
    21. PAM w banku spółdzielczym – JumpServer, DORA i kontrola dostępu uprzywilejowanego
    22. Bank bez systemu PAM? JumpServer – bezpłatna ochrona dostępu uprzywilejowanego dla banków spółdzielczych
    23. Skan to za mało. Jakie testy penetracyjne powinien zlecić bank spółdzielczy, żeby nie usłyszeć tego na audycie?
    24. Wysadzenie bankomatu to nie tylko szkoda. To test procedur Banku
    25. 10 wybranych najważniejszych zaleceń KNF po ocenie ryzyka ICT 2025 — praktyczne podsumowanie dla banków spółdzielczych
    26. Dokument jest? KNF zapyta o dowód, że działa
    27. Znalazłeś podatność? KNF zapyta, kiedy ją usunąłeś
    28. Raport ICT do Zarządu — KNF pyta, kto nadzoruje ryzyko ICT w Banku
    29. Jeden dostawca, wiele systemów, jedno duże ryzyko. KNF pyta o koncentrację ICT
    30. Skan podatności to nie test odporności. KNF zapyta, czy Bank naprawdę testuje ICT

Zadzwoń lub napisz do Servus Comp, aby omówić temat.


Servus Comp Data Security, Świętokrzyska 12/403, 30-015 Kraków

tel. +48 608 407 668, +48 12 631 91 22 • biuro@servus-comp.pl

PODEJMIEMY DLA PAŃSTWA KAŻDE WYZWANIE!

JESTEŚ ZAINTERESOWANY? ZADZWOŃ, NAPISZ DO NAS

#UmowaZDostawcąICT #ZDU #BankSpółdzielczy #DostawcaICT #DORA #SLA #RTO #RPO #BIA #Podwykonawcy #RODO #AI #PrawoAudytu #StrategiaWyjścia #RyzykoICT #CiągłośćDziałania #Cyberbezpieczeństwo #ZarządBanku #ServusCompKraków

Dodaj komentarz