Audyt zgodności DORA dla banku krok po kroku

Audyt zgodności DORA dla banku porządkuje luki, dowody i plan remediacji. Sprawdź zakres, metodykę oraz rezultaty oczekiwane przez zarząd i regulatora.

17 stycznia 2025 r. DORA przestała być projektem regulacyjnym, a stała się operacyjnym wymaganiem dla banków. Problem nie polega jednak na samym potwierdzeniu, że polityki istnieją. Audyt zgodności DORA dla banku ma odpowiedzieć na trudniejsze pytanie: czy organizacja potrafi wykazać, że zarządza ryzykiem ICT, wykrywa incydenty, testuje odporność i kontroluje dostawców w sposób powtarzalny, mierzalny oraz udokumentowany.

Dla zarządu wynik audytu powinien wskazywać ekspozycję na zakłócenie usług krytycznych, koszty zaniedbań i kolejność decyzji. Dla CISO, CIO oraz właścicieli procesów musi przekładać się na konkretny backlog: właściciela luki, termin, zależności techniczne, akceptację ryzyka i dowód zamknięcia. Raport ograniczony do cytowania rozporządzenia nie daje ani jednego, ani drugiego.

Czym powinien być audyt zgodności DORA dla banku

Dobrze przeprowadzony audyt nie jest ankietą zgodności ani jednorazową oceną dokumentacji. To weryfikacja, czy wymagania DORA działają w środowisku banku - od modelu odpowiedzialności zarządczej, przez konfigurację systemów i procesy SOC, po umowy z dostawcami ICT oraz scenariusze odtworzenia usługi.

Punktem wyjścia jest ustalenie zakresu opartego na usługach biznesowych. W praktyce warto zacząć od procesów, których niedostępność, utrata integralności danych lub wyciek informacji powodują wymierną szkodę dla klientów, płynności operacyjnej albo obowiązków regulacyjnych. Dopiero potem należy prześledzić wspierające je aplikacje, infrastrukturę, przepływy danych, konta uprzywilejowane, komponenty chmurowe i podmioty trzecie.

To podejście pozwala uniknąć częstego błędu: szczegółowej analizy kontroli technicznych bez ustalenia, jaką usługę dana kontrola faktycznie chroni. Bank może mieć poprawnie skonfigurowane narzędzie bezpieczeństwa, a mimo to nie znać zależności między systemem kredytowym, usługą tożsamości, operatorem chmury i kanałem komunikacji z klientem. W sytuacji incydentu taka luka architektoniczna wydłuża decyzje i odzyskanie działania.

Pięć obszarów, które wymagają dowodów

DORA tworzy spójne ramy cyfrowej odporności operacyjnej. W audycie należy zbadać nie tylko istnienie procesów, lecz także ich skuteczność oraz jakość dowodów.

Zarządzanie i odpowiedzialność

Rozporządzenie przypisuje organowi zarządzającemu odpowiedzialność za zarządzanie ryzykiem ICT. Audyt powinien więc potwierdzić, że zarząd otrzymuje informacje pozwalające podejmować decyzje: aktualny profil ryzyka, status krytycznych podatności, wyniki testów, istotne incydenty, ryzyka dostawców i zaległości w remediacji.

Istotna jest praktyka, a nie sam schemat organizacyjny. Czy właściciele ryzyka mają formalne kompetencje? Czy wyjątki od standardów są zatwierdzane, ograniczone czasowo i okresowo przeglądane? Czy komitet bezpieczeństwa podejmuje decyzje zapisane w protokołach, a ich wykonanie jest monitorowane? Odpowiedzi na te pytania stanowią dowody procesu, których nie zastąpi ogólna polityka bezpieczeństwa.

Zarządzanie ryzykiem ICT

Bank powinien posiadać aktualny i możliwy do obrony obraz aktywów, systemów, danych oraz ich zależności. Audyt weryfikuje między innymi kompletność inwentaryzacji, klasyfikację krytyczności, zarządzanie zmianą, skanowanie podatności, kontrolę dostępu, kopie zapasowe, szyfrowanie i segmentację sieci.

Szczególną uwagę należy poświęcić różnicy między wykrytą podatnością a ryzykiem zaakceptowanym lub zredukowanym. Lista kilku tysięcy wyników skanowania nie jest materiałem zarządczym. Potrzebny jest triage według SLA, ekspozycji, dostępności exploitu, znaczenia usługi i skuteczności kontroli kompensacyjnych. Audyt powinien wykazać, czy krytyczne luki są zamykane w terminie oraz czy opóźnienia mają zatwierdzone uzasadnienie.

Obsługa i raportowanie incydentów

W tym obszarze ocena procedury to za mało. Należy prześledzić rzeczywisty przebieg obsługi incydentu: od alertu w SOC, przez kwalifikację i eskalację, po ocenę wpływu, decyzję o komunikacji oraz działania poincydentowe. Warto pobrać próbę spraw i sprawdzić znaczniki czasu, kompletność dowodów, decyzje analityków, korespondencję z właścicielami usług i realizację rekomendacji.

