Gotowość na DORA dla podmiotów finansowych i ich dostawców ICT

Rozporządzenie DORA w sprawie operacyjnej odporności cyfrowej sektora finansowego jest stosowane od 17 stycznia 2025 r. Dla podmiotów finansowych gotowość oznacza dziś utrzymywanie modelu operacyjnego zapewniającego operacyjną odporność cyfrową, a nie przygotowania do przyszłego terminu. Dla dostawców technologii oznacza zrozumienie obowiązków wobec klientów oraz ustalenie, czy ma do nich zastosowanie odrębny reżim bezpośredniego nadzoru.

Pytanie dla kierownictwa jest praktyczne: czy organizacja potrafi wyjaśnić, które usługi finansowe zależą od których systemów ICT, jak będzie postępować w razie zakłóceń i jakie dowody potwierdzają jej założenia dotyczące odtwarzania? Polityki mają znaczenie, ale same nie odpowiedzą na to pytanie. Kierownictwo potrzebuje spójnego obrazu obowiązków, zależności, umów, testów, incydentów i nierozwiązanych ryzyk.

Ustal swoją rolę, zanim zbudujesz listę kontrolną

Zacznij od udokumentowanej decyzji o stosowaniu przepisów dla każdego właściwego podmiotu prawnego. Art. 2 DORA określa objęte kategorie i wyłączenia. Przedsiębiorstwo, które określa się jako FinTech, startup lub MŚP, nie jest z tego powodu automatycznie objęte zakresem ani z niego wyłączone.

Przykładami objętych podmiotów finansowych są instytucje kredytowe, instytucje płatnicze, firmy inwestycyjne i zakłady ubezpieczeń, z zastrzeżeniem szczegółowych zasad dotyczących zakresu stosowania rozporządzenia. Zapisz właściwą kategorię, ewentualne wyłączenie lub zwolnienie, właściwy organ i uzasadnienie wniosku.

W przypadku dostawców rozróżnij trzy sytuacje:

Dostawca wspierający krytyczną lub istotną funkcję podmiotu finansowego nie staje się z tego tylko powodu wyznaczonym kluczowym zewnętrznym dostawcą usług ICT. Podmioty finansowe oceniają istotność swoich funkcji i zależności; wyznaczanie kluczowych dostawców odbywa się w ramach nadzoru na podstawie art. 31.

Lokalizacja nie rozstrzyga kwestii dostawcy. Amerykański dostawca chmury lub oprogramowania może spotkać się z wymaganiami klientów związanymi z DORA, gdy obsługuje podmioty finansowe z UE. Ta relacja handlowa nie sprawia jednak automatycznie, że podlega on wszystkim obowiązkom nałożonym na podmiot finansowy.

Proporcjonalność również wymaga uzasadnionej oceny. Art. 4 uwzględnia czynniki takie jak wielkość, ogólny profil ryzyka oraz charakter, skala i złożoność usług. Art. 16 przewiduje uproszczone ramy zarządzania ryzykiem związanym z ICT dla określonych kategorii. Nie są to pojęcia wymienne, a zwykły status MŚP nie jest uniwersalnym skrótem. Przechowuj analizę kwalifikowalności razem z decyzją o zakresie.

Spraw, by odpowiedzialność kierownictwa była widoczna

Zgodnie z art. 5 DORA organ zarządzający ponosi ostateczną odpowiedzialność za zarządzanie ryzykiem związanym z ICT w podmiocie finansowym. Delegowanie wdrożenia na CISO, zespół technologiczny lub zewnętrznego dostawcę nie przenosi tej odpowiedzialności.

Kierownictwo powinno ustalić, kto proponuje decyzje, kto je zatwierdza i kto sprawdza, czy wdrożenie działa. Model operacyjny powinien obejmować ciągłość działania, reagowanie na incydenty i przywracanie, ustalenia z dostawcami zewnętrznymi, budżet oraz wiedzę potrzebną do rzeczywistego nadzoru.

W praktyce zalecamy przekazywanie kierownictwu pakietu raportowego skoncentrowanego na decyzjach zamiast pulpitu pokazującego procent ukończenia. Uwzględnij w nim:

