Backup jest? To za mało. KNF zapyta, czy Bank potrafi się odtworzyć

Strategia ciągłości działania ICT po ocenie KNF ryzyka ICT za 2025 r.

Ocena nadzorcza KNF ryzyka ICT za 2025 r. po raz kolejny pokazała bankom spółdzielczym, że w obszarze DORA nie wystarczy odpowiedzieć: „mamy backup”, „mamy BCP”, „mamy DRP” albo „procedura ciągłości działania jest przyjęta uchwałą”.

To dopiero początek.

Prawdziwe pytanie brzmi:

czy Bank potrafi udowodnić, że po awarii, cyberataku, utracie systemu, problemie z dostawcą albo niedostępności usługi ICT jest w stanie odtworzyć działanie procesów krytycznych lub istotnych w wymaganym czasie?

Jeżeli odpowiedź brzmi: „nie testowaliśmy tego kompleksowo”, „mamy tylko kopie”, „informatyk wie, co robić”, „dostawca odpowiada za system”, „nie mamy pełnego raportu z testu” — to z punktu widzenia nadzorczego pojawia się ryzyko.

Kopia zapasowa to nie strategia ciągłości działania ICT

W wielu bankach spółdzielczych funkcjonuje przekonanie, że jeżeli wykonywane są kopie zapasowe, to temat ciągłości działania ICT jest zabezpieczony.

To jest niebezpieczne uproszczenie.

Backup jest tylko jednym z elementów odporności cyfrowej. Sam fakt posiadania kopii zapasowej nie oznacza jeszcze, że Bank:

• wie, które systemy trzeba odtworzyć w pierwszej kolejności,
• zna wymagane RTO i RPO,
• sprawdził integralność kopii,
• przetestował odtworzenie danych,
• przetestował odtworzenie systemu,
• wie, kto podejmuje decyzję o uruchomieniu procedury awaryjnej,
• ma scenariusz działania przy ransomware,
• wie, jak działać przy niedostępności dostawcy ICT,
• potrafi udokumentować wynik testu,
• przedstawił wnioski Zarządowi.

Kopia zapasowa bez testu odtworzenia jest obietnicą, nie dowodem.

Dlaczego KNF pyta o ciągłość działania ICT?

DORA wymaga, aby Bank patrzył na ICT nie tylko jako na technologię, ale jako na fundament świadczenia usług finansowych. Jeżeli system bankowości elektronicznej, system centralny, system rozliczeniowy, poczta, sieć, dostęp administracyjny, system AML, system obsługi płatności albo dostawca kluczowej usługi ICT przestanie działać, Bank musi wiedzieć, jak utrzymać lub odtworzyć działanie.

Ocena KNF ryzyka ICT za 2025 r. pokazała, że nadzór będzie oczekiwał od banków nie tylko procedury, ale również dowodu, że ciągłość działania ICT jest:

opisana, powiązana z BIA, powiązana z analizą ryzyka ICT, przetestowana, udokumentowana i raportowana do Zarządu.

To oznacza, że strategia ciągłości działania ICT nie może być dokumentem oderwanym od reszty środowiska proceduralnego Banku.

Strategia ciągłości działania ICT musi być spójna z całym środowiskiem Banku

Największy błąd to stworzenie dokumentu pod nazwą „Strategia ciągłości działania ICT”, który nie ma realnego związku z BIA, DRP, backupem, dostawcami ICT, rejestrem systemów, analizą ryzyka i testami.

Taki dokument może wyglądać dobrze formalnie, ale przy praktycznej ocenie będzie słaby.

Strategia ciągłości działania ICT powinna czerpać z:

• analizy procesów BIA,
• klasyfikacji funkcji krytycznych lub istotnych,
• rejestru systemów ICT,
• rejestru usług ICT,
• rejestru dostawców ICT,
• analizy ryzyka środowiska ICT,
• BCP,
• DRP,
• procedur backupu,
• wyników testów odtworzeniowych,
• wyników testów odporności ICT,
• rejestru incydentów,
• rejestru podatności,
• planów wyjścia od dostawców ICT,
• raportów dla Zarządu.

Dopiero wtedy strategia ciągłości działania ICT ma sens.

Oderwane procedury to dokumentacyjne wyspy. A wyspy dokumentacyjne nie budują odporności. Odporność powstaje wtedy, gdy dokumenty, testy, systemy, procesy, dostawcy i decyzje Zarządu tworzą jeden spójny mechanizm.

Co powinna zawierać strategia ciągłości działania ICT?

1. Powiązanie z BIA

BIA wskazuje, które procesy Banku są krytyczne lub istotne, jakie mają wymagania czasowe i jakie skutki powoduje ich niedostępność.

Strategia ciągłości działania ICT powinna odpowiedzieć:

• które procesy są zależne od ICT,
• które systemy wspierają te procesy,
• jacy dostawcy obsługują te systemy,
• jakie są wymagania RTO/RPO,
• jakie scenariusze awaryjne należy testować,
• jakie są minimalne zasoby potrzebne do odtworzenia działania.

