DORA obowiązuje już na tyle długo, że dla wielu organizacji finansowych podstawowym problemem przestało być samo przygotowanie dokumentacji. Znacznie ważniejsze staje się pytanie, czy wdrożone rok wcześniej procedury rzeczywiście działają.

Rozporządzenie DORA jest stosowane od 17 stycznia 2025 r. Wiele banków, firm inwestycyjnych, ubezpieczycieli, instytucji płatniczych i innych podmiotów finansowych przed tą datą przeprowadziło rozbudowane projekty dostosowawcze. Powstawały polityki zarządzania ryzykiem ICT, procedury incydentowe, strategie ciągłości działania, rejestry dostawców i nowe klauzule umowne.

Po kilkunastu miesiącach funkcjonowania systemu pojawia się jednak zupełnie inny rodzaj ryzyka. Dokumenty istnieją, lecz pracownicy nie zawsze je stosują. Rejestr ICT nie odpowiada rzeczywistym umowom. Niektóre procedury przygotowane przed wejściem DORA w życie nigdy nie zostały przetestowane. Część dostawców nadal działa na starych kontraktach, a w organizacji brakuje dowodu regularnego przeglądu ram zarządzania ryzykiem.

Właśnie dlatego w 2026 r. istotnego znaczenia nabiera audyt powdrożeniowy DORA.

Czym jest audyt powdrożeniowy DORA?

Określenie „audyt powdrożeniowy DORA” nie jest nazwą jednego szczególnego audytu zdefiniowanego w rozporządzeniu.

Jest to praktyczne badanie przeprowadzane po zakończeniu projektu wdrożenia, którego celem jest sprawdzenie, czy założone rozwiązania zostały faktycznie zaimplementowane oraz czy organizacja działa zgodnie z wymaganiami DORA.

Nie należy utożsamiać takiego przeglądu wyłącznie z audytem IT.

DORA dotyczy zarządzania, procesów, dokumentacji, dostawców, testów, incydentów, ciągłości działania i odpowiedzialności kierownictwa. Ocena powinna więc obejmować obszary prawne, organizacyjne i techniczne.

DORA sama przewiduje, że ramy zarządzania ryzykiem ICT powinny być dokumentowane i przeglądane co najmniej raz w roku, poza szczególnymi zasadami dotyczącymi mikroprzedsiębiorstw. W przypadku podmiotów innych niż mikroprzedsiębiorstwa ramy podlegają również regularnemu audytowi wewnętrznemu przeprowadzanemu przez odpowiednio niezależnych audytorów. Rozporządzenie wymaga także formalnego procesu weryfikacji i usuwania krytycznych ustaleń audytowych.

Oznacza to, że sam pomysł okresowej weryfikacji wdrożenia odpowiada konstrukcji DORA.

Dokumentacja nie oznacza zgodności

Pierwszym obszarem audytu jest sprawdzenie, czy dokumentacja odpowiada praktyce.

Organizacja może posiadać bardzo dobrą politykę zarządzania ryzykiem ICT. Jeżeli jednak wskazane w niej kwartalne przeglądy nie są wykonywane, dokument nie odzwierciedla rzeczywistego systemu.

Podobny problem występuje przy planach ciągłości działania. Dokument może szczegółowo opisywać sposób odtworzenia infrastruktury, ale nikt nie sprawdził, czy backup rzeczywiście można odtworzyć w założonym czasie.

Audyt powinien więc badać nie tylko istnienie dokumentu, ale także dowody jego wykonania. Należy sprawdzić protokoły testów, raporty, logi, zgłoszenia, szkolenia, zatwierdzenia przez zarząd i dokumentację decyzji.

Czy zakres DORA został prawidłowo określony?

Pierwszym pytaniem powinno być ustalenie, czy podczas pierwotnego wdrożenia właściwie zidentyfikowano wszystkie funkcje wspierane przez ICT.

DORA wymaga identyfikowania, klasyfikowania i odpowiedniego dokumentowania funkcji biznesowych wspieranych przez ICT, aktywów informacyjnych i aktywów ICT oraz zależności między nimi. Klasyfikacja powinna być okresowo weryfikowana, co najmniej raz w roku.

