DOSTAWCA NIE DZIAŁA. BANK TEŻ. CZY TAK MIAŁO BYĆ?

Jest poniedziałek, 9:10.

Pracownicy zgłaszają brak dostępu do jednej z kluczowych usług.

IT sprawdza infrastrukturę.

Po stronie banku wszystko wygląda poprawnie.

Po kilku minutach przychodzi informacja:

„Trwa awaria po stronie dostawcy. Pracujemy nad rozwiązaniem.”

I wtedy pojawia się pytanie, które powinno interesować Zarząd:

czy awaria dostawcy ICT musi oznaczać zatrzymanie procesu banku?

Jeżeli odpowiedź brzmi „tak”, warto wiedzieć jak długo, dlaczego i co bank zrobi dalej.

Czy bank wie, które usługi ZDU są naprawdę krytyczne?

Nie każdy dostawca ICT tworzy takie samo ryzyko.

W pierwszej kolejności należy wiedzieć:

• jaki proces wspiera dana usługa,
• czy jest to proces krytyczny,
• jak długo może pozostawać niedostępny,
• jakie RTO/RPO wynikają z BIA,
• czy istnieje rozwiązanie alternatywne.

To właśnie BIA pozwala odróżnić zwykłą awarię dostawcy od zdarzenia, które może szybko stać się kryzysem operacyjnym banku.

SLA mówi 99,9%. Ale co dzieje się podczas prawdziwej awarii?

Dostępność procentowa wygląda dobrze w umowie.

Tylko że Zarząd nie potrzebuje procentu.

Potrzebuje odpowiedzi:

„Kiedy usługa wróci?”

Warto sprawdzić:

• od którego momentu liczony jest czas awarii,
• jaki jest czas reakcji dostawcy,
• jaki czas przywrócenia został uzgodniony,
• czy parametry odpowiadają BIA,
• co dzieje się po przekroczeniu SLA.

SLA powinno wspierać potrzeby banku, a nie tylko dobrze wyglądać w raporcie.

Czy BCP/DR dostawcy naprawdę działa?

Bank może otrzymać od ZDU informację:

„Posiadamy BCP i Disaster Recovery.”

To ważne.

Ale jeszcze ważniejsze jest pytanie:

czy te mechanizmy zostały przetestowane i czy bank zna wynik testów?

Warto wiedzieć:

• kiedy wykonano ostatni test,
• co obejmował,
• jaki czas odtworzenia osiągnięto,
• jakie problemy wykryto,
• czy wdrożono działania naprawcze.

Dokument BCP/DR jest deklaracją.

Wynik testu jest dowodem.

Co jeśli dostawca nie potrafi podać czasu naprawy?

To jeden z najtrudniejszych momentów.

Bank pyta:

„Kiedy usługa wróci?”

Dostawca odpowiada:

„Nie jesteśmy jeszcze w stanie podać ETA.”

Wtedy bank powinien mieć własny punkt decyzyjny.

Nie może czekać bez końca.

Powinno być wiadomo:

• jak długo można pozostać w trybie awaryjnym,
• kiedy uruchomić rozwiązanie alternatywne,
• kiedy eskalować problem,
• kiedy informować Zarząd,
• kiedy rozpocząć działania wynikające z Exit Planu.

Komunikacja awaryjna może zdecydować o skali problemu

Podczas awarii bank potrzebuje nie tylko informacji:

„mamy problem”.

Potrzebuje odpowiedzi:

• co się wydarzyło,
• które usługi są objęte awarią,
• jaki jest przewidywany czas przywrócenia,
• czy istnieje ryzyko dla danych,
• jakie działania wykonuje ZDU,
• kiedy będzie kolejna aktualizacja.

Brak informacji może być równie problematyczny jak sama awaria.

Co naprawdę oznacza awaria ZDU dla banku?

Awaria dostawcy może wpływać na:

• procesy krytyczne,
• obsługę klientów,
• dostępność danych,
• realizację płatności,
• pracę placówek,
• obowiązki operacyjne i regulacyjne.

Dlatego ocena nie powinna kończyć się stwierdzeniem:

„dostawca ma awarię”.

Powinna odpowiedzieć:

„jaki jest wpływ tej awarii na bank?”

Najlepszy moment na test dostawcy? Zanim przestanie działać

Bank może przeprowadzić scenariusz:

krytyczny ZDU przestaje świadczyć usługę i przez kilka godzin nie podaje wiarygodnego czasu przywrócenia.

Następnie sprawdzić:

• kto reaguje,
• kto kontaktuje ZDU,
• kiedy informowany jest Zarząd,
• czy działa rozwiązanie alternatywne,
• czy bank mieści się w RTO,
• czy Exit Plan jest wykonalny.

