Skan to za mało. KNF zapyta, czy Bank naprawdę testuje odporność ICT

Testowanie operacyjnej odporności cyfrowej po ocenie KNF ryzyka ICT za 2025 r.

Ocena nadzorcza KNF ryzyka ICT za 2025 r. pokazała bankom spółdzielczym, że samo posiadanie dokumentacji, procedur, strategii i planów nie wystarczy. Bank musi jeszcze wykazać, że jego środowisko ICT jest regularnie testowane, wyniki testów są dokumentowane, podatności są usuwane, a wnioski trafiają do Zarządu.

Jednym z obszarów, który w praktyce wymaga szczególnej uwagi, jest testowanie operacyjnej odporności cyfrowej. To temat, który często bywa zawężany wyłącznie do skanu podatności albo jednego raportu technicznego. Tymczasem takie podejście jest zbyt wąskie.

Skan podatności to ważny element bezpieczeństwa ICT, ale nie jest jeszcze pełnym testem operacyjnej odporności cyfrowej Banku.

Testowanie odporności ICT to nie jeden raport ze skanera

W wielu bankach funkcjonuje podejście: „robimy skan podatności, więc testowanie ICT mamy wykonane”. Niestety, z punktu widzenia DORA i oczekiwań nadzorczych to może być niewystarczające.

Skan podatności odpowiada głównie na pytanie:

czy w środowisku występują znane luki techniczne?

Ale nie odpowiada na wiele innych pytań, które są kluczowe dla odporności cyfrowej Banku:

Czy Bank potrafi odtworzyć system po awarii?
Czy backup został realnie przetestowany?
Czy systemy wspierające funkcje krytyczne lub istotne są objęte testami?
Czy testowano scenariusz ransomware?
Czy procedura obsługi incydentu została przećwiczona?
Czy podatności krytyczne zostały usunięte i potwierdzone retestem?
Czy dostawcy ICT uczestniczą w testach lub przedstawiają dowody odporności?
Czy Zarząd otrzymał raport z wyników testów i zaleceń?

Jeżeli Bank nie potrafi odpowiedzieć na te pytania, to sam raport ze skanera nie zbuduje odporności i nie będzie wystarczającym materiałem dowodowym.

Co KNF może rozumieć przez testowanie operacyjnej odporności cyfrowej?

Testowanie operacyjnej odporności cyfrowej powinno być traktowane jako program działań, a nie pojedyncze wydarzenie.

Taki program powinien obejmować różne rodzaje testów, dostosowane do skali, profilu ryzyka, wykorzystywanych systemów, funkcji krytycznych lub istotnych oraz zależności od dostawców ICT.

W praktyce Bank powinien posiadać:

• roczny program testowania odporności ICT,
• harmonogram testów,
• zakres testów dla systemów wspierających funkcje krytyczne lub istotne,
• raporty z wykonanych testów,
• rejestr podatności i zaleceń,
• terminy usuwania podatności,
• retesty po wdrożeniu działań naprawczych,
• rejestr wyjątków i ryzyk akceptowanych czasowo,
• raportowanie wyników do Zarządu.

Testowanie odporności cyfrowej to cykl: zaplanuj, wykonaj, udokumentuj, napraw, przetestuj ponownie i zaraportuj.

Jakie testy powinien uwzględnić Bank?

1. Skanowanie podatności

Skan podatności jest potrzebny, ale powinien być częścią większego procesu. Bank powinien wiedzieć:

• jakie systemy i hosty są skanowane,
• jak często wykonywane są skany,
• czy obejmują systemy wspierające funkcje krytyczne lub istotne,
• kto analizuje wyniki,
• kto odpowiada za usunięcie podatności,
• jakie są terminy usunięcia podatności,
• czy wykonano retest,
• czy wynik trafił do raportu dla Zarządu.

Samo wykrycie podatności nie rozwiązuje problemu. W ocenie odporności liczy się to, czy Bank potrafi podatność skutecznie obsłużyć.

Znaleźć lukę to dopiero początek. Trzeba ją jeszcze usunąć, potwierdzić retestem i udokumentować zamknięcie.

2. Testy systemów wspierających funkcje krytyczne lub istotne

