DORA: testy odporności cyfrowej TLPT i scenariusze...

Rozmawiałem w tym roku z trzema prezesami instytucji finansowych. Każdy z nich w momencie wejścia rozporządzenia DORA w życie — 17 stycznia 2025 roku — zadał mi to samo pytanie: “Słyszałem o TLPT, ale co to tak naprawdę jest i czy nas to dotyczy?” Odpowiedź na to pytanie ma konkretne konsekwencje finansowe, operacyjne i reputacyjne. Pomyłka w ocenie własnego statusu kosztuje — zarówno w przypadku, gdy instytucja nie przeprowadzi wymaganego testu, jak i gdy zleci go nieuprawionemu dostawcy.

Threat-Led Penetration Testing (TLPT) to jedno z najbardziej wymagających i zarazem najbardziej wartościowych narzędzi, jakie DORA wprowadza do arsenału zarządzania odpornością cyfrową. W odróżnieniu od tradycyjnego pentestingu, test TLPT to zaawansowana, kilkumiesięczna operacja wywiadowcza i techniczna, która symuluje działanie rzeczywistych grup APT (Advanced Persistent Threat) ukierunkowanych właśnie na Twoją instytucję. Stawką jest sprawdzenie, czy Twoje systemy obrony — ludzie, procesy, technologia — są w stanie wykryć i powstrzymać atakujących, zanim wyrządzą oni realną szkodę.

Ten artykuł to praktyczny przewodnik dla CISO, Dyrektorów Ryzyka i Zarządów instytucji finansowych. Wyjaśniamy, czym jest TLPT, kogo dotyczy, jak przebiega i ile kosztuje — a przede wszystkim, jak skutecznie się do niego przygotować. Po prawie roku obowiązywania DORA widzimy wyraźnie, które instytucje podeszły do tego tematu strategicznie, a które wciąż traktują TLPT jako odległy problem regulacyjny. Różnica w gotowości jest ogromna — i coraz bardziej widoczna dla organów nadzorczych.

Czym są testy TLPT i czym różnią się od zwykłych pentestów?

Threat-Led Penetration Testing (TLPT) to specyficzna klasa testów bezpieczeństwa, w której scenariusze ataku nie są definiowane przez testerów, lecz przez aktualną, spersonalizowaną analizę wywiadu o zagrożeniach (threat intelligence). Innymi słowy, zanim ktokolwiek tknie Twoje systemy techniczne, najpierw przez kilka tygodni zbierana i analizowana jest wiedza o tym, jakie grupy cyberprzestępcze faktycznie atakują instytucje Twojego typu, jakimi technikami, narzędziami i procedurami (TTP) się posługują, i które Twoje aktywa byłyby dla nich najbardziej atrakcyjne.

Zwykły pentest to przede wszystkim weryfikacja techniczna: tester przegląda podatności, próbuje je wykorzystać i raportuje znaleziska. To cenne ćwiczenie, ale ma ograniczone zastosowanie do oceny odporności na zaawansowane, ukierunkowane ataki. Nowoczesny pentest sprawdza, czy masz niezaktualizowane oprogramowanie lub błędnie skonfigurowane serwisy. TLPT sprawdza, czy przeżyjesz atak grupy APT, która przez trzy miesiące systematycznie penetruje Twoje zabezpieczenia, zanim ktokolwiek w Twojej organizacji zorientuje się, że jest obserwowana.

Kluczowe różnice są cztery. Po pierwsze, zakres: TLPT obejmuje środowisko produkcyjne i realne funkcje krytyczne instytucji, nie środowiska testowe. Po drugie, metodyka: test jest oparty na aktualnym, spersonalizowanym raporcie threat intelligence przygotowanym przez wyspecjalizowanego dostawcę TI (Threat Intelligence Provider). Po trzecie, czas trwania: pełny cykl TLPT trwa od 3 do 12 miesięcy, podczas gdy typowy pentest zamyka się w tygodniach. Po czwarte, nadzór: test jest prowadzony pod nadzorem organu regulacyjnego (KNF w Polsce) i może być uznany przez inne właściwe organy unijne w ramach mechanizmu wzajemnego uznawania.

Warto przy tym podkreślić, że TLPT nie zastępuje regularnych testów penetracyjnych wymaganych przez DORA dla wszystkich podmiotów finansowych. Art. 25 DORA nakłada na wszystkie instytucje obowiązek prowadzenia programu testowania obejmującego m.in. testy podatności, testy open-source i oceny bezpieczeństwa sieci. TLPT z art. 26 to najwyższy, najtrudniejszy poziom tej piramidy testowania — zarezerwowany dla instytucji o największym znaczeniu systemowym.

📚 Przeczytaj kompletny przewodnik: Testy Penetracyjne: Testy penetracyjne — rodzaje, metodologie, przebieg