• Krytyczne lub istotne funkcje z nieprzetestowanymi założeniami dotyczącymi odtwarzania.
• Poważne incydenty, ich skutki dla klientów i zaległe działania naprawcze.
• Zależności od dostawców z niekompletnymi umowami lub słabymi możliwościami wyjścia.
• Istotne luki w zabezpieczeniach, odpowiedzialnych właścicieli i terminy działań naprawczych.
• Decyzje wymagające finansowania, zmiany dostawcy lub wyraźnej reakcji na ryzyko.

Każda luka powinna rozróżniać wymóg regulacyjny, bieżącą słabość operacyjną i proponowane rozwiązanie. Brakujący zapis zatwierdzenia to coś innego niż kopia zapasowa, której nie da się odtworzyć. Obie sytuacje mogą wymagać działania, ale potrzebują innych właścicieli i priorytetów.

Zatwierdzenie przez kierownictwo planu naprawczego nie jest zgodą na bezterminowe odkładanie mających zastosowanie obowiązków. Jeżeli luka jest istotna, rozważ natychmiastowe zabezpieczenia, eskalację i ewentualne implikacje nadzorcze równolegle z długoterminowym rozwiązaniem.

Zbuduj program wokół funkcji finansowych

Inwentarz aktywów jest niezbędny, ale planowanie odporności powinno zaczynać się od usługi, która musi być kontynuowana. Zidentyfikuj funkcję finansową, jej właściciela biznesowego, skutki zakłóceń oraz wspierające ją systemy i dostawców.

W przypadku usługi płatniczej odwzoruj tożsamość, infrastrukturę chmurową, przetwarzanie transakcji, monitorowanie i eskalację do dostawców. Uwzględnij mniej widoczne zależności, takie jak DNS, łączność, dostęp uprzywilejowany, klucze szyfrujące i narzędzia wsparcia. Alternatywne środowisko produkcyjne może być bezużyteczne, jeśli zależy od tej samej usługi tożsamości, która uległa awarii.

Powstała mapa powinna łączyć każdą funkcję z:

• Wspierającymi aplikacjami, infrastrukturą, aktywami informacyjnymi i usługami zewnętrznymi.
• Odpowiednimi umowami i właścicielami usług.
• Celami odtwarzania i wspierającą je analizą wpływu na działalność.
• Rozwiązaniami w zakresie wykrywania, reagowania, przywracania i komunikacji.
• Testami, ustaleniami i nierozwiązanymi ryzykami związanymi z zależnościami.

Zweryfikuj mapę zarówno z zespołami operacyjnymi, jak i biznesowymi. Rejestry zakupów pokazują, co zostało kupione; niekoniecznie pokazują, jak usługa działa dziś.

Wykorzystaj ten model do uporządkowania zarządzania ryzykiem związanym z ICT, zarządzania incydentami i ich zgłaszania, testowania odporności oraz ryzyka związanego z zewnętrznymi dostawcami usług ICT. DORA zawiera także przepisy dotyczące dobrowolnej wymiany informacji o cyberzagrożeniach. Jeżeli w niej uczestniczysz, określ członkostwo, poufność, dozwolone wykorzystanie i zasady postępowania, zamiast traktować wymianę jako nieograniczone udostępnianie danych o incydentach.

Przekształć zarządzanie ryzykiem związanym z ICT w sfinansowaną pracę

Przepisy DORA dotyczące zarządzania ryzykiem związanym z ICT obejmują identyfikację, ochronę i zapobieganie, wykrywanie, reagowanie i przywracanie, wyciąganie wniosków oraz komunikację. Ramy muszą łączyć te działania, a nie pozostawiać je jako odrębne zbiory polityk.

Zacznij ocenę luk od odwzorowanych funkcji. Zapytaj, czy kontrola dostępu chroni ich systemy, czy podatności są usuwane, czy zmiany są kontrolowane, czy podejrzana aktywność jest wykrywana i czy rozwiązania w zakresie przywracania odzwierciedlają realistyczne awarie. Uwzględnij usterki techniczne i błędy operacyjne, a nie tylko złośliwe ataki.

Dla każdej istotnej słabości utwórz zapis działania naprawczego zawierający właściciela, wpływ na działalność, wymagane działanie, kryteria ukończenia i dowody zamknięcia. Zależności mają znaczenie: usprawnienie procedur odtwarzania może wymagać zmian w dostępie do kopii zapasowych, zobowiązaniach dostawców i szkoleniach personelu, zanim udany test będzie w ogóle możliwy.