Bank powinien szczególnie zadbać o systemy, które wspierają funkcje krytyczne lub istotne. To one powinny być traktowane priorytetowo w programie testowania.

Testy powinny obejmować nie tylko warstwę techniczną, ale również zależności biznesowe:

• proces, który system wspiera,
• właściciela procesu,
• właściciela systemu,
• dostawcę systemu,
• RTO/RPO,
• backup,
• dostępność,
• uprawnienia,
• monitoring,
• integracje,
• podatności,
• incydenty,
• scenariusze awaryjne.

Jeżeli Bank testuje system, ale nie wie, jaki proces jest od niego zależny, to test ma ograniczoną wartość zarządczą.

3. Testy backupu i odtworzenia

Backup bez testu odtworzenia to tylko deklaracja.

Bank powinien okresowo sprawdzać:

• czy kopia zapasowa rzeczywiście się wykonuje,
• czy dane można odtworzyć,
• czy dane są kompletne,
• czy dane są integralne,
• ile trwa odtworzenie,
• czy czas odtworzenia mieści się w RTO,
• czy utrata danych mieści się w RPO,
• czy po odtworzeniu system działa poprawnie,
• czy wynik testu został udokumentowany.

Test backupu nie powinien kończyć się informacją: „kopia wykonana”. Powinien odpowiadać na pytanie:

czy Bank potrafi wrócić do działania po awarii lub cyberataku?

4. Testy scenariuszowe

DORA i odporność cyfrowa wymagają myślenia scenariuszowego. Bank powinien testować nie tylko pojedyncze systemy, ale również zdarzenia, które mogą zakłócić ciągłość działania.

Przykładowe scenariusze:

• ransomware,
• awaria bankowości elektronicznej,
• niedostępność systemu centralnego,
• niedostępność dostawcy ICT,
• awaria łącza,
• utrata dostępu do danych,
• awaria poczty elektronicznej,
• błąd aktualizacji,
• incydent phishingowy,
• niedostępność administratora,
• naruszenie bezpieczeństwa danych.

Test scenariuszowy powinien pokazać, czy Bank wie, kto podejmuje decyzje, kto komunikuje się z dostawcą, kto informuje Zarząd, kto obsługuje klientów, kto dokumentuje zdarzenie i kto zamyka działania naprawcze.

5. Testy procedury incydentowej

Procedura incydentowa może być dobrze napisana, ale dopiero test pokazuje, czy działa.

Bank powinien sprawdzić:

• czy pracownicy wiedzą, jak zgłosić incydent,
• czy incydent jest klasyfikowany,
• czy działa ścieżka eskalacji,
• czy wiadomo, kiedy zdarzenie może być poważnym incydentem ICT,
• czy działa komunikacja z Zarządem,
• czy działa komunikacja z dostawcą,
• czy tworzona jest dokumentacja incydentu,
• czy wykonywana jest analiza przyczyn,
• czy powstają działania następcze.

Zamknięcie zgłoszenia to nie koniec incydentu. Koniec incydentu to wnioski, działania naprawcze i dowód ich wykonania.

6. Testy dostawców ICT

W bankach spółdzielczych wiele usług ICT zależy od dostawców zewnętrznych. Dlatego program testowania powinien uwzględniać również dostawców, szczególnie tych, którzy wspierają funkcje krytyczne lub istotne.

Bank powinien ustalić:

• czy dostawca wykonuje własne testy,
• czy Bank otrzymuje raporty lub potwierdzenia testów,
• czy umowa przewiduje współpracę przy testach,
• czy dostawca uczestniczy w testach ciągłości działania,
• czy znane są SLA i czasy odtworzenia,
• czy dostawca posiada BCP/DRP,
• czy Bank zna podwykonawców,
• czy istnieje plan wyjścia.

Jeżeli dostawca obsługuje kluczową usługę, to brak wiedzy o jego odporności staje się ryzykiem Banku.

Program testów ICT/DORA — co powinien zawierać?

Bank powinien przygotować program testowania operacyjnej odporności cyfrowej, który będzie dokumentem praktycznym, a nie ogólną deklaracją.

Zakres testów

Należy wskazać, które systemy, aplikacje, usługi, procesy, dostawcy i scenariusze będą objęte testami.

