BANK MA PROCEDURY. AUDYTOR PYTA: „PROSZĘ POKAZAĆ, ŻE ONE DZIAŁAJĄ”.

Procedura jest.

Zarząd ją zatwierdził.

Pracownicy zostali z nią zapoznani.

Dokument ma numer wersji, datę przeglądu i właściciela.

Audytor zadaje jednak jedno pytanie:

„Proszę pokazać dowód, że ta procedura rzeczywiście działa.”

I właśnie wtedy zaczyna się prawdziwa weryfikacja.

Bo w obszarze bezpieczeństwa ICT samo posiadanie dokumentu nie oznacza jeszcze, że bank potrafi zgodnie z nim działać.

Procedura to początek. Nie dowód

Dobra dokumentacja jest potrzebna.

Ale audyt powinien odpowiadać również na pytania:

• czy procedura była stosowana,
• czy została przetestowana,
• kto uczestniczył w teście,
• jaki był wynik,
• jakie problemy wykryto,
• czy zostały usunięte,
• czy skuteczność poprawy została ponownie sprawdzona.

Dlatego warto myśleć o prostym łańcuchu:

PROCEDURA → TEST → WYNIK → LUKA → DZIAŁANIE → DOWÓD

BCP i DRP – czy plan naprawdę można wykonać?

Bank może posiadać rozbudowany BCP i DRP.

Ale dopiero scenariusz awaryjny pokaże:

• czy role są aktualne,
• czy osoby wiedzą, co robić,
• czy dane kontaktowe działają,
• czy kolejność odtwarzania jest prawidłowa,
• czy można osiągnąć RTO/RPO,
• czy zależności ICT zostały właściwie opisane.

Audytor może więc zapytać nie tylko:

„Czy bank posiada DRP?”

ale:

„Kiedy ostatnio go przetestowano i jaki był wynik?”

To zasadnicza różnica.

SOC – czy alert rzeczywiście prowadzi do działania?

Bank ma SOC.

To również jeszcze nie jest dowód skuteczności.

Warto potrafić pokazać konkretny przypadek:

alert → analiza → eskalacja → decyzja → działanie → zamknięcie

Dowodem mogą być m.in.:

• zgłoszenie SOC,
• czas reakcji,
• historia eskalacji,
• działania IT,
• decyzje ABI/ASI,
• dokumentacja zamknięcia zdarzenia.

Najważniejsze pytanie brzmi:

czy SOC tylko generuje alerty, czy bank potrafi wykazać, co się z nimi później dzieje?

Backup „SUCCESS” również nie wystarczy

Raport:

Backup wykonany prawidłowo

jest dowodem wykonania kopii.

Nie jest jeszcze dowodem zdolności odtworzenia.

Znacznie mocniejszym dowodem jest:

protokół testu restore + osiągnięty czas + zgodność z RTO/RPO + wykryte problemy + działania naprawcze.

Audytor powinien móc zobaczyć, że bank nie tylko tworzy kopie.

Potrafi z nich wrócić do działania.

ZDU – ankieta dostawcy nie kończy nadzoru

Dostawca potwierdził:

• posiadanie BCP,
• wykonywanie backupu,
• stosowanie zabezpieczeń,
• prowadzenie testów.

To ważne informacje.

Ale bank powinien również potrafić wykazać własny nadzór nad ZDU.

Na przykład:

• przegląd SLA,
• analizę raportów,
• ocenę incydentów,
• przegląd BCP/DR,
• wyniki testów dostawcy,
• decyzje wynikające z wykrytych problemów,
• monitoring działań naprawczych.

Nadzór powinien prowadzić do decyzji.

Nie tylko do zebrania kolejnej ankiety.

Jak powinien wyglądać dobry dowód z testu?

Protokół testu nie musi mieć kilkudziesięciu stron.

Powinien jednak jasno wskazywać:

• co testowano,
• kiedy,
• kto uczestniczył,
• jakie były kryteria sukcesu,
• jaki osiągnięto rezultat,
• jakie wykryto luki,
• kto odpowiada za poprawę,
• jaki jest termin,
• czy wykonano retest.

Wtedy audytor widzi cały proces.

Nie tylko dokument.

Największy problem? Luka została wykryta i nic dalej się nie wydarzyło

Test wykazał problem.

Powstała rekomendacja.

I temat został zamknięty w raporcie.

To za mało.

