Czym jest rozporządzenie DORA? Wyjaśnienie unijnego aktu o odporności operacyjnej cyfrowej

Rozporządzenie DORA — Digital Operational Resilience Act — to unijne prawo dotyczące odporności cybernetycznej sektora finansowego. Określa, jak instytucje finansowe mają zarządzać cyberbezpieczeństwem i ryzykiem IT. Mówiąc prosto, każdy bank, firma płatnicza, firma inwestycyjna, ubezpieczyciel i giełda kryptowalut w UE muszą być zdolne do działania mimo włamania, awarii chmury lub błędnej aktualizacji oprogramowania oraz kontrolować dostawców IT, od których zależą.

Ten przewodnik jest przeznaczony dla osób bez wykształcenia prawniczego lub IT. Omawia, kogo dotyczy DORA, czego wymaga, jak szybko należy zgłosić incydent, czym różni się od NIS2 i GDPR, jakie są kary oraz co wymogi DORA oznaczają dla firm fintech i kryptowalutowych; kończy się krótką listą kontrolną zgodności z DORA.

Czym jest DORA — prosto wyjaśnione?

DORA — czasem określana jako EU DORA lub DORA Act — to rozporządzenie (UE) 2022/2554 w sprawie odporności operacyjnej cyfrowej sektora finansowego. „Odporność operacyjna cyfrowa” brzmi skomplikowanie, lecz oznacza jedno: czy firma może nadal obsługiwać klientów, gdy jej IT zawiedzie? Haker uzyskuje dostęp, aktualizacja nie działa, dostawca przestaje być dostępny — czy płatności nadal są realizowane, klienci mogą się zalogować, a ich dane pozostają bezpieczne? DORA zmienia to pytanie z dobrej praktyki w obowiązek prawny.

Przed DORA każde państwo UE i każda część sektora finansowego miały własne zasady bezpieczeństwa IT oraz własne formularze incydentów. DORA zastępuje tę mozaikę jednym zbiorem reguł dla całego unijnego sektora finansowego. Ponieważ jest rozporządzeniem, a nie dyrektywą, obowiązuje dosłownie w każdym państwie członkowskim — nie potrzeba krajowej ustawy, aby zaczęła obowiązywać.

Termin zgodności z DORA już minął. Dwuletni okres przygotowawczy po przyjęciu aktu dobiegł końca, wszystkie obowiązki DORA obowiązują, a krajowi regulatorzy finansowi je kontrolują. Ramy DORA opierają się na pięciu filarach, które omawia dalsza część przewodnika:

• zarządzanie ryzykiem ICT — pisemny plan ryzyka IT, za który odpowiada organ zarządzający (zarząd);
• zarządzanie incydentami związanymi z ICT i ich zgłaszanie — wykrywanie, rejestrowanie i zgłaszanie incydentów IT organowi nadzoru;
• testowanie odporności operacyjnej cyfrowej — od rutynowych skanów podatności po pełne symulacje ataku „red team”;
• zarządzanie ryzykiem ICT ze strony osób trzecich — kontrola dostawców IT, od których zależy firma, wraz z rejestrem wszystkich dostawców;
• wymiana informacji — dobrowolna wymiana informacji o zagrożeniach między podmiotami finansowymi.

Wyjaśnienie kluczowych pojęć DORA

Garść zdefiniowanych pojęć pojawia się w każdym artykule rozporządzenia DORA, formularzu nadzorczym i umowie z dostawcą. Po ich poznaniu dalsza lektura jest znacznie łatwiejsza.

Kogo dotyczy DORA?

Zakres DORA określa art. 2, który wymienia dwadzieścia kategorii podmiotów finansowych. Jeżeli instytucja finansowa posiada jedną z tych licencji w dowolnym miejscu UE, jest objęta przepisami — niezależnie od wielkości — chyba że ma zastosowanie konkretne wyłączenie. Poniżej znajdują się główne grupy.

A co z samymi firmami IT? Platformy chmurowe, centra danych, dostawcy oprogramowania i firmy zarządzające bezpieczeństwem nie są podmiotami finansowymi, lecz DORA obejmuje je na dwa sposoby. Po pierwsze, każdy podmiot finansowy musi wprowadzić do umów z nimi warunki zgodne z DORA, więc dostawca, który odmawia, ryzykuje utratę klienta. Po drugie, najwięksi dostawcy — główni dostawcy chmury, centrów danych, telekomunikacji i oprogramowania finansowego — są uznawani za kluczowych zewnętrznych dostawców usług ICT i podlegają bezpośredniemu nadzorowi UE; lista jest aktualizowana co roku.