BIA bez powiązania z ICT jest niepełna. Strategia ICT bez BIA jest oderwana od rzeczywistości.

2. RTO i RPO dla systemów oraz procesów

Bank powinien wiedzieć, jak długo może nie działać dany proces i ile danych może utracić bez istotnego wpływu na klientów, rozliczenia, zgodność regulacyjną i reputację.

RTO i RPO nie mogą być wpisane przypadkowo.

Muszą wynikać z:

• krytyczności procesu,
• wymagań biznesowych,
• zależności od systemów,
• wymagań regulacyjnych,
• możliwości technicznych,
• umów z dostawcami,
• wyników testów.

Jeżeli BIA mówi jedno, DRP drugie, umowa z dostawcą trzecie, a backup działa według czwartego harmonogramu — Bank ma problem.

3. Scenariusze awaryjne

Strategia ciągłości działania ICT powinna obejmować realne scenariusze, a nie tylko ogólne zapisy.

Przykładowe scenariusze:

• awaria systemu centralnego,
• niedostępność bankowości elektronicznej,
• ransomware,
• utrata dostępu do danych,
• awaria łącza,
• awaria serwerowni,
• niedostępność dostawcy ICT,
• awaria systemu płatności,
• awaria poczty elektronicznej,
• brak dostępności kluczowego administratora,
• niedostępność usług wspierających funkcje krytyczne lub istotne.

Każdy scenariusz powinien mieć przypisane:

• odpowiedzialności,
• ścieżkę eskalacji,
• kryteria uruchomienia,
• działania techniczne,
• działania biznesowe,
• komunikację,
• sposób dokumentowania,
• sposób zakończenia i raportowania.

4. Testy backupu i odtworzenia

To jeden z najważniejszych elementów.

Bank powinien testować nie tylko fakt wykonania kopii, ale również:

• możliwość odtworzenia danych,
• integralność danych,
• czas odtworzenia,
• kompletność odtworzenia,
• odtworzenie aplikacji,
• odtworzenie uprawnień,
• odtworzenie konfiguracji,
• odtworzenie integracji,
• możliwość pracy po odtworzeniu,
• zgodność wyniku testu z RTO/RPO.

Test zakończony stwierdzeniem „backup wykonuje się poprawnie” nie wystarczy, jeżeli Bank nie sprawdził, czy z tej kopii można realnie odtworzyć działanie.

5. Dostawcy ICT w ciągłości działania

W bankach spółdzielczych istotna część odporności zależy od dostawców zewnętrznych. Dotyczy to systemów centralnych, bankowości elektronicznej, kart, płatności, usług chmurowych, hostingu, łączy, SOC, serwisu, dostawców oprogramowania i infrastruktury.

Strategia ciągłości działania ICT powinna wskazywać:

• którzy dostawcy wspierają funkcje krytyczne lub istotne,
• jakie mają SLA,
• jakie są ich obowiązki w awarii,
• jakie są kanały kontaktu,
• czy dostawca ma własne BCP/DRP,
• czy dostawca testuje swoje plany,
• czy Bank ma plan wyjścia,
• czy istnieje ryzyko koncentracji,
• czy Bank ma alternatywę lub działania kompensujące.

Jeżeli dostawca przestaje działać, problem klienta nadal trafia do Banku.

6. Raportowanie do Zarządu

Ciągłość działania ICT nie jest tylko sprawą IT. To temat dla Zarządu.

Zarząd powinien otrzymywać informacje o:

• wynikach testów backupu,
• wynikach testów DRP,
• niespełnieniu RTO/RPO,
• problemach z dostawcami,
• zaległych działaniach naprawczych,
• ryzykach akceptowanych czasowo,
• scenariuszach, które nie zostały przetestowane,
• potrzebach budżetowych,
• rekomendowanych zmianach w dokumentacji.

Zarząd nie musi znać każdego technicznego szczegółu. Ale powinien wiedzieć, czy Bank faktycznie może się odtworzyć po awarii lub cyberataku.

Najczęstsze błędy banków

Błąd 1: „Mamy backup, więc mamy ciągłość”

Nie. Backup to tylko narzędzie. Ciągłość działania wymaga procesu, scenariuszy, RTO/RPO, odpowiedzialności, testów i raportów.

Błąd 2: Brak testu odtworzenia

Bank może mieć kopie, ale nie wiedzieć, czy da się je skutecznie odtworzyć. To jedna z najpoważniejszych luk dowodowych.

Błąd 3: BIA nie jest powiązana z ICT

Jeżeli analiza BIA nie przekłada się na systemy, dostawców, backup, DRP i testy, to Bank ma tylko fragment procesu.

Błąd 4: DRP jest nieaktualny

Procedura odtworzeniowa może opisywać systemy, osoby, dostawców lub lokalizacje, które już nie odpowiadają stanowi faktycznemu.

Błąd 5: Brak raportu do Zarządu

Jeżeli wyniki testów i ryzyka ciągłości działania ICT nie trafiają do Zarządu, trudno wykazać realny nadzór.

