Testy TLPT pod DORA – jak zacząć: kto podlega, 7 etapów i terminy z RTS 2025/1190

Czym jest TLPT pod DORA? TLPT (Threat-Led Penetration Testing) to zaawansowany test bezpieczeństwa wymagany przez rozporządzenie DORA od wyznaczonych podmiotów finansowych: banków, dużych instytucji płatniczych, ubezpieczycieli, CCP i CSD. Zespół testerów odtwarza działania realnych grup przestępczych na działających systemach produkcyjnych, a cały proces nadzoruje organ ds. TLPT – w Polsce Komisja Nadzoru Finansowego. Test trzeba powtarzać co najmniej raz na 3 lata, a jego przebieg regulują art. 26-27 DORA oraz rozporządzenie delegowane (UE) 2025/1190, stosowane od 8 lip 2025.

Definicja kanoniczna: TLPT (Threat-Led Penetration Testing) to test odporności cyfrowej wymagany przez art. 26 DORA, w którym zewnętrzni testerzy symulują na systemach produkcyjnych taktyki realnych agresorów na podstawie ukierunkowanej analizy zagrożeń.

Testy TLPT pod DORA – w skrócie:

1. DORA (rozporządzenie (UE) 2022/2554) stosuje się od 17 styznia 2025; art. 26 nakłada obowiązek TLPT co najmniej raz na 3 lata na podmioty wyznaczone przez organ ds. TLPT.
2. RTS 2025/1190 (opublikowane 18 czerwca 2025, stosowane od 8 lipca 2025) określa progi kwalifikacji, wymogi wobec testerów i harmonogram każdego etapu testu.
3. Obowiązek nie jest samoistny: uruchamia go powiadomienie od organu ds. TLPT, po którym instytucja ma 3 miesiące na kartę projektu i 6 miesięcy na dokument określający zakres.
4. Faza aktywnego red teamingu trwa co najmniej 12 tygodni, a cały cykl od powiadomienia do planu naprawczego zajmuje zwykle 9-14 miesięcy.
5. Dostawca analizy zagrożeń musi być zawsze zewnętrzny, a co trzeci test – w całości zlecony testerom zewnętrznym.
6. Patronusec realizuje pełny cykl TLPT jako dostawca analizy zagrożeń i zespołu red team, z wymaganym przez RTS rozdzieleniem obu ról – od readiness assessment po wsparcie w planie naprawczym.

---

Czym różni się TLPT od klasycznego testu penetracyjnego?

TLPT różni się od klasycznego pentestu zakresem, celem i sposobem nadzoru. Pentest weryfikuje podatności wskazanego systemu w ograniczonym czasie i za wiedzą zespołu IT. TLPT testuje całą organizację – ludzi, procesy i technologię – na systemach produkcyjnych, w tajemnicy przed zespołem obrony i pod nadzorem regulatora, według scenariuszy zbudowanych na realnym wywiadzie o zagrożeniach.

Motyw 12 preambuły RTS 2025/1190 opisuje tę różnicę wprost: konwencjonalne testy penetracyjne oceniają podatności techniczne i konfiguracyjne pojedynczego systemu, natomiast test oparty na analizie zagrożeń obejmuje pełny scenariusz ukierunkowanego ataku na cały podmiot. Z tego wynika kilka konsekwencji praktycznych:

Kryterium	Klasyczny pentest	Red team (komercyjny)	TLPT pod DORA
Podstawa scenariusza	lista podatności, OWASP, PTES	cele uzgodnione z klientem	ukierunkowana analiza zagrożeń (TTI) od zewnętrznego dostawcy
Środowisko	testowe lub produkcyjne, wydzielone	zwykle produkcyjne	wyłącznie działające systemy produkcyjne
Wiedza zespołu obrony	zazwyczaj poinformowany	nieświadomy	nieświadomy (blue team nie zna testu)
Czas aktywnego testowania	1-4 tygodnie	4-8 tygodni	co najmniej 12 tygodni (art. 11 ust. 5 RTS)
Nadzór	wewnętrzny	wewnętrzny	organ ds. TLPT zatwierdza zakres, dostawców, plan i raporty
Wynik	raport z podatnościami	raport z narracją ataku	raport red team, raport blue team, sprawozdanie podsumowujące, plan naprawczy, poświadczenie organu
Częstotliwość	1-2 razy w roku	według potrzeb	co najmniej raz na 3 lata

