Jeden dostawca, wiele systemów, jedno duże ryzyko. KNF pyta o koncentrację ICT

Ryzyko koncentracji dostawców ICT po ocenie KNF ryzyka ICT za 2025 r.

Ocena nadzorcza KNF ryzyka ICT za 2025 r. pokazała bankom spółdzielczym, że temat dostawców ICT nie kończy się na podpisaniu umowy, odebraniu aneksu DORA i wpisaniu dostawcy do rejestru.

To dopiero początek.

Prawdziwe pytanie brzmi:

czy Bank wie, jak bardzo jest zależny od jednego dostawcy ICT i co stanie się z Bankiem, jeżeli ten dostawca przestanie świadczyć usługę, ulegnie awarii, będzie miał incydent, nie dotrzyma SLA albo nie będzie w stanie wesprzeć Banku w sytuacji kryzysowej?

Ryzyko koncentracji ICT nie polega na tym, że dostawca jest zły. Często są to dostawcy dobrzy, sprawdzeni, wieloletni i sektorowo wyspecjalizowani. Problem polega na czymś innym: jeden dostawca może obsługiwać wiele systemów, wiele usług, wiele procesów i wiele funkcji krytycznych lub istotnych Banku jednocześnie.

A wtedy jego problem staje się problemem Banku.

Dostawca działa? To za mało

W wielu bankach spółdzielczych dominuje praktyczne podejście: skoro system działa, faktury są płacone, serwis odpowiada, a umowa jest podpisana, to ryzyko dostawcy jest pod kontrolą.

Z punktu widzenia DORA i oceny KNF takie podejście może być niewystarczające.

Bank powinien wiedzieć nie tylko, czy dostawca działa, ale również:

które procesy Banku od niego zależą,
które systemy ICT są z nim powiązane,
czy wspiera funkcje krytyczne lub istotne,
jakie są SLA, RTO i RPO,
czy występują podwykonawcy,
czy istnieje ryzyko koncentracji,
czy Bank ma plan wyjścia,
czy dostawca był oceniany, kontrolowany lub audytowany,
czy wyniki nadzoru nad dostawcą trafiają do Zarządu.

Jeżeli odpowiedź brzmi: „wiemy, że dostawca jest ważny, ale nie mamy tego dobrze opisanego” — to jest właśnie obszar ryzyka, który po ocenie KNF wymaga uporządkowania.

Czym jest ryzyko koncentracji dostawców ICT?

Ryzyko koncentracji dostawców ICT występuje wtedy, gdy Bank jest zbyt silnie zależny od jednego dostawcy, jednej grupy kapitałowej, jednej platformy technologicznej, jednego środowiska, jednej lokalizacji, jednego centrum danych albo jednego łańcucha podwykonawców.

W praktyce banku spółdzielczego może to oznaczać, że jeden dostawca obsługuje jednocześnie:

system centralny,
bankowość elektroniczną,
systemy płatnicze,
obsługę kart,
hosting,
infrastrukturę serwerową,
łącza,
backup,
SOC,
monitoring,
usługi serwisowe,
aplikacje regulacyjne,
systemy wspierające AML, raportowanie lub obsługę klienta.

Im więcej obszarów zależy od jednego dostawcy, tym większe znaczenie ma pytanie:

co stanie się z Bankiem, jeżeli ten dostawca nie będzie dostępny?

To nie jest pytanie teoretyczne. To pytanie o ciągłość działania, odporność operacyjną, bezpieczeństwo klientów, reputację Banku i odpowiedzialność Zarządu.

Dlaczego KNF zwraca uwagę na koncentrację ICT?

KNF patrzy na ryzyko ICT nie tylko przez pryzmat pojedynczego systemu lub pojedynczej umowy. Nadzór patrzy na zależności.

Jeżeli wiele kluczowych usług Banku zależy od jednego dostawcy, to awaria lub incydent u tego dostawcy może spowodować jednoczesne zakłócenie wielu procesów Banku.