Cele odtwarzania powinny wynikać z potrzeb biznesowych i analizy wpływu, a nie z tego, co akurat oferuje standardowy poziom usług dostawcy. Jeżeli możliwości techniczne nie pozwalają osiągnąć celu, kierownictwo musi zdecydować, czy usprawnić architekturę, zmienić ustalenia dotyczące usługi, czy przemyśleć model operacyjny. Wartość docelowa zapisana w planie ciągłości działania nie jest dowodem możliwości odtworzenia.

Przygotuj decyzje dotyczące incydentów przed wystąpieniem zakłócenia

DORA wymaga od podmiotów finansowych zarządzania incydentami związanymi z ICT i zgłaszania poważnych incydentów właściwemu organowi. Art. 17–23 ustanawiają ramy; mające zastosowanie regulacyjne standardy techniczne i wykonawcze standardy techniczne określają szczegółowe kryteria klasyfikacji, progi, treść zgłoszeń i procedury.

Nie polegaj na ogólnej liście kontrolnej dotyczącej incydentów w kwestii szczegółowego harmonogramu zgłoszeń. Prowadź aktualną macierz zgłoszeń wskazującą mające zastosowanie standardy, instrukcje organu, kanał przekazywania, etapy zgłaszania i sposób obliczania terminów. Wyznacz osobę odpowiedzialną za jej aktualizowanie.

Proces reagowania powinien umożliwiać podjęcie kilku decyzji pod presją:

• Kto zapisuje znaczniki czasu wykrycia, oceny i klasyfikacji?
• Kto pozyskuje informacje o skutkach od zespołów operacyjnych i dostawców?
• Kto decyduje, czy spełnione są kryteria poważnego incydentu?
• Kto zatwierdza i przekazuje zgłoszenia, także poza normalnymi godzinami pracy?
• Kto odpowiada za komunikację z klientami i inne mające zastosowanie powiadomienia?

Zapisuj uzasadnienie klasyfikacji także wtedy, gdy incydent nie zostaje zgłoszony jako poważny. Niepełny obraz początkowy powinien uruchamiać ponowną ocenę w miarę napływu informacji, a nie trwałe założenie, że zdarzenie jest drobne.

Zobowiązania dostawców dotyczące powiadamiania powinny zostawiać podmiotowi finansowemu wystarczająco dużo czasu na ocenę i wypełnienie własnych obowiązków. Zadania związane ze zgłaszaniem można zlecić na zewnątrz, jeśli jest to dozwolone, ale odpowiedzialność pozostaje po stronie podmiotu finansowego.

Jeżeli poważny incydent związany z ICT wpływa na interesy finansowe klientów, DORA wymaga od podmiotów finansowych poinformowania tych klientów bez zbędnej zwłoki o incydencie i o środkach podjętych w celu złagodzenia jego negatywnych skutków. Oddzielnie oceń obowiązki związane z naruszeniem ochrony danych osobowych i inne mające zastosowanie przepisy. Jedno zakłócenie może wymagać kilku decyzji o powiadomieniu, z różnymi adresatami i przesłankami prawnymi.

Testuj założenia, na których polega kierownictwo

Program testowania operacyjnej odporności cyfrowej powinien być proporcjonalny i oparty na ryzyku. Oceny podatności, ćwiczenia scenariuszowe, testy bezpieczeństwa i testy odtwarzania odpowiadają na różne pytania; żadnego z nich nie należy traktować jako uniwersalnego zamiennika pozostałych.

Ćwiczenie sztabowe może pokazać, czy decydenci rozumieją zasady eskalacji. Nie może dowieść, że dane transakcyjne da się dokładnie odtworzyć. Test penetracyjny może ujawnić podatności możliwe do wykorzystania, nie dowodząc, że alternatywny dostawca jest w stanie przejąć usługę.

Dla każdego testu określ funkcję, scenariusz, zakres, kryteria sukcesu, w stosownych przypadkach wymogi dotyczące niezależności oraz oczekiwane dowody. Zachowuj wyniki, ustalenia, decyzje dotyczące działań naprawczych i wyniki ponownych testów. Sprawdź mające zastosowanie wymogi dotyczące zakresu i częstotliwości w świetle DORA i odpowiednich standardów, w tym ewentualne zwolnienia lub przepisy dotyczące uproszczonych ram.