TLPT różni się od klasycznego pentestu tym, że scenariusze ataku opierają się na taktykach, technikach i procedurach (TTP) realnych aktorów zagrożeń, a nie na katalogu podatności technicznych.

W praktyce oznacza to, że doświadczenie z corocznych pentestów nie przygotowuje organizacji do TLPT. Inne są role, inna dokumentacja, inny partner po drugiej stronie stołu – zamiast działu IT jest kierownik testu z ramienia KNF.

Patronusec Insight: Z naszego doświadczenia projektowego wynika, że instytucje najczęściej nie doceniają fazy Threat Intelligence. Sprawozdanie TTI to nie raport OSINT – RTS (załącznik III) wymaga między innymi analizy wycieków poświadczeń pracowników, podobnych domen, informacji na sprzedaż w dark webie i profili konkretnych grup przestępczych atakujących sektor finansowy w danym kraju. Jeśli dostawca analizy zagrożeń sprowadza to do skanu zewnętrznej powierzchni ataku, scenariusze nie przejdą zatwierdzenia przez kierownika testu. Realizujemy fazę TI w oddzielnym zespole niż red team, zgodnie z art. 7 ust. 1 lit. e) RTS, dzięki czemu dokumentacja od razu spełnia wymogi rozdzielności ról.

Kto podlega obowiązkowi TLPT pod DORA i jak sprawdzić, czy dotyczy to Twojej instytucji?

Obowiązkowi TLPT podlegają wyłącznie podmioty finansowe wyznaczone przez organ ds. TLPT na podstawie art. 26 ust. 8 DORA i kryteriów z art. 2 RTS 2025/1190. Nie ma samodzielnego obowiązku: instytucja rozpoczyna test dopiero po otrzymaniu powiadomienia. Wyłączone są mikroprzedsiębiorstwa i podmioty objęte uproszczonymi ramami zarządzania ryzykiem ICT z art. 16 DORA.

Art. 2 ust. 2 RTS 2025/1190 wskazuje kategorie, dla których organ ds. TLPT domyślnie wymaga testu, chyba że ocena profilu ryzyka wskaże inaczej:

• instytucje kredytowe uznane za globalne (G-SII) lub inne instytucje o znaczeniu systemowym (O-SII) zgodnie z art. 131 CRD, oraz podmioty należące do takich grup;
• instytucje płatnicze, których łączna wartość transakcji płatniczych przekroczyła 150 mld EUR w każdym z dwóch poprzednich lat kalendarzowych;
• instytucje pieniądza elektronicznego z transakcjami powyżej 150 mld EUR albo pieniądzem elektronicznym w obiegu powyżej 40 mld EUR;
• centralne depozyty papierów wartościowych (CSD) i kontrahenci centralni (CCP) – bez progów ilościowych;
• systemy obrotu z największym krajowym udziałem w obrocie danej klasy instrumentów lub z udziałem powyżej 5 % na poziomie UE;
• zakłady ubezpieczeń i reasekuracji ze składką przypisaną brutto powyżej 1,5 mld EUR, rezerwami powyżej 10 mld EUR i aktywami powyżej 3,5 % aktywów sektora w kraju – a spośród nich te, które dodatkowo przekraczają 3 mld EUR składki, 30 mld EUR rezerw albo 10 % aktywów sektora.

Ponadto art. 2 ust. 1 pozwala organowi wyznaczyć każdy inny podmiot finansowy na podstawie oceny jakościowej: wielkości, wzajemnych powiązań, zastępowalności usług, złożoności architektury ICT, liczby umów z dostawcami ICT oraz dojrzałości SOC. Motyw 3 RTS wskazuje wprost dostawców usług w zakresie kryptoaktywów (MiCA) jako kandydatów do przyszłego wyznaczenia.

Organem ds. TLPT w Polsce jest Komisja Nadzoru Finansowego, która wyznacza podmioty zobowiązane do testu, zatwierdza jego zakres i dostawców oraz wydaje poświadczenie po zakończeniu testu.

---

Drzewo decyzyjne – czy Twoja instytucja podlega TLPT?

1. Czy jesteś mikroprzedsiębiorstwem lub podmiotem objętym art. 16 DORA (uproszczone ramy)?
   → TAK: poza zakresem TLPT; obowiązuje tylko podstawowy program testów z art. 24-25.
   → NIE: przejdź do pkt 2.