Wtedy problem nie dotyczy już tylko technicznej niedostępności systemu. Problem dotyczy tego, czy Bank:

rozpoznał skalę zależności,
ocenił skutki biznesowe,
uwzględnił dostawcę w BIA,
powiązał dostawcę z funkcjami krytycznymi lub istotnymi,
ocenił ryzyko koncentracji,
ma działania ograniczające ryzyko,
posiada plan wyjścia,
testował scenariusz niedostępności dostawcy,
raportuje to ryzyko do Zarządu.

Koncentracja ICT jest ryzykiem zarządczym, a nie tylko technicznym.

Ryzyko koncentracji musi być powiązane z całym środowiskiem Banku

Tak jak przy strategii operacyjnej odporności cyfrowej, ciągłości działania ICT i testach odporności, również ryzyko koncentracji dostawców nie może być analizowane jako samotna wyspa.

Ocena dostawcy powinna czerpać z całego środowiska dokumentacyjnego Banku, w szczególności z:

rejestru dostawców ICT,
rejestru usług ICT,
rejestru systemów ICT,
klasyfikacji funkcji krytycznych lub istotnych,
analizy procesów BIA,
analizy ryzyka ICT,
BCP/DRP,
programu testowania odporności cyfrowej,
rejestru incydentów,
rejestru podatności,
umów i aneksów DORA,
SLA,
planów wyjścia,
wyników audytów i kontroli dostawców,
raportów dla Zarządu.

Jeżeli Bank ma rejestr dostawców, ale nie wie, które procesy i systemy są od nich zależne, rejestr jest tylko tabelą. Jeżeli Bank ma umowę, ale nie ma oceny ryzyka dostawcy, umowa nie wystarczy. Jeżeli Bank ma SLA, ale nie sprawdza jego realizacji, SLA jest deklaracją.

Siła jest w spójności dokumentów, danych, ryzyk, testów i decyzji Zarządu.

Co powinien obejmować nadzór nad ryzykiem koncentracji ICT?

1. Identyfikację kluczowych dostawców ICT

Bank powinien wiedzieć, którzy dostawcy mają największy wpływ na jego działalność.

Nie każdy dostawca ICT ma takie samo znaczenie. Inaczej należy traktować dostawcę drobnej aplikacji pomocniczej, a inaczej dostawcę systemu centralnego, bankowości elektronicznej, usług płatniczych, hostingu, SOC lub infrastruktury wspierającej funkcje krytyczne.

Bank powinien oznaczyć dostawców według ich znaczenia, np.:

dostawcy wspierający funkcje krytyczne lub istotne,
dostawcy usług podstawowych dla ciągłości działania,
dostawcy infrastrukturalni,
dostawcy bezpieczeństwa ICT,
dostawcy usług pomocniczych,
dostawcy o niskim wpływie na działalność Banku.

2. Powiązanie dostawców z systemami i procesami

To jeden z najważniejszych elementów.

Bank powinien umieć odpowiedzieć:

który dostawca wspiera który system, który proces i którą funkcję krytyczną lub istotną?

Przykład:

Jeżeli dostawca odpowiada za system bankowości elektronicznej, to Bank powinien wiedzieć, jakie procesy są od tego zależne: obsługa rachunków, płatności, dostęp klienta do usług, komunikacja elektroniczna, autoryzacja, obsługa incydentów, reklamacje.

Bez takiego powiązania Bank nie jest w stanie realnie ocenić skutków awarii dostawcy.

3. Analizę zależności od jednego dostawcy

Bank powinien sprawdzić, czy jeden dostawca nie obsługuje zbyt wielu krytycznych obszarów.

Warto ocenić:

liczbę usług świadczonych przez dostawcę,
liczbę systemów obsługiwanych przez dostawcę,
liczbę procesów zależnych od dostawcy,
liczbę funkcji krytycznych lub istotnych wspieranych przez dostawcę,
zależność od jednej platformy technologicznej,
zależność od jednego centrum danych,
zależność od jednego kanału komunikacji,
zależność od jednego zespołu wsparcia,
zależność od podwykonawców dostawcy.

To pozwala ocenić, czy problem dostawcy może stać się problemem całego Banku.

4. Ocenę SLA i realnych możliwości odtworzenia usługi

SLA nie może być traktowane jako formalny zapis w umowie.

Bank powinien sprawdzić:

czy SLA dotyczy usług krytycznych,
jakie są czasy reakcji,
jakie są czasy naprawy,
jakie są poziomy dostępności,
czy SLA jest mierzone,
czy dostawca raportuje wykonanie SLA,
czy Bank weryfikuje naruszenia SLA,
czy SLA jest zgodne z RTO/RPO wynikającymi z BIA,
czy kary umowne nie są jedynym mechanizmem ochronnym.

Bo nawet najlepsza kara umowna nie przywróci działania systemu w czasie kryzysu.

5. Analizę podwykonawców

Ryzyko koncentracji może być ukryte w łańcuchu podwykonawców.

Bank może mieć umowę z jednym dostawcą, ale faktycznie usługa może być zależna od:

centrum danych,
operatora telekomunikacyjnego,
dostawcy chmury,
producenta oprogramowania,
podmiotu serwisowego,
zewnętrznego SOC,
podmiotu utrzymującego infrastrukturę,
podwykonawcy helpdesk.

Dlatego Bank powinien wiedzieć, czy dostawca korzysta z podwykonawców, gdzie są świadczone usługi, jakie dane są przetwarzane i czy podwykonawcy wpływają na funkcje krytyczne lub istotne.

6. Plan wyjścia od dostawcy

Plan wyjścia nie jest dokumentem „na wszelki wypadek”. To dowód, że Bank rozumie, jak ograniczyć zależność od dostawcy.

Plan wyjścia powinien odpowiadać na pytania:

kiedy Bank może zakończyć współpracę,
jakie są warunki wypowiedzenia,
jakie dane trzeba odzyskać,
w jakim formacie,
kto odpowiada za migrację,
jaki jest minimalny czas przejścia,
czy istnieje dostawca alternatywny,
czy Bank ma procedurę awaryjnego działania,
jakie są koszty wyjścia,
jakie ryzyka mogą wystąpić przy migracji,
jak zapewnić ciągłość usług dla klientów.

Jeżeli Bank nie wie, jak wyjść od dostawcy, to jest od niego silnie zależny.

7. Testowanie scenariusza niedostępności dostawcy

Ryzyko koncentracji powinno być testowane praktycznie.

Bank powinien rozważyć scenariusze:

niedostępność systemu centralnego,
awaria bankowości elektronicznej,
brak kontaktu z dostawcą,
opóźniona reakcja serwisu,
incydent bezpieczeństwa u dostawcy,
awaria centrum danych dostawcy,
brak realizacji SLA,
niedostępność podwykonawcy,
konieczność uruchomienia procedur awaryjnych.

Takie scenariusze mogą być testowane w formie ćwiczeń technicznych, testów DRP, testów BCP albo ćwiczeń tabletop.

8. Raportowanie ryzyka koncentracji do Zarządu

Zarząd powinien wiedzieć, gdzie Bank jest najbardziej zależny od dostawców.

Raport dla Zarządu powinien obejmować:

listę kluczowych dostawców ICT,
dostawców wspierających funkcje krytyczne lub istotne,
obszary koncentracji,
usługi o największym znaczeniu,
naruszenia SLA,
incydenty u dostawców,
wyniki audytów lub kontroli,
status planów wyjścia,
ryzyka wymagające akceptacji,
działania ograniczające koncentrację.

Zarząd nie musi analizować każdej umowy technicznej. Ale powinien wiedzieć, gdzie pojedynczy dostawca może stać się pojedynczym punktem awarii dla Banku.

