Dyrektor IT średniego domu maklerskiego pyta na spotkaniu: „ile nas będzie kosztować TLPT?”. Pytanie jest przedwczesne o cały poziom. Zanim padnie odpowiedź, trzeba sprawdzić, czy organ nadzoru w ogóle wyznaczył ten podmiot do TLPT — bo jeśli nie, pieniądze wydane na test zaawansowany kupią prestiż, a nie zgodność. W drugą stronę działa ten sam błąd: instytucja, która słyszy sześciocyfrowe wyceny TLPT i stwierdza „nas na to nie stać”, często nie robi nic, choć obowiązek programu testowania ciąży na niej niezależnie od TLPT.
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z 14 grudnia 2022 r. (Dz.Urz. UE L 333 z 27.12.2022, s. 1), znane jako DORA, jest stosowane od 17 stycznia 2025 r. (art. 64 akapit drugi). Jego rozdział IV opisuje testowanie w artykułach 24–27 i rozkłada je na dwa poziomy: program testowania obowiązujący prawie wszystkich oraz TLPT dla wąskiej, wyznaczonej grupy. Ten tekst rozdziela oba poziomy i przy każdym twierdzeniu podaje przepis, z którego ono wynika. Szczegóły samego TLPT — metodykę, przygotowanie i przebieg — rozwijamy w osobnych artykułach, do których odsyłamy po drodze.
Czego DORA wymaga od podmiotu finansowego w zakresie testowania?
Ustanowienia i utrzymywania programu, a nie przeprowadzania pojedynczych testów. Art. 24 ust. 1 nakazuje podmiotom finansowym innym niż mikroprzedsiębiorstwa ustanowić i utrzymywać „prawidłowy i kompleksowy program testowania operacyjnej odporności cyfrowej”, stanowiący integralną część ram zarządzania ryzykiem ICT z art. 6, oraz dokonywać przeglądu tego programu.
Program ma cztery cele wymienione wprost w tym samym ustępie: ocenę gotowości do obsługi incydentów ICT, określanie słabości, określanie niedoskonałości i luk oraz niezwłoczne wdrażanie środków naprawczych. To ostatnie jest najczęściej pomijane w praktyce — test, po którym nie idzie naprawa, nie realizuje celu przepisu, choć formalnie się odbył.
Art. 24 ust. 5 domyka pętlę: podmiot ustanawia procedury ustalania hierarchii, klasyfikowania i rozwiązywania wszystkich problemów ujawnionych w testach oraz wewnętrzne metody zatwierdzania potwierdzające, że stwierdzone słabości zostały w pełni usunięte. Sam raport z testu nie jest dowodem zgodności; dowodem jest zamknięty cykl od ustalenia do weryfikacji naprawy.
Kto podlega obowiązkowi testowania, a kto jest z niego zwolniony?
Obowiązek obejmuje wszystkie podmioty finansowe poza mikroprzedsiębiorstwami, a definicja jest ostra i liczbowa. Zgodnie z art. 3 pkt 60 rozporządzenia mikroprzedsiębiorstwo to podmiot finansowy inny niż system obrotu, kontrahent centralny, repozytorium transakcji lub centralny depozyt papierów wartościowych, który zatrudnia mniej niż 10 osób i którego roczny obrót lub bilans roczny nie przekracza 2 mln EUR.
Zwolnienie nie jest zupełne. Art. 25 ust. 3 nakazuje mikroprzedsiębiorstwom przeprowadzać testy z katalogu art. 25 ust. 1, łącząc podejście oparte na analizie ryzyka ze strategicznym planowaniem testowania — z uwzględnieniem równowagi między skalą zasobów a krytycznością zasobów informacyjnych. Znika kompleksowy program, nie znika testowanie.
Skala obowiązku jest natomiast stopniowana zasadą proporcjonalności. Art. 4 ust. 2 nakazuje stosować rozdział IV proporcjonalnie do wielkości podmiotu, jego ogólnego profilu ryzyka oraz charakteru, skali i stopnia złożoności usług i operacji. W praktyce to ten przepis, a nie wielkość budżetu, uzasadnia, dlaczego program mniejszego podmiotu wygląda inaczej niż program banku.
Rozstrzygnięcie na wejściu: dopóki nie wiesz, czy jesteś mikroprzedsiębiorstwem w rozumieniu art. 3 pkt 60, nie wiesz, jaki reżim testowania Cię obowiązuje. To pytanie o dwie liczby z własnego sprawozdania, nie o ocenę dojrzałości.
Jakie testy mieszczą się w katalogu rozporządzenia?
Katalog z art. 25 ust. 1 jest długi i celowo niejednorodny. Rozporządzenie wymienia w nim oceny podatności i skanowanie pod tym kątem, analizy otwartego oprogramowania, oceny bezpieczeństwa sieci, analizy braków, fizyczne kontrole bezpieczeństwa, kwestionariusze i rozwiązania w zakresie oprogramowania skanującego, przeglądy kodu źródłowego — gdy jest to wykonalne — testy scenariuszowe, testy kompatybilności, testy wydajności, testy kompleksowe oraz testy penetracyjne.
Testy penetracyjne są w tym katalogu jedną z kilkunastu pozycji przykładowego wyliczenia („takich jak”), a nie jego streszczeniem. To ma konsekwencję planistyczną: zamówienie jednego pentestu rocznie nie wyczerpuje art. 25, jeśli analiza ryzyka wskazuje, że krytyczne funkcje zależą od kodu, którego nikt nie przeglądał, albo od konfiguracji sieci, której nikt nie ocenił.
Dla dwóch kategorii podmiotów przepis idzie dalej niż katalog. Art. 25 ust. 2 wymaga od centralnych depozytów papierów wartościowych i kontrahentów centralnych przeprowadzania ocen podatności przed każdym wdrożeniem lub przeniesieniem nowych albo istniejących aplikacji, elementów infrastruktury i usług ICT wspierających krytyczne lub istotne funkcje. To wymóg zdarzeniowy, nie kalendarzowy.
Jak często trzeba testować systemy wspierające krytyczne funkcje?
Co najmniej raz w roku — i to jest jedyna twarda kadencja na poziomie podstawowym. Art. 24 ust. 6 nakazuje podmiotom innym niż mikroprzedsiębiorstwa zapewnić co najmniej raz w roku przeprowadzenie odpowiednich testów wszystkich systemów i aplikacji ICT wspierających krytyczne lub istotne funkcje.
Dwa słowa w tym przepisie decydują o kosztach. „Wszystkich” oznacza, że mianownikiem jest inwentarz systemów wspierających funkcje krytyczne, a nie lista tych, które akurat zmieniano. „Odpowiednich” oznacza, że dobór testu do systemu wynika z analizy ryzyka — i tu wraca cały katalog z art. 25 ust. 1, a nie jedna metoda dla wszystkiego.
TLPT ma własny zegar, niezależny od tego rocznego. Art. 26 ust. 1 wymaga przeprowadzania zaawansowanych testów nie rzadziej niż co trzy lata, z zastrzeżeniem, że właściwy organ może — w oparciu o profil ryzyka podmiotu i okoliczności operacyjne — zwrócić się o zmniejszenie lub zwiększenie tej częstotliwości.
Kto może wykonać test i co znaczy „niezależny tester”?
Niezależna strona wewnętrzna albo zewnętrzna — art. 24 ust. 4 dopuszcza oba warianty na poziomie podstawowym. Przy testerze wewnętrznym przepis stawia dwa warunki: podmiot przeznacza wystarczające zasoby oraz zapewnia unikanie konfliktów interesów na wszystkich etapach projektowania i wykonywania testu.
Konflikt interesów jest tu pojęciem szerszym niż „nie testuj własnego kodu”. Dotyczy także etapu projektowania testu, czyli momentu, w którym ustala się zakres. Zespół, który sam decyduje, czego nie obejmie testem, i sam odpowiada za bezpieczeństwo tego obszaru, spełnia literę wymogu tylko na papierze.
Na poziomie TLPT rozporządzenie zaostrza regułę arytmetycznie. Art. 26 ust. 8 nakazuje podmiotom korzystającym z testerów wewnętrznych zlecać co trzeci test testerom zewnętrznym, a instytucje kredytowe sklasyfikowane jako istotne zgodnie z art. 6 ust. 4 rozporządzenia (UE) nr 1024/2013 mogą korzystać wyłącznie z testerów zewnętrznych spełniających warunki art. 27 ust. 1 lit. a)–e).
Czym TLPT różni się od testu penetracyjnego z artykułu 25?
Zakresem, sceną i tym, kto zatwierdza. Art. 26 ust. 2 wymaga, by test penetracyjny pod kątem wyszukiwania zagrożeń obejmował kilka krytycznych lub istotnych funkcji podmiotu albo wszystkie te funkcje i był przeprowadzany na działających systemach produkcyjnych wspierających te funkcje. Wynik oceny, które funkcje objąć testem, wyznacza dokładny zakres TLPT i podlega zatwierdzeniu przez właściwe organy.
Test z katalogu art. 25 tych trzech cech nie ma. Jego zakresem bywa pojedyncza aplikacja, sceną — najczęściej środowisko testowe lub przedprodukcyjne, a zakres ustala sam podmiot w ramach swojego programu. Różnica nie polega więc na „głębokości” testu, tylko na tym, czym test jest w porządku prawnym: narzędziem programu albo odrębnym obowiązkiem pod nadzorem organu.
Metodykę TLPT, sposób budowania scenariuszy i warstwę wywiadowczą opisujemy szczegółowo w artykule o testach TLPT opartych na wywiadzie cybernetycznym. Tutaj interesuje nas wyłącznie granica między poziomami.
Kto naprawdę musi przeprowadzić TLPT?
Podmioty wyznaczone przez organ, a od 2025 r. wiadomo, kto trafia na tę listę domyślnie. Art. 26 ust. 8 akapit trzeci pozostawiał wyznaczenie właściwym organom, wskazując trzy grupy kryteriów: czynniki związane z wpływem na sektor finansowy, obawy o stabilność finansową oraz profil ryzyka ICT i poziom zaawansowania technologicznego podmiotu.
Doprecyzowało to rozporządzenie delegowane Komisji (UE) 2025/1190 z 13 lutego 2025 r. (Dz.Urz. UE seria L, 2025/1190 z 18.6.2025). Jego art. 2 ust. 2 wymienia podmioty, od których organ wymaga TLPT, o ile ocena profilu ryzyka nie wskaże inaczej: globalne i inne instytucje o znaczeniu systemowym oraz podmioty wchodzące w ich skład, instytucje płatnicze z wartością transakcji powyżej 150 mld EUR w każdym z dwóch poprzedzających lat, instytucje pieniądza elektronicznego powyżej tego samego progu albo powyżej 40 mld EUR pieniądza elektronicznego w obiegu, centralne depozyty papierów wartościowych, kontrahentów centralnych, największe systemy obrotu oraz zakłady ubezpieczeń spełniające łącznie kryteria składki, rezerw i udziału w aktywach rynku.
Progi z listy ubezpieczeniowej pokazują skalę odcięcia: składka przypisana brutto powyżej 1,5 mld EUR, rezerwy techniczno-ubezpieczeniowe powyżej 10 mld EUR oraz — dla zakładów życiowych i mieszanych — aktywa przekraczające 3,5 % aktywów wszystkich zakładów w danym państwie członkowskim. Podmiot, który nie zbliża się do tych rzędów wielkości, prawie na pewno nie jest adresatem TLPT. Praktyczne przygotowanie dla tych, którzy są, opisujemy w tym samym artykule o testach TLPT, w części o przygotowaniu do testu.
Kolejność, która oszczędza pieniądze: najpierw przyłóż własne liczby do art. 2 ust. 2 rozporządzenia 2025/1190, potem policz koszt testu. Odwrotna kolejność kosztuje albo niepotrzebny test, albo rok zwłoki w budowaniu programu, który i tak jest obowiązkowy.
Ile trwa TLPT, jeśli policzyć terminy z rozporządzenia delegowanego?
Jedynym twardym minimum w całym procesie jest 12 tygodni aktywnego testu. Art. 11 ust. 5 rozporządzenia 2025/1190 wymaga, by czas trwania etapu aktywnego testowania z udziałem zespołu typu red team był proporcjonalny do zakresu i złożoności testu, „a w każdym przypadku trwa co najmniej 12 tygodni”. Pozostałe terminy w tym akcie są maksymalne — wyznaczają najpóźniejszy dopuszczalny moment, a nie najwcześniejszy.
Zsumowane dają jednak realistyczny obraz kalendarza. Od powiadomienia organu podmiot ma 3 miesiące na kartę projektu i 6 miesięcy na dokument określający zakres (art. 9 ust. 2 i 6). Po zakończeniu aktywnego testu testerzy mają 4 tygodnie na sprawozdanie zespołu red team, zespół blue team — 10 tygodni na własne sprawozdanie i odtworzenie działań, podmiot — 8 tygodni na sprawozdanie podsumowujące (art. 12 ust. 2, 4, 5 i 7) oraz kolejne 8 tygodni na plan naprawczy (art. 13 ust. 1).
Przy pełnym wykorzystaniu tych terminów, od powiadomienia do złożenia planu naprawczego mija około piętnastu miesięcy — i to bez wliczenia etapu analizy zagrożeń, który własnego terminu nie ma. Liczba jest sumą przepisów, nie szacunkiem rynkowym; każdy jej składnik da się sprawdzić w tekście rozporządzenia.
Czego DORA wymaga od firmy, która ma przeprowadzić TLPT?
Pięciu rzeczy naraz, wyliczonych w art. 27 ust. 1 rozporządzenia 2022/2554. Testerzy mają być najbardziej odpowiedni do zadania i cieszyć się największą renomą, posiadać zdolności techniczne i organizacyjne oraz wykazać szczególną wiedzę w zakresie analizy zagrożeń, testów penetracyjnych i testów z udziałem zespołów typu red team.
Trzy pozostałe wymogi są formalne i to one najczęściej rozstrzygają przetarg: certyfikat wydany przez jednostkę akredytującą w państwie członkowskim albo przystąpienie do formalnych kodeksów postępowania lub ram etycznych, niezależne zapewnienie lub sprawozdanie z audytu dotyczące zarządzania ryzykiem przy TLPT, a także pełne ubezpieczenie od odpowiedzialności cywilnej z tytułu wykonywania zawodu, obejmujące ryzyko uchybień i zaniedbań.
Rozporządzenie delegowane dokłada do tego próg doświadczenia liczony w referencjach. Art. 7 ust. 1 wymaga, by dostawca analizy zagrożeń przedstawił co najmniej trzy rekomendacje z wcześniejszych zadań, a testerzy zewnętrzni — co najmniej pięć. Rolę certyfikacji i kompetencji zespołu po stronie wykonawcy omawiamy w tym samym artykule o testach TLPT, w części o umiejętnościach zespołu testującego.
Jak w zakres testów wchodzą zewnętrzni dostawcy usług ICT?
Wchodzą wtedy, gdy obsługują funkcje objęte zakresem — i to podmiot finansowy odpowiada za ich udział. Art. 26 ust. 3 nakazuje stosować niezbędne środki i zabezpieczenia zapewniające udział zewnętrznych dostawców usług ICT w TLPT, przy czym podmiot finansowy „przez cały czas ponosi pełną odpowiedzialność za zapewnianie zgodności z niniejszym rozporządzeniem”.
Rozporządzenie przewiduje wentyl dla sytuacji, w której taki udział zaszkodziłby innym klientom dostawcy. Art. 26 ust. 4 dopuszcza pisemne uzgodnienie, że dostawca zawrze umowę bezpośrednio z testerem zewnętrznym i przeprowadzone zostanie testowanie zbiorcze kilku podmiotów finansowych pod kierownictwem jednego z nich. Takie testowanie uznaje się za TLPT przeprowadzone przez każdy uczestniczący podmiot.
Konsekwencja umowna jest prosta i warto ją wyciągnąć przed podpisaniem kontraktu, nie po wyznaczeniu do TLPT: umowa z dostawcą usług ICT wspierających funkcje krytyczne powinna z góry przewidywać jego udział w testach. Dopisywanie tego aneksem pod presją terminu organu jest najdroższym możliwym momentem na negocjacje.
Od czego zacząć w zależności od kategorii podmiotu?
Od jednoznacznego ustalenia własnej kategorii, bo każda z nich prowadzi do innego pierwszego kroku. Poniższa mapa łączy trzy rzeczy, które w rozporządzeniu leżą w różnych miejscach: status podmiotu, wymagane działanie i przepis, z którego ono wynika.
| Kategoria podmiotu | Pierwszy krok | Podstawa |
|---|---|---|
| Mikroprzedsiębiorstwo (art. 3 pkt 60) | Dobór testów z katalogu w oparciu o analizę ryzyka, bez kompleksowego programu | art. 25 ust. 1 i 3 |
| Podmiot inny niż mikroprzedsiębiorstwo, nie objęty TLPT | Program testowania + inwentarz systemów wspierających funkcje krytyczne + kadencja roczna | art. 24 ust. 1 i 6 |
| CDPW i kontrahent centralny | Powyższe plus ocena podatności przed każdym wdrożeniem i przeniesieniem | art. 25 ust. 2 |
| Podmiot z listy domyślnej RTS | Przygotowanie zespołu control team i dokumentu zakresu, zanim przyjdzie powiadomienie | art. 26 ust. 2, art. 9 rozp. 2025/1190 |
| Istotna instytucja kredytowa | Jak wyżej, z założeniem wyłącznie testerów zewnętrznych | art. 26 ust. 8 akapit drugi |
Trzeci wiersz od dołu jest tym, na którym najczęściej traci się czas. Podmiot z listy domyślnej nie ma powodu czekać na powiadomienie: dokument określający zakres wymaga zatwierdzenia przez organ zarządzający (art. 9 ust. 6 rozporządzenia 2025/1190), a więc przejścia przez cykl decyzyjny, którego nie da się skrócić poleceniem. Sześciomiesięczny termin liczony od powiadomienia jest komfortowy dla tych, którzy mają gotowy inwentarz funkcji krytycznych, i bardzo ciasny dla reszty.
Warto też odnotować rzecz, która w polskich opracowaniach pojawia się rzadko: ramy TIBER-EU, na których oparto rozporządzenie delegowane (motyw 1), zostały opublikowane przez EBC w maju 2018 r. i zaktualizowane w 2024 r. pod kątem zgodności ze standardami TLPT. Na liście jurysdykcji, które je przyjęły, Polska nie figuruje — stan odczytu strony EBC na 18 września 2026 r. Nie zwalnia to z niczego, bo obowiązek płynie z rozporządzenia, a nie z TIBER-EU, ale oznacza, że polski podmiot sięga po ramy TIBER-EU jako punkt odniesienia, a nie jako krajowy tryb postępowania.
Pułapka, którą widujemy najczęściej: program testowania budowany od narzędzia, nie od inwentarza. Lista systemów wspierających krytyczne lub istotne funkcje jest mianownikiem rocznego obowiązku z art. 24 ust. 6 i zakresu TLPT z art. 26 ust. 2 jednocześnie. Dopóki jej nie ma, żadna z tych dwóch rzeczy nie jest policzalna — ani przez podmiot, ani przez organ.
Jeżeli ustalenie własnej kategorii i zbudowanie mianownika jest dziś pracą, której nie ma kto wykonać, zaczynamy od niej w ramach audytu gotowości i zgodności z DORA. Kolejność jest zawsze ta sama: najpierw inwentarz i kategoria, potem dobór testów, a TLPT — dopiero gdy przepis albo organ tego wymagają.
Najczęściej zadawane pytania
Czy DORA wymaga testów penetracyjnych od każdego podmiotu finansowego?
Nie wprost. Art. 24 ust. 1 rozporządzenia (UE) 2022/2554 nakłada na podmioty finansowe inne niż mikroprzedsiębiorstwa obowiązek ustanowienia programu testowania operacyjnej odporności cyfrowej, a art. 25 ust. 1 wymienia testy penetracyjne jako jedną z pozycji katalogu narzędzi tego programu — obok ocen podatności, przeglądów kodu źródłowego czy testów scenariuszowych. Dobór narzędzi jest oparty na analizie ryzyka, więc to podmiot uzasadnia, dlaczego akurat te testy pokrywają jego ryzyko.
Kto musi przeprowadzać TLPT zgodnie z DORA?
Podmioty wyznaczone przez organ do spraw TLPT na podstawie art. 26 ust. 8 akapit trzeci rozporządzenia (UE) 2022/2554. Rozporządzenie delegowane Komisji (UE) 2025/1190 doprecyzowało to w art. 2 ust. 2: domyślnie obowiązek obejmuje m.in. globalne i inne instytucje o znaczeniu systemowym, instytucje płatnicze i pieniądza elektronicznego powyżej 150 mld EUR wartości transakcji rocznie, centralne depozyty papierów wartościowych, kontrahentów centralnych oraz największe zakłady ubezpieczeń. Organ może zwolnić podmiot z tej listy po ocenie jego profilu ryzyka.
Jak często trzeba testować systemy ICT według DORA?
Art. 24 ust. 6 rozporządzenia (UE) 2022/2554 wymaga co najmniej raz w roku odpowiednich testów wszystkich systemów i aplikacji ICT wspierających krytyczne lub istotne funkcje. TLPT ma własną kadencję: nie rzadziej niż co trzy lata (art. 26 ust. 1), przy czym właściwy organ może tę częstotliwość zmniejszyć albo zwiększyć w oparciu o profil ryzyka podmiotu i okoliczności operacyjne.
Czy test penetracyjny może wykonać zespół wewnętrzny?
Tak, przy zachowaniu warunków. Art. 24 ust. 4 rozporządzenia (UE) 2022/2554 dopuszcza niezależne strony wewnętrzne lub zewnętrzne, wymagając od podmiotu przeznaczenia wystarczających zasobów i unikania konfliktów interesów na wszystkich etapach testu. Przy TLPT reguła jest ostrzejsza: co trzeci test zleca się testerom zewnętrznym (art. 26 ust. 8), a istotne instytucje kredytowe korzystają wyłącznie z testerów zewnętrznych.
Czym TLPT różni się od zwykłego testu penetracyjnego?
Zakresem, sceną i nadzorem. TLPT obejmuje kilka krytycznych lub istotnych funkcji albo wszystkie i jest prowadzony na działających systemach produkcyjnych, a jego zakres podlega zatwierdzeniu przez właściwe organy (art. 26 ust. 2 rozporządzenia (UE) 2022/2554). Zwykły test penetracyjny z katalogu art. 25 ust. 1 jest narzędziem, którego zakres i harmonogram ustala sam podmiot w ramach własnego programu testowania.