2. Czy należysz do kategorii z art. 2 ust. 2 RTS (O-SII, instytucja płatnicza >150 mld EUR, CCP, CSD, duży ubezpieczyciel)?
   → TAK: oczekuj powiadomienia od KNF; przygotowania zacznij teraz.
   → NIE: przejdź do pkt 3.
3. Czy wykonujesz krytyczne funkcje dla sektora (np. operator infrastruktury, dostawca usług dla wielu banków) lub należysz do grupy, w której inny podmiot spełnia progi?
   → TAK: możliwe wyznaczenie jakościowe lub udział we wspólnym TLPT grupy; oceń gotowość i poznaj wymogi.
   → NIE: TLPT prawdopodobnie Cię nie obejmie, ale obowiązek testów z art. 24 DORA (w tym pentesty i skany podatności) pozostaje.

W praktyce oznacza to: jeśli Twoja instytucja jest w pkt 2 lub 3, przygotowania warto rozpocząć przed powiadomieniem, bo terminy z RTS liczone są od jego daty i nie uwzględniają czasu na przetarg czy budowę zespołu control team.

---

Jakie role występują w TLPT i kto za co odpowiada?

W TLPT występuje pięć ról: control team i blue team po stronie instytucji, TLPT cyber team (kierownicy testów) po stronie organu nadzoru oraz dwaj zewnętrzni dostawcy TLPT – dostawca analizy zagrożeń i testerzy (red team). Podział ról wprowadza art. 1 RTS 2025/1190 i odwzorowuje strukturę TIBER-EU.

Rola	Kto	Kluczowe zadania	Podstawa
Lider control team	pracownik instytucji z dostępem do zarządu	bieżące zarządzanie testem, decyzje, poufność, kontakt z KNF	art. 4 ust. 1 RTS
Control team (white team)	3-6 osób: bezpieczeństwo, IT, ryzyko, prawo	zakres, wybór dostawców, ocena ryzyka testu, ułatwienia, raportowanie do zarządu	art. 9 ust. 4 RTS
Blue team	SOC, infrastruktura, incident response – nieświadomy testu	normalna obrona; po teście raport blue team i odtworzenie ataku	art. 1 pkt 3, art. 12 RTS
TLPT cyber team (TCT)	kierownik testu + zastępca z organu ds. TLPT	zatwierdzanie dokumentów, nadzór każdego etapu, poświadczenie	art. 3 RTS
Dostawca analizy zagrożeń	zewnętrzny, zawsze	sprawozdanie TTI, profile agresorów, min. 3 scenariusze	art. 10 RTS, art. 27 DORA
Testerzy (red team)	zewnętrzni lub wewnętrzni (co trzeci test zewnętrzny)	plan testów, aktywne testowanie ≥12 tygodni, raport red team, purple teaming	art. 11-12 RTS

Blue team w TLPT to zespół obrony instytucji, który zgodnie z art. 1 pkt 3 RTS 2025/1190 nie jest świadomy prowadzonego testu – dlatego test dostaje kryptonim, a informacje o nim krążą wyłącznie na zasadzie wiedzy koniecznej.

Dwa elementy tej struktury są najczęściej niedoszacowane. Po pierwsze, lider control team musi mieć realny mandat: motyw 10 RTS wymaga odpowiedniego starszeństwa i dostępu do organu zarządzającego, bo to on decyduje o zawieszeniu testu, gdy pojawi się ryzyko dla ciągłości działania. Po drugie, art. 4 ust. 2 lit. c) RTS nakłada obowiązek powstrzymania eskalacji incydentu, jeśli blue team wykryje działania testerów – control team musi mieć procedurę, jak to zrobić bez ujawnienia testu reszcie organizacji.

---

Jak przebiega TLPT krok po kroku i jakie terminy narzuca RTS 2025/1190?

TLPT przebiega w trzech etapach – przygotowawczym, testowania i zamykania – a RTS 2025/1190 przypisuje do nich twarde terminy: 3 miesiące na inicjację, 6 miesięcy na dokument określający zakres, co najmniej 12 tygodni aktywnego red teamingu oraz 4, 10 i 8 tygodni na kolejne raporty i plan naprawczy. Cały cykl trwa zwykle 9-14 miesięcy.