Czy DORA dotyczy firm spoza UE? Bezpośrednio — wyłącznie firm licencjonowanych w UE, w tym unijnych spółek zależnych i oddziałów grup z Wielkiej Brytanii, USA lub Azji. Pośrednio obejmuje każdego zagranicznego dostawcę obsługującego unijną firmę finansową, ponieważ obowiązkowe klauzule umowne stosuje się niezależnie od siedziby dostawcy. Dostawca spoza UE uznany za kluczowego musi utworzyć spółkę zależną w UE w ciągu dwunastu miesięcy.

Wreszcie DORA jest proporcjonalna: obowiązki rosną wraz z wielkością i złożonością instytucji finansowej. Mikroprzedsiębiorstwa — mniej niż dziesięciu pracowników oraz obrót lub suma bilansowa poniżej dwóch milionów euro — są zwolnione z kilku wymogów, w tym z TLPT oraz części obowiązków dotyczących zarządzania i raportowania. Określona grupa mniejszych firm, taka jak małe i niepowiązane wzajemnie firmy inwestycyjne oraz niektóre zwolnione instytucje płatnicze i pieniądza elektronicznego, stosuje uproszczone ramy zarządzania ryzykiem ICT na podstawie art. 16. Mały rozmiar nie wyłącza licencjonowanej firmy z DORA; jedynie zmniejsza obciążenie.

Wymogi DORA: wyjaśnienie pięciu filarów

Wymogi zgodności z DORA dzielą się na pięć grup. Łącznie tworzą jeden cykl — zapobieganie, wykrywanie, reagowanie, odzyskiwanie sprawności, uczenie się — a regulator oczekuje dowodów na każdym etapie.

Ramy zarządzania ryzykiem ICT (artykuły 5–16)

Mówiąc prosto: trzeba wiedzieć, jakie IT posiada firma, co może pójść nie tak, oraz mieć pisemny plan ochrony i przywracania sprawności. Ramy muszą zawierać wykaz zasobów i zależności IT, określać, jak firma zapobiega problemom i je wykrywa, jak reaguje i odzyskuje sprawność oraz jak wyciąga wnioski z incydentów. Są przeglądane co najmniej raz w roku i po każdym poważnym incydencie. Organ zarządzający je zatwierdza, określa akceptowalny poziom ryzyka i zapewnia budżet. Należy zmapować funkcje krytyczne, faktycznie testować kopie zapasowe i posiadać plan ciągłości działania IT uzupełniający ogólny plan ciągłości działania firmy.

Zgłaszanie incydentów: terminy 4 godzin, 72 godzin i miesiąca

Każdy incydent związany z ICT musi zostać zarejestrowany i sklasyfikowany według jednolitych kryteriów w całej UE: liczby dotkniętych klientów, szkody dla reputacji firmy, czasu trwania, zasięgu, utraconych danych, krytyczności usługi i stawki finansowej. Incydent przekraczający progi jest „poważny” i należy go zgłosić organowi nadzoru w trzech krokach: pierwsze zgłoszenie w ciągu czterech godzin od uznania go za poważny (i nigdy później niż 24 godziny od powzięcia wiedzy przez firmę), raport okresowy w ciągu 72 godzin od pierwszego zgłoszenia oraz raport końcowy w ciągu miesiąca od raportu okresowego. Klientów, których pieniądze lub dane zostały dotknięte, należy poinformować bez zwłoki. Poważne cyberzagrożenia, które nie przekształciły się w incydenty, można zgłaszać dobrowolnie.

Testowanie odporności i testy penetracyjne oparte na analizie zagrożeń (TLPT)

Testowanie odporności operacyjnej cyfrowej to coroczny program: każdy system wspierający funkcję krytyczną lub istotną musi przejść skany podatności, analizy luk, przeglądy kodu źródłowego, testy scenariuszowe, testy wydajności i testy penetracyjne. Firmy uznane przez organ nadzoru za istotne — ze względu na ich rozmiar lub wpływ ich awarii — muszą dodatkowo przeprowadzać TLPT co najmniej raz na trzy lata. Jest to kontrolowany atak na działające systemy prowadzony przez wykwalifikowanych etycznych hakerów zgodnie z uznanymi ramami. Mikroprzedsiębiorstwa i firmy objęte uproszczonymi ramami są zwolnione z TLPT oraz testują według lżejszego, opartego na ryzyku harmonogramu.

Ryzyko osób trzecich, outsourcing i rejestr informacji

