DORA, RTS, EBA, KNF – JAK NIE POGUBIĆ SIĘ W WYTYCZNYCH I WIEDZIEĆ, CO NAPRAWDĘ WDROŻYĆ?

DORA. RTS. EBA. KNF. Do tego polityki, instrukcje, rejestry, BIA, ocena ryzyka ICT, dostawcy, SOC, incydenty, testy, backup, podatności…

Dokumentów przybywa. Wymagań również. I w pewnym momencie pojawia się bardzo praktyczne pytanie: czy bank rzeczywiście buduje odporność, czy tylko kolejne dokumenty dotyczące odporności?

To zasadnicza różnica. Bo celem wdrożenia DORA i RTS w banku spółdzielczym nie powinno być stworzenie największego segregatora procedur.

Celem powinno być zbudowanie systemu, w którym bank wie:

co jest krytyczne → jakie istnieje ryzyko → jak jest chronione → jak jest monitorowane → jak jest testowane → kto odpowiada → jaki mamy dowód skuteczności.

Problemem nie jest brak regulacji. Problemem jest ich połączenie

Bank może posiadać:

BIA,
analizę ryzyka ICT,
politykę bezpieczeństwa,
instrukcję zarządzania incydentami,
procedurę backupu,
umowy z ZDU,
raporty SOC,
skany podatności,
plany BCP i DRP,
wyniki testów.

Każdy z tych elementów może być poprawny.

Ale czy są ze sobą logicznie połączone?

Przykład.

BIA wskazuje proces krytyczny.

Proces wykorzystuje konkretny system ICT.

System ma podatność Critical.

SOC monitoruje zdarzenia związane z tym systemem.

Backup ma określone RTO/RPO.

Część infrastruktury utrzymuje ZDU.

To nie jest sześć oddzielnych tematów.

To jeden łańcuch odporności banku.

BIA powinna być początkiem mapy

Jednym z najważniejszych punktów odniesienia jest BIA.

To ona pomaga odpowiedzieć:

które procesy są krytyczne,
jak długo mogą być niedostępne,
jakie systemy je wspierają,
jakie dane są potrzebne,
od których dostawców zależą,
jakie RTO/RPO są wymagane.

Bez tego łatwo traktować wszystkie systemy, podatności i dostawców niemal jednakowo.

A przecież nie wszystko w banku ma takie samo znaczenie.

BIA nadaje priorytet.

Od procesu do aktywa ICT

Kolejny krok to powiązanie procesu z technologią.

Bank powinien potrafić przejść ścieżkę:

proces → usługa → system → aplikacja → infrastruktura → dane → ZDU

Dzięki temu wiadomo, jakie aktywa ICT rzeczywiście wspierają procesy krytyczne.

To z kolei wpływa na:

ocenę ryzyka,
monitoring,
podatności,
backup,
testy,
ciągłość działania,
wymagania wobec dostawców.

Bez takiego powiązania rejestr aktywów pozostaje głównie ewidencją.

Ryzyko ICT powinno wynikać z rzeczywistego wpływu

Nie każde ryzyko techniczne ma taki sam wpływ biznesowy.

Dlatego ocena ryzyka ICT powinna uwzględniać nie tylko prawdopodobieństwo zdarzenia.

Ważne jest również:

co stanie się z bankiem, jeżeli dane zagrożenie rzeczywiście się zmaterializuje?

Czy zatrzyma proces krytyczny?

Czy uniemożliwi obsługę klientów?

Czy wpłynie na dostępność danych?

Czy spowoduje przekroczenie RTO?

Czy bank ma rozwiązanie alternatywne?

Dopiero wtedy ryzyko zaczyna być informacją zarządczą, a nie wyłącznie wartością w tabeli.

SOC powinien wiedzieć, co jest ważne dla banku

SOC może widzieć tysiące zdarzeń.

Ale techniczny poziom alertu nie zawsze oznacza jego rzeczywisty priorytet dla banku.

Alert dotyczący systemu wspierającego proces krytyczny może wymagać zupełnie innej reakcji niż podobne zdarzenie dotyczące mniej istotnego zasobu.

Dlatego potrzebne jest powiązanie:

SOC → aktywo → proces → BIA → wpływ biznesowy → eskalacja

Wtedy monitoring zaczyna wspierać odporność banku, a nie tylko bezpieczeństwo techniczne.

Critical nie zawsze oznacza „napraw pierwsze”

Podobnie jest z podatnościami.

CVSS 9,8 wygląda poważnie.

I często rzeczywiście jest poważny.

Ale priorytet powinien uwzględniać również:

ekspozycję systemu,
krytyczność procesu,
dostępność exploita,
aktywne zagrożenia,
zastosowane zabezpieczenia,
znaczenie danych,
możliwość wykorzystania podatności.

Dlatego praktyczny model powinien wyglądać raczej tak:

CVSS + ekspozycja + BIA + Threat Intelligence + zabezpieczenia = priorytet działania

Nie tylko:

najwyższy CVSS = pierwsza poprawka.

Backup trzeba połączyć z BIA i testem odtworzenia

Bank wykonuje backup.

Raport pokazuje: SUCCESS.

Ale wymaganie biznesowe brzmi: „Proces musi wrócić do działania w czasie wynikającym z BIA.”

To dwie różne rzeczy.

Dlatego backup należy połączyć z:

RTO,
RPO,
kolejnością odtwarzania,
zależnościami systemów,
testem restore,
protokołem wyniku.

Dopiero wtedy bank posiada dowód zdolności odtworzenia.

ZDU również jest częścią tej samej mapy

Jeżeli proces krytyczny zależy od dostawcy ICT, bank powinien wiedzieć:

jak krytyczna jest jego usługa,
jakie SLA obowiązuje,
czy parametry odpowiadają BIA,
czy ZDU posiada BCP/DR,
czy rozwiązania były testowane,
jakie są podwykonawstwa,
jak wygląda Exit Plan,
co stanie się podczas długiej awarii.

Nie wystarczy więc posiadać rejestr dostawców.

Trzeba rozumieć rzeczywistą zależność banku od każdego istotnego ZDU.

Test łączy dokumentację z rzeczywistością

Można posiadać bardzo dobre procedury.

Ale dopiero test odpowiada na pytanie: czy to naprawdę działa?

Dlatego spójny system powinien obejmować m.in.:

testy BCP,
testy DRP,
testy odtworzenia backupu,
scenariusze incydentowe,
testy komunikacji,
testy awarii ZDU,
retesty po działaniach naprawczych.

Wyniki powinny prowadzić do kolejnego etapu:

luka → właściciel → działanie → termin → retest → dowód zamknięcia

A gdzie w tym wszystkim DORA, RTS, EBA i KNF?

Właśnie tutaj.

Nie powinny funkcjonować jako cztery oddzielne „światy dokumentacyjne”.

Ich wymagania trzeba przełożyć na konkretne mechanizmy działające w banku.

Dlatego zamiast pytać wyłącznie: „Czy mamy zapis zgodny z wymaganiem?”

warto również zapytać: „Gdzie ten mechanizm działa, kto za niego odpowiada, kiedy był sprawdzony i jaki mamy dowód?”

To zmienia sposób patrzenia na zgodność.

Z: regulacja → dokument

na: wymaganie → proces → odpowiedzialność → mechanizm → test → dowód

10 pytań porządkujących DORA i RTS w banku

Warto sprawdzić, czy bank potrafi odpowiedzieć na następujące pytania:

Które procesy są krytyczne i dlaczego?
Jakie aktywa ICT wspierają te procesy?
Jakie są najważniejsze ryzyka ICT?
Czy SOC wie, które systemy wymagają priorytetowej reakcji?
Czy podatności są priorytetyzowane według rzeczywistego ryzyka?
Czy backup i odtworzenie odpowiadają RTO/RPO z BIA?
Którzy ZDU są krytyczni dla działania banku?
Czy procedury zostały przetestowane?
Czy wykryte luki prowadzą do działań i retestów?
Czy Zarząd otrzymuje dowody skuteczności, a nie tylko informację, że dokumenty istnieją?

Jeżeli odpowiedzi tworzą jeden spójny obraz, wdrożenie zaczyna działać systemowo.

Jeżeli każdej odpowiedzi trzeba szukać w innym miejscu i nikt nie potrafi ich połączyć — warto uporządkować model.

Co powinien zobaczyć Zarząd?

Zarząd nie musi analizować setek stron DORA, RTS i dokumentacji technicznej.

Powinien jednak otrzymać czytelny obraz: co jest krytyczne → jakie mamy ryzyka → jak je zabezpieczamy → co testowaliśmy → co nie zadziałało → co poprawiamy → jakie ryzyko pozostaje

To jest informacja potrzebna do podejmowania decyzji.

Nie lista nazw procedur.

Podsumowanie

Największym wyzwaniem nie jest stworzenie kolejnego dokumentu.

Jest nim połączenie wszystkich elementów w jeden działający system zarządzania odpornością ICT.

Praktyczna mapa może wyglądać tak: BIA → AKTYWA → RYZYKO ICT → ZABEZPIECZENIA → SOC → PODATNOŚCI → BACKUP/DR → ZDU → TESTY → INCYDENTY → DOWODY → ZARZĄD

Wtedy DORA i RTS przestają być zbiorem oddzielnych obowiązków.

Zaczynają tworzyć logiczny model zarządzania odpornością banku.

Pytania i odpowiedzi

Od czego zacząć porządkowanie DORA i RTS w banku?

Dobrym punktem odniesienia jest BIA oraz identyfikacja procesów krytycznych, a następnie powiązanie ich z aktywami ICT, ryzykiem, dostawcami i mechanizmami ciągłości.

Czy sama dokumentacja wystarcza do wykazania zgodności?

Dokumentacja jest ważna, ale trzeba również wykazać, że określone mechanizmy zostały wdrożone, działają i są odpowiednio testowane.

Jak połączyć BIA z ryzykiem ICT?

Krytyczność procesu i wpływ jego niedostępności powinny być jednym z elementów oceny rzeczywistego znaczenia ryzyka ICT.

Jaką rolę odgrywa SOC?

SOC powinien nie tylko wykrywać zdarzenia, ale również posiadać kontekst pozwalający określić ich znaczenie dla krytycznych procesów banku.

Jak traktować dostawców ICT?

Należy oceniać rzeczywistą zależność banku od ich usług, parametry SLA, ciągłość działania, BCP/DR, podwykonawców oraz możliwość wyjścia z usługi.

Jak wykazać, że wdrożone zabezpieczenia działają?

Poprzez testy, wyniki, protokoły, obsługę wykrytych luk, działania naprawcze oraz retesty potwierdzające ich skuteczność.

DORA wdrożona. RTS przeanalizowane. Procedury są. Ale czy wszystko tworzy jeden system?

To pytanie warto zadać przed kolejnym audytem, kontrolą lub poważnym incydentem.

Jeżeli BIA funkcjonuje osobno, ryzyko ICT osobno, SOC osobno, ZDU osobno, testy osobno, a Zarząd otrzymuje kolejne niezależne raporty — problemem może nie być brak dokumentacji.

Problemem może być brak połączeń między jej elementami.

W Servus Comp Kraków pomagamy bankom spółdzielczym uporządkować ten model poprzez:

mapowanie wymagań DORA, RTS, EBA i KNF,
powiązanie BIA z ICT i ryzykiem,
analizę aktywów i zależności,
ocenę SOC i podatności,
weryfikację backupu i DR,
nadzór nad ZDU i Exit Planami,
projektowanie testów odporności,
budowę dowodów zgodności,
przygotowanie czytelnego obrazu ryzyka i odporności dla Zarządu.

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

Nie chodzi o to, aby mieć osobny dokument na każde wymaganie. Chodzi o to, aby wszystkie elementy razem chroniły bank.

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.

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 #RTS #EBA #KNF #BankSpółdzielczy #ZgodnośćRegulacyjna #OdpornośćCyfrowa #OdpornośćOperacyjna #BIA #RyzykoICT #AktywaICT #SOC #Podatności #Backup #DisasterRecovery #ZDU #IncydentyICT #TestyOdporności #DowodyZgodności #ZarządBanku #Cyberbezpieczeństwo #ServusCompKraków