Pytania, które Bank może skierować do SOZ BPS

W związku z koordynacją przez SOZ BPS pytań i uwag do wyników oceny nadzorczej ryzyka ICT za 2025 r., Bank może przekazać pytania dotyczące sposobu interpretacji wymagań w zakresie ryzyka koncentracji dostawców ICT.

Pytania powinny być rzeczowe, praktyczne i ukierunkowane na uzyskanie wspólnego podejścia dla banków spółdzielczych.

1. Jak KNF definiuje ryzyko koncentracji dostawców ICT w przypadku banków spółdzielczych?

Czy ryzyko koncentracji należy rozumieć wyłącznie jako zależność od jednego dostawcy, czy również jako zależność od jednej platformy technologicznej, jednego centrum danych, jednego podwykonawcy, jednego operatora lub jednej grupy dostawców sektorowych?

2. Czy koncentracja sektorowa dostawców w bankach spółdzielczych będzie oceniana z uwzględnieniem specyfiki zrzeszeń?

Banki spółdzielcze często korzystają z ograniczonego katalogu wyspecjalizowanych dostawców sektorowych. Zasadne jest doprecyzowanie, czy KNF uwzględni tę specyfikę przy ocenie ryzyka koncentracji.

3. Jakie minimalne dane powinien zawierać rejestr dostawców ICT, aby umożliwiał ocenę ryzyka koncentracji?

Czy wystarczające są informacje o dostawcy, usłudze, systemie, funkcji krytycznej lub istotnej, lokalizacji świadczenia usługi, podwykonawcach, SLA, planie wyjścia i wyniku oceny ryzyka?

4. Czy Bank powinien oceniać koncentrację na poziomie dostawcy, usługi, systemu, procesu czy funkcji krytycznej?

To pytanie jest ważne, ponieważ jeden dostawca może obsługiwać wiele usług i systemów, a z kolei jedna usługa może wspierać wiele procesów Banku.

5. Jak KNF oczekuje dokumentowania działań ograniczających ryzyko koncentracji?

Czy wystarczające mogą być działania kompensujące, takie jak dodatkowy monitoring, testy DRP, procedury awaryjne, plan wyjścia, alternatywne kanały obsługi klienta albo dodatkowe raportowanie do Zarządu?

6. Czy plan wyjścia musi być opracowany dla każdego dostawcy ICT, czy tylko dla dostawców wspierających funkcje krytyczne lub istotne?

Bank powinien uzyskać doprecyzowanie zakresu wymaganych planów wyjścia, aby nie tworzyć nadmiarowej dokumentacji dla dostawców o niskim znaczeniu.

7. Czy audyty i kontrole dostawców ICT mogą być realizowane w formie przeglądu dokumentów, ankiety, raportu dostawcy albo potwierdzeń zgodności?

Dla banków spółdzielczych ważne jest ustalenie, czy nadzór nad dostawcą musi oznaczać każdorazowo audyt na miejscu, czy dopuszczalne są proporcjonalne formy kontroli.

8. Jak należy traktować dostawców, którzy nie umożliwiają indywidualnego audytu przez pojedynczy bank?

Czy w takich przypadkach dopuszczalne są raporty zbiorcze, certyfikaty, raporty audytowe, atestacje, wspólne działania zrzeszenia albo kontrole koordynowane sektorowo?

9. Czy Bank może zaliczyć działania SOZ BPS, zrzeszenia lub podmiotu sektorowego jako element nadzoru nad dostawcą?

Jeżeli tak, warto doprecyzować, jakie dowody Bank powinien posiadać u siebie, aby wykazać udział w takim modelu nadzoru.

10. Jak KNF ocenia ryzyko koncentracji, gdy zmiana dostawcy jest praktycznie trudna lub ekonomicznie nieuzasadniona?