Każda istotna luka powinna otrzymać:

właściciela → działanie → termin → oczekiwany rezultat → weryfikację.

Jeżeli działanie naprawcze nie zostało sprawdzone, bank nadal nie wie, czy problem rzeczywiście zniknął.

7 pytań, które warto zadać przed audytem

1. Które kluczowe procedury były faktycznie testowane?
2. Czy posiadamy protokoły i wyniki tych testów?
3. Czy BCP/DRP został sprawdzony scenariuszowo?
4. Czy potrafimy pokazać pełną ścieżkę obsługi alertu SOC?
5. Czy mamy dowód rzeczywistego odtworzenia z backupu?
6. Czy potrafimy wykazać aktywny nadzór nad ZDU?
7. Czy wszystkie istotne luki mają zamknięte i zweryfikowane działania naprawcze?

Jeżeli przy którymś pytaniu pojawia się:

„chyba mamy taki dokument…”

warto sprawdzić to przed audytem.

Co powinien zobaczyć Zarząd?

Zarząd nie potrzebuje segregatora dowodów.

Powinien jednak otrzymywać jasną informację:

co sprawdziliśmy → co zadziałało → co nie zadziałało → jakie jest ryzyko → co poprawiamy → kiedy będzie retest.

Dzięki temu testowanie nie jest tylko wymaganiem audytowym.

Staje się elementem rzeczywistego zarządzania odpornością banku.

Podsumowanie

W audycie coraz ważniejsze jest nie tylko:

„Czy bank posiada procedurę?”

ale również:

„Czy bank potrafi wykazać, że procedura działa?”

Dlatego praktyczny model powinien wyglądać tak:

PROCEDURA → TEST → WYNIK → LUKA → DZIAŁANIE NAPRAWCZE → RETEST → DOWÓD

Dokument opisuje, jak powinno być.

Dowód pokazuje, jak było naprawdę.

Pytania i odpowiedzi

Czy sama procedura wystarcza jako dowód zgodności?

Nie zawsze. Procedura pokazuje przyjęte zasady, ale skuteczność mechanizmu najlepiej potwierdzają również wyniki testów, kontroli i rzeczywistych działań.

Jakie procedury warto testować?

W pierwszej kolejności te dotyczące procesów i mechanizmów o największym znaczeniu: BCP/DRP, incydentów, backupu, SOC, dostępu oraz nadzoru nad ZDU.

Co powinien zawierać protokół testu?

Zakres, termin, uczestników, scenariusz lub kryteria, wynik, wykryte luki, działania naprawcze, właścicieli i terminy.

Czy wynik negatywny testu jest problemem?

Sam negatywny wynik nie musi być problemem. Znacznie większym problemem jest wykrycie luki bez późniejszego działania naprawczego.

Czy po działaniu naprawczym potrzebny jest retest?

Warto go przeprowadzić, ponieważ dopiero ponowna weryfikacja pozwala potwierdzić skuteczność wprowadzonej poprawy.

Jak wykazać nadzór nad dostawcą ICT?

Poprzez udokumentowane przeglądy, ocenę raportów, incydentów, SLA, testów BCP/DR oraz decyzje i działania wynikające z wykrytych problemów.

Co jest najlepszym dowodem dla audytora?

Spójny łańcuch pokazujący, że bank nie tylko zidentyfikował wymaganie, ale również je wdrożył, przetestował, ocenił wynik i usunął wykryte luki.

Audytor jutro poprosi o dowód. Czy wiesz, co mu pokażesz?

Nie warto budować dowodowości dopiero podczas audytu.

Jeżeli chcesz sprawdzić, czy procedury BCP/DRP, SOC, backup, reakcja na incydenty i nadzór nad ZDU posiadają rzeczywiste, spójne i możliwe do wykazania dowody działania, skontaktuj się bezpośrednio ze specjalistami Servus Comp Kraków.

Pomagamy bankom spółdzielczym w:

• przeglądzie dowodów zgodności,
• przygotowaniu programów testów,
• testowaniu BCP/DRP,
• weryfikacji dowodów SOC i obsługi incydentów,
• testach backupu i odtworzenia,
• ocenie nadzoru nad ZDU,
• budowie rejestrów działań naprawczych,
• retestach,
• przygotowaniu materiałów dla audytora i Zarządu.

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

Nie wystarczy pokazać procedurę. Trzeba potrafić pokazać, że ona działa.

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