DORA w praktyce: odporność operacyjna wykraczająca poza checklistę

DORA nie jest projektem tworzenia polityk. Jest wymaganiem, by podmiot finansowy potrafił wykazać, jak chroni krytyczne lub ważne funkcje, jak reaguje na incydent i jak odzyska usługę mimo awarii własnych systemów albo dostawcy ICT. Najbardziej wiarygodnym dowodem nie jest zatwierdzony dokument, lecz przeprowadzony test, zamknięte działanie naprawcze i spójny zapis decyzji.

Rozporządzenie (UE) 2022/2554 stosuje się od 17 stycznia 2025 roku. Łączy zarządzanie ryzykiem ICT, incydenty, testowanie odporności i ryzyko stron trzecich w jeden model. W praktyce oznacza to, że zespoły ryzyka, bezpieczeństwa, ciągłości działania, zakupów i inżynierii nie mogą utrzymywać osobnych obrazów tej samej usługi.

Zacznij od funkcji, nie od systemu

Mapa odporności powinna wychodzić od funkcji krytycznej lub ważnej i procesu klienta. Dopiero potem wskazuje dane, aplikacje, infrastrukturę, ludzi, lokalizacje, dostawców i podwykonawców. System może być technicznie dostępny, a funkcja nadal niedostępna z powodu braku danych referencyjnych, autoryzacji, zespołu operacyjnego albo połączenia z dostawcą.

Dla każdej funkcji trzeba nazwać właściciela biznesowego i technicznego, tolerancję przerwy, cel odtworzenia, zależności oraz scenariusze utraty. RTO i RPO nie mogą być jedynie liczbami odziedziczonymi z arkusza BIA. Muszą odpowiadać rzeczywistej architekturze, kolejności startu komponentów i możliwości odtworzenia danych. Rozbieżność między deklarowanym celem a wynikiem testu jest ustaleniem do zarządzania, nie powodem do korekty raportu.

Przełóż ramy ryzyka ICT na pracę operacyjną

Kontrole powinny mieć właściciela, częstotliwość, źródło dowodu oraz regułę eskalacji. Przykładowo kontrola kopii zapasowej nie kończy się na udanym zadaniu backupu; obejmuje integralność, separację, test odtworzenia, czas wykonania i zgodność z docelowym punktem odtworzenia. Kontrola podatności łączy krytyczność zasobu, ekspozycję, dostępność poprawki i termin remediacji.

Dowód powinien być możliwy do odtworzenia przez osobę spoza zespołu wykonującego kontrolę. Zapisuje się zakres, środowisko, czas, użyte narzędzie, wynik, odstępstwa i akceptację. Jeśli kontrola jest automatyczna, trzeba monitorować również jej własną sprawność: brak nowych wyników może oznaczać brak problemów albo awarię integracji. Mechanizm eskalacji powinien rozróżniać oba stany.

Organ zarządzający potrzebuje syntetycznego obrazu ryzyka, ale nie powinien otrzymywać wyłącznie kolorowych statusów. Materiał decyzyjny powinien wskazywać funkcję, scenariusz szkody, kontrolę, aktualny dowód, pozostałe ryzyko, właściciela oraz decyzję wymaganą od zarządu. Wyjątki mają termin ważności i warunek ponownego przeglądu.

Połącz obsługę incydentu z raportowaniem

Klasyfikacja regulacyjna nie może odbywać się w osobnym obiegu kilka dni po analizie technicznej. Rekord incydentu powinien zawierać informacje potrzebne do oceny kryteriów: dotkniętych klientów i kontrahentów, czasu trwania, zasięgu geograficznego, utraty danych, krytyczności usługi i skutków ekonomicznych. Każda wartość musi mieć źródło i status potwierdzenia.

Rozporządzenie delegowane (UE) 2025/301 określa dla poważnych incydentów ICT raport wstępny do czterech godzin od klasyfikacji i nie później niż 24 godziny od wykrycia, raport pośredni do 72 godzin od raportu wstępnego oraz raport końcowy w ciągu miesiąca. Automatyzacja może przygotować dane i pilnować zegara, lecz kwalifikacja, zatwierdzenie treści i komunikacja wymagają ustalonej odpowiedzialności.

Testuj zdolność, a nie scenariusz prezentacyjny