DORA stawia wysokie wymagania wobec klasyfikacji oraz zgłaszania poważnych incydentów związanych z ICT. Bank musi umieć szybko połączyć sygnał techniczny z wpływem na klientów, transakcje i usługi krytyczne. Jeżeli CMDB, monitoring, rejestr usług i proces zarządzania incydentami działają w izolacji, ocena wpływu będzie oparta na domysłach. Audyt powinien wskazać te przerwy w przepływie informacji przed realnym kryzysem.

Testowanie cyfrowej odporności operacyjnej

Testy muszą odpowiadać profilowi ryzyka banku. W zależności od skali i krytyczności środowiska mogą obejmować testy odtworzeniowe, ćwiczenia zarządcze, testy penetracyjne aplikacji i infrastruktury, analizę konfiguracji chmury, scenariusze ransomware oraz testy komunikacji kryzysowej. Nie każdy bank będzie podlegać testom TLPT, ale każdy potrzebuje programu testów proporcjonalnego do ryzyka.

Największą wartość dają ćwiczenia oparte na konkretnym scenariuszu. Przykładowo: niedostępność usługi uwierzytelniania w chmurze w dniu zwiększonego wolumenu transakcji. Audyt sprawdza wtedy nie tylko RTO zapisane w planie ciągłości działania, lecz także faktyczny czas odtworzenia, kompletność danych, skuteczność obejść operacyjnych, role decyzyjne i jakość komunikacji. Wynik testu powinien kończyć się kontrolowaną remediacją, a nie prezentacją z wnioskami bez właścicieli i terminów.

Ryzyko dostawców ICT

Relacje z dostawcami wymagają spojrzenia wykraczającego poza dział zakupów. Rejestr informacji o umowach powinien być kompletny, aktualny i połączony z usługami krytycznymi, lokalizacją przetwarzania danych, podwykonawcami oraz warunkami wyjścia z usługi. Audyt weryfikuje, czy bank potrafi określić koncentrację ryzyka - na przykład zależność kilku procesów krytycznych od jednego dostawcy chmurowego lub operatora telekomunikacyjnego.

W umowach liczą się egzekwowalne zapisy dotyczące bezpieczeństwa, zgłaszania incydentów, współpracy podczas testów, dostępu audytowego, ciągłości działania i zakończenia współpracy. Trzeba jednak uczciwie ocenić ograniczenia negocjacyjne. Globalny dostawca może nie zaakceptować pełnej zmiany wzorca umowy. Wówczas bank powinien udokumentować analizę ryzyka, zastosować kontrole kompensacyjne i ustalić realistyczny plan ograniczania zależności, zamiast formalnie odhaczać wymóg.

Metodyka, która daje wynik możliwy do wdrożenia

Skuteczny audyt zaczyna się od warsztatu scopingowego z bezpieczeństwem, IT, ryzykiem, compliance, ciągłością działania, zakupami i właścicielami usług. Jego rezultatem jest mapa zakresu, lista systemów oraz uzgodnione kryteria próbkowania. Następnie audytor łączy analizę regulacyjną z testami dowodowymi: przegląda dokumenty, rejestry, konfiguracje, bilety zmianowe, wyniki skanów, logi, raporty SOC, umowy i materiały z ćwiczeń.

Każde ustalenie powinno mieć opis wymogu, stan faktyczny, dowód, ocenę ryzyka, konsekwencję biznesową oraz rekomendację. Zalecenie typu „poprawić monitoring” jest nieużyteczne. Warto wskazać, które źródła logów nie są objęte korelacją, jakie przypadki użycia brakuje w SIEM, kto ma je wdrożyć, jak sprawdzić skuteczność i w jakim SLA zamknąć działanie.

W SprintTech audyt można połączyć z weryfikacją techniczną, w tym testami penetracyjnymi, oceną bezpieczeństwa chmury i analizą zdolności SOC. Taka korelacja rozdziela ryzyka teoretyczne od luk, które są faktycznie osiągalne i mogą przerwać usługę. Jednocześnie pozwala zbudować jeden plan działań dla zespołów technicznych oraz czytelny obraz ryzyka dla zarządu.

Jak przygotować bank przed rozpoczęciem audytu DORA

Najlepszym pierwszym krokiem nie jest zbieranie wszystkich polityk do wspólnego folderu. Należy wyznaczyć sponsora po stronie zarządczej, właściciela programu oraz osoby odpowiedzialne za dowody w poszczególnych domenach. Równolegle warto ustalić, które usługi są krytyczne, gdzie znajduje się ich aktualna dokumentacja i jakie incydenty lub testy z ostatnich 12 miesięcy można wykorzystać jako próbę operacyjną.

Jeżeli brakuje kompletnego rejestru dostawców lub mapy zależności, nie należy ukrywać tego problemu pod warstwą deklaracji. To zwykle obszar o najwyższym priorytecie, ponieważ wpływa jednocześnie na ciągłość działania, zarządzanie incydentem i ryzyko koncentracji. Audyt ma stworzyć bazę do naprawy, nie dekorację na potrzeby kontroli.

Dojrzałość DORA nie będzie oceniana po liczbie dokumentów. Będzie widoczna wtedy, gdy bank potrafi w krótkim czasie pokazać, która usługa jest zagrożona, kto podejmuje decyzję, jakie dane potwierdzają stan faktyczny i kiedy ryzyko zostanie zredukowane. Od tego warto zacząć planowanie audytu.