W praktyce organizacja zmienia się bardzo szybko. W ciągu roku może wdrożyć nowy CRM, narzędzie AI, dodatkowego dostawcę chmurowego albo aplikację SaaS używaną przez jeden dział bez formalnego procesu zakupowego.

Audyt powinien wychwycić takie przypadki. Szczególnym problemem jest shadow IT. Dział biznesowy kupuje usługę bez zaangażowania funkcji odpowiedzialnej za ICT, dlatego dostawca nie trafia do rejestru ani analizy ryzyka.

Audyt rejestru informacji ICT

Rejestr informacji dotyczących umów z zewnętrznymi dostawcami ICT jest jednym z najważniejszych elementów systemu DORA.

Po wdrożeniu należy sprawdzić przede wszystkim kompletność danych. Rejestr powinien odpowiadać rzeczywiście obowiązującym umowom, aneksom, podwykonawcom i usługom.

Częstym problemem jest sytuacja, w której rejestr przygotowano jednorazowo przed 17 stycznia 2025 r., a kolejne umowy nie były wprowadzane w ramach spójnego procesu.

Audyt powinien porównać dane z rejestru z systemem księgowym, procurementem, listą dostawców i rzeczywistymi usługami używanymi przez działy. Warto również sprawdzić, czy organizacja prawidłowo identyfikuje usługi wspierające funkcje krytyczne lub istotne.

Umowy z dostawcami ICT po wdrożeniu DORA

Jednym z najbardziej pracochłonnych elementów projektu DORA była renegocjacja kontraktów z dostawcami. Audyt powdrożeniowy powinien ustalić, ile umów rzeczywiście zostało dostosowanych i czy zawarte klauzule odpowiadają wymaganiom.

Szczególnej uwagi wymagają prawo dostępu, audytu i inspekcji, obowiązki współpracy, lokalizacja danych, bezpieczeństwo, zgłaszanie incydentów, podwykonawstwo, zakończenie umowy i plan wyjścia.

Częstym problemem jest przyjęcie przez organizację standardowych warunków dużego dostawcy bez analizy, czy spełniają wymagania właściwe dla konkretnej usługi.

Warto również zweryfikować umowy zawarte już po 17 stycznia 2025 r. Zdarza się, że projekt DORA objął wyłącznie stare kontrakty, natomiast dział zakupów po kilku miesiącach powrócił do poprzedniego wzoru.

Organ zarządzający musi faktycznie uczestniczyć w systemie

DORA wyraźnie przypisuje organowi zarządzającemu odpowiedzialność za ramy zarządzania ryzykiem ICT.

Organ zarządzający określa, zatwierdza i nadzoruje ich wdrażanie oraz ponosi ostateczną odpowiedzialność za zarządzanie ryzykiem ICT. Powinien także zatwierdzać strategię odporności cyfrowej, plany ciągłości działania i plan audytów ICT oraz zapewnić odpowiednie zasoby.

Audyt powinien więc sprawdzić, czy zarząd rzeczywiście otrzymuje informacje potrzebne do realizacji tych obowiązków. Nie wystarczy zapis w polityce, że „Zarząd nadzoruje ICT”. Należy sprawdzić protokoły posiedzeń, cykliczne raporty, zatwierdzenia polityk i decyzje dotyczące poziomu ryzyka.

Jeżeli kwestie cyberbezpieczeństwa są omawiane wyłącznie w dziale IT i nigdy nie trafiają do organu zarządzającego, może to świadczyć o niedojrzałości wdrożenia.

Szkolenia zarządu

DORA wymaga, aby członkowie organu zarządzającego regularnie aktualizowali wiedzę pozwalającą rozumieć i oceniać ryzyko związane z ICT, w tym przez uczestnictwo w odpowiednich szkoleniach.

Audyt powinien sprawdzić, czy obowiązek ten został wykonany. Jedno szkolenie przeprowadzone przed wejściem rozporządzenia w życie nie powinno być traktowane jako rozwiązanie permanentne.

Znaczenie ma zarówno częstotliwość, jak i zakres. Szkolenie powinno odnosić się do realnych zagrożeń organizacji, incydentów, zależności od dostawców i wyników testów.

Zarządzanie ryzykiem ICT