Program testów powinien obejmować podatności, konfigurację, scenariusze, kompatybilność, wydajność, testy end-to-end i odtworzenie. Podmioty inne niż mikroprzedsiębiorstwa mają co najmniej raz w roku zapewnić odpowiednie testy wszystkich systemów i aplikacji wspierających funkcje krytyczne lub ważne. Zakres powinien wynikać z ryzyka i zmian, a nie tylko z kalendarza.

Wybrane podmioty realizują TLPT co najmniej raz na trzy lata, przy czym właściwy organ może zmienić częstotliwość. Test obejmuje niektóre lub wszystkie funkcje krytyczne lub ważne oraz ich produkcyjne systemy, także zależności zewnętrzne w ustalonym zakresie. Wyniki muszą prowadzić do planu remediacji, ponownej walidacji i dowodu zamknięcia. Sam raport red-team nie podnosi odporności.

Zarządzaj pełnym łańcuchem usług ICT

Rejestr informacji o umowach powinien łączyć dostawcę z funkcją, usługą, lokalizacją danych, podwykonawcami, terminami oraz możliwością zastąpienia. Due diligence wymaga oceny nie tylko zabezpieczeń dostawcy, ale również koncentracji i zależności od wspólnej infrastruktury. Dwóch różnych kontrahentów może korzystać z tej samej chmury, regionu lub operatora tożsamości.

Rozporządzenie delegowane (UE) 2025/532 doprecyzowuje ocenę podwykonawców wspierających funkcje krytyczne lub ważne. Organizacja powinna wiedzieć, jaka część usługi jest dalej zlecana, gdzie jest realizowana, jak dostawca monitoruje podwykonawcę oraz kiedy materialna zmiana uruchamia sprzeciw, modyfikację kontroli lub zakończenie umowy.

Uczyń plan wyjścia wykonalnym

Klauzula wypowiedzenia nie jest planem wyjścia. Potrzebne są formaty eksportu, mapa interfejsów, kolejność migracji, dostęp do dokumentacji i logów, procedura odebrania kont, zasady usunięcia danych oraz minimalny tryb działania podczas zmiany. Właściciel funkcji powinien znać czas i zasoby potrzebne do przejścia na alternatywę.

Test wyjścia może mieć różną skalę: od eksportu i walidacji danych, przez przełączenie części ruchu, po pełne ćwiczenie zastąpienia. Ważne, aby ujawniał założenia niewidoczne w umowie. Jeżeli zamiennik nie obsługuje krytycznej funkcji albo migracja wymaga niedostępnych kompetencji, ryzyko musi trafić do decyzji, zanim wystąpi przymusowe zakończenie współpracy.

Plan powinien uwzględniać pogarszającą się kondycję dostawcy, a nie tylko uporządkowane wypowiedzenie. Dostęp do zespołu, dokumentacji, kluczy lub eksportu może osłabnąć jeszcze przed formalnym zakończeniem umowy. Wczesne sygnały uruchamiają zabezpieczenie wiedzy, test danych i ograniczenie nowych zależności. Właściciel biznesowy decyduje, kiedy koszt przygotowania alternatywy jest uzasadniony ryzykiem dalszego oczekiwania.

Raportuj dowody i pozostałe ryzyko

Przydatny zestaw miar obejmuje: odsetek funkcji z aktualną mapą zależności, zgodność wyników testów z RTO/RPO, wiek otwartych działań naprawczych, czas klasyfikacji incydentu, kompletność danych raportowych, udział krytycznych dostawców z aktualnym dowodem odporności oraz czas wykonania scenariusza wyjścia. Każda miara powinna mieć próg i odbiorcę decyzji.

Nie należy agregować wszystkiego do jednego wskaźnika „zgodności DORA”. Wysoki wynik może maskować pojedynczą, istotną zależność bez odtworzenia. Zarząd powinien widzieć najważniejsze scenariusze, aktualny dowód, ograniczenia i koszt decyzji. Odporność rośnie wtedy, gdy ustalenia z incydentów i testów wracają do architektury, umów i priorytetów inwestycyjnych.

Źródła

• Regulation (EU) 2022/2554 on digital operational resilience for the financial sector
• Commission Delegated Regulation (EU) 2025/301 on major ICT-related incident reporting
• Commission Delegated Regulation (EU) 2025/532 on subcontracting ICT services
• European Supervisory Authorities: Guide to DORA oversight activities