Priorytety

Najwyższy priorytet powinny mieć systemy wspierające funkcje krytyczne lub istotne, usługi dostępne z Internetu, systemy o wysokim poziomie ryzyka, systemy po zmianach oraz obszary, w których wystąpiły incydenty lub podatności.

Częstotliwość

Program powinien wskazywać, które testy są wykonywane raz w roku, które częściej, a które po istotnej zmianie.

Odpowiedzialności

Bank powinien wiedzieć, kto planuje test, kto go wykonuje, kto analizuje wynik, kto usuwa nieprawidłowości i kto raportuje do Zarządu.

Dokumentowanie wyników

Każdy test powinien kończyć się raportem lub protokołem, który zawiera:

• datę testu,
• zakres testu,
• osoby lub podmioty uczestniczące,
• testowany system lub proces,
• scenariusz,
• wynik,
• stwierdzone braki,
• poziom ryzyka,
• działania naprawcze,
• terminy,
• właścicieli działań,
• informację o retestach.

Retesty

Retest jest kluczowy. Bez retestu Bank nie wie, czy problem został faktycznie rozwiązany.

Zalecenie bez retestu jest tylko obietnicą poprawy.

Rejestr podatności i zaleceń — serce procesu testowania

Bank powinien prowadzić rejestr podatności i zaleceń, który pozwala rozliczyć cały proces od wykrycia do zamknięcia.

Rejestr powinien zawierać:

• identyfikator podatności lub zalecenia,
• źródło wykrycia,
• system lub zasób,
• poziom krytyczności,
• właściciela,
• datę wykrycia,
• wymagany termin usunięcia,
• status,
• działania naprawcze,
• datę usunięcia,
• wynik retestu,
• wyjątek ryzyka, jeżeli podatność nie może być usunięta w terminie,
• informację o eskalacji do Zarządu.

Dobrze prowadzony rejestr pokazuje, że Bank zarządza słabościami środowiska ICT, a nie tylko je zbiera.

Raport do Zarządu — testy muszą kończyć się decyzją

Wyniki testów nie powinny zostawać wyłącznie w IT.

Zarząd powinien otrzymywać syntetyczną informację:

• jakie testy wykonano,
• które systemy objęto testami,
• jakie stwierdzono podatności,
• które podatności są krytyczne lub wysokie,
• co zostało już usunięte,
• co jest po terminie,
• jakie ryzyka wymagają akceptacji,
• jakie działania wymagają budżetu,
• jakie zależności dotyczą dostawców,
• jakie są wnioski na kolejny okres.

Zarząd nie musi znać każdego technicznego szczegółu. Ale musi wiedzieć, czy Bank realnie wzmacnia odporność cyfrową.

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 testowania operacyjnej odporności cyfrowej. Pytania powinny być konkretne, niekonfrontacyjne i ukierunkowane na uzyskanie wspólnej interpretacji dla banków spółdzielczych.

Poniżej przykładowy zestaw pytań do wykorzystania w ankiecie lub stanowisku kierowanym do SOZ BPS.

1. Jak KNF definiuje minimalny zakres testowania operacyjnej odporności cyfrowej dla banku spółdzielczego?

Czy za wystarczający można uznać program obejmujący skany podatności, testy backupu, testy DRP, testy scenariuszowe, testy procedury incydentowej, przegląd uprawnień oraz testy usług dostępnych z Internetu, jeżeli zakres jest oparty na analizie ryzyka?

2. Czy skan podatności może być traktowany jako jeden z testów odporności cyfrowej, ale nie jako pełne wykonanie programu testowania?

Bank powinien uzyskać potwierdzenie, że skan podatności jest elementem programu testowania, ale nie zastępuje innych testów, takich jak testy odtworzeniowe, scenariuszowe, incydentowe i ciągłości działania.

3. Jak należy rozumieć obowiązek testowania systemów wspierających funkcje krytyczne lub istotne?

Czy każdy system wspierający funkcję krytyczną lub istotną powinien być testowany odrębnie, czy dopuszczalne jest grupowanie testów według procesu, platformy technologicznej, dostawcy, usługi lub scenariusza zakłócenia?