Harmonogram odniesiony do dnia powiadomienia (D) wygląda następująco:

Krok	Co się dzieje	Termin z RTS	Artykuł
1. Powiadomienie	KNF informuje o obowiązku TLPT i podaje dane kierowników testów	D	art. 9 ust. 1
2. Inicjacja	karta projektu (zał. I), lider control team, testerzy wewnętrzni/zewnętrzni, kanały komunikacji, kryptonim	D + 3 miesiące	art. 9 ust. 2
3. Dokument określający zakres	wykaz funkcji krytycznych lub istotnych, systemy ICT, wstępne flagi (zał. II); zatwierdza zarząd, potem KNF	D + 6 miesięcy	art. 9 ust. 6
4. Wybór dostawców	ocena testerów i dostawcy TI wg art. 27 DORA i art. 7 RTS; dowody dla KNF przed podpisaniem umowy	przed etapem testowania	art. 9 ust. 9-11
5. Analiza zagrożeń	sprawozdanie TTI (zał. III), min. 3 scenariusze, zatwierdzenie przez KNF	ok. 4 tygodnie (motyw 18)	art. 10
6. Red team	plan testów (zał. IV), aktywne testowanie, cotygodniowe raporty postępu	co najmniej 12 tygodni	art. 11
7a. Raport red team	pełny opis ścieżek ataku, flag, podatności, przyczyn źródłowych (zał. V)	4 tygodnie po zakończeniu red teamingu	art. 12 ust. 2
7b. Raport blue team + replay + purple team	wykrycia, logi, wnioski (zał. VI); odtworzenie ataku z testerami	10 tygodni po zakończeniu red teamingu	art. 12 ust. 4-5
7c. Sprawozdanie podsumowujące	istotne ustalenia dla organu (zał. VII)	8 tygodni od potwierdzenia raportów przez KNF	art. 12 ust. 7
7d. Plan naprawczy	opis niedociągnięć, priorytety, przyczyny źródłowe, odpowiedzialni, ryzyko braku wdrożenia	8 tygodni od tego samego potwierdzenia	art. 13
8. Poświadczenie	organ wydaje poświadczenie (zał. VIII) umożliwiające wzajemne uznawanie w UE	po zamknięciu	art. 14

Etap aktywnego testowania z udziałem red teamu w TLPT trwa co najmniej 12 tygodni – tak stanowi art. 11 ust. 5 rozporządzenia delegowanego (UE) 2025/1190 – a scenariusze mogą być realizowane kolejno lub równolegle.

Kilka mniej oczywistych zasad z tego harmonogramu:

• Testerzy raportują postęp co najmniej raz w tygodniu control teamowi i kierownikom testów (art. 11 ust. 7).
• Ułatwienia (leg-ups) – informacje lub dostęp przyznawane testerom, gdy utkną – muszą być zaplanowane w planie testów i zatwierdzone przez kierowników testów (art. 11 ust. 8).
• Jeśli blue team wykryje test, control team proponuje kierownikom testów środki pozwalające kontynuować TLPT z zachowaniem poufności (art. 11 ust. 9).
• W wyjątkowych sytuacjach lider control team może zawiesić test lub – za zgodą organu – przejść do ograniczonych działań purple team, które wliczają się do minimum 12 tygodni (art. 11 ust. 10).

W praktyce oznacza to, że sam etap testowania (TI + red team) zajmuje minimum 4 miesiące, a wraz z zamykaniem – kolejne 4-5. Doliczając 6 miesięcy etapu przygotowawczego, pierwszy cykl trudno zamknąć w krócej niż rok.

---

Twoja instytucja spełnia progi z art. 2 RTS, a powiadomienie od KNF jeszcze nie przyszło?

Patronusec przeprowadza TLPT readiness assessment: w ciągu 10 dni roboczych dostajesz ocenę gotowości control teamu, wstępną listę funkcji krytycznych lub istotnych do zakresu, mapę luk dokumentacyjnych względem załączników I-II RTS oraz realistyczny harmonogram pierwszego cyklu.

Umów readiness assessment TLPT

---

Jak wybrać funkcje krytyczne lub istotne i zbudować dokument określający zakres?

