Penetration Testing a zgodność z DORA: Co instytucje finansowe w UE muszą wiedzieć

Ustawa o Cyfrowej Odporności Operacyjnej (Digital Operational Resilience Act) – DORA – stanowi najbardziej znaczącą zmianę w regulacjach dotyczących cyberbezpieczeństwa, jaką kiedykolwiek widział unijny sektor finansowy. U jej podstaw, obok ram zarządzania ryzykiem ICT i obowiązków raportowania incydentów, leży zestaw wymagań dotyczących testowania, które przekształcają Penetration Testing z dobrowolnego ćwiczenia w prawnie nakazane działanie z określonymi częstotliwościami, zasadami zakresu, kwalifikacjami testerów i nadzorem organów nadzoru.

Jeśli jesteś bankiem, ubezpieczycielem, instytucją płatniczą, firmą inwestycyjną lub innym podmiotem regulowanym na mocy unijnego prawa usług finansowych, to dotyczy to Ciebie. Jeśli masz znaczenie systemowe, sprawa staje się jeszcze bardziej intensywna. A jeśli jesteś zewnętrznym dostawcą ICT obsługującym te podmioty, również nie jesteś zwolniony.

Ten przewodnik omawia wszystko, co musisz zrozumieć: czego wymaga DORA, kogo obejmuje, jaka jest różnica między standardowymi testami rocznymi a zaawansowanym reżimem Threat-Led Penetration Testing (TLPT) oraz jak zbudować program testowania, który zapewni zgodność bez tonięcia w złożoności regulacyjnej.

---

Czym jest DORA i dlaczego istnieje?

Ustawa o Cyfrowej Odporności Operacyjnej (Rozporządzenie UE 2022/2554) została przyjęta przez Radę Europejską w grudniu 2022 r., weszła w życie 16 stycznia 2023 r. i zaczęła obowiązywać 17 stycznia 2025 r. W przeciwieństwie do dyrektywy, która wymaga transpozycji do prawa krajowego, DORA jest rozporządzeniem – co oznacza, że ma bezpośrednie zastosowanie we wszystkich państwach członkowskich UE bez modyfikacji.

DORA istnieje, ponieważ sektor finansowy UE miał problem z fragmentacją. Wcześniej różne kraje stosowały różne wymagania dotyczące cyberbezpieczeństwa wobec swoich instytucji finansowych. Niektóre miały solidne ramy testowania (Holandia miała TIBER-NL, Niemcy miały TIBER-DE), podczas gdy inne miały minimalne wymagania techniczne. Bank transgraniczny mógł podlegać trzem różnym reżimom testowania, w zależności od tego, która jurysdykcja go kontrolowała.

W międzyczasie sektor finansowy stawał się coraz bardziej zależny od infrastruktury cyfrowej i zewnętrznych dostawców ICT. Pojedyncza awaria chmury lub cyberatak mogły rozprzestrzenić się kaskadowo na instytucje, granice i rynki. DORA została zaprojektowana w celu stworzenia zharmonizowanych ram, które zapewnią, że każdy podmiot finansowy w UE może wytrzymać zakłócenia związane z ICT, reagować na nie i odzyskiwać po nich zdolność operacyjną.

Rozporządzenie opiera się na pięciu filarach: zarządzanie ryzykiem ICT, zarządzanie incydentami związanymi z ICT i raportowanie, testowanie cyfrowej odporności operacyjnej, zarządzanie ryzykiem ICT związanym z podmiotami trzecimi oraz wymiana informacji. Penetration Testing wchodzi w zakres trzeciego filaru, omówionego w rozdziale IV (art. 24–27) rozporządzenia – i jest to filar z najostrzejszymi zębami dla codziennych zespołów ds. bezpieczeństwa.

Kogo obejmuje?

DORA ma szerokie zastosowanie w całym sektorze finansowym. Podmioty podlegające jej wymogom obejmują instytucje kredytowe (banki), instytucje płatnicze, instytucje pieniądza elektronicznego, firmy inwestycyjne, firmy ubezpieczeniowe i reasekuracyjne, dostawców usług w zakresie kryptoaktywów na mocy MiCA, centralne depozyty papierów wartościowych, platformy obrotu, repozytoria transakcji, firmy zarządzające funduszami, agencje ratingowe i dostawców usług finansowania społecznościowego, między innymi.