📚 Przeczytaj kompletny przewodnik: DORA: DORA - rozporządzenie o cyfrowej odporności operacyjnej dla sektora finansowego

Które instytucje finansowe muszą przeprowadzać TLPT?

DORA nie nakłada obowiązku przeprowadzania TLPT na wszystkie objęte rozporządzeniem podmioty. To kluczowe rozróżnienie, które wiele instytucji nieprawidłowo interpretuje. Artykuł 26 DORA wskazuje, że TLPT jest wymagany dla znaczących podmiotów finansowych — ale co to dokładnie oznacza, zależy od decyzji właściwego organu nadzorczego każdego kraju członkowskiego.

Właściwy organ (w Polsce: KNF) ma prawo wyznaczyć, które instytucje podlegają obowiązkowi TLPT, biorąc pod uwagę trzy kryteria: dojrzałość ICT instytucji, istotność dla stabilności finansowej systemu oraz profil ryzyka cybernetycznego. W praktyce oznacza to, że TLPT będzie obowiązywał przede wszystkim duże banki i ubezpieczycieli, operatorów systemów płatności o kluczowym znaczeniu systemowym, największe firmy inwestycyjne, dostawców infrastruktury krytycznej dla sektora finansowego oraz inne podmioty, które KNF uzna za istotne z perspektywy ryzyka systemowego.

Rozporządzenie delegowane Komisji Europejskiej dotyczące TLPT (RTS on TLPT) precyzuje szczegółowe kryteria kwalifikacyjne. Instytucje są oceniane pod kątem systemowego znaczenia dla stabilności finansowej, złożoności infrastruktury ICT, historii incydentów i profilu zagrożeń, a także gotowości organizacyjnej do przeprowadzenia i obsługi testu tej skali. Organ nadzorczy może prowadzić dialog z instytucją przed formalnym wyznaczeniem jej do TLPT — i warto aktywnie uczestniczyć w tym dialogu.

Nawet jeśli Twoja instytucja nie jest dziś wyznaczona jako objęta obowiązkiem TLPT, warto zapoznać się z tym wymogiem z dwóch powodów. Pierwszy to kwestia przyszłości: KNF może rozszerzyć listę podmiotów obowiązanych wraz z rosnącą dojrzałością rynku. Drugi to kwestia dobrowolności i wartości: TLPT to po prostu jedno z najskuteczniejszych ćwiczeń odporności, jakie można przeprowadzić — i wiele instytucji przeprowadza je z własnej inicjatywy, nawet bez regulacyjnego nakazu.

Instytucje wyznaczone przez właściwy organ mają obowiązek przeprowadzać TLPT co najmniej raz na trzy lata. Wyniki testu, wraz z planem naprawczym, muszą zostać przekazane organowi nadzorczemu. Co istotne, właściwy organ może zażądać przeprowadzenia TLPT poza regularnym harmonogramem — na przykład po poważnym incydencie cybernetycznym.

Jak wygląda framework TIBER-EU, na którym opiera się TLPT w DORA?

TIBER-EU (Threat Intelligence-Based Ethical Red Teaming for the European Union) to framework opracowany przez Europejski Bank Centralny we współpracy z krajowymi bankami centralnymi, na którym w pełni bazuje metodyka TLPT opisana w DORA. Zrozumienie struktury TIBER-EU jest kluczowe dla każdej instytucji przygotowującej się do testu.

Framework TIBER-EU dzieli test na trzy główne fazy. Pierwsza faza to przygotowanie: obejmuje zaangażowanie organu nadzorczego lub banku centralnego, powołanie Białego Zespołu (White Team) wewnątrz instytucji, który zarządza testem i komunikuje się z zewnętrznymi dostawcami, a także wybór i kontraktowanie dostawców — zarówno dostawcy wywiadu o zagrożeniach (TIBER Threat Intelligence Provider), jak i zewnętrznego Red Teamu. Faza ta kończy się formalnym uruchomieniem testu i podpisaniem umów o zakresie i odpowiedzialności.

Druga faza to testowanie: najpierw dostawca TI przeprowadza ukierunkowaną analizę wywiadu i dostarcza Targeted Threat Intelligence Report (TTIR) — dokument, który szczegółowo opisuje, jakie grupy APT realnie zagrażają danej instytucji i jakich TTP używają. Na podstawie TTIR Red Team opracowuje scenariusze ataku, które następnie realizuje w środowisku produkcyjnym. Red Team działa jak prawdziwy przeciwnik — po cichu, wytrwale, metodycznie.