Zakres TLPT budujesz wokół funkcji krytycznych lub istotnych (CIF) z rejestru wymaganego przez art. 8 DORA, a nie wokół systemów. Art. 26 ust. 2 DORA wymaga objęcia testem kilku lub wszystkich takich funkcji, a art. 9 ust. 7 RTS podaje siedem kryteriów wyboru. Dokument określający zakres zatwierdza organ zarządzający instytucji, a następnie organ ds. TLPT.

Kryteria z art. 9 ust. 7 RTS, którymi uzasadniasz włączenie lub wyłączenie każdej funkcji:

1. krytyczny lub istotny charakter funkcji i jej wpływ na sektor oraz stabilność finansową,
2. znaczenie funkcji dla bieżącej działalności instytucji,
3. wymienność (czy inny podmiot może ją przejąć),
4. wzajemne powiązania z innymi funkcjami,
5. położenie geograficzne,
6. sektorowa zależność innych podmiotów od tej funkcji,
7. dostępna analiza zagrożeń dotycząca funkcji.

Załącznik II RTS wymaga, aby dokument określający zakres zawierał wykaz wszystkich CIF, a dla każdej z nich: uzasadnienie włączenia lub wyłączenia, systemy ICT wspierające funkcję, informację o outsourcingu z nazwą dostawcy, jurysdykcje oraz wysokopoziomowy opis wstępnie wybranych flag ze wskazaniem, którego atrybutu bezpieczeństwa dotyczą – poufności, integralności, dostępności czy autentyczności.

Flagi w TLPT to kluczowe cele w systemach ICT wspierających funkcje krytyczne lub istotne, do których testerzy próbują dotrzeć podczas testu; definiuje je art. 1 pkt 14 RTS 2025/1190.

Najczęstszy błąd na tym etapie to wyłączenie z zakresu funkcji obsługiwanych przez zewnętrznych dostawców ICT. Art. 26 ust. 3 DORA wymaga uwzględnienia dostawców, których usługi wspierają CIF, a gdy test mógłby zaszkodzić innym klientom dostawcy, art. 26 ust. 4 przewiduje testowanie zbiorcze – dostawca organizuje jeden TLPT dla kilku instytucji. Jeśli Twoja instytucja korzysta z tego samego dostawcy co inne banki, KNF może zaproponować taki model; warto o to zapytać już na etapie inicjacji. Więcej o klasyfikacji dostawców i due diligence znajdziesz w artykule o zarządzaniu ryzykiem dostawców ICT pod DORA i NIS2.

---

Jakie wymogi muszą spełnić testerzy i dostawca analizy zagrożeń?

Testerzy i dostawca analizy zagrożeń muszą spełnić wymogi art. 27 DORA (reputacja, kompetencje, certyfikacja lub kodeks etyczny, niezależny raport zapewnienia, ubezpieczenie OC) oraz szczegółowe kryteria art. 7 RTS 2025/1190: udokumentowane doświadczenie zespołu, 3-5 rekomendacji, brak konfliktu z zadaniami blue team i rozdzielenie personelu TI od red teamu. Control team dokumentuje tę ocenę i przedstawia ją KNF przed podpisaniem umowy.

Minimalne wymogi wobec zespołów według art. 7 ust. 1 RTS:

Wymóg	Dostawca analizy zagrożeń	Testerzy zewnętrzni (red team)
Skład zespołu	kierownik z ≥5 lat doświadczenia w TI + min. 1 osoba z ≥2 lat	kierownik z ≥5 lat w pentestach i red teamingu + min. 2 testerów z ≥2 lat każdy
Rekomendacje z poprzednich projektów	co najmniej 3	co najmniej 5
Kompetencje	TTP gromadzenia danych wywiadowczych, wiedza geopolityczna i sektorowa, komunikacja	rozpoznanie, zarządzanie ryzykiem, opracowywanie exploitów, penetracja fizyczna, inżynieria społeczna, analiza podatności
CV i certyfikaty	szczegółowe życiorysy i kopie certyfikatów wg uznanych standardów rynkowych	jak obok
Ubezpieczenie OC zawodowe	wymagane, w tym od uchybień i zaniedbań	wymagane
Konflikt interesów	brak zadań blue team dla instytucji lub jej dostawców ICT	brak związku z dostawcą TI wykonującym zadania blue team
Rozdzielność	personel TI oddzielony od red teamu tego samego dostawcy i mu niepodległy	analogicznie
Po teście	bezpieczne usunięcie poświadczeń i danych	dodatkowo: dezaktywacja C2, usunięcie backdoorów, wyłączniki awaryjne, powiadomienie o naruszeniach