Błąd 6: Brak scenariuszy ransomware

W obecnych realiach testy ciągłości bez scenariusza cyberataku są niepełne.

Co Bank powinien zrobić po ocenie KNF?

1. Zweryfikować BIA

Bank powinien sprawdzić, czy BIA aktualnie wskazuje:

• procesy krytyczne lub istotne,
• wymagania RTO/RPO,
• zależności od systemów ICT,
• zależności od dostawców,
• skutki niedostępności procesów,
• minimalne zasoby do odtworzenia działania.

2. Zaktualizować strategię ciągłości działania ICT

Dokument powinien wskazywać, jak Bank zapewnia i odtwarza działanie systemów ICT wspierających procesy Banku.

3. Przejrzeć DRP i procedury backupu

Należy sprawdzić, czy procedury są aktualne i zgodne z realnym środowiskiem technicznym Banku.

4. Przygotować harmonogram testów

Testy powinny obejmować nie tylko backup, ale także odtworzenie systemów, scenariusze awaryjne, incydenty ICT i zależności od dostawców.

5. Udokumentować wyniki

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

• zakres testu,
• datę,
• osoby uczestniczące,
• testowany system,
• wynik,
• czas odtworzenia,
• zgodność z RTO/RPO,
• błędy,
• działania naprawcze,
• termin realizacji,
• właściciela działania.

6. Przekazać wyniki Zarządowi

Zarząd powinien otrzymać podsumowanie wyników, ryzyk i rekomendacji.

Pytania, które Bank powinien sobie zadać

1. Czy wiemy, które systemy ICT wspierają funkcje krytyczne lub istotne?
2. Czy mamy aktualne RTO/RPO dla tych systemów?
3. Czy RTO/RPO wynikają z BIA?
4. Czy backupy są testowane odtworzeniowo?
5. Czy testowaliśmy odtworzenie po ransomware?
6. Czy testowaliśmy odtworzenie systemu, a nie tylko pliku?
7. Czy dostawcy ICT mają obowiązki ciągłościowe w umowach?
8. Czy wyniki testów są raportowane Zarządowi?
9. Czy działania naprawcze po testach są rozliczane?
10. Czy strategia ciągłości działania ICT jest przeglądana co najmniej raz w roku?

Jeżeli na którekolwiek z tych pytań Bank odpowiada „nie wiemy”, „częściowo”, „nie mamy dowodu” — temat wymaga uporządkowania.

Pytania i odpowiedzi

Czy backup wystarczy do spełnienia wymagań ciągłości działania ICT?

Nie. Backup jest jednym z elementów. Bank musi wykazać, że potrafi odtworzyć dane, systemy, dostępność usług i procesy w wymaganym czasie.

Czy test backupu to to samo co test DRP?

Nie. Test backupu sprawdza kopię. Test DRP powinien sprawdzać możliwość odtworzenia działania systemu lub usługi w określonym scenariuszu.

Czy BCP i DRP mogą być osobnymi dokumentami?

Tak, ale muszą być spójne. BCP pokazuje ciągłość działania procesów, DRP pokazuje odtworzenie technologii. Strategia ciągłości działania ICT powinna je łączyć.

Czy testy powinny obejmować dostawców?

Tak, szczególnie jeżeli dostawca wspiera funkcję krytyczną lub istotną. Bank powinien wiedzieć, jakie obowiązki ma dostawca i jakie dowody odporności może przedstawić.

Czy wyniki testów trzeba pokazywać Zarządowi?

Tak. Zarząd powinien znać najważniejsze wyniki testów, ryzyka, opóźnienia, braki i działania naprawcze.

Najważniejszy wniosek

Po ocenie KNF ryzyka ICT za 2025 r. Bank nie powinien pytać wyłącznie: „czy mamy backup?”

Bank powinien zapytać:

czy potrafimy udowodnić, że odtworzymy działanie po awarii lub cyberataku?

To oznacza konieczność powiązania backupu, DRP, BCP, BIA, analizy ryzyka ICT, dostawców, testów i raportowania do Zarządu w jeden spójny system.

Backup jest ważny. Ale backup to za mało. Odporność zaczyna się dopiero wtedy, gdy Bank potrafi odtworzyć działanie i ma na to dowód.

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 aktualizacji dokumentacji ciągłości działania ICT oraz dokumentacji DORA.

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

• opracowania strategii ciągłości działania ICT,
• aktualizacji BIA,
• przeglądu BCP/DRP,
• analizy ryzyka środowiska ICT,
• przeglądu procedur backupu i odtwarzania,
• przygotowania programu testów odporności cyfrowej,
• dokumentowania testów backupu i DRP,
• powiązania ciągłości działania z dostawcami ICT,
• przygotowania raportów dla Zarządu,
• przygotowania odpowiedzi i 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 backup, BIA, BCP, DRP i strategia ciągłości działania ICT tworzą spójny system odporności, 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 #Backup #BCP #DRP #BIA #CiągłośćDziałania #BankSpółdzielczy #Cyberbezpieczeństwo #ServusComp