Zaawansowane testy penetracyjne prowadzone w oparciu o analizę zagrożeń (TLPT) są odrębnym wymogiem nadzorczym dla wybranych podmiotów finansowych na podstawie art. 26. Nie są ogólnym obowiązkiem każdego przedsiębiorstwa finansowego ani dostawcy ICT.

Kierownictwo powinno analizować założenia, które się nie sprawdziły, a nie tylko to, czy testy się odbyły. Jeśli ćwiczenie ujawni, że odtwarzanie zależy od jednego niedostępnego administratora, wynikiem jest ryzyko operacyjne wymagające działania, a nie zrealizowany kamień milowy testów.

Traktuj ryzyko związane z podmiotami zewnętrznymi jako kwestię ciągłości usług

Zgodnie z DORA podmiot finansowy pozostaje odpowiedzialny za swoje obowiązki, korzystając z dostawców ICT. Art. 28–30 łączą ocenę ryzyka związanego z podmiotami zewnętrznymi, ustalenia umowne, monitorowanie i planowanie wyjścia.

Prowadź rejestr i obraz operacyjny

Podmioty finansowe muszą prowadzić rejestr informacji dotyczący ustaleń umownych w zakresie usług ICT na wymaganym poziomie jednostkowym, subskonsolidowanym i skonsolidowanym. Jego strukturę określają mające zastosowanie wykonawcze standardy techniczne. Arkusz zakupowy lub lista zatwierdzonych dostawców nie jest automatycznie wystarczająca.

Uzgadniaj rejestr z umowami, odpowiedzialnością za usługi i mapami zależności. Zachowuj wymagane rozróżnienia dla usług wspierających funkcje krytyczne lub istotne. Nowy podwykonawca, lokalizacja świadczenia usługi lub rozszerzony zakres mogą zmienić obraz ryzyka, nawet jeśli nazwa dostawcy pozostaje ta sama.

Weryfikuj umowy względem faktycznej usługi

Oceń mające zastosowanie wymogi umowne, w tym opisy usług, lokalizacje, ochronę danych, dostęp do danych i ich odzyskiwanie, pomoc przy incydentach, współpracę, prawo do wypowiedzenia i poziomy usług. Ustalenia wspierające funkcje krytyczne lub istotne wymagają dodatkowych postanowień, w tym dotyczących sprawozdawczości, ciągłości, dostępu, inspekcji, audytu i wyjścia.

Właściciele z obszarów prawnego, zakupów, technologii i biznesu powinni analizować je wspólnie. Umowne prawo do audytu może być trudne do wykonania w praktyce; obiecane rozwiązanie w zakresie odtwarzania może nie obejmować pełnego łańcucha usług klienta. Zidentyfikuj te ograniczenia przed zaakceptowaniem ustaleń.

Badaj koncentrację i zdolność do wyjścia

Ryzyko koncentracji nie ogranicza się do kupowania kilku usług od jednej firmy. Różni dostawcy mogą polegać na tej samej platformie chmurowej, regionie, sieci lub podwykonawcy. Oceń substytucyjność, złożoność migracji i skutki wspólnej awarii.

Plan wyjścia powinien obejmować formaty danych, ich wyodrębnienie, dostęp, zależności migracyjne, wsparcie w okresie przejściowym, usuwanie danych i ciągłość w trakcie przenosin. W przypadku funkcji krytycznych lub istotnych traktuj testowanie i przegląd wyjścia jako pracę merytoryczną, a nie ćwiczenie z pisania dokumentów.

Dostawcy mogą przygotować spójny pakiet zapewnienia zawierający zakres usług, granice odpowiedzialności, kontakty w sprawie incydentów, dowody ciągłości, informacje o podwykonawstwie i stanowiska umowne. Wymagania specyficzne dla klientów nadal wymagają przeglądu; certyfikat ich nie zastępuje.

Zrozum, gdzie DORA spotyka się z NIS2

DORA jest rozporządzeniem UE stosowanym bezpośrednio. NIS2 jest dyrektywą wdrażaną przez prawo krajowe, a jej stosowanie zależy od sektora, wielkości, usługi i reguł objęcia. Termin jej transpozycji do prawa krajowego upłynął 17 października 2024 r.; organizacje muszą zbadać mające zastosowanie wdrożenie krajowe, zamiast zakładać jeden identyczny reżim operacyjny.