Bank powinien wiedzieć, czy w takiej sytuacji wystarczające będzie udokumentowanie ryzyka, działań kompensujących, testów, planu wyjścia i akceptacji ryzyka przez Zarząd.

11. Czy Bank powinien raportować ryzyko koncentracji dostawców ICT do Zarządu w odrębnym raporcie?

Czy może być ono elementem okresowego raportu ICT/DORA, raportu ryzyka operacyjnego, raportu z przeglądu dostawców lub raportu z przeglądu ram zarządzania ryzykiem ICT?

12. Czy SOZ BPS planuje opracowanie wspólnego minimalnego standardu oceny ryzyka koncentracji dostawców ICT dla banków spółdzielczych?

Taki standard pomógłby bankom stosować jednolite podejście i ograniczyć ryzyko rozbieżnych interpretacji przy kolejnych ocenach nadzorczych.

Najczęstsze błędy banków

Błąd 1: dostawca jest w rejestrze, ale bez powiązania z procesami

Sam wpis w rejestrze dostawców nie wystarczy. Trzeba wiedzieć, które systemy, procesy i funkcje krytyczne zależą od danego dostawcy.

Błąd 2: brak oceny ryzyka koncentracji

Bank ocenia dostawcę ogólnie, ale nie analizuje, czy jeden dostawca obsługuje wiele kluczowych usług jednocześnie.

Błąd 3: SLA istnieje, ale nie jest monitorowane

Umowa zawiera SLA, ale Bank nie sprawdza, czy poziomy usług są faktycznie dotrzymywane.

Błąd 4: brak planu wyjścia

Bank wie, że dostawca jest kluczowy, ale nie ma praktycznego scenariusza zakończenia współpracy albo przejścia na inne rozwiązanie.

Błąd 5: brak wiedzy o podwykonawcach

Bank zna głównego dostawcę, ale nie zna podwykonawców, którzy faktycznie mogą wpływać na dostępność i bezpieczeństwo usługi.

Błąd 6: brak raportowania do Zarządu

Ryzyko koncentracji pozostaje na poziomie operacyjnym, a Zarząd nie otrzymuje informacji o kluczowych zależnościach Banku od dostawców ICT.

Co Bank powinien zrobić po ocenie KNF?

1. Zaktualizować rejestr dostawców ICT

Rejestr powinien wskazywać nie tylko nazwę dostawcy i usługę, ale także systemy, procesy, funkcje krytyczne lub istotne, SLA, podwykonawców, lokalizację świadczenia usługi, plan wyjścia i wynik oceny ryzyka.

2. Powiązać dostawców z BIA i analizą ryzyka ICT

Dostawcy powinni być oceniani nie w oderwaniu od Banku, ale w powiązaniu z procesami, systemami, RTO/RPO i skutkami niedostępności.

3. Ocenić koncentrację usług u jednego dostawcy

Bank powinien sprawdzić, czy jeden dostawca nie wspiera zbyt wielu kluczowych systemów lub procesów.

4. Przejrzeć SLA i umowy

Należy sprawdzić, czy umowy zawierają realne wymagania dotyczące dostępności, bezpieczeństwa, incydentów, ciągłości działania, audytu, podwykonawców i zakończenia współpracy.

5. Opracować lub uzupełnić plany wyjścia

W szczególności dla dostawców wspierających funkcje krytyczne lub istotne.

6. Wprowadzić monitoring i raportowanie

Wyniki oceny dostawców, ryzyko koncentracji, naruszenia SLA, incydenty i plany działań powinny być raportowane do Zarządu.

Pytania, które Bank powinien sobie zadać