W praktyce: jeśli Twoja organizacja jest regulowana na mocy unijnego prawa usług finansowych, prawie na pewno jesteś objęty zakresem DORA. Rozporządzenie celowo rzuca szeroką sieć, aby zapewnić spójność cyfrowej odporności operacyjnej w całym sektorze.

Jest jedno wyłączenie, o którym warto wspomnieć. Mikroprzedsiębiorstwa – zdefiniowane jako podmioty zatrudniające mniej niż 10 pracowników i których roczny obrót lub bilans nie przekracza 2 mln EUR – podlegają łagodniejszemu reżimowi testowania. Nadal muszą stosować podejście oparte na ryzyku do testowania ICT, ale wymagania są proporcjonalnie skalowane. Dla wszystkich pozostałych obowiązują pełne obowiązki w zakresie testowania.

Co istotne, zasięg DORA wykracza poza same podmioty finansowe. Zewnętrzni dostawcy usług ICT – platformy chmurowe, dostawcy SaaS, dostawcy usług zarządzanych, firmy zajmujące się analizą danych – podlegają ramom nadzoru DORA, zwłaszcza jeśli uznani są za krytycznych dla stabilności sektora finansowego. Jeśli jesteś dostawcą technologii obsługującym unijne instytucje finansowe, obowiązki DORA Twoich klientów szybko stają się Twoim problemem.

Dwa poziomy testowania w DORA

DORA ustanawia dwupoziomowe podejście do testowania odporności. Zrozumienie tej struktury jest niezbędne, ponieważ wymagania, częstotliwość i złożoność różnią się znacznie w zależności od poziomu.

Wymiar	Poziom 1: Standardowe testowanie	Poziom 2: TLPT (zaawansowane)
Kto	Wszystkie podmioty regulowane przez DORA (z wyjątkiem mikroprzedsiębiorstw)	Podmioty o znaczeniu systemowym zidentyfikowane przez właściwe organy
Częstotliwość	Co najmniej raz w roku dla funkcji krytycznych/ważnych	Co najmniej raz na 3 lata (organ może dostosować)
Zakres	Systemy ICT wspierające funkcje krytyczne lub ważne	Funkcje krytyczne w systemach produkcyjnych na żywo, w tym ICT stron trzecich
Podejście	Oceny podatności, Penetration Testing, testy oparte na scenariuszach i inne	Ćwiczenie red team oparte na danych wywiadowczych, naśladujące rzeczywistych aktorów zagrożeń
Świadomość blue team	Zazwyczaj świadomy testowania	Nieświadomy – testowanie prowadzone w tajemnicy
Nadzór regulacyjny	Program testowania udokumentowany i dostępny na żądanie	Zakres zatwierdzony przez właściwy organ; po zakończeniu wydawane jest zaświadczenie

Poziom 1: Roczny Penetration Testing na mocy art. 24 i 25

Podstawowy wymóg testowania dotyczy każdego podmiotu finansowego regulowanego przez DORA, który nie jest mikroprzedsiębiorstwem. Artykuł 24 wymaga od podmiotów finansowych ustanowienia, utrzymywania i przeglądu kompleksowego programu testowania cyfrowej odporności operacyjnej w ramach ram zarządzania ryzykiem ICT.

Artykuł 24 ust. 6 to kluczowa klauzula: podmioty finansowe muszą zapewnić, aby odpowiednie testy były przeprowadzane na wszystkich systemach i aplikacjach ICT wspierających funkcje krytyczne lub ważne co najmniej raz w roku.

Artykuł 25 wymienia następnie rodzaje testów, które powinien obejmować program testowania. Rozporządzenie nie wymaga od każdego podmiotu przeprowadzania każdego rodzaju testu – obowiązuje zasada proporcjonalności – ale przykłady dają jasny obraz tego, czego oczekują organy nadzoru. Obejmują one oceny i skanowanie podatności, analizy otwartego oprogramowania, oceny bezpieczeństwa sieci, analizy luk, przeglądy bezpieczeństwa fizycznego, przeglądy kodu źródłowego (w miarę możliwości), testy oparte na scenariuszach, testy kompatybilności, testy wydajności, testy kompleksowe i Penetration Testing.