Outsourcing IT — do dostawcy usług chmurowych lub kogokolwiek innego — nie oznacza outsourcingu odpowiedzialności. Zarządzanie ryzykiem ICT ze strony osób trzecich zaczyna się od pisemnej strategii ryzyka dostawców; firma musi sprawdzać dostawców przed podpisaniem umowy, unikać nadmiernej zależności od jednego dostawcy oraz prowadzić rejestr informacji — ustrukturyzowany wykaz każdej umowy IT — przekazywany organowi nadzoru co najmniej raz w roku. Same umowy muszą zawierać określony zestaw klauzul: czym jest usługa i jaki poziom jest obiecany, gdzie przechowywane są dane, prawo do kontroli i audytu, obowiązek pomocy podczas incydentów, sposób rozwiązania umowy oraz sposób przejścia do innego dostawcy w razie potrzeby. Firma pozostaje w pełni odpowiedzialna nawet wtedy, gdy dostawca jest kluczowym dostawcą nadzorowanym na poziomie UE.

Wymiana informacji o cyberzagrożeniach

Podmioty finansowe mogą wymieniać informacje o zagrożeniach — wzorce ataków, wskaźniki naruszenia bezpieczeństwa — w zaufanych grupach. Nikt nie ma obowiązku dołączać, lecz firma, która to robi, musi poinformować organ nadzoru, a wymiana musi respektować zasady poufności i ochrony danych.

DORA vs NIS2 vs GDPR: jak te przepisy współdziałają

Trzy akty prawa UE nakładają się w zakresie odporności cybernetycznej i zgłaszania incydentów, a wiele instytucji finansowych podlega więcej niż jednemu z nich. Tabela pokazuje, kogo obejmuje każdy z nich i jak różnią się terminy zgłaszania.

W praktyce firma finansowa zgłasza incydenty IT swojemu organowi nadzoru finansowego, a nie krajowej agencji cyberbezpieczeństwa. GDPR obowiązuje równolegle: jeśli cyberatak ujawni dane klientów, firma zgłasza go dwukrotnie — na podstawie DORA organowi nadzoru finansowego i na podstawie GDPR organowi ochrony danych — według dwóch odrębnych terminów.

DORA i kryptoaktywa: co oznacza dla CASP i emitentów tokenów

Dla firm kryptowalutowych rozporządzenie DORA i ramy MiCA działają jako para. MiCA określa, kto może świadczyć usługi w zakresie kryptoaktywów lub emitować tokeny w UE; DORA określa, jak należy prowadzić technologię stojącą za tymi usługami. Dostawca usług w zakresie kryptoaktywów autoryzowany na podstawie MiCA staje się podmiotem finansowym w rozumieniu DORA z chwilą przyznania licencji, podobnie jak każdy emitent tokenów powiązanych z aktywami. Sama MiCA odsyła do DORA w kwestii wymogów IT i bezpieczeństwa, dlatego każdy organ nadzoru odczytuje oba akty łącznie.

W praktyce odporność jest weryfikowana już podczas procesu licencyjnego, a nie dopiero później. Gdy organ nadzoru rozpatruje wniosek CASP, ramy ryzyka IT, plan ciągłości działania, procedury incydentowe i rozwiązania outsourcingowe są częścią dokumentacji, a DORA stanowi kryterium ich oceny. Giełda kryptowalut lub depozytariusz nie może uzyskać ani utrzymać licencji z planem odporności istniejącym wyłącznie na papierze.

Firmy kryptowalutowe mają także zależności IT, których bank nie ma: przechowywanie kluczy prywatnych, dostawców węzłów blockchain, infrastrukturę portfeli stron trzecich, komponenty smart kontraktów oraz rynki działające przez całą dobę bez okna konserwacyjnego. W ramach DORA każdy z tych elementów jest zasobem IT lub relacją z dostawcą, które należy wykazać, sklasyfikować, objąć umową i testować. Tak też nielicencjonowani dostawcy hostingu, zarządzania kluczami lub infrastruktury blockchain spełniają DORA: poprzez umowy z klientami.

Kary, grzywny i sankcje DORA za brak zgodności

Nie istnieje jedna unijna tabela sankcji DORA. Zamiast tego art. 50 nakazuje każdemu państwu członkowskiemu ustanowić kary „skuteczne, proporcjonalne i odstraszające” oraz przyznaje organom nadzoru uprawnienia do żądania dokumentów, przeprowadzania kontroli, nakazywania działań naprawczych i publikowania ostrzeżeń. Stosuje je właściwy organ krajowy każdego państwa członkowskiego na podstawie sektorowego prawa licencyjnego, więc bank, firma płatnicza i giełda kryptowalut podlegają własnej drabinie sankcji sektorowych.