Czy wiemy, którzy dostawcy ICT wspierają funkcje krytyczne lub istotne?
Czy wiemy, które systemy i procesy zależą od każdego dostawcy?
Czy jeden dostawca obsługuje wiele kluczowych usług Banku?
Czy mamy ocenę ryzyka koncentracji?
Czy znamy podwykonawców kluczowych dostawców?
Czy SLA jest monitorowane i raportowane?
Czy mamy plan wyjścia dla dostawców krytycznych lub istotnych?
Czy testowaliśmy scenariusz niedostępności dostawcy?
Czy ryzyko koncentracji jest uwzględnione w BIA, BCP/DRP i analizie ryzyka ICT?
Czy Zarząd otrzymuje informację o kluczowych zależnościach od dostawców ICT?

Jeżeli Bank odpowiada „nie”, „częściowo” albo „nie mamy dowodu”, obszar wymaga uporządkowania.

Pytania i odpowiedzi

Czy ryzyko koncentracji oznacza, że Bank musi zmienić dostawcę?

Nie zawsze. Ryzyko koncentracji nie oznacza automatycznie konieczności zmiany dostawcy. Oznacza konieczność rozpoznania zależności, oceny skutków, wdrożenia działań ograniczających ryzyko i raportowania do Zarządu.

Czy dostawca sektorowy może być źródłem ryzyka koncentracji?

Tak. Nawet dobry i sprawdzony dostawca może generować ryzyko koncentracji, jeżeli obsługuje wiele kluczowych systemów lub procesów Banku.

Czy plan wyjścia musi być bardzo szczegółowy?

Dla dostawców wspierających funkcje krytyczne lub istotne powinien być praktyczny i możliwy do użycia. Nie chodzi o dokument teoretyczny, ale o realny scenariusz działania.

Czy audyt dostawcy zawsze musi być audytem na miejscu?

Nie zawsze. W zależności od charakteru usługi i możliwości Banku dopuszczalne mogą być różne formy nadzoru: ankieta, przegląd dokumentów, raport dostawcy, certyfikat, raport audytowy, spotkanie kontrolne lub działania koordynowane przez zrzeszenie.

Czy Zarząd powinien znać ryzyko koncentracji?

Tak. Zarząd powinien wiedzieć, od których dostawców Bank jest najbardziej zależny i jakie działania ograniczające ryzyko zostały wdrożone.

Najważniejszy wniosek

Po ocenie KNF ryzyka ICT za 2025 r. Bank nie powinien pytać wyłącznie:

czy mamy podpisane umowy z dostawcami ICT?

Bank powinien zapytać:

czy wiemy, jak bardzo Bank jest zależny od kluczowych dostawców ICT i co zrobimy, jeżeli jeden z nich przestanie działać?

Ryzyko koncentracji dostawców ICT to nie problem formalny. To problem ciągłości działania, bezpieczeństwa, odporności cyfrowej i odpowiedzialności Zarządu.

Jeden dostawca, wiele systemów, jedno duże ryzyko — chyba że Bank potrafi to ryzyko rozpoznać, ograniczyć i udokumentować.

10 wybranych najważniejszych tematów po ocenie KNF ryzyka ICT 2025