Dla większości podmiotów finansowych z istotną infrastrukturą ICT Penetration Testing będzie podstawowym elementem ich rocznego programu. Rozporządzenie jest jasne: musisz wykazać, że Twoje systemy mogą wytrzymać rzeczywiste techniki ataku, a nie tylko, że zostały przeskanowane pod kątem znanych luk w zabezpieczeniach.

Co oznaczają "Funkcje krytyczne lub ważne"

DORA definiuje funkcję krytyczną lub ważną jako funkcję, której zakłócenie w istotny sposób naruszyłoby wyniki finansowe podmiotu finansowego, solidność lub ciągłość jego usług lub jego stałą zgodność z obowiązkami regulacyjnymi. W praktyce obejmuje to Twoją podstawową działalność biznesową: przetwarzanie płatności, platformy transakcyjne, portale dla klientów, systemy podejmowania decyzji kredytowych, platformy zgłaszania roszczeń ubezpieczeniowych, infrastrukturę rozliczeniową i systemy zaplecza, które je wspierają.

Identyfikacja tych funkcji jest pierwszym krokiem w określeniu zakresu Twojego programu testowania. Jeśli system wspiera funkcję krytyczną lub ważną – bezpośrednio lub poprzez zależności – jest on objęty zakresem rocznego testowania.

Proporcjonalność: Skalowanie testów do Twojego profilu ryzyka

DORA wyraźnie uznaje, że nie każdy podmiot finansowy jest takiej samej wielkości lub stoi w obliczu takiego samego profilu ryzyka. Artykuł 4 ust. 2 ustanawia zasadę proporcjonalności: głębokość i częstotliwość testowania powinny być dostosowane do wielkości i złożoności Twojego podmiotu, ogólnego profilu ryzyka, krytyczności testowanych systemów ICT, narażenia poprzez outsourcing lub zależności od chmury, istotnych zmian w infrastrukturze ICT oraz dotkliwości i wyników poprzednich incydentów.

Oznacza to, że od małej firmy fintech z ukierunkowanym produktem i ograniczoną infrastrukturą nie oczekuje się dorównania programowi testowania G-SII (globalnie systemowo ważna instytucja). Ale oznacza to również, że nie możesz używać proporcjonalności jako ogólnej wymówki dla minimalnego testowania. Zasada skaluje głębokość testowania, a nie obowiązek testowania.

Poziom 2: Threat-Led Penetration Testing (TLPT) na mocy art. 26 i 27

Jeśli standardowe testy roczne są podstawą DORA, TLPT jest poziomem zaawansowanym – i jest to zasadniczo inna bestia.

TLPT to pełnowymiarowe ćwiczenie red team oparte na danych wywiadowczych, przeprowadzane na żywo w systemach produkcyjnych, w tajemnicy przed zespołami obronnymi organizacji, naśladujące taktyki, techniki i procedury, których używaliby rzeczywści aktorzy zagrożeń przeciwko podmiotowi. To nie jest skanowanie podatności z fantazyjną nazwą. To kontrolowany cyberatak zaprojektowany w celu sprawdzenia, czy Twoja instytucja – jej technologia, procesy i ludzie – może wytrzymać i wykryć wyrafinowaną, ukierunkowaną intruzję.

TLPT jest obowiązkowe tylko dla niektórych podmiotów finansowych zidentyfikowanych przez ich właściwe organy na podstawie znaczenia systemowego, profilu ryzyka i dojrzałości ICT. Podmioty, które z największym prawdopodobieństwem zostaną wyznaczone, obejmują globalnie systemowo ważne banki (G-SII) i inne instytucje o znaczeniu systemowym (O-SII), największe instytucje płatnicze (przetwarzające łącznie ponad 150 miliardów EUR w transakcjach w każdym z dwóch poprzednich lat), duże firmy ubezpieczeniowe i reasekuracyjne, kontrahenci centralni i centralne depozyty papierów wartościowych oraz główne platformy obrotu.

Jeśli Twój właściwy organ wyznaczy Cię do TLPT, musisz przeprowadzać zaawansowane testy co najmniej raz na trzy lata. Organ może również zwiększyć lub zmniejszyć tę częstotliwość na podstawie Twojego profilu ryzyka i okoliczności operacyjnych.

Jak działa TLPT: Sześć faz