Trzecia faza to zamknięcie: obejmuje formalny debriefing (tzw. purple teaming), w którym Red Team i Blue Team instytucji razem analizują przebieg operacji, wymiana wiedzy i doświadczeń, opracowanie raportu końcowego i planu naprawczego (remediation plan), a następnie przekazanie raportu do właściwego organu nadzorczego. Co ważne, jeśli test został przeprowadzony w pełnej zgodności z TIBER-EU, może on zostać wzajemnie uznany przez właściwe organy innych państw UE — co ma ogromne znaczenie dla grup finansowych działających w wielu krajach.

Framework TIBER-EU jest dziś wdrożony lub wdrażany w ponad dwudziestu krajach europejskich, w tym w Polsce (TIBER-PL koordynowany przez NBP). Ta szeroka adaptacja oznacza, że rynek dostawców TIBER-EU dojrzewa, rosną kompetencje regulatorów, a mechanizm wzajemnego uznawania testów staje się coraz bardziej operacyjny. Dla polskich instytucji finansowych o charakterze transgranicznym to konkretna korzyść: test przeprowadzony raz — uznany wielokrotnie.

Jak wybrać dostawcę testów TLPT — wymogi kompetencyjne?

Wybór odpowiedniego dostawcy jest jedną z najważniejszych decyzji w całym procesie TLPT i jednocześnie jednym z obszarów, gdzie instytucje popełniają największe błędy. DORA i framework TIBER-EU stawiają dostawcom konkretne, wysokie wymagania kompetencyjne — i nie wszystkie firmy oferujące “pentesty” lub “red teaming” je spełniają.

W zakresie dostawcy wywiadu o zagrożeniach (TI Provider) wymagane jest udokumentowane doświadczenie w zakresie analizy APT ukierunkowanych na sektor finansowy, zdolność do przeprowadzenia ukierunkowanej analizy Open Source Intelligence (OSINT), Dark Web Intelligence oraz Human Intelligence (HUMINT), możliwość dostarczenia formalnego raportu TTIR zgodnego z metodologią TIBER-EU, a także poufność operacyjna — dostawca TI nie może mieć dostępu do wiedzy o zakresie testu, który będzie prowadził Red Team.

W zakresie dostawcy Red Teamu wymagane jest posiadanie doświadczenia w zaawansowanych, długotrwałych operacjach red team (minimum kilkudziesiąt operacji w środowiskach produkcyjnych), zdolność do realizacji całego łańcucha ataku MITRE ATT&CK (od rozpoznania po eksfiltrację), doświadczenie specyficzne dla sektora finansowego (systemy SWIFT, płatnicze, bankowe core systemy), udokumentowane procesy bezpieczeństwa operacyjnego (OPSEC), które eliminują ryzyko przypadkowego zakłócenia produkcji, oraz certyfikaty i doświadczenie na poziomie CREST STAR lub ekwiwalentnym.

Warto też zwrócić uwagę na aspekt niezależności: dostawca Red Teamu nie może być tą samą firmą, która przeprowadza regularny audyt bezpieczeństwa Twojej instytucji lub świadczy usługi zarządzanego bezpieczeństwa (MSSP). Brak niezależności podważa wiarygodność wyników i może być zakwestionowany przez organ nadzorczy. Przed zawarciem umowy z dostawcą warto sprawdzić, czy właściwy organ (KNF) prowadzi rejestr lub wydaje wytyczne dotyczące kwalifikowanych dostawców TIBER-EU/TLPT — praktyki różnią się w zależności od kraju.

Dobrą praktyką jest przeprowadzenie procesu RFP (Request for Proposal) z udziałem co najmniej trzech dostawców i oceną propozycji nie tylko pod kątem ceny, ale przede wszystkim pod kątem głębokości rozumienia Twojego sektora, jakości referencji z podobnych projektów oraz dojrzałości procesów OPSEC. Referencje od innych instytucji finansowych są tu nieocenione — popytaj rynek, zanim podpiszesz umowę. Zła decyzja o wyborze dostawcy TLPT to strata kilku miesięcy i kilkuset tysięcy złotych bez wartościowych rezultatów.

Jak przebiega test TLPT od przygotowania do raportu?

Pełen cykl TLPT jest złożoną operacją, której zrozumienie pozwala znacznie lepiej zarządzać projektem i unikać typowych pułapek. Poniżej opisujemy poszczególne etapy w sposób operacyjny — tak, jak faktycznie wyglądają z perspektywy instytucji finansowej.

Etap 1: Faza przygotowawcza (4-8 tygodni). Instytucja powołuje Biały Zespół (White Team) złożony z wewnętrznych ekspertów, zwykle CISO, Dyrektora Ryzyka ICT i wybranego prawnika. Biały Zespół jest jedyną grupą wewnątrz organizacji, która wie, że test jest przeprowadzany — Blue Team (zespół bezpieczeństwa SOC) musi działać bez tej wiedzy, bo tylko wtedy test ma wartość pomiarową. Instytucja formalizuje zakres, definiuje Critical Functions i Critical Assets, które będą objęte testem, oraz zawiera umowy z obydwoma dostawcami.