Ramy zarządzania ryzykiem są centralnym elementem DORA. Audyt powinien ustalić, czy metodyka ryzyka rzeczywiście działa. Należy przeanalizować rejestr ryzyka, jego aktualność, sposób określania właścicieli oraz proces akceptacji ryzyka rezydualnego.

Szczególnie ważne jest to, czy analiza jest powtarzana po dużych zmianach infrastruktury i procesów.

Rozporządzenie wymaga od podmiotów innych niż mikroprzedsiębiorstwa dokonywania oceny ryzyka przy każdej istotnej zmianie infrastruktury sieciowej i informacyjnej oraz procesów dotyczących funkcji wspieranych przez ICT. (Eur-Lex)

Jeżeli organizacja wdrożyła w ostatnim roku migrację chmurową, nową aplikację bankową albo system oparty na AI, audyt powinien sprawdzić, czy zmiana została objęta formalną oceną.

Incydenty ICT

Kolejnym obszarem jest proces identyfikowania i klasyfikacji incydentów.

Należy sprawdzić wszystkie zdarzenia z okresu po wdrożeniu. Audyt powinien odpowiedzieć na pytanie, czy organizacja prawidłowo klasyfikowała zdarzenia, czy działał proces eskalacji oraz czy informacje trafiały do właściwych osób.

Szczególnym testem dojrzałości jest analiza realnego incydentu. Jeżeli w ciągu roku organizacja miała poważną awarię, należy porównać rzeczywisty sposób działania z procedurą.

Bardzo często okazuje się, że numery kontaktowe są nieaktualne, osoby nie znają swoich ról, decyzje są podejmowane na komunikatorze bez dokumentacji, a prawnik dowiaduje się o zdarzeniu zbyt późno.

Business continuity i disaster recovery

Papierowy plan nie zapewnia odporności. Audyt powinien zbadać wyniki testów ciągłości i odtworzenia. Należy sprawdzić, czy ustalone RTO i RPO są osiągalne, czy kopie są kompletne i czy osoby odpowiedzialne znają procedury.

Istotne jest również uwzględnienie zależności od dostawców. Organizacja może posiadać bardzo dobry plan własnego centrum danych, ale jednocześnie pozostawać całkowicie uzależniona od jednego dostawcy SaaS bez realnej strategii wyjścia.

Testowanie odporności cyfrowej

DORA wymaga programu testowania odporności operacyjnej. Audyt powdrożeniowy powinien sprawdzić, czy testy są dobierane w oparciu o ryzyko oraz czy wyniki prowadzą do realnych zmian.

Samo przeprowadzenie testu penetracyjnego i zapisanie raportu na dysku nie jest końcem procesu.

Należy ustalić właściciela każdego istotnego ustalenia, termin usunięcia i sposób weryfikacji. Ten sam mechanizm powinien działać w odniesieniu do audytów wewnętrznych. Rozporządzenie wymaga formalnego procesu monitorowania ustaleń i terminowego usuwania krytycznych problemów. (Eur-Lex)

Dojrzałość organizacyjna a zgodność formalna

Audyt warto zakończyć nie tylko listą naruszeń, ale także oceną dojrzałości.

Dwie organizacje mogą posiadać identyczny zestaw dokumentów i znajdować się na zupełnie innym poziomie.

W jednej polityka stanowi jedynie wymagany dokument. W drugiej system jest częścią zarządzania przedsiębiorstwem. Zarząd otrzymuje raporty, proces zakupowy automatycznie uruchamia ocenę dostawcy, incydenty są analizowane, a wnioski wpływają na rozwój infrastruktury.

Ocena dojrzałości pozwala określić, które elementy działają ad hoc, które są powtarzalne, które są formalnie zarządzane, a które zostały już zoptymalizowane.

Audyt dokumentacji

Należy zweryfikować aktualność polityk oraz zgodność pomiędzy nimi. Częstym problemem jest przygotowanie dokumentów przez kilka niezależnych zespołów.

Polityka bezpieczeństwa wskazuje jeden termin raportowania, procedura incydentowa drugi, a umowa z dostawcą trzeci. Podobnie mogą występować rozbieżności pomiędzy rejestrem dostawców a polityką outsourcingową.

Audyt powinien wychwycić sprzeczności i zaproponować jedno spójne rozwiązanie.