Regulacyjne Standardy Techniczne dotyczące TLPT (rozporządzenie delegowane Komisji UE 2025/1190, opublikowane w czerwcu 2025 r.) definiują ustrukturyzowany proces, który obejmuje kilka odrębnych faz.

Faza przygotowawcza rozpoczyna się, gdy właściwy organ (Twój organ TLPT) powiadamia Twój podmiot o konieczności przeprowadzenia TLPT. Tworzysz zespół kontrolny – małą, zaufaną grupę w Twojej organizacji, która zarządza testem – i identyfikujesz funkcje krytyczne, które mają być przetestowane. Zakres jest następnie przedkładany organowi TLPT do zatwierdzenia.

Faza analizy zagrożeń obejmuje dostawcę analizy zagrożeń, który przygotowuje ukierunkowany raport analizy zagrożeń specyficzny dla Twojej instytucji. Raport ten analizuje aktorów zagrożeń, którzy z największym prawdopodobieństwem wezmą na cel Twój podmiot, ich znane taktyki i techniki oraz scenariusze ataków najbardziej odpowiednie dla Twojego modelu biznesowego, stosu technologicznego i obszaru geograficznego. Te dane wywiadowcze napędzają cały test – zapewniając, że odzwierciedla rzeczywiste zagrożenia, a nie ogólne podręczniki ataków.

Faza testowania red team to wykonanie. Red team – pracując na podstawie analizy zagrożeń – przeprowadza długotrwałą kampanię ofensywną przeciwko Twoim systemom produkcyjnym na żywo. W przeciwieństwie do standardowego pentestingu, test trwa przez dłuższy okres (zazwyczaj od trzech do czterech miesięcy), blue team (Twoi obrońcy) nie jest informowany, a celem jest symulacja prawdziwego zaawansowanego, uporczywego zagrożenia.

Faza zamknięcia obejmuje obowiązkowe ćwiczenie purple teaming, które jest kluczową różnicą w stosunku do poprzednich ram TIBER-EU, gdzie purple teaming było tylko zalecane. Podczas purple teaming red team i blue team współpracują, aby przejść przez scenariusze ataków, przejrzeć, co zostało wykryte, a co pominięte, i wspólnie zidentyfikować ulepszenia. Zapewnia to, że test generuje naukę, a nie tylko ustalenia.

Wreszcie, faza raportowania i naprawy wytwarza dokumentację, która jest przedkładana właściwemu organowi do zatwierdzenia i poświadczenia. Organ potwierdza, że TLPT został przeprowadzony zgodnie z wymogami DORA i wydaje formalne poświadczenie.

TLPT a standardowy Pentesting: Zrozumienie różnicy

Rozróżnienie między TLPT a standardowym Penetration Testing to jedna z najważniejszych koncepcji zgodności z DORA i jedna z najczęściej źle rozumianych.

Standardowy Penetration Test zazwyczaj celuje w określony system lub aplikację – aplikację internetową, API, segment sieci. Trwa od jednego do trzech tygodni. Zespół ds. bezpieczeństwa wie, że się to dzieje. Zakres jest ograniczony i uzgodniony z góry. Tester szuka luk technicznych, próbuje je wykorzystać i tworzy raport z ustaleniami i wskazówkami dotyczącymi naprawy. Jest to ocena techniczna zdefiniowanej powierzchni.

TLPT obejmuje całą organizację. Celuje w krytyczne funkcje biznesowe – a nie w konkretne systemy. Trwa miesiącami, a nie tygodniami. Zespół obronny jest całkowicie nieświadomy. Test jest napędzany przez analizę zagrożeń na zamówienie, a nie ogólną metodologię. Testerzy symulują pełny cykl życia prawdziwego ataku: rozpoznanie, wstępny dostęp, trwałość, ruch boczny, eskalacja uprawnień i eksfiltracja danych lub zakłócenie operacyjne. I testuje nie tylko technologię, ale także ludzi (czy pracownicy dają się nabrać na phishing?) i procesy (czy SOC wykrywa intruzję? Czy plan reagowania na incydenty rzeczywiście działa?).

Pomyśl o tym w ten sposób: pentest pyta "czy ktoś może włamać się do tego pokoju?" TLPT pyta "czy wyrafinowany przeciwnik może dostać się do naszego budynku, znaleźć skarbiec, otworzyć go, zabrać to, czego chce, i wyjść, niepostrzeżenie przez nikogo?"