Możesz spotkać się z „grzywną DORA” w wysokości jednego procenta średniego dziennego światowego obrotu. Ta liczba jest prawdziwa, ale dotyczy kogoś innego: to dzienna kara, którą Europejskie Urzędy Nadzoru mogą nałożyć na kluczowego zewnętrznego dostawcę usług ICT ignorującego decyzję nadzorczą, maksymalnie przez sześć miesięcy. Nie jest to grzywna dla banków ani firm kryptowalutowych. Cytowane czasem obok „2% rocznego obrotu” również nie pochodzi z DORA: wynika z NIS2, gdzie stanowi minimalny pułap, który państwa muszą ustalić dla podmiotów kluczowych. Dla firmy finansowej realne konsekwencje to:

• środki nadzorcze — nakazy usunięcia problemów, ograniczenia działalności, a w poważnych przypadkach zawieszenie lub utrata licencji;
• kary administracyjne na podstawie krajowego prawa danego sektora;
• osobista odpowiedzialność członków zarządu, ponieważ DORA czyni zarząd odpowiedzialnym za ramy IT;
• odpowiedzialność karna w państwach, które zdecydowały się ją wprowadzić, na co zezwala art. 52;
• szkoda reputacyjna i handlowa — utrata klientów, partnerów bankowych i inwestorów.

Kto nadzoruje DORA? Regulatorzy krajowi i unijni

Bieżący nadzór DORA pozostaje w rękach regulatora, który już licencjonuje firmę — banku centralnego lub organu nadzoru finansowego jej macierzystego państwa członkowskiego. Właściwy organ otrzymuje zgłoszenia incydentów i rejestry informacji, decyduje, kto musi przeprowadzać TLPT, oraz sprawdza ramy ryzyka IT w ramach zwykłego nadzoru. Większość publikuje na swoich stronach wytyczne DORA, wzory i terminy.

Na poziomie UE pracę dzielą trzy organy: Europejski Urząd Nadzoru Giełd i Papierów Wartościowych, Europejski Urząd Nadzoru Bankowego oraz EIOPA, organ ds. ubezpieczeń i emerytur. Opracowują one standardy techniczne uzupełniające szczegóły i wspólnie wyznaczają kluczowych zewnętrznych dostawców usług ICT, z których każdy jest następnie nadzorowany przez jeden z tych trzech organów jako główny organ nadzorczy.

Lista kontrolna zgodności z DORA: jak ją zapewnić

Niezależnie od tego, czy firma ubiega się o licencję, czy już podlega nadzorowi, ten sam zestaw dokumentów potwierdza zgodność z DORA podczas audytu. Praktyczny punkt wyjścia do planu wdrożenia DORA lub analizy luk:

• Potwierdź zakres: do której kategorii z art. 2 należysz i czy mają zastosowanie uproszczone ramy lub zwolnienie dla mikroprzedsiębiorstw.
• Zmapuj każdy zasób IT, system i przepływ danych wspierający funkcję krytyczną lub istotną.
• Przyjmij zatwierdzoną przez zarząd politykę zarządzania ryzykiem ICT z wyznaczonymi właścicielami i corocznym przeglądem.
• Wprowadź klasyfikację incydentów, rejestr incydentów i wzory zgłoszeń zgodne z ustawowymi terminami.
• Stwórz roczny kalendarz testów i sprawdź, czy organ nadzoru umieścił Cię na liście TLPT.
• Sporządź rejestr informacji o wszystkich dostawcach IT i zaktualizuj ich umowy o obowiązkowe klauzule.
• Sprawdź ryzyko koncentracji i sporządź plany wyjścia dla dostawców wspierających funkcje krytyczne.
• Testuj kopie zapasowe, odtwarzanie i plan ciągłości działania IT co najmniej raz w roku.
• Przeszkol zarząd i zachowaj dowód przeprowadzenia szkolenia.

Eesti Firma doradza firmom fintech i kryptowalutowym w prawnych aspektach DORA: ustala, które obowiązki mają zastosowanie, dostosowuje ramy IT do wymogów licencyjnych MiCA, analizuje umowy z dostawcami i przygotowuje dokumenty, których oczekuje organ nadzoru. Skontaktuj się z nami, aby omówić zastosowanie rozporządzenia do Twojej działalności.

Umów konsultację

Najczęściej zadawane pytania o DORA