Audyt dowodów

DORA w praktyce wymaga nie tylko działania, ale również możliwości wykazania działania. Dlatego audyt powinien badać dokumentację operacyjną. Czy istnieją protokoły testów? Czy szkolenia zostały potwierdzone? Czy zarząd zatwierdził odpowiednie dokumenty? Czy ryzyka zostały zaakceptowane przez właściwe osoby?

Brak dowodu może podczas kontroli prowadzić do sytuacji, w której organizacja twierdzi, że wykonywała obowiązek, ale nie jest w stanie tego potwierdzić.

Plan naprawczy po audycie

Najważniejszym wynikiem audytu nie powinien być raport wskazujący kilkaset niezgodności. Organizacja potrzebuje planu działań. Każde ustalenie powinno otrzymać priorytet, właściciela, termin i sposób weryfikacji wykonania.

Należy rozdzielić problemy krytyczne wymagające natychmiastowej reakcji od usprawnień zwiększających dojrzałość. Dobrym rozwiązaniem jest późniejsza kontrola follow-up sprawdzająca, czy rekomendacje rzeczywiście wdrożono.

Kiedy warto przeprowadzić audyt powdrożeniowy?

2026 r. jest dobrym momentem. DORA funkcjonuje już wystarczająco długo, aby istniały realne dane pozwalające ocenić skuteczność procedur. Organizacja ma za sobą co najmniej jeden pełny cykl planowania, przeglądu dostawców, incydentów i testowania.

Możliwe jest więc odejście od analizy hipotetycznej i sprawdzenie rzeczywistych zachowań.

Audyt jest szczególnie uzasadniony po dużym incydencie, zmianie dostawcy chmurowego, reorganizacji, przejęciu innego podmiotu albo znaczącej zmianie infrastruktury.

Podsumowanie

Pierwszy etap DORA polegał na wdrożeniu. Drugi powinien polegać na sprawdzeniu, czy wdrożenie rzeczywiście działa.

Po ponad roku stosowania rozporządzenia organizacje posiadają już wystarczające doświadczenie, aby ocenić jakość swoich procedur na podstawie rzeczywistych danych.

Audyt powdrożeniowy powinien obejmować nie tylko dokumentację, lecz również zarządzanie ryzykiem, incydenty, dostawców, testy, ciągłość działania, rejestry i rolę zarządu. Najważniejszym pytaniem nie jest bowiem, czy organizacja posiada dokument nazwany „Polityka DORA”. Znacznie ważniejsze jest to, czy w razie poważnego incydentu, awarii dostawcy albo kontroli jest w stanie wykazać, że system został wdrożony, przetestowany i rzeczywiście funkcjonuje.

Część kontraktową kontroli uzupełnia poradnik o umowie outsourcingu IT zgodnej z DORA. Odrębny tekst dotyczy NIS2 i dokumentów dla firm IT.

Co powinno być rezultatem audytu?

Nie tylko raport.
Organizacja powinna otrzymać ocenę niezgodności, poziomu ryzyka i dojrzałości oraz konkretny plan naprawczy z priorytetami i terminami.

Czy audyt powinien obejmować dostawców?

Tak.
Zarządzanie ryzykiem zewnętrznych dostawców ICT jest jednym z podstawowych obszarów DORA. Należy zweryfikować umowy, rejestr informacji, klasyfikację usług i nadzór nad dostawcami.

Co jest najczęstszym problemem po wdrożeniu?

Rozbieżność pomiędzy dokumentacją i praktyką.
Organizacja posiada formalne procedury, ale nie wykonuje przewidzianych przeglądów, testów albo aktualizacji rejestrów.

Czy audyt wystarczy przeprowadzić raz?

Nie.
System DORA ma działać w sposób ciągły. Ryzyko ICT, infrastruktura i dostawcy zmieniają się, dlatego przeglądy i audyty mają charakter okresowy.

Czy DORA wymaga audytów?

Tak. Podmioty finansowe inne niż mikroprzedsiębiorstwa powinny zapewnić regularny audyt wewnętrzny ram zarządzania ryzykiem ICT zgodnie z planem audytu i poziomem ryzyka.
DORA wymaga również okresowego przeglądu samych ram zarządzania ryzykiem ICT.