Etap 2: Faza wywiadu i opracowania scenariuszy (6-10 tygodni). Dostawca TI prowadzi ukierunkowaną analizę i dostarcza raport TTIR. Ten dokument jest niejawny i przekazywany wyłącznie Red Teamowi, nie Białemu Zespołowi instytucji. Na podstawie TTIR Red Team opracowuje 2-3 realistyczne scenariusze ataku (Generic Threat Scenarios dostosowane do specyfiki instytucji) i przedstawia je Białemu Zespołowi do formalnego zatwierdzenia zakresu.

Etap 3: Faza testowania (8-16 tygodni). Red Team przeprowadza operację symulowanego ataku. Faza ta obejmuje rozpoznanie i zbieranie informacji (passive i active reconnaissance), próby uzyskania pierwszego dostępu (initial access) różnymi technikami — w tym spear phishing, ataki na aplikacje webowe i eksploitację podatności — lateral movement wewnątrz sieci, eskalację uprawnień, dotarcie do zdefiniowanych Critical Assets i udokumentowaną symulację eksfiltracji lub zakłócenia. Red Team dokumentuje każdy krok operacji z precyzją wymaganą do późniejszego formalnego raportu.

Etap 4: Zamknięcie i Purple Teaming (2-4 tygodnie). Po zakończeniu fazy testowania odbywa się formalne ujawnienie (disclosure): Blue Team poznaje fakty dotyczące operacji. Następuje tzw. Purple Teaming — wspólna analiza Red Teamu i Blue Teamu, podczas której omawiane są każde działania atakujących i odpowiedzi (lub brak odpowiedzi) obrońców. Rezultatem jest precyzyjna mapa tego, co działało, co nie działało, jakie luki detekcyjne należy uzupełnić i jakie środki zaradcze wdrożyć. Finalny raport trafia do organu nadzorczego.

Wartość Purple Teamingu jest często niedoceniana przez instytucje przystępujące do TLPT po raz pierwszy. To właśnie w tej fazie generowana jest największa część wiedzy operacyjnej: Blue Team dowiaduje się, jakie techniki ataku były dla nich niewidoczne, które alerty były wyzwalane, ale ignorowane, i które luki detekcyjne wymagają pilnego wypełnienia. Ta wiedza bezpośrednio przekłada się na konkretny plan ulepszeń dla SOC — i właśnie dlatego wiele instytucji po pierwszym TLPT znacząco podnosi swoje inwestycje w wykrywanie zagrożeń.

Jak threat intelligence zasila scenariusze TLPT?

Threat intelligence jest sercem całego procesu TLPT — i to właśnie tutaj leży fundamentalna przewaga tej metodyki nad tradycyjnym pentestingiem. Zrozumienie, jak TI jest zbierane i wykorzystywane, pozwala lepiej ocenić jakość potencjalnego dostawcy i wartość całego ćwiczenia.

Ukierunkowana analiza wywiadu dla konkretnej instytucji finansowej obejmuje kilka warstw. OSINT (Open Source Intelligence) to analiza publicznych źródeł: ofert pracy Twojej instytucji (które ujawniają używane technologie), wycieków danych i loginów w serwisach takich jak Have I Been Pwned, aktywności pracowników w mediach społecznościowych, a także historycznych danych o incydentach zgłoszonych przez podobne instytucje. Dark Web Intelligence obejmuje monitoring forów przestępczych pod kątem dyskusji o Twojej instytucji, sprzedaży dostępu do Twoich systemów, wynajętych ofertach ataków i skradzionych danych.

Analiza TTP grup APT to najcenniejszy element raportu TTIR. Dostawca TI identyfikuje, które grupy APT aktywnie atakują sektor finansowy w Twojej jurysdykcji lub podobne instytucje na świecie, i mapuje ich techniki na framework MITRE ATT&CK. Dla instytucji finansowej w Polsce będzie to oznaczało analizę grup takich jak Lazarus Group (atakujący systemy SWIFT), FIN7, Carbanak i innych grup ukierunkowanych na sektor bankowy. Analiza obejmuje nie tylko historyczne TTP, ale też aktualne kampanie — co sprawia, że raport TTIR ma krótką “datę ważności” i powinien być przygotowywany bezpośrednio przed startem fazy testowania.