Taki test może pokazać więcej niż kolejna ankieta dostawcy.

Exit Plan powinien być planem B

Jeżeli awaria się przedłuża, bank powinien wiedzieć:

co dalej?

Exit Plan powinien być powiązany z:

• krytycznością usługi,
• BIA,
• maksymalnym czasem przerwy,
• rozwiązaniem alternatywnym,
• migracją do innego dostawcy,
• przejęciem danych i konfiguracji.

Jeżeli strategia wyjścia istnieje wyłącznie w dokumentacji, może nie pomóc podczas realnej awarii.

7 pytań, które warto zadać o krytycznego ZDU

1. Który proces banku zatrzyma się, jeśli dostawca przestanie działać?
2. Jak długo bank może funkcjonować bez tej usługi?
3. Czy SLA odpowiada RTO/RPO z BIA?
4. Kiedy ostatnio ZDU przetestował BCP/DR?
5. Co robimy, gdy dostawca nie podaje czasu przywrócenia?
6. Czy mamy realne rozwiązanie alternatywne?
7. Czy kiedykolwiek przetestowaliśmy awarię tego dostawcy?

Jeżeli na któreś pytanie trudno odpowiedzieć, bank właśnie znalazł obszar wymagający sprawdzenia.

Podsumowanie

Outsourcing usługi nie oznacza outsourcingu ryzyka.

Bank może przekazać dostawcy:

system, usługę lub obsługę techniczną.

Nie przekazuje jednak odpowiedzialności za ciągłość własnych procesów.

Dlatego warto stosować prosty model:

BIA → ZDU → SLA → BCP/DR → test → rozwiązanie alternatywne → Exit Plan → dowód

Najważniejsze pytanie nie brzmi:

„Czy dostawca ma plan ciągłości?”

Ale:

„Czy bank potrafi działać, kiedy dostawca przestaje działać?”

Pytania i odpowiedzi

Czy awaria dostawcy ICT oznacza, że bank musi przestać działać?

Nie powinna automatycznie. Bank powinien znać wpływ awarii i posiadać rozwiązania wynikające z krytyczności usługi oraz BIA.

Jak BIA pomaga w nadzorze nad ZDU?

Pokazuje, które procesy zależą od dostawcy, jak długo mogą być niedostępne oraz jakie RTO/RPO powinien zapewnić ZDU.

Czy samo SLA wystarczy?

Nie. SLA należy zestawić z rzeczywistą zdolnością odtworzenia, BCP/DR, komunikacją awaryjną i wynikami testów.

Co zrobić, gdy ZDU nie podaje czasu przywrócenia?

Bank powinien uruchomić własną ścieżkę eskalacji i zgodnie z ustalonymi kryteriami zdecydować o rozwiązaniu alternatywnym lub kolejnych działaniach.

Czy bank powinien testować awarię dostawcy?

Tak. Test pozwala zweryfikować komunikację, decyzje, RTO, rozwiązania alternatywne oraz realność Exit Planu.

Co powinien wiedzieć Zarząd?

Jak krytyczna jest usługa, jaki jest wpływ awarii, ile czasu bank może czekać, jakie istnieją alternatywy i jakie ryzyko pozostaje.

Dostawca przestaje działać. Czy Twój bank wie, co robi dalej?

Tego najlepiej nie sprawdzać podczas prawdziwej awarii.

Jeżeli chcesz zweryfikować, czy SLA, BIA, BCP/DR, komunikacja awaryjna, rozwiązania alternatywne i Exit Plan krytycznego ZDU rzeczywiście chronią bank, skontaktuj się bezpośrednio ze specjalistami Servus Comp Kraków.

Pomagamy bankom spółdzielczym w:

• ocenie krytyczności usług ZDU,
• analizie SLA i RTO/RPO,
• weryfikacji BCP/DR dostawców,
• analizie komunikacji awaryjnej,
• projektowaniu testów awarii ZDU,
• ocenie rozwiązań alternatywnych,
• weryfikacji Exit Planów,
• dokumentowaniu wyników testów i luk,
• przygotowaniu rekomendacji dla Zarządu.

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

Dostawca może mieć awarię. Bank powinien mieć plan.

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

#AwariaDostawcyICT #ZDU #BankSpółdzielczy #DostawcaICT #SLA #BIA #RTO #RPO #BCP #DisasterRecovery #CiągłośćDziałania #ExitPlan #StrategiaWyjścia #RyzykoICT #DORA #TestyOdporności #Cyberbezpieczeństwo #ZarządBanku #OdpornośćCyfrowa #ServusCompKraków