Zewnętrzni dostawcy ICT: Nie jesteś zwolniony

Jedną z najważniejszych innowacji DORA jest traktowanie ryzyka związanego z zewnętrznymi dostawcami ICT jako problemu systemowego, a nie dwustronnej kwestii umownej. Jeśli jesteś dostawcą chmury, dostawcą SaaS, zarządzaną usługą bezpieczeństwa lub inną firmą technologiczną obsługującą unijne instytucje finansowe, DORA dociera do Ciebie na kilka ważnych sposobów.

Po pierwsze, podmioty finansowe muszą umownie wymagać od swoich zewnętrznych dostawców usług ICT uczestniczenia i współpracy w TLPT, gdy dostawcy ci są objęci zakresem testu. Artykuł 30 ust. 3 lit. d) DORA wyraźnie to stanowi. Jeśli Twoja platforma chmurowa hostuje infrastrukturę przetwarzania płatności banku, a ten bank jest wyznaczony do TLPT, bank musi zapewnić Twój udział w teście – a Ty musisz to ułatwić.

Po drugie, dostawcy ICT uznani za krytycznych dla stabilności sektora finansowego zostaną wyznaczeni jako Krytyczni Zewnętrzni Dostawcy (CTPP) przez Europejskie Urzędy Nadzoru (ESA). CTPP podlegają bezpośredniemu nadzorowi ze strony ESA, w tym szczegółowym wymaganiom dotyczącym testowania bezpieczeństwa, zarządzania ryzykiem i odporności operacyjnej. Oczekuje się, że pierwsza fala wyznaczeń CTPP nastąpi w 2025 r., po ocenach krytyczności przeprowadzonych przez ESA.

Po trzecie, nawet jeśli nie jesteś wyznaczony jako CTPP, DORA szybko staje się filtrem zamówień. Podmioty finansowe oceniające dostawców technologii będą w coraz większym stopniu wymagać dowodów na solidne programy testowania bezpieczeństwa, zdolność do wspierania symulacji prowadzonych przez klientów i gotowość do wspólnych testów operacyjnych. Brak zgodności będzie oznaczał nie tylko ryzyko regulacyjne – będzie oznaczał utratę dostępu do europejskich klientów finansowych.

Jeśli obsługujesz podmioty finansowe regulowane przez UE, praktyczna rada jest prosta: przygotuj się do wspierania wymagań dotyczących testowania DORA swoich klientów, oferuj w razie potrzeby odizolowane środowiska testowe i bądź gotów zademonstrować własną odporność operacyjną poprzez udokumentowane programy testowania.

Kto może przeprowadzać testy?

DORA ustanawia szczegółowe wymagania kwalifikacyjne dla testerów, szczególnie dla TLPT.

Standardowe testowanie (art. 24–25)

W przypadku rocznego programu testowania DORA dopuszcza przeprowadzanie testów przez niezależne zespoły wewnętrzne lub przez wykwalifikowanych dostawców zewnętrznych. Kluczowym wymogiem jest niezależność – testerzy nie mogą mieć konfliktów interesów i nie mogą być żywo zainteresowani wynikami. W przypadku korzystania z wewnętrznych testerów wymagane jest odpowiednie oddzielenie organizacyjne.

Rozporządzenie nie nakazuje szczegółowych certyfikatów dla standardowych testów, ale wymaga, aby testerzy posiadali niezbędne umiejętności i wiedzę fachową. W praktyce właściwe organy oczekują, że testerzy będą posiadali uznane kwalifikacje zawodowe i udokumentowane doświadczenie w rodzajach przeprowadzanych testów.

TLPT (art. 26–27)

W przypadku TLPT wymagania są znacznie bardziej rygorystyczne. Rozporządzenie wymaga, aby testerzy byli jak najbardziej odpowiedni i renomowani, posiadali zdolności techniczne i organizacyjne ze szczególną wiedzą fachową w zakresie analizy zagrożeń, Penetration Testing lub testowania red team, posiadali certyfikat wydany przez jednostkę akredytującą w państwie członkowskim lub przestrzegali formalnych kodeksów postępowania lub ram etycznych, a w przypadku testerów zewnętrznych posiadali ubezpieczenie od odpowiedzialności zawodowej od ryzyka niewłaściwego postępowania.