Finalny raport TTIR nie jest ogólną analizą trendów, którą można kupić od dostawcy threat intelligence za subskrypcję. To spersonalizowany dokument, który opisuje, co realnie grozi konkretnej instytucji, biorąc pod uwagę jej infrastrukturę technologiczną, profil pracowników, relacje z dostawcami i specyficzną ekspozycję na zagrożenia. Na podstawie tego raportu Red Team dobiera techniki, narzędzia i procedury, które odzwierciedlają działanie prawdziwych przeciwników — nie hipotetycznych napastników z ogólnego scenariusza.

Warto też zaznaczyć rolę tzw. Threat Intelligence Sharing przewidzianego w DORA: art. 45 rozporządzenia zachęca instytucje finansowe do dobrowolnej wymiany informacji o zagrożeniach w ramach zaufanych społeczności. Instytucje aktywnie uczestniczące w takich platformach (np. FS-ISAC) mają dostęp do lepszego, bardziej aktualnego TI — co bezpośrednio podnosi jakość scenariuszy TLPT i ogólną skuteczność programu zarządzania zagrożeniami.

📚 Przeczytaj więcej o zagrożeniach w sektorze finansowym: Anatomia cyberataku na sektor bankowy — od phishingu po zaawansowane fraudy

Jak zarządzać ryzykiem podczas testu w środowisku produkcyjnym?

To pytanie, które słyszę od każdego CISO przed pierwszym TLPT: “Co się stanie, jeśli Red Team coś popsuję? Kto odpowiada za ewentualny przestój?” Prowadzenie zaawansowanego testu w środowisku produkcyjnym instytucji finansowej to bez wątpienia operacja podwyższonego ryzyka — ale zarządzalnego, o ile odpowiednio się do niej przygotujemy.

Pierwszym i najważniejszym elementem zarządzania ryzykiem jest precyzyjna definicja zakresu i granic. Umowa z Red Teamem musi zawierać jednoznaczny opis, które systemy są w zakresie testu, które są poza zakresem (np. systemy podtrzymujące życie, krytyczne systemy płatnicze w godzinach szczytu transakcyjnego), jakie działania Red Team może podejmować autonomicznie, a jakie wymagają uprzedniego powiadomienia Białego Zespołu, oraz jakie są warunki natychmiastowego zatrzymania operacji (tzw. kill switch). Biały Zespół musi mieć możliwość zatrzymania testu w dowolnym momencie bez podawania powodów Red Teamowi.

Kluczowe znaczenie ma OPSEC Red Teamu — czyli rygorystyczne procedury bezpieczeństwa operacyjnego, które minimalizują ryzyko niezamierzonych skutków ubocznych. Profesjonalny Red Team nie używa narzędzi, które mogą powodować niestabilność systemu, dostosowuje intensywność działań do godzin operacyjnych instytucji (unika działań w godzinach szczytu transakcyjnego), dokumentuje każdą akcję w czasie rzeczywistym i dysponuje procedurami rollback dla każdego kroku, który mógłby spowodować trwałą zmianę w systemie produkcyjnym.

Warto też zaplanować komunikację z działem prawnym i ubezpieczeniowym przed startem testu. Umowa z dostawcami powinna jednoznacznie regulować podział odpowiedzialności. Instytucja musi upewnić się, że obowiązujące polisy ubezpieczeniowe (cyber insurance) nie zawierają klauzul wykluczających zdarzenia wynikające z autoryzowanych testów penetracyjnych. Poinformowanie ubezpieczyciela o planowanym TLPT jest dobrą praktyką — większość ubezpieczycieli z sektora cyber aktywnie wspiera takie działania jako element zarządzania ryzykiem.

Istotnym aspektem zarządzania ryzykiem jest też kontrola wiedzy o teście wewnątrz organizacji. Zbyt wiele osób wiedzących o TLPT oznacza ryzyko wycieku informacji do Blue Teamu, co zafałszuje wyniki testu. Z kolei zbyt mała liczba osób zaangażowanych po stronie Białego Zespołu może prowadzić do sytuacji, w której test dotknie systemu poza zakresem lub wywoła nadmierną reakcję operacyjną (np. odcięcie sieci przez SOC, który nie wie, że aktywność Red Teamu jest autoryzowana). Dobra zasada to: minimum wiedzy, maksimum kontroli — i staranna kalibracja scenariusza “co robimy, jeśli Blue Team wykryje Red Team i zacznie reagować”.

Ile kosztuje TLPT i jak zaplanować budżet?

To pytanie, od którego często zaczyna się rozmowa z zarządem. Odpowiedź jest prosta: TLPT jest drogi. Ale odpowiedź bardziej kompletna brzmi: TLPT jest drogi w stosunku do typowego pentestingu, ale tani w porównaniu do kosztów incydentu, który mógłby wykryć. Rozmawiałem z dyrektorem operacyjnym jednego z polskich banków, który porównywał te liczby i stwierdził wprost: “Jeśli TLPT kosztuje nas 400 tysięcy złotych, a potencjalny incydent — biorąc pod uwagę przestój, kary regulacyjne i koszty reputacyjne — mógłby kosztować 40 milionów, to jest to najtańsza polisa ubezpieczeniowa, jaką kupiłem w tym roku.”