Art. 1 ust. 2 DORA w związku z art. 4 NIS2 ustanawia relację przepisów sektorowych dla objętych podmiotów finansowych w odpowiednich obszarach. Nie należy tego interpretować jako polecenia dublowania równoważnych zabezpieczeń w zakresie zarządzania ryzykiem i zgłaszania incydentów. Nie należy też zakładać, że zwalnia to z obowiązków każdą spółkę w grupie finansowej lub w jej łańcuchu dostaw.

Dostawca usług zarządzanych obsługujący bank może potrzebować własnej oceny pod kątem NIS2, wypełniając jednocześnie zobowiązania umowne związane z DORA. Macierz obowiązków prowadzona dla każdego podmiotu osobno powinna zawierać podstawę prawną, zakres, organ, ścieżkę zgłaszania i wymagane dowody.

Wspólne zabezpieczenia mogą wspierać DORA, ISO 27001, obowiązki w zakresie ochrony danych i zapewnienia dla klientów, o ile zakres i dowody są zgodne. Wykorzystuj ponownie przegląd dostępu lub test odtwarzania, gdy rzeczywiście wspiera on kilka wymogów, zachowując jednak szczegóły specyficzne dla sektora finansowego. Certyfikat ISO 27001 nie dowodzi zgodności z DORA.

Różni się także egzekwowanie przepisów. Uprawnienia nadzorcze i sankcje wobec podmiotów finansowych zależą od przepisów DORA i mających zastosowanie środków krajowych; wyznaczeni kluczowi dostawcy podlegają odrębnemu reżimowi nadzoru. Nie planuj budżetu ryzyka wokół rzekomej uniwersalnej kary z DORA. Oceń odpowiednią ekspozycję prawną i operacyjne skutki niewystarczającej odporności.

Przykład: przegląd zależności usługi płatniczej

Rozważmy przykładową instytucję płatniczą, która korzysta z platformy chmurowej, dostawcy tożsamości i zewnętrznej usługi monitorowania. Załóżmy, że instytucja jest objęta zakresem DORA, a realizacja płatności została sklasyfikowana jako funkcja krytyczna lub istotna.

Pierwszy przegląd ujawnia trzy słabości: środowisko produkcyjne i środowisko odtwarzania mają tę samą zależność od usługi tożsamości; proces eskalacji incydentów u dostawcy usługi monitorowania jest niejasny; a plan wyjścia z chmury wymienia alternatywnego dostawcę bez wykazania możliwości wyodrębnienia i migracji danych.

Kierownictwo zleca trzy powiązane pakiety prac:

Właściciel biznesowy sprawdza, czy cele odtwarzania dla płatności pozostają osiągalne. Dział zgodności weryfikuje, czy procedury zgłaszania i wpisy w rejestrze odzwierciedlają ustalenia. Kierownictwo zatwierdza niezbędne finansowanie i analizuje pozostałe ograniczenia.

Ten przykład sam w sobie nie dowodzi zgodności. Pokazuje, jak jedna funkcja może ujawnić decyzje, które pozostałyby ukryte w odrębnych listach kontrolnych dotyczących polityk, dostawców i testów.

Ustal rytm przeglądów oparty na dowodach

DORA nie przewiduje uniwersalnego procesu certyfikacji, który zastępowałby bieżące obowiązki. Niezależne zapewnienie może dostarczać informacji kierownictwu, ale gotowość trzeba wykazywać przez działające zabezpieczenia, zapisy i, w stosownych przypadkach, współpracę z organem nadzoru.

Praktycznym kolejnym krokiem jest wybranie jednej funkcji krytycznej lub istotnej i zebranie dla niej decyzji o zakresie, mapy zależności, oceny ryzyka, umów, procedur obsługi incydentów, wyników testów i otwartych działań. Sprawdź, czy te zapisy tworzą spójny obraz.

Secani wspiera ten proces, modelując systemy i usługi, łącząc zależności oraz utrzymując wymagania, dowody, właścicieli, zadania i decyzje przeglądowe we wspólnym kontekście. Prześlij istniejące materiały i przypisz je do odpowiednich obiektów, przekształć luki w przypisane zadania i zachowaj wyraźne zatwierdzanie przez człowieka dla sugestii i wniosków wspieranych przez AI.

Rozszerzaj zakres, wychodząc od tej pierwszej funkcji, gdy odpowiedzialność i ścieżki dowodowe będą jasne. Kierownictwo powinno widzieć, co zostało wykazane, co pozostaje niepewne i jaka decyzja jest potrzebna jako następna.