Istotny niuans: DORA dopuszcza, aby wewnętrzni testerzy przeprowadzali komponent red team TLPT, ale z dwoma krytycznymi ograniczeniami. Analiza zagrożeń musi być zawsze dostarczana przez podmiot zewnętrzny, a co trzeci TLPT musi być przeprowadzany przez zewnętrznego dostawcę red team. W praktyce oznacza to, że nawet jeśli zbudujesz wewnętrzną zdolność red team, będziesz potrzebować zewnętrznych testerów co najmniej raz na trzy cykle TLPT.

Naprawa, raportowanie i poświadczenie

DORA nie traktuje testowania jako samodzielnej działalności – jest ono osadzone w pętli ciągłego doskonalenia. Rozporządzenie wymaga od podmiotów finansowych ustanowienia procedur i polityk w celu ustalania priorytetów, klasyfikowania i naprawiania wszystkich problemów ujawnionych w wyniku testowania oraz zapewnienia pełnego rozwiązania wszystkich zidentyfikowanych luk w zabezpieczeniach i niedociągnięć.

W przypadku standardowych testów rocznych oczekuje się, że program testowania generuje udokumentowane ustalenia, ustalenia te są sortowane według ważności, naprawa jest śledzona i zakończona, a wyniki są przekazywane z powrotem do ram zarządzania ryzykiem ICT. Twoja dokumentacja musi być dostępna dla właściwych organów na żądanie.

W przypadku TLPT wymagania są bardziej formalne. Po zakończeniu testu – w tym obowiązkowego ćwiczenia purple teaming – podmiot finansowy i zewnętrzni testerzy przekazują właściwemu organowi dokumentację potwierdzającą, że TLPT został przeprowadzony zgodnie z wymogami DORA. Właściwy organ zatwierdza tę dokumentację i wydaje poświadczenie. Poświadczenie to może być następnie udostępniane innym właściwym organom w celu umożliwienia wzajemnego uznawania, zmniejszając potrzebę powielania testów w różnych jurysdykcjach.

Mechanizm wzajemnego uznawania jest jedną z najbardziej praktycznych innowacji DORA. Jeśli jesteś instytucją transgraniczną działającą w wielu państwach członkowskich UE, pojedyncze poświadczenie TLPT może spełnić wymogi nadzorcze w różnych jurysdykcjach – co stanowi znaczną poprawę w stosunku do sytuacji sprzed DORA, gdzie oddzielne krajowe ramy testowania wymagały oddzielnych testów.

Kluczowe harmonogramy

Harmonogram ma znaczenie strategiczne. Jeśli jesteś kandydatem do wyznaczenia TLPT, pierwsze powiadomienia spodziewane są w 2026 r. Sześciomiesięczne okno od powiadomienia do złożenia zakresu jest krótkie dla organizacji, które nie położyły podwalin. Rozpocznij mapowanie funkcji, zidentyfikuj lidera zespołu kontrolnego i oceń opcje dostawców zanim otrzymasz pismo.

Budowanie Twojego programu testowania DORA

Niezależnie od tego, czy jesteś średniej wielkości instytucją płatniczą, która buduje program testowania od zera, czy G-SII, który dostosowuje istniejący program do wymogów DORA, oto praktyczne ramy.

Krok 1: Zmapuj swoje funkcje krytyczne i ważne

Zanim cokolwiek przetestujesz, musisz wiedzieć, co jest ważne. Zidentyfikuj wszystkie funkcje, których zakłócenie w istotny sposób naruszyłoby wyniki finansowe Twojego podmiotu, ciągłość usług lub zgodność z przepisami. Następnie zmapuj systemy ICT, aplikacje i zależności od podmiotów trzecich, które wspierają każdą funkcję. To mapowanie staje się podstawą Twojego zakresu testowania i bezpośrednio zasila Twoje ramy zarządzania ryzykiem ICT.

Krok 2: Ustanów program testowania oparty na ryzyku

Zaprojektuj program testowania, który obejmuje wszystkie systemy ICT wspierające funkcje krytyczne lub ważne, obejmuje rodzaje testów wymienione w artykule 25 (dostosowane do Twojego profilu proporcjonalności), działa co najmniej w cyklu rocznym i dostosowuje się w oparciu o istotne zmiany w Twojej infrastrukturze, wyniki poprzednich testów i ewoluujące dane wywiadowcze o zagrożeniach.