Koszty TLPT są złożone i obejmują kilka komponentów. Koszt dostawcy TI (Threat Intelligence Provider): przygotowanie raportu TTIR to zazwyczaj 30 000–80 000 EUR, w zależności od głębokości analizy i rozmiaru instytucji. Koszt Red Teamu: zaawansowana operacja red team trwająca 8–16 tygodni z udziałem doświadczonego, wieloosobowego zespołu to koszt rzędu 100 000–350 000 EUR dla instytucji średniej wielkości, a dla największych graczy kwota ta może sięgać 500 000 EUR lub więcej. Koszty wewnętrzne: czas pracy Białego Zespołu, prawników, konsultantów zarządzających projektem po stronie instytucji to dodatkowe 50 000–150 000 PLN przy założeniu minimalnego zaangażowania zewnętrznych doradców.

Koszty raportu i remediacji: sam raport końcowy i plan naprawczy są zazwyczaj wliczone w cenę Red Teamu, ale wdrożenie rekomendacji (remediacja) jest osobnym projektem, który może kosztować kolejne 100 000–500 000 PLN w zależności od zakresu zidentyfikowanych braków. W instytucjach przystępujących do TLPT po raz pierwszy koszty remediacji są zazwyczaj wyższe, bo test ujawnia więcej luk detekcyjnych i proceduralnych.

Koszty przygotowania wewnętrznego to kategoria często pomijana w budżetach. Zanim instytucja będzie gotowa do przeprowadzenia TLPT, może być konieczne podniesienie dojrzałości SOC, wdrożenie lub ulepszenie platformy SIEM/SOAR, zbudowanie zdolności do monitorowania ruchu wschód-zachód (east-west) w sieci wewnętrznej oraz przeszkolenie Białego Zespołu w zakresie zarządzania operacją TIBER-EU. Instytucje, które zainwestują w te przygotowania przed TLPT, czerpią z testu znacznie więcej wartości — bo mają odpowiednie narzędzia detekcyjne, które pozwalają faktycznie zmierzyć zdolność do wykrycia Red Teamu.

Przy planowaniu budżetu warto uwzględnić, że TLPT musi być przeprowadzany co 3 lata — co oznacza konieczność zaplanowania tych wydatków w wieloletnim budżecie cyberbezpieczeństwa. Dobrą praktyką jest wpisanie TLPT do wieloletniego planu inwestycji w bezpieczeństwo razem z innymi regularnymi testami i audytami, traktując go jako element regularnego kosztu operacyjnego, a nie jednorazowego projektu.

Jak wygląda harmonogram przygotowania do TLPT?

Przygotowanie do TLPT to nie tygodnie, lecz miesiące pracy. Poniższa tabela pokazuje realistyczny harmonogram przygotowań dla instytucji, która planuje przeprowadzenie swojego pierwszego TLPT.

Etap	Czas trwania	Kluczowe działania	Odpowiedzialny
1. Ocena gotowości	4–6 tygodni	Audyt dojrzałości ICT; weryfikacja statusu “significant entity”; analiza luk względem DORA Art. 26	CISO + Dyrektor Ryzyka
2. Powołanie Białego Zespołu	1–2 tygodnie	Formalne powołanie White Team; określenie ról; konfiguracja kanałów komunikacji	Zarząd + CISO
3. Definiowanie zakresu	3–4 tygodnie	Mapowanie Critical Functions i Critical Assets; konsultacje z organem nadzorczym (KNF); formalne zatwierdzenie zakresu	White Team + KNF
4. Wybór i kontraktowanie dostawców	6–10 tygodni	RFP dla TI Provider i Red Team; weryfikacja kompetencji; due diligence; negocjacje i podpisanie umów	White Team + Dział Prawny
5. Faza wywiadu (TI)	6–10 tygodni	Dostawca TI przygotowuje raport TTIR; przekazanie raportu Red Teamowi	TI Provider
6. Opracowanie scenariuszy	2–3 tygodnie	Red Team opracowuje Generic Threat Scenarios; White Team zatwierdza zakres operacyjny	Red Team + White Team
7. Faza testowania	8–16 tygodni	Red Team prowadzi operację symulowanego ataku w środowisku produkcyjnym	Red Team
8. Zamknięcie i Purple Teaming	2–4 tygodnie	Ujawnienie; wspólna analiza; warsztaty Purple Team; opracowanie raportu końcowego	Red Team + Blue Team + White Team
9. Remediacja i raportowanie	4–8 tygodni	Wdrożenie planu naprawczego; przygotowanie dokumentacji dla KNF; formalne zamknięcie testu	CISO + White Team

