EXIT PLAN DOSTAWCY A EXIT PLAN BANKU – CZY STRATEGIA WYJŚCIA NAPRAWDĘ CHRONI INTERES BANKU?

Dostawca deklaruje:  „Mamy Exit Plan.”

To brzmi dobrze.

Ale kluczowe pytanie brzmi inaczej:   czy ten plan chroni interes banku, czy przede wszystkim porządkuje sposób zakończenia usługi po stronie dostawcy?

To nie jest to samo.

Exit Plan w banku powinien określać, jak bezpiecznie zmienić ZDU bez utraty danych, ciągłości działania, wiedzy i kontroli nad usługą.

Czy Exit Plan dostawcy wystarczy bankowi?

Nie zawsze.

Plan dostawcy zwykle opisuje sposób zakończenia świadczenia jego usługi.

Bank potrzebuje dodatkowo wiedzieć:

• kiedy rozpocząć migrację,
• kto odpowiada za przejęcie usługi,
• jakie dane należy odzyskać,
• jakie konfiguracje trzeba przenieść,
• jak zachować wiedzę o środowisku,
• jak długo stary ZDU ma wspierać migrację,
• kiedy nowy dostawca przejmuje pełną odpowiedzialność.

Najważniejsze jest to, aby bank kontrolował proces wyjścia, a nie tylko reagował na harmonogram dostawcy.

Dla których usług Exit Plan jest naprawdę krytyczny?

Nie każda usługa ICT wymaga takiego samego poziomu przygotowania.

Największe znaczenie mają usługi, których brak może:

• zatrzymać proces krytyczny,
• uniemożliwić obsługę klientów,
• spowodować utratę danych,
• przekroczyć RTO wynikające z BIA,
• stworzyć istotne ryzyko operacyjne lub regulacyjne.

Im większa zależność od dostawcy, tym bardziej szczegółowa powinna być strategia wyjścia.

Jak BIA wpływa na Exit Plan?

BIA powinna określać:

• krytyczność procesu,
• dopuszczalny czas zakłócenia,
• RTO i RPO,
• zależności ICT,
• systemy i dane niezbędne do działania.

To właśnie te informacje powinny decydować o tym, ile czasu bank ma na zmianę dostawcy i jaka przerwa w usłudze jest akceptowalna.

Jeżeli BIA zakłada przywrócenie procesu w 4 godziny, strategia wyjścia nie może opierać się na migracji trwającej kilka dni bez rozwiązania alternatywnego.

Co bank musi przejąć od starego ZDU?

Nie chodzi tylko o dane.

Bank może potrzebować również:

• konfiguracji,
• dokumentacji technicznej,
• licencji,
• kluczy,
• informacji o integracjach,
• procedur,
• historii zmian,
• dokumentacji bezpieczeństwa,
• wiedzy operacyjnej.

Brak jednego z tych elementów może znacząco utrudnić migrację.

Dlatego warto zadać proste pytanie:

czy wiemy dokładnie, co musi zostać przejęte przed zakończeniem współpracy?

Kto odpowiada za okres przejściowy?

Migracja zwykle wymaga współpracy:

stary ZDU → bank → nowy ZDU

Powinno być jasno określone:

• kto przygotowuje dane,
• kto potwierdza ich kompletność,
• kto odpowiada za konfigurację,
• kto testuje nowe środowisko,
• kto utrzymuje usługę w okresie przejściowym,
• kto podejmuje decyzję o przełączeniu.

Najgorszy moment na ustalanie tych ról to dzień migracji.

Jak zmienić dostawcę bez utraty ciągłości?

Dobra strategia wyjścia powinna obejmować:

przygotowanie → kopię bezpieczeństwa → migrację → test → akceptację → przełączenie → monitoring → zamknięcie

Warto wcześniej ustalić:

• kryteria powodzenia,
• punkt „go/no-go”,
• sposób powrotu do poprzedniego środowiska,
• osoby podejmujące decyzję,
• maksymalny dopuszczalny czas przerwy.

Migracja nie powinna być eksperymentem wykonywanym na środowisku produkcyjnym.

Co z danymi po zakończeniu współpracy?

Po migracji bank powinien wiedzieć:

• czy wszystkie dane zostały przeniesione,
• czy potwierdzono ich integralność,
• czy kopie pozostały u starego dostawcy,
• kiedy zostaną usunięte,
• jak ZDU potwierdzi ich trwałe usunięcie.

Exit Plan nie kończy się w chwili uruchomienia nowej usługi.

Kończy się wtedy, gdy bank odzyskał pełną kontrolę nad danymi i usługą.

Czy podwykonawcy mogą zablokować wyjście?

Tak.