Strategia ICT to za mało. KNF pyta o operacyjną odporność cyfrową Banku:
https://premiumbank.zadbajobezpieczenstwo.pl/strategia-ict-to-za-malo-knf-pyta-o-operacyjna-odpornosc-cyfrowa-banku/
Backup jest? To za mało. KNF zapyta, czy Bank potrafi się odtworzyć:
https://premiumbank.zadbajobezpieczenstwo.pl/backup-jest-to-za-malo-knf-zapyta-czy-bank-potrafi-sie-odtworzyc-strategia-ciaglosci-dzialania-ict-po-ocenie-knf-ryzyka-ict-za-2025-r/
Skan to za mało. KNF zapyta, czy Bank naprawdę testuje odporność ICT:
https://premiumbank.zadbajobezpieczenstwo.pl/skan-podatnosci-to-nie-test-odpornosci-knf-zapyta-czy-bank-naprawde-testuje-ict/
Jeden dostawca, wiele systemów, jedno duże ryzyko. KNF pyta o koncentrację ICT:
https://premiumbank.zadbajobezpieczenstwo.pl/jeden-dostawca-wiele-systemow-jedno-duze-ryzyko-knf-pyta-o-koncentracje-ict/
Audyt ZDU — czy wiesz, kogo naprawdę powinien kontrolować Bank?:
https://premiumbank.zadbajobezpieczenstwo.pl/audyt-zdu-w-banku-spoldzielczym-jak-kontrolowac-dostawcow-zewnetrznych-zgodnie-z-dora/
Zarząd musi wiedzieć. KNF zapyta, kto naprawdę nadzoruje ryzyko ICT w Banku:
https://premiumbank.zadbajobezpieczenstwo.pl/raport-ict-do-zarzadu-knf-pyta-kto-nadzoruje-ryzyko-ict-w-banku/
Znalazłeś podatność? KNF zapyta, kiedy ją usunąłeś:
https://premiumbank.zadbajobezpieczenstwo.pl/znalazles-podatnosc-knf-zapyta-kiedy-ja-usunales-zarzadzanie-podatnosciami-ict-po-ocenie-knf-ryzyka-ict-za-2025-r/
Masz procedury DORA? KNF zapyta: kiedy ostatnio naprawdę je przeczytałeś?:
https://premiumbank.zadbajobezpieczenstwo.pl/coroczny-przeglad-dokumentacji-ict-dora-w-banku-spoldzielczym-po-ocenie-nadzorczej-knf-ryzyka-ict-za-2025-r/
DORA nie zna wymówki: pracownik nie miał czasu na szkolenie:
https://premiumbank.zadbajobezpieczenstwo.pl/szkolenia-ict-dora-po-ocenie-knf-ryzyka-ict-za-2025-r-czy-bank-przeszkolil-wszystkich-czy-tylko-ma-plan-szkolenia/
Dokument jest? KNF zapyta o dowód, że działa:
https://premiumbank.zadbajobezpieczenstwo.pl/dokument-jest-knf-zapyta-o-dowod-ze-dziala/

O genezie powstania 10 wybranych tematów można dowiedzieć się więcej :
https://premiumbank.zadbajobezpieczenstwo.pl/10-wybranych-najwazniejszych-zalecen-knf-po-ocenie-ryzyka-ict-2025-praktyczne-podsumowanie-dla-bankow-spoldzielczych/

Servus Comp Kraków — wsparcie dla banków spółdzielczych

Servus Comp Kraków wspiera banki spółdzielcze w ocenie i porządkowaniu ryzyka dostawców ICT, w tym ryzyka koncentracji.

W ramach współpracy pomagamy bankom w szczególności w zakresie:

aktualizacji rejestru dostawców ICT,
aktualizacji rejestru usług ICT,
powiązania dostawców z systemami, procesami i funkcjami krytycznymi lub istotnymi,
oceny ryzyka koncentracji ICT,
przeglądu SLA i umów ICT,
przygotowania planów wyjścia,
opracowania ankiet i kart oceny dostawców,
przygotowania audytów i kontroli dostawców ICT,
powiązania dostawców z BIA, BCP/DRP i analizą ryzyka ICT,
przygotowania raportów dla Zarządu,
opracowania materiałów dowodowych po ocenie KNF ryzyka ICT.

Wspieramy banki zarówno w ramach stałej współpracy, jak również w formie oddzielnych ofert na opracowanie lub przegląd wymaganej dokumentacji.

Jeżeli Państwa Bank chce sprawdzić, czy rejestr dostawców, SLA, BIA, plany wyjścia i ocena ryzyka koncentracji tworzą spójny system nadzoru nad dostawcami ICT, zapraszamy do kontaktu z Servus Comp Kraków.

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

#DORA #KNF #RyzykoICT #DostawcyICT #ZDU #OutsourcingICT #BankSpółdzielczy #RyzykoKoncentracji #SOZBPS #BCP #BIA #ServusComp