Łączny czas od decyzji o uruchomieniu TLPT do formalnego zamknięcia testu wynosi zazwyczaj 12–18 miesięcy. Instytucje, które wyznaczone zostaną do TLPT przez KNF, powinny traktować ten harmonogram jako punkt wyjścia i jak najszybciej rozpocząć fazę oceny gotowości i budowania wewnętrznych kompetencji.

Szczególnie ważne jest, by nie odkładać etapu oceny gotowości na moment otrzymania formalnego wyznaczenia. Instytucje, które z wyprzedzeniem zbudują wewnętrzną wiedzę o TIBER-EU, powołają zalążek Białego Zespołu i przejdą przez wstępny audyt dojrzałości ICT, radykalnie skracają czas przejścia przez pierwsze dwa etapy po formalnym wyznaczeniu. To realna przewaga — szczególnie jeśli KNF wyznaczy termin pierwszego TLPT krótszy niż standardowe 18 miesięcy.

Jak nFlo realizuje testy zgodne z TIBER-EU i DORA?

nFlo to firma cyberbezpieczeństwa z udokumentowanym doświadczeniem w zaawansowanych testach red team i programach zgodności z regulacjami sektora finansowego. Mamy za sobą ponad 500 projektów bezpieczeństwa, obsługujemy ponad 200 klientów z branż regulowanych i utrzymujemy 98% retencję klientów — co w branży usług bezpieczeństwa jest wymowną miarą jakości i zaufania.

Nasze podejście do TLPT dla sektora finansowego opiera się na trzech filarach. Pierwszy to specjalizacja sektorowa: nasz Red Team posiada głębokie doświadczenie w architekturach systemów bankowych, płatniczych i ubezpieczeniowych — rozumiemy, jak działają systemy, które mamy testować, co przekłada się na precyzję i bezpieczeństwo operacji. Drugi to własna platforma threat intelligence: dysponujemy wewnętrznymi zasobami TI i zestawionymi feedami specyficznymi dla sektora finansowego, co pozwala nam realizować pełen cykl TIBER-EU — od raportu TTIR po finalne Purple Teaming — z zachowaniem wymaganej separacji ról. Trzeci to czas reakcji i wsparcie operacyjne: w przypadku nieplanowanych zdarzeń podczas testu możemy zareagować w czasie poniżej 15 minut — co ma krytyczne znaczenie, gdy operacja jest prowadzona w środowisku produkcyjnym.

Nasze usługi TLPT są zaprojektowane jako program, nie jednorazowy projekt. Wspieramy instytucje finansowe od etapu oceny gotowości i konsultacji z KNF, przez pełne przeprowadzenie testu zgodnego z TIBER-EU, po implementację planu naprawczego i przygotowanie organizacji do kolejnego cyklu TLPT za trzy lata. Szacujemy, że dzięki naszym testom i rekomendacjom klienci osiągają średnio 90% redukcję ryzyka cybernetycznego w obszarach objętych testami — i to jest miara, której od nas wymagamy.

Wiemy też, że dla wielu instytucji pierwszym krokiem nie jest TLPT, lecz ocena gotowości do TLPT. Oferujemy dedykowany serwis pre-TLPT readiness assessment, który w ciągu 4–6 tygodni daje CISO i zarządowi rzetelną odpowiedź na pytanie: “Czy jesteśmy gotowi i co musimy zrobić, żeby być gotowi?” To inwestycja, która wielokrotnie zwraca się w postaci sprawniejszego przebiegu właściwego testu i wyższej jakości wyników.

Pojęcia powiązane

Red Teaming — zaawansowane testy bezpieczeństwa symulujące rzeczywistych atakujących
Testy penetracyjne — zakres, metodologie i przebieg
DORA — wymogi sektora finansowego — kompletny przewodnik po rozporządzeniu

Dowiedz się więcej

Sprawdź nasze usługi

Jeśli Twoja instytucja finansowa przygotowuje się do TLPT lub chcesz ocenić swoją gotowość na wymogi DORA w zakresie testowania odporności cyfrowej, skontaktuj się z nami. Przeprowadzimy bezpłatną konsultację wstępną i ocenimy, na którym etapie drogi do TLPT się znajdujesz.

Skontaktuj się z nFlo

FAQ — Najczęstsze pytania o TLPT i DORA

Czy TLPT jest obowiązkowy dla wszystkich instytucji finansowych objętych DORA?