4. Czy testy backupu i odtworzenia mogą być zaliczone do programu testowania operacyjnej odporności cyfrowej?

Jeżeli tak, jakie minimalne elementy powinien zawierać protokół lub raport z takiego testu: zakres, system, dane, czas odtworzenia, zgodność z RTO/RPO, wynik, błędy i działania naprawcze?

5. Czy test scenariuszowy, np. ransomware, awaria bankowości elektronicznej albo niedostępność dostawcy ICT, może być traktowany jako test odporności cyfrowej?

Bank powinien uzyskać doprecyzowanie, czy ćwiczenia scenariuszowe i tabletop mogą stanowić element programu testowania odporności, szczególnie w bankach spółdzielczych.

6. Jak KNF oczekuje dokumentowania retestów?

Czy wystarczające jest potwierdzenie usunięcia podatności przez administratora, czy wymagany jest formalny retest wykonany przez niezależnego audytora, dostawcę narzędzia, SOC albo inną jednostkę?

7. Jak należy postępować z podatnościami, których nie można usunąć w terminie?

Czy akceptowalne jest zastosowanie rejestru wyjątków ryzyka, zabezpieczeń kompensujących, monitoringu, decyzji właściciela ryzyka i terminu ponownej weryfikacji?

8. Czy wyniki testów powinny być raportowane do Zarządu w formie odrębnego raportu, czy mogą być częścią okresowego raportu ICT/DORA?

Bank powinien ustalić, jaka forma raportowania będzie uznawana za wystarczającą: osobny raport z programu testów, kwartalny raport ICT, raport bezpieczeństwa informacji albo raport z realizacji działań DORA.

9. Jakie dowody SOZ BPS/KNF uznaje za minimalnie wystarczające dla potwierdzenia realizacji programu testowania?

Przykładowo: program testów, harmonogram, raporty skanów, protokoły testów backupu, raporty DRP, rejestr podatności, retesty, plan naprawczy, raport do Zarządu, decyzje Zarządu.

10. Czy testy realizowane przez dostawców ICT lub w ramach usług SOC mogą być zaliczone do programu testowania Banku?

Jeżeli tak, Bank powinien wiedzieć, jakie potwierdzenia powinien posiadać: raport dostawcy, certyfikat, protokół testu, SLA, informację o zakresie testu, potwierdzenie działań naprawczych.

11. Jak KNF ocenia sytuację, gdy Bank posiada różne testy, ale nie były one formalnie nazwane „programem testowania operacyjnej odporności cyfrowej”?

To pytanie jest ważne dla banków, które wykonywały skany, testy backupu, testy BCP/DRP i audyty bezpieczeństwa, ale nie spinały ich w jeden formalny program testowania DORA.

12. Czy SOZ BPS planuje opracowanie wspólnego minimalnego katalogu testów odporności cyfrowej dla banków spółdzielczych?

Takie doprecyzowanie pozwoliłoby bankom stosować jednolite podejście i ograniczyć ryzyko rozbieżnych interpretacji przy kolejnych ocenach.

Najczęstsze błędy banków

Błąd 1: utożsamienie skanu podatności z testowaniem odporności

Skan jest tylko jednym z testów. Nie zastępuje testu odtworzenia, testu scenariuszowego, testu incydentowego ani programu testowania KLIF.

Błąd 2: brak retestów

Bank wykrywa podatności, usuwa część z nich, ale nie potwierdza retestem, że problem został zamknięty.

Błąd 3: brak powiązania testów z BIA i KLIF

Testy są wykonywane technicznie, ale nie wiadomo, które procesy i funkcje krytyczne zabezpieczają.

Błąd 4: brak harmonogramu

Testy są wykonywane doraźnie, a nie zgodnie z rocznym programem.

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

Wyniki testów zostają w IT, a Zarząd nie otrzymuje informacji o ryzyku i działaniach naprawczych.

Błąd 6: brak planu naprawczego

Raport z testu istnieje, ale nie ma właścicieli, terminów, statusów i rozliczenia wykonania.

Co Bank powinien zrobić po ocenie KNF?

1. Przyjąć roczny program testowania operacyjnej odporności cyfrowej

Program powinien obejmować systemy, procesy, dostawców, scenariusze, częstotliwość, odpowiedzialności i sposób raportowania.

