DORA nie jest kolejnym dokumentem, który można „obsłużyć” polityką bezpieczeństwa i szkoleniem raz w roku. Od 17 stycznia 2025 roku podmioty finansowe muszą umieć wykazać, że potrafią utrzymać krytyczne usługi podczas awarii systemów, cyberataku, błędu dostawcy chmurowego albo utraty dostępu do danych. Liczy się nie sama ochrona przed incydentem, lecz zdolność do jego wykrycia, opanowania i przywrócenia działalności w kontrolowanym czasie.
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554, czyli Digital Operational Resilience Act, ujednoliciło wymagania dotyczące ryzyka technologicznego w sektorze finansowym. W Polsce jego stosowanie uzupełnia ustawa z 25 czerwca 2025 roku o zmianie niektórych ustaw w związku z zapewnieniem operacyjnej odporności cyfrowej sektora finansowego oraz emitowaniem europejskich zielonych obligacji.
Największa zmiana jest organizacyjna: ryzyko ICT przestało być wyłącznie problemem działu IT. Za ramy zarządzania tym ryzykiem, ich zatwierdzanie, nadzorowanie oraz finansowanie odpowiada organ zarządzający, czyli w praktyce zarząd instytucji. Nie wystarczy więc kupić system SIEM, zlecić test penetracyjny i uznać projekt za zamknięty. Trzeba jeszcze wiedzieć, jakie procesy biznesowe zależą od poszczególnych systemów, kto podejmuje decyzję podczas awarii i jak szybko można uruchomić rozwiązanie zastępcze.
Kogo obejmuje DORA i co realnie zmienia w instytucji finansowej
Zakres DORA jest szeroki. Regulacja obejmuje między innymi:
- banki i instytucje kredytowe,
- instytucje płatnicze oraz instytucje pieniądza elektronicznego,
- firmy inwestycyjne,
- zakłady ubezpieczeń i reasekuracji,
- pośredników ubezpieczeniowych spełniających warunki objęcia regulacją,
- zarządzających alternatywnymi funduszami inwestycyjnymi i spółki zarządzające,
- centralne depozyty papierów wartościowych i kontrahentów centralnych,
- dostawców usług w zakresie kryptoaktywów,
- administratorów kluczowych wskaźników referencyjnych,
- repozytoria transakcji,
- dostawców usług finansowania społecznościowego,
- dostawców usług raportowania danych.
DORA przewiduje wyłączenia oraz zasadę proporcjonalności. Niektóre mniejsze podmioty mogą stosować uproszczone ramy zarządzania ryzykiem ICT, ale uproszczenie nie oznacza zwolnienia z odpowiedzialności. Nadal trzeba zarządzać incydentami, testować odporność, kontrolować dostawców technologii i prowadzić wymagane rejestry. Część obowiązków nie dotyczy mikroprzedsiębiorstw albo jest wobec nich ograniczona, jednak status podmiotu trzeba potwierdzić na podstawie definicji zawartych w DORA, a nie potocznego rozumienia małej firmy.
W praktyce pierwszym problemem nie jest zakup technologii, lecz ustalenie zakresu. Instytucje często mają dokładną ewidencję serwerów i aplikacji, ale nie potrafią szybko odpowiedzieć na trzy prostsze pytania:
- które usługi finansowe są funkcjami krytycznymi lub istotnymi,
- jakie systemy, dane i osoby umożliwiają ich świadczenie,
- którzy podwykonawcy mają wpływ na ich dostępność.
Bez takiego powiązania analiza ryzyka jest pozorna. Lista podatności technicznych nie pokaże, że awaria niewielkiej usługi autoryzacyjnej zablokuje logowanie wszystkich klientów albo że brak dostępu do jednego interfejsu API zatrzyma realizację płatności.
DORA wymaga wdrożenia udokumentowanych ram zarządzania ryzykiem ICT. Powinny one obejmować co najmniej:
- identyfikację aktywów, zależności i źródeł ryzyka,
- ochronę systemów oraz informacji,
- wykrywanie anomalii i incydentów,
- reagowanie oraz odtwarzanie działalności,
- tworzenie kopii zapasowych i procedur przywracania danych,
- komunikację podczas incydentu,
- analizę przyczyn i wyciąganie wniosków,
- regularne przeglądy skuteczności zabezpieczeń.
Organ zarządzający zatwierdza między innymi strategie, polityki, plany ciągłości działania i rozwiązania dotyczące dostawców ICT. Członkowie zarządu powinni również utrzymywać wiedzę wystarczającą do rozumienia ryzyka technologicznego. Nie muszą analizować logów ani konfigurować zapór sieciowych, ale powinni wiedzieć, jakie usługi mogą zostać zatrzymane, na jak długo i jakie skutki poniosą klienci.
To zmienia sposób zatwierdzania budżetów. Odmowa wymiany niewspieranego systemu nie jest już wyłącznie decyzją kosztową. Jeżeli system obsługuje funkcję krytyczną, zarząd powinien znać ryzyko, zaakceptować je w udokumentowany sposób albo zatwierdzić plan jego ograniczenia. Najbardziej ryzykowny błąd polega na pozostawieniu takich decyzji w protokołach technicznych, których organ zarządzający nigdy nie widzi.
Incydenty, testy i dokumentacja: obowiązki, których nie da się wykonać po fakcie
DORA obejmuje zarówno cyberataki, jak i zwykłe awarie operacyjne. Incydentem związanym z ICT może być ransomware, ale również niedostępność centrum danych, błąd aktualizacji, uszkodzenie bazy, przerwanie łączności albo wadliwe działanie systemu dostawcy.
Każde zdarzenie trzeba zarejestrować i sklasyfikować według ustalonych kryteriów. Przy ocenie bierze się pod uwagę między innymi:
- liczbę i znaczenie klientów lub kontrahentów dotkniętych zdarzeniem,
- czas trwania incydentu oraz przestoju usługi,
- zasięg geograficzny,
- utratę dostępności, autentyczności, integralności lub poufności danych,
- krytyczność dotkniętych usług,
- bezpośrednie oraz pośrednie skutki ekonomiczne.
Po uznaniu zdarzenia za poważny incydent związany z ICT rozpoczynają się krótkie terminy raportowe. Wstępne powiadomienie trzeba przekazać możliwie szybko, nie później niż:
- w ciągu 4 godzin od sklasyfikowania incydentu jako poważnego,
- jednocześnie nie później niż 24 godziny od jego wykrycia.
Jeżeli klasyfikacja nastąpiła później niż 24 godziny od wykrycia, opóźnienie należy wyjaśnić.
Raport pośredni przekazuje się zasadniczo w ciągu 72 godzin od złożenia powiadomienia wstępnego. Powinien zawierać bardziej szczegółowe informacje o przebiegu zdarzenia, jego skutkach i podjętych działaniach. Raport końcowy należy złożyć w ciągu miesiąca od raportu pośredniego albo od ostatniej jego aktualizacji.
To bardzo mało czasu. Firma, która dopiero podczas awarii ustala właściciela usługi, skalę dotkniętych klientów i wartość strat, prawdopodobnie nie zdąży zebrać wiarygodnych danych. Proces powinien wcześniej określać:
- kto może nadać incydentowi klasyfikację „poważny”,
- kto zatwierdza raport do organu nadzoru,
- skąd pobiera się dane o klientach, transakcjach i czasie niedostępności,
- kto dokumentuje decyzje podejmowane przez zespół kryzysowy,
- jak działa procedura poza godzinami pracy.
W polskich realiach raportowanie do KNF odbywa się kanałami wskazanymi przez UKNF. Nie należy czekać na pełną analizę przyczyn, jeżeli upływa termin zgłoszenia wstępnego. Pierwszy raport z założenia może zawierać dane niepełne, później aktualizowane.
Drugim filarem jest testowanie operacyjnej odporności cyfrowej. Program testów powinien obejmować systemy wspierające funkcje krytyczne i istotne oraz być dopasowany do skali ryzyka. Stosuje się między innymi:
- skanowanie podatności,
- analizę kodu źródłowego,
- przeglądy bezpieczeństwa,
- testy penetracyjne,
- testy zgodności,
- testy wydajnościowe,
- scenariusze awarii i odtwarzania,
- testy kopii zapasowych,
- ćwiczenia zespołów reagowania.
Odpowiednie systemy i aplikacje wspierające funkcje krytyczne lub istotne powinny być testowane co najmniej raz w roku. Sam raport od zewnętrznego pentestera nie wystarczy, jeżeli nie ma właściciela działań naprawczych, terminów usunięcia luk i weryfikacji po poprawkach.
Wybrane podmioty wskazane przez organ nadzoru muszą wykonywać zaawansowane testy TLPT, czyli testy penetracyjne oparte na analizie zagrożeń. Odbywają się one co najmniej raz na trzy lata, chyba że nadzorca ustali inną częstotliwość. TLPT nie jest typowym testem aplikacji internetowej. Obejmuje realistyczny scenariusz ataku na działające środowisko, ludzi, procesy i technologie wspierające funkcje krytyczne. Źle przygotowany test może spowodować zakłócenie usług, dlatego wymaga ścisłej kontroli zakresu, procedur awaryjnych i współpracy z dostawcami.
Najczęstsza niedogodność we wdrożeniach DORA pojawia się przy dokumentacji. Łatwo wyprodukować kilkadziesiąt polityk, których nikt nie stosuje. Trudniej stworzyć kilka spójnych procedur, które odpowiadają rzeczywistemu podziałowi odpowiedzialności. Dokument mówiący, że „incydenty są niezwłocznie eskalowane”, jest bezużyteczny, dopóki nie określa progu eskalacji, kanału kontaktu, zastępstw i czasu na podjęcie decyzji.
Dostawcy ICT pod kontrolą: umowa nie przenosi odpowiedzialności
Instytucja finansowa może korzystać z chmury Microsoft Azure, Amazon Web Services, Google Cloud, zewnętrznego centrum danych, systemu core banking, platformy transakcyjnej albo usługi SOC. Nie może jednak przenieść na dostawcę własnej odpowiedzialności regulacyjnej.
DORA wymaga prowadzenia rejestru informacji o ustaleniach umownych dotyczących usług ICT. Rejestr powinien obejmować zarówno umowy bezpośrednie, jak i dane o podwykonawcach istotnych dla realizacji usług. Dokumentacja musi pozwalać ustalić między innymi:
- kto świadczy usługę,
- jaki podmiot finansowy z niej korzysta,
- jakie funkcje biznesowe są wspierane,
- czy funkcja jest krytyczna lub istotna,
- gdzie świadczona jest usługa i gdzie przetwarzane są dane,
- jakie są okresy obowiązywania i wypowiedzenia umowy,
- czy dostawca korzysta z podwykonawców,
- jakie rozwiązania przewidziano na wypadek zakończenia współpracy.
W praktyce najwięcej problemów powoduje jakość danych. Nazwa dostawcy wpisana raz jako pełna firma, raz jako marka handlowa, a raz jako skrót może spowodować błąd walidacji lub utrudnić analizę koncentracji. Podobnie działa brak identyfikatora LEI, niezgodny format dat albo pominięcie podwykonawcy. Pierwsze przekazywanie rejestrów do KNF pokazało, że techniczna walidacja pliku potrafi być równie wymagająca jak samo zebranie informacji.
Dla usług wspierających funkcje krytyczne lub istotne umowy powinny precyzyjnie regulować między innymi:
- opis usług i ich zakres,
- lokalizacje świadczenia usług oraz przetwarzania danych,
- wymagania dotyczące dostępności, integralności i bezpieczeństwa,
- obowiązki informacyjne dostawcy,
- wsparcie podczas incydentów ICT,
- obowiązek współpracy z organami nadzoru,
- prawa dostępu, kontroli i audytu,
- zasady korzystania z podwykonawców,
- odzyskiwanie i zwrot danych,
- okresy przejściowe,
- możliwość rozwiązania umowy,
- plany wyjścia z usługi.
Samo dopisanie do umowy zdania, że dostawca „spełnia DORA”, nie rozwiązuje problemu. Klauzule muszą być wykonalne. Prawo audytu, którego nie można użyć częściej niż raz na trzy lata, może okazać się nieadekwatne przy usłudze krytycznej. Deklaracja zwrotu danych niewiele znaczy, jeżeli nie określa formatu, czasu przekazania i zasad usunięcia kopii.
Przed zawarciem umowy instytucja powinna przeprowadzić ocenę ryzyka, w tym sprawdzić:
- zależność od jednego dostawcy,
- możliwość przeniesienia usługi do innego operatora,
- ryzyko podwykonawstwa,
- jurysdykcję i miejsce przechowywania danych,
- zdolność dostawcy do obsługi incydentów,
- skutki niewypłacalności lub nagłego zakończenia świadczenia usługi.
Szczególnie niebezpieczna jest koncentracja technologiczna. Kilka aplikacji może wyglądać jak niezależne usługi, ale wszystkie mogą działać w tym samym regionie chmurowym, korzystać z jednego operatora DNS albo wspólnego dostawcy tożsamości. Awaria jednego elementu zatrzyma wtedy wiele procesów jednocześnie.
Dla funkcji krytycznych potrzebna jest strategia wyjścia. Nie zawsze oznacza ona możliwość zmiany dostawcy w ciągu kilku dni. Migracja systemu bankowego lub platformy ubezpieczeniowej może trwać kilkanaście miesięcy. Plan powinien jednak określać realny czas przejścia, wymagane zasoby, dostęp do danych, rozwiązanie tymczasowe oraz moment, w którym dalsze korzystanie z usługi staje się zbyt ryzykowne.
DORA wprowadza również unijny nadzór nad kluczowymi zewnętrznymi dostawcami usług ICT. Za niewykonanie zaleceń głównego organu nadzorczego taki dostawca może otrzymać okresową karę pieniężną sięgającą 1 proc. średniego dziennego światowego obrotu za każdy dzień naruszenia, nakładaną przez maksymalnie sześć miesięcy. Nie zwalnia to jednak instytucji finansowej z własnego nadzoru nad umową i ryzykiem dostawcy.
FAQ
Od kiedy DORA obowiązuje podmioty finansowe?
Rozporządzenie jest stosowane od 17 stycznia 2025 roku. Nie przewidziano ogólnego okresu przejściowego pozwalającego wdrażać wymagania dopiero po tej dacie.
Czy DORA dotyczy tylko cyberataków?
Nie. Obejmuje również awarie sprzętu i oprogramowania, błędne aktualizacje, utratę łączności, problemy z dostawcami oraz inne zdarzenia zakłócające systemy ICT.
Czy mała instytucja finansowa musi stosować wszystkie wymagania?
Nie zawsze. Część podmiotów korzysta z uproszczonych ram, a wobec mikroprzedsiębiorstw stosuje się określone wyłączenia. Nadal pozostają jednak obowiązki dotyczące incydentów, testów, dostawców i dokumentacji.
Czy każdy incydent trzeba zgłaszać do KNF?
Nie. Wszystkie incydenty powinny być rejestrowane i klasyfikowane, ale obowiązkowemu raportowaniu podlegają przede wszystkim zdarzenia spełniające kryteria poważnego incydentu związanego z ICT.
Ile czasu jest na pierwsze zgłoszenie poważnego incydentu?
Maksymalnie 4 godziny od jego sklasyfikowania i nie później niż 24 godziny od wykrycia. Następnie przekazuje się raport pośredni i końcowy.
Czy certyfikat ISO 27001 oznacza zgodność z DORA?
Nie. ISO 27001 może wspierać zarządzanie bezpieczeństwem, ale DORA zawiera dodatkowe wymagania dotyczące zarządu, raportowania incydentów, testowania odporności, rejestru umów ICT i kontroli dostawców.
Czy outsourcing IT przenosi odpowiedzialność na dostawcę?
Nie. Podmiot finansowy pozostaje odpowiedzialny za zgodność, ciągłość funkcji oraz kontrolę ryzyka także wtedy, gdy cała infrastruktura działa u zewnętrznego operatora.
Jak często trzeba wykonywać testy?
Systemy i aplikacje wspierające funkcje krytyczne lub istotne powinny być testowane co najmniej raz w roku. Wybrane podmioty wykonują zaawansowane testy TLPT co najmniej raz na trzy lata.
Pierwszym działaniem nie powinno być zamawianie kolejnego audytu ani pisanie nowych polityk. Najpierw trzeba sporządzić listę funkcji krytycznych i istotnych, a następnie przypisać do nich systemy, dane, pracowników oraz dostawców. Jeżeli instytucja nie potrafi dla każdej takiej funkcji wskazać dopuszczalnego czasu przestoju, procedury odtworzenia i osoby podejmującej decyzję podczas awarii, właśnie tę lukę należy usunąć w pierwszej kolejności. Bez tego raportowanie, testy i rejestr umów pozostaną zestawem oddzielnych obowiązków, zamiast tworzyć działający system odporności.