Nie. TLPT dotyczy wyłącznie podmiotów wyznaczonych przez właściwy organ nadzorczy (w Polsce: KNF) jako “znaczące”. Pozostałe instytucje objęte DORA muszą prowadzić regularne testy bezpieczeństwa (w tym pentesty), ale nie muszą przeprowadzać pełnego TLPT zgodnego z metodologią TIBER-EU. Warto jednak sprawdzić swój status bezpośrednio z KNF, gdyż lista podmiotów obowiązanych może być aktualizowana. Dobrą praktyką jest proaktywny dialog z organem nadzorczym jeszcze przed formalnym wyznaczeniem — pozwala to lepiej zaplanować przygotowania i uniknąć nieprzyjemnych niespodzianek.

Jak długo trwa pełny cykl TLPT od decyzji do zamknięcia testu?

Realistyczny czas to 12–18 miesięcy od podjęcia decyzji o uruchomieniu procesu do formalnego zamknięcia testu i przekazania raportu do organu nadzorczego. Czas ten obejmuje fazę przygotowawczą, wybór dostawców, fazę wywiadu TI, operację Red Teamu, Purple Teaming oraz wdrożenie planu naprawczego. Instytucje, które wcześniej zainwestowały w budowanie dojrzałości SOC i wewnętrznej wiedzy o TIBER-EU, mogą ten czas skrócić do 10–12 miesięcy. Nie warto odkładać przygotowań do momentu formalnego wyznaczenia przez KNF.

Czy wyniki TLPT przeprowadzonego w jednym kraju UE są uznawane w innym?

Tak — pod warunkiem, że test został przeprowadzony w pełnej zgodności z metodologią TIBER-EU i zaakceptowany przez właściwy organ krajowy. Mechanizm wzajemnego uznawania wyników TLPT jest jedną z kluczowych innowacji regulacyjnych DORA i ma szczególne znaczenie dla grup finansowych działających w wielu krajach Unii Europejskiej. Szczegółowe warunki uznania regulują właściwe organy zaangażowanych krajów. Warto z wyprzedzeniem uzgodnić z organami nadzorczymi wszystkich krajów, w których działa Twoja grupa, warunki wzajemnego uznania — zanim test zostanie przeprowadzony.

Co dzieje się, jeśli wyniki TLPT ujawnią poważne luki bezpieczeństwa?

Ujawnienie poważnych luk jest w istocie celem testu — to sukces, nie porażka. Po zakończeniu TLPT instytucja musi opracować i wdrożyć plan naprawczy (remediation plan), który adresuje zidentyfikowane słabości. Plan ten jest przekazywany do organu nadzorczego razem z raportem z testu. Organ nadzorczy może monitorować postęp wdrożenia planu naprawczego. Brak planu lub brak jego realizacji może skutkować działaniami nadzorczymi. W praktyce organy nadzorcze rozumieją, że celem TLPT jest wykrycie słabości, i traktują aktywnie wdrażany plan naprawczy jako dowód dojrzałości zarządzania ryzykiem — nie jako przyznanie się do winy.

Jaka jest minimalna częstotliwość przeprowadzania TLPT wymagana przez DORA?

DORA wymaga przeprowadzania TLPT co najmniej raz na trzy lata. Właściwy organ nadzorczy może jednak zażądać przeprowadzenia testu przed upływem tego terminu — na przykład po poważnym incydencie cybernetycznym, po istotnej zmianie w infrastrukturze technologicznej instytucji lub w przypadku zidentyfikowania nowego, poważnego zagrożenia sektorowego. Trzyletni cykl powinien być traktowany jako minimum, a nie jako optymalny harmonogram. Instytucje o wysokiej dojrzałości w zakresie cyberbezpieczeństwa często przeprowadzają elementy metodyki TIBER-EU (np. skrócone ćwiczenia Red Team) corocznie — między pełnymi cyklami TLPT.

Źródła

Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA) — Art. 24–27
European Central Bank: TIBER-EU Framework — How to implement the European framework for threat intelligence-based ethical red teaming (2018, updated 2022)
European Banking Authority (EBA): Guidelines on ICT and security risk management (2019); zaktualizowane w kontekście DORA
European Insurance and Occupational Pensions Authority (EIOPA): DORA implementation guidance for insurance sector (2024)
European Securities and Markets Authority (ESMA): Joint ESAs guidance on DORA implementation (2024)
MITRE ATT&CK Framework: Enterprise Matrix v14 — https://attack.mitre.org/
CREST: STAR (Simulated Targeted Attack and Response) standard — https://www.crest-approved.org/
Komisja Nadzoru Finansowego (KNF): Komunikaty dotyczące wdrożenia DORA w Polsce (2024–2025)
Narodowy Bank Polski: Prace implementacyjne TIBER-PL (2024)

Potrzebujesz wsparcia? Zespół nFlo pomoże zabezpieczyć Twoją organizację:

DORA a testy odporności cyfrowej — jak przygotować się na TLPT i scenariusze threat-led