Zgodnie z art. 27 ust. 2 DORA dostawca analizy zagrożeń w TLPT musi być zawsze zewnętrzny wobec podmiotu finansowego, natomiast testerzy mogą być wewnętrzni pod warunkiem zatwierdzenia przez organ ds. TLPT i zlecenia co trzeciego testu na zewnątrz.

Art. 26 ust. 8 DORA dodaje jeszcze jedno ograniczenie: instytucje kredytowe uznane za istotne (nadzorowane bezpośrednio przez EBC) korzystają wyłącznie z testerów zewnętrznych. Dla pozostałych art. 15 RTS określa warunki testerów wewnętrznych: polityka zarządzania testerami, lider + co najmniej 2 osoby zatrudnione w instytucji od minimum 12 miesięcy, brak negatywnego wpływu na zdolności obronne w trakcie testu.

Ten sam dostawca może zapewnić i analizę zagrożeń, i red team – RTS wymaga wtedy rozdzielenia personelu i braku podległości między zespołami (art. 7 ust. 1 lit. e pkt v oraz lit. f pkt v). Patronusec realizuje testy TLPT w obu rolach, z oddzielnymi zespołami i dokumentacją rozdzielności przygotowaną pod ocenę kierownika testu, a klasyczne testy penetracyjne traktujemy jako etap poprzedzający – nie jako substytut TLPT.

Patronusec Insight: Kryteria art. 7 RTS to minimum, a nie gwarancja jakości. Z naszego doświadczenia projektowego wynika, że o powodzeniu testu decydują trzy rzeczy, o które warto zapytać każdego dostawcę: czy zespół potrafi prowadzić operację przez 12 tygodni bez wykrycia (infrastruktura C2, OPSEC), czy ma udokumentowaną procedurę reagowania na wykrycie przez blue team oraz czy jego raport red team mapuje ścieżki ataku na MITRE ATT&CK w sposób, który blue team może odtworzyć w logach. Nasz zespół pentesterów z certyfikatami OSCP, CREST i OSWE przygotowuje raporty z myślą o tym, że czytać je będzie kierownik testu z KNF, a nie tylko dział IT.

---

Jak przygotować organizację do TLPT, zanim przyjdzie powiadomienie od KNF?

Przygotowanie do TLPT przed powiadomieniem obejmuje pięć obszarów: aktualny rejestr funkcji krytycznych lub istotnych, wytypowanie lidera i składu control teamu, budżet oraz harmonogram zakupu usług TI i red team, ocenę dojrzałości SOC (bo to blue team będzie oceniany) oraz uporządkowanie umów z dostawcami ICT pod kątem klauzul o testowaniu. Wszystko bez informowania blue teamu.

Motyw 20 RTS pozwala, aby czas aktywnego testowania był dłuższy niż 12 tygodni, gdy zakres jest duży – dlatego dojrzałość organizacyjna przekłada się bezpośrednio na koszt testu. Poniższa lista kontrolna odpowiada pytaniom, które kierownik testu z KNF zada na etapie przygotowawczym.

Checklist gotowości do TLPT (perspektywa kierownika testu):

1. Czy rejestr funkcji krytycznych lub istotnych z art. 8 DORA jest aktualny i zawiera mapowanie na systemy ICT oraz dostawców?
2. Czy wyznaczono lidera control teamu z dostępem do zarządu i mandatem do zawieszenia testu?
3. Czy skład control teamu jest możliwie mały (motyw 10 RTS) i nie obejmuje osób z zadań blue team?
4. Czy istnieje procedura powstrzymania eskalacji incydentu po wykryciu testerów (art. 4 ust. 2 lit. c RTS)?
5. Czy umowy z zewnętrznymi dostawcami ICT wspierającymi CIF dopuszczają testy na produkcji i określają zasady udziału ich personelu?
6. Czy przygotowano ocenę ryzyka testu obejmującą sześć kategorii z art. 5 ust. 2 RTS, w tym ryzyko dla stabilności finansowej?
7. Czy zaplanowano bezpieczne kanały komunikacji (szyfrowana poczta, data room, komunikator) wymagane w karcie projektu (zał. I)?
8. Czy budżet i procedura zakupowa pozwalają zakontraktować dostawcę TI i testerów w oknie między zatwierdzeniem zakresu a startem testowania?
9. Czy SOC ma retencję logów pozwalającą po 12 tygodniach odtworzyć działania testerów do raportu blue team (zał. VI)?
10. Czy zarząd wie, że zatwierdza dokument określający zakres (art. 9 ust. 6 RTS) i przyjmie plan naprawczy?