Stary dostawca może korzystać z:

• centrów danych,
• operatorów chmurowych,
• podmiotów serwisowych,
• właścicieli licencji,
• kolejnych podwykonawców.

Bank powinien wiedzieć:

• gdzie faktycznie są dane,
• kto posiada elementy usługi,
• które komponenty należą do podwykonawców,
• jakie zależności trzeba rozwiązać osobno.

Im bardziej złożony łańcuch dostaw, tym większe ryzyko vendor lock-in.

Czy Exit Plan był kiedykolwiek testowany?

To jedno z najważniejszych pytań.

Plan może wyglądać bardzo dobrze na papierze.

Ale czy bank sprawdził:

• czy dane można wyeksportować,
• czy można je zaimportować do innego środowiska,
• czy dokumentacja jest kompletna,
• czy nowy ZDU potrafi przejąć usługę,
• ile trwa cały proces,
• jakie problemy pojawiają się w praktyce?

Exit Plan bez testu jest założeniem, nie dowodem gotowości.

6 pytań, które Zarząd powinien zadać

1. Czy mamy realną alternatywę dla obecnego ZDU?
2. Ile czasu zajmie zmiana dostawcy?
3. Czy zachowamy ciągłość działania?
4. Czy odzyskamy wszystkie dane i konfiguracje?
5. Czy jesteśmy zależni od wiedzy obecnego dostawcy?
6. Czy strategię wyjścia kiedykolwiek przetestowano?

Jeżeli odpowiedzi są niejasne, bank może być bardziej uzależniony od ZDU, niż wynika to z samej umowy.

Podsumowanie

Exit Plan nie powinien odpowiadać tylko na pytanie:

„Jak zakończyć umowę?”

Powinien odpowiadać:

„Jak bank zachowa ciągłość, dane, wiedzę i kontrolę po zmianie dostawcy?”

Praktyczny model wygląda tak:

BIA → zależności → dane → role → migracja → test → przełączenie → usunięcie danych → dowód

Dopiero wtedy strategia wyjścia rzeczywiście chroni interes banku.

Pytania i odpowiedzi

Czym różni się Exit Plan dostawcy od Exit Planu banku?

Plan dostawcy opisuje zwykle zakończenie jego usługi. Strategia banku powinna dodatkowo zapewniać ciągłość, migrację danych, przejęcie wiedzy i kontrolę nad zmianą ZDU.

Czy każdy ZDU wymaga Exit Planu?

Największe znaczenie ma on dla usług krytycznych lub takich, od których bank jest silnie zależny.

Jak BIA wpływa na Exit Plan?

Określa krytyczność procesu, dopuszczalny czas przerwy oraz wymagane RTO/RPO, co wpływa na sposób i tempo migracji.

Co powinno zostać przejęte od starego dostawcy?

Nie tylko dane, ale także konfiguracje, dokumentacja, licencje, integracje, procedury i wiedza potrzebna do dalszego świadczenia usługi.

Czy Exit Plan trzeba testować?

Tak. Tylko test pozwala sprawdzić, czy bank rzeczywiście potrafi przenieść usługę bez niekontrolowanej utraty ciągłości.

Co jest największym ryzykiem braku realnego Exit Planu?

Vendor lock-in, czyli sytuacja, w której bank formalnie może zakończyć współpracę, ale operacyjnie nie jest w stanie szybko i bezpiecznie przejść do innego rozwiązania.

Czy Twój bank naprawdę może zmienić dostawcę?

Nie wtedy, gdy umowa się kończy.

Dzisiaj.

Jeżeli nie potrafisz jednoznacznie odpowiedzieć:

• ile potrwa migracja,
• kto przejmie dane,
• jak zostanie zachowana ciągłość,
• czy istnieje realna alternatywa dla obecnego ZDU,

warto zweryfikować strategię wyjścia zanim będzie potrzebna.

Skontaktuj się bezpośrednio ze specjalistami Servus Comp Kraków.

Pomagamy bankom spółdzielczym w:

• przygotowaniu i weryfikacji Exit Planów,
• ocenie zależności od ZDU,
• powiązaniu strategii wyjścia z BIA,
• przygotowaniu planów migracji,
• analizie danych, konfiguracji i dokumentacji do przejęcia,
• określeniu odpowiedzialności stron,
• testowaniu wykonalności strategii wyjścia,
• ocenie ryzyka vendor lock-in,
• przygotowaniu rekomendacji dla Zarządu.

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

Exit Plan jest dobry dopiero wtedy, gdy bank potrafi z niego naprawdę wyjść.

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. 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.

• Strona główna: https://premiumbank.zadbajobezpieczenstwo.pl

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