2. Ustalić priorytet dla systemów wspierających funkcje krytyczne lub istotne

Systemy KLIF powinny być objęte testami w pierwszej kolejności i z największą starannością.

3. Uporządkować rejestr podatności i zaleceń

Każda podatność i każde zalecenie powinny mieć właściciela, termin, status i retest.

4. Wprowadzić retesty jako obowiązkowy element procesu

Bez retestu nie ma pewności, że problem został rozwiązany.

5. Połączyć testy z BIA, BCP/DRP i analizą ryzyka ICT

Testy powinny wynikać z tego, co jest krytyczne dla działania Banku.

6. Raportować wyniki Zarządowi

Zarząd powinien otrzymywać okresowy raport z testów, podatności, retestów, zaległości i ryzyk.

Pytania, które Bank powinien sobie zadać

1. Czy mamy roczny program testowania odporności ICT?
2. Czy testy obejmują systemy wspierające funkcje krytyczne lub istotne?
3. Czy wykonujemy testy backupu i odtworzenia?
4. Czy testujemy scenariusz ransomware?
5. Czy prowadzimy rejestr podatności i zaleceń?
6. Czy każda podatność ma właściciela i termin usunięcia?
7. Czy wykonujemy retesty?
8. Czy wyniki testów są raportowane Zarządowi?
9. Czy testy są powiązane z BIA, BCP/DRP i analizą ryzyka ICT?
10. Czy uwzględniamy w testach dostawców ICT?

Jeżeli Bank na kilka z tych pytań odpowiada „nie”, „częściowo” albo „nie mamy dowodu”, to program testowania wymaga uporządkowania.

Pytania i odpowiedzi

Czy skan podatności wystarczy jako test odporności ICT?

Nie. Skan podatności jest ważny, ale nie zastępuje kompleksowego programu testowania odporności cyfrowej.

Czy każdy system musi być testowany tak samo?

Nie. Zakres testów powinien być oparty na ryzyku. Systemy wspierające funkcje krytyczne lub istotne powinny mieć najwyższy priorytet.

Czy test backupu jest elementem testowania odporności cyfrowej?

Tak. Zwłaszcza wtedy, gdy obejmuje realne odtworzenie danych lub systemu i weryfikację RTO/RPO.

Czy retest jest konieczny?

Tak, jeżeli test wykazał podatność lub nieprawidłowość. Retest potwierdza, że problem został faktycznie usunięty.

Czy wyniki testów powinny trafiać do Zarządu?

Tak. Zarząd powinien otrzymywać informację o wynikach testów, podatnościach, opóźnieniach, ryzykach i działaniach naprawczych.

Najważniejszy wniosek

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

czy mamy raport ze skanera?

Bank powinien zapytać:

czy mamy kompletny program testowania odporności ICT, który pokazuje, że Bank potrafi wykryć słabości, usunąć podatności, odtworzyć działanie, obsłużyć incydent i udokumentować wyniki przed Zarządem?

Skan to za mało. Odporność zaczyna się wtedy, gdy Bank potrafi przetestować, naprawić i udowodnić skuteczność działania.

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

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

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

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

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

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

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

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

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

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

10. 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 opracowaniu, przeglądzie i realizacji programu testowania operacyjnej odporności cyfrowej.

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

• opracowania programu testowania ICT/DORA,
• przeglądu zakresu testów dla systemów wspierających funkcje krytyczne lub istotne,
• powiązania testów z BIA, BCP/DRP i analizą ryzyka ICT,
• organizacji skanów podatności,
• przygotowania testów odtworzeniowych,
• dokumentowania wyników testów,
• opracowania rejestru podatności i zaleceń,
• przygotowania planów naprawczych,
• raportowania wyników do Zarządu,
• przygotowania 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 i programu testów.

Jeżeli Państwa Bank chce sprawdzić, czy skan podatności, testy backupu, DRP, incydenty, dostawcy i raportowanie do Zarządu tworzą spójny program odporności cyfrowej, 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 #TestyICT #OdpornośćCyfrowa #SkanPodatności #BankSpółdzielczy #Cyberbezpieczeństwo #BCP #DRP #SOZBPS #ServusComp