---

Jeśli w Twojej organizacji nie ma osoby, która weźmie na siebie te przygotowania, funkcję lidera control teamu lub jego doradcy może pełnić vCISO – z zachowaniem rozdzielności od zespołów, które będą testowane. Ogólną kolejność działań w programie bezpieczeństwa znajdziesz w 12-miesięcznym planie cyberbezpieczeństwa.

---

Które przekonania o TLPT pod DORA są mitami?

Wokół TLPT narosło kilka przekonań, które nie mają oparcia w tekście DORA ani RTS 2025/1190. Poniższe pary mit/fakt odnoszą się bezpośrednio do konkretnych artykułów.

MIT: Każdy podmiot objęty DORA musi wykonać TLPT.
FAKT: TLPT wykonują wyłącznie podmioty wyznaczone przez organ ds. TLPT (art. 26 ust. 8 DORA, art. 2 RTS). Pozostałe realizują program testów z art. 24-25, w tym pentesty i skany podatności.

MIT: TLPT można zrealizować jako rozszerzony pentest w środowisku testowym.
FAKT: Art. 26 ust. 2 DORA wymaga testu na działających systemach produkcyjnych wspierających funkcje krytyczne lub istotne.

MIT: Wystarczy zatrudnić jednego dostawcę red team, który sam zrobi threat intelligence.
FAKT: Dostawca analizy zagrożeń musi być zewnętrzny (art. 27 ust. 2 DORA), a jego personel oddzielony od testerów tego samego dostawcy (art. 7 ust. 1 lit. e pkt v RTS).

MIT: Test kończy się raportem red teamu.
FAKT: Etap zamykania obejmuje raport blue team, odtworzenie ataku, purple teaming, sprawozdanie podsumowujące dla organu i plan naprawczy (art. 12-13 RTS). Dopiero po nich organ wydaje poświadczenie.

MIT: Wewnętrzny zespół red team może wykonywać wszystkie testy.
FAKT: Co trzeci test musi wykonać zespół zewnętrzny, a istotne instytucje kredytowe korzystają wyłącznie z testerów zewnętrznych (art. 26 ust. 8 DORA).

---

FAQ – jak przygotować się do TLPT pod DORA

---

Warto przeczytać

1. DORA i cyberbezpieczeństwo – słownik pojęć – definicje control team, threat intelligence i pozostałych terminów używanych w tym artykule.
2. Metody testowania bezpieczeństwa IT – jak pentesty, skany i red teaming układają się w program testów, który poprzedza TLPT.
3. Zarządzanie ryzykiem dostawców ICT – jak uporządkować umowy z dostawcami wspierającymi funkcje krytyczne przed włączeniem ich do zakresu testu.
4. Ransomware – pierwsze 72 godziny – scenariusz ograniczenia dostępności, który zgodnie z zał. III RTS musi znaleźć się wśród scenariuszy TLPT.

---

Testy TLPT pod DORA – bezpłatna konsultacja

Patronusec realizuje testy TLPT jako dostawca analizy zagrożeń i zespołu red team, z rozdzieleniem obu ról wymaganym przez RTS 2025/1190. Pracujemy z instytucjami z sektora finansowego i fintech, a nasz zespół pentesterów posiada certyfikaty OSCP, CREST i OSWE.

W bezpłatnej 30-minutowej konsultacji pomożemy Ci:

• ocenić, czy Twoja instytucja spełnia progi z art. 2 RTS 2025/1190 i kiedy spodziewać się powiadomienia,
• wytypować funkcje krytyczne lub istotne do zakresu oraz wstępne flagi,
• określić skład control teamu i procedury poufności zgodne z art. 4 RTS,
• ułożyć realny harmonogram pierwszego cyklu z uwzględnieniem terminów 3 / 6 miesięcy i 12 tygodni.

Umów bezpłatną konsultację TLPT | Testy TLPT | Wdrożenie DORA | Testy penetracyjne | vCISO