Udokumentuj program formalnie. DORA wymaga, aby Twój program testowania był udokumentowany, przeglądany i utrzymywany w ramach ram zarządzania ryzykiem ICT. Dokumentacja ta musi być dostępna dla właściwego organu na żądanie.

Krok 3: Zaangażuj wykwalifikowanych dostawców testów

W przypadku większości podmiotów zewnętrzni dostawcy Penetration Testing dostarczą komponent rocznego testowania. Wybierz dostawców, którzy mają udokumentowane doświadczenie w sektorze finansowym, rozumieją szczegółowe wymagania DORA i mogą tworzyć raporty spełniające oczekiwania regulacyjne. Upewnij się, że umowy o zaangażowanie uwzględniają wymogi dotyczące niezależności, obowiązki w zakresie poufności i proces uzgadniania zakresu.

Jeśli jesteś kandydatem do TLPT, będziesz również musiał zidentyfikować dostawców analizy zagrożeń i dostawców red team, którzy spełniają rygorystyczne kwalifikacje określone w art. 27 i TLPT RTS. Rozpocznij tę ocenę wcześnie – pula wykwalifikowanych dostawców TLPT jest mniejsza niż ogólny rynek pentestingu, a okna harmonogramowania szybko się wypełniają.

Krok 4: Zbuduj pętlę naprawy

Testowanie bez naprawy to wydajność bez celu. Ustanów udokumentowany przepływ pracy, który prowadzi ustalenia od identyfikacji do naprawy i weryfikacji. Klasyfikuj ustalenia według ważności, przypisuj właściciela, określaj ramy czasowe reakcji i śledź zamknięcie. Każda naprawa powinna być zweryfikowana – albo poprzez ponowne testowanie, albo poprzez wdrożenie zatwierdzonej kontroli.

Przekaż wyniki testów z powrotem do ram zarządzania ryzykiem ICT. DORA postrzega testowanie jako jeden wkład w szerszy obraz odporności – a nie jako samodzielne ćwiczenie zgodności.

Krok 5: Przygotuj się do TLPT (jeśli dotyczy)

Jeśli Twój podmiot prawdopodobnie zostanie wyznaczony do TLPT, przygotowania powinny rozpocząć się na długo przed nadejściem powiadomienia. Zidentyfikuj lidera zespołu kontrolnego – osobę wystarczająco starszą, aby zarządzać testem ponad granicami organizacyjnymi, i wystarczająco zaufaną, aby zachować tajemnicę przed blue team. Zmapuj funkcje krytyczne, które prawdopodobnie będą w zakresie. Oceń zależności od podmiotów trzecich, które mogą wymagać uwzględnienia. Przejrzyj swoje ustalenia umowne z dostawcami ICT, aby upewnić się, że obowiązują klauzule uczestnictwa zgodne z DORA.

Typowe błędy w zgodności z testami DORA

Traktowanie testowania jako odhaczenia pola wyboru

Cała filozofia DORA to odporność – a nie teatr zgodności. Organy nadzoru zaprojektowały wymagania dotyczące testowania, aby zapewnić, że podmioty finansowe mogą rzeczywiście wytrzymać cyberataki, a nie tylko tworzyć raporty, które mówią, że próbowały. Jeśli Twój program testowania generuje ustalenia, które nigdy nie zostaną naprawione, obejmuje łatwe systemy, unikając złożonych, lub tworzy raporty, które leżą w szufladzie do następnego audytu, pomijasz sedno i regulator to zauważy.

Mylenie skanowania podatności z Penetration Testing

Artykuł 25 wymienia zarówno oceny i skanowanie podatności, jak i Penetration Testing jako elementy programu testowania. Są to odrębne działania. Zautomatyzowane skanowanie podatności identyfikuje znane słabości na dużą skalę. Penetration Testing obejmuje wykwalifikowanego testera, który aktywnie próbuje wykorzystać te słabości, połączyć je i ocenić rzeczywisty wpływ. Uruchomienie skanowania Nessus i nazwanie go Penetration Testing nie spełni DORA.

Ignorowanie zależności od podmiotów trzecich

Jeśli Twoje funkcje krytyczne zależą od zewnętrznych dostawców ICT – a we współczesnych usługach