DORA pentest: obowiązki testów penetracyjnych zgodnie z Art. 24 i Art. 26

Od 17 stycznia 2025 r. Digital Operational Resilience Act (DORA, rozporządzenie (UE) 2022/2554) obowiązuje bezpośrednio we wszystkich państwach członkowskich UE. Artykuł 24 zobowiązuje podmioty finansowe do regularnych testów penetracyjnych ich systemów ICT; Artykuł 26 dla systemowo istotnych podmiotów dodatkowo nakazuje Threat-Led Penetration Tests (TLPT). Ten przewodnik wyjaśnia, które podmioty są w zakresie, czego konkretnie wymaga rozporządzenie i które podejście do pentestu spełnia wymagania.

Rozpocznij pentest DORA

Written by Malte Wagenbach

Founder of Matproof Security. Specialized in AI-driven penetration testing and EU compliance (DORA, NIS2, ISO 27001, SOC 2).

Last reviewed: May 17, 2026

Dlaczego DORA czyni pentest regulacyjnym obowiązkiem

DORA nie jest wytyczną, lecz bezpośrednio stosowanym prawem UE. W przeciwieństwie do wcześniejszych wytycznych EBA dotyczących ryzyk ICT (EBA/GL/2019/04), DORA ma moc wiążącą: KNF i EBC mogą nakładać kary pieniężne do 1 % globalnego dziennego obrotu i osobiście pociągać do odpowiedzialności zarząd. Art. 24 ust. 1 DORA wymaga, aby podmioty finansowe regularnie sprawdzały swoje systemy, aplikacje i infrastrukturę ICT pod kątem podatności przez 'program testowania cyfrowej odporności operacyjnej'. Art. 24 ust. 2 wprost wymienia 'testy penetracyjne, w tym testy penetracyjne ukierunkowane na zagrożenia'. Krajowe organy nadzoru w komunikatach DORA (styczeń 2025) wyjaśniły, że proste skanowanie podatności (Vulnerability Scan) nie spełnia tego wymogu - potrzebny jest pełny test penetracyjny z udokumentowanym zakresem, metodyką i Proof-of-Exploit. Dla istotnych i systemowo istotnych podmiotów (zgodnie z Art. 26 DORA) dochodzi dodatkowo standard TLPT (Threat-Led Penetration Testing zgodnie z ramami TIBER-EU), który mogą przeprowadzać wyłącznie akredytowani przez EBC dostawcy Red Team.

DORA Art. 24 ust. 1 i 2: Obowiązek regularnych testów bezpieczeństwa ICT, w tym testów penetracyjnych, dla wszystkich podmiotów finansowych zgodnie z Art. 2 DORA - banki, ubezpieczyciele, dostawcy usług płatniczych, firmy inwestycyjne, dostawcy usług krypto-aktywów, agencje ratingowe, dostawcy usług w zakresie danych.
DORA Art. 26 ust. 1: Obowiązek TLPT dla systemowo istotnych podmiotów - co najmniej raz na trzy lata pełny Threat-Led Penetration Test przez akredytowanego dostawcę, koordynowany z właściwym organem (KNF / EBC).
DORA Art. 24 ust. 7 i 8: Testy muszą być przeprowadzane przez niezależne strony (wewnętrzne lub zewnętrzne); przy krytycznych usługach ICT przez zewnętrznych testerów; pełna dokumentacja w tym 'raport końcowy zawierający wskazanie przeprowadzonych testów, użytych metod i stwierdzonych podatności'.
DORA RTS (rozporządzenie delegowane (UE) 2024/1774): Regulacyjne standardy techniczne precyzują wymagania dla testów bezpieczeństwa ICT - minimalne pokrycie, częstotliwość, obowiązki raportowania.
Wytyczne organów nadzoru DORA (styczeń 2025): Skany podatności nie zastępują testu penetracyjnego; audytor musi mieć możliwość zażądania udokumentowanego dowodu zakresu, kwalifikacji testera (OSCP/CREST lub równoważne) oraz obsługi wyników.
Osobista odpowiedzialność zarządu (Art. 5 DORA): Zarząd i rada nadzorcza są bezpośrednio odpowiedzialne za odporność ICT - brak dowodu pentestu jest bezpośrednim ryzykiem zarządczym.
Koordynacja transgraniczna (Art. 26 ust. 8 DORA): Dla podmiotów działających transgranicznie EBC koordynuje wspólne testy TLPT - wytyczne TIBER-EU definiują ramy.

Co musi obejmować test penetracyjny zgodny z DORA

Systemy ICT funkcji podstawowych (Art. 24 ust. 3 DORA): systemy bankowe, API obrotu płatniczego, platformy tradingowe, repozytoria danych klientów - pełna inwentaryzacja aktywów jako warunek wstępny.
Uwierzytelnianie i kontrola dostępu: implementacje MFA (wymagania PSD2 SCA), przepływy OAuth2/OIDC, Privileged Access Management (PAM), uprawnienia kont usługowych.
Bezpieczeństwo API zgodnie z OWASP API Top 10 (2023): API1 Broken Object Level Authorization, API2 Broken Authentication, API3 Broken Property Level Authorization - szczególnie krytyczne przy API Open Banking (PSD2, Berlin Group NextGenPSD2).
Segmentacja sieci i konfiguracja firewalla: separacja środowisk ICT (produkcja / staging / rozwój), ruch lateralny między segmentami, izolacja sieci SWIFT (SWIFT CSP CSCF v2024).
Szyfrowanie danych w spoczynku i przesyłanych: TLS 1.3 (RFC 8446), integracja HSM dla materiału kluczowego, przestarzałe pakiety szyfrów (bez RC4, 3DES, MD5), CVE-2023-0215 (OpenSSL) i CVE-2022-0778 (OpenSSL infinite loop) jako punkty odniesienia.
Zależności ICT od dostawców zewnętrznych (Art. 28 DORA): komponenty SaaS, dostawcy infrastruktury chmurowej, procesory płatności - ryzyka łańcucha dostaw, znane CVE w bibliotekach dostawców zewnętrznych.
Business Continuity & Disaster Recovery: test czy atakujący może skompromitować procesy backupu; symulacja ransomware przeciwko systemom backupu; weryfikacja czasu odtwarzania.
Inżynieria społeczna i symulacje phishingu (dla obszerniejszych zleceń TLPT): świadomość pracowników, techniczne kontrole wykrywania phishingu, czas reakcji zespołu incident response.
Infrastruktura chmurowa (Art. 28 DORA ryzyka stron trzecich): błędne konfiguracje IAM w AWS/Azure/GCP, uprawnienia S3 bucket, eksponowane konta storage, niezabezpieczone funkcje serverless.
Logowanie i monitoring (Art. 10 DORA): weryfikacja czy aktywności ataku są wykrywane w SIEM/SOAR - zasada 'detect what we do' jako dowód DORA.

Sample finding

Critical

Niezabezpieczony przepływ OAuth2 w bramie API Open Banking (naruszenie FAPI)

Brama API Open Banking implementuje OAuth2 Authorization Code Flow bez PKCE (Proof Key for Code Exchange, RFC 7636). Atakujący Man-in-the-Middle może przechwycić Authorization Code z URL przekierowania przeglądarki i bez posiadania Code Verifier wymienić go na Access Token. Dodatkowo endpoint tokenu nie akceptuje parametru 'state', co umożliwia Cross-Site-Request-Forgery przy inicjowaniu OAuth. Brama przetwarza dziennie >50.000 transakcji PSD2; skompromitowany token umożliwia pełny dostęp do odczytu danych konta i inicjowanego obrotu płatniczego.

Fix: Wdrożenie PKCE (RFC 7636) jako obowiązkowego wymogu dla wszystkich przepływów OAuth2 (także po stronie serwera, jako defense-in-depth). Walidacja parametru 'state' przy każdym żądaniu autoryzacji. Migracja do Financial-grade API Security Profile (FAPI 2.0, OpenID Foundation) jako best practice dla Open Banking. Rotacja tokenu po każdym użyciu, krótki czas życia Access Token (maks. 5 minut), Refresh Token tylko z rotacją. Udokumentować protokół testu penetracyjnego zgodnie z DORA Art. 24 ust. 7.

Reference: CVE-2022-21449 (ECDSA Psychic Signatures, Java) · OWASP API2:2023 Broken Authentication · RFC 7636 PKCE · DORA Art. 24 ust. 2 · PSD2 RTS on SCA (UE) 2018/389 Art. 9

DORA pentest: opcje w porównaniu

—	Free scan	Matproof Sentinel	Traditional consultancy
Automated scan engine	✓ (3-min preview)	✓ Full scan	✗ Manual only
OWASP Top 10 coverage	Partial	✓ Complete	✓ Complete
Proof-of-exploit evidence	✗	✓ Per finding	✓ Per finding
Regulatory mapping (DORA/NIS2/ISO 27001)	✗	✓ Automated	✓ Manual
Audit-ready PDF report	✗	✓ Instant	✓ 2–4 weeks delivery
Continuous / recurring scans	✗	✓ Per deploy	✗ Annual engagement
Time to first result	~3 min	~30 min full scan	2–4 weeks
Price	€0	From €149	€8,000–€25,000
Source code review (SAST)	✗	✓ On Growth plan	✓ Scoped engagement
API testing (REST/GraphQL)	✗	✓ Automated	✓ Manual

Pakiety pentestu zgodne z DORA

Single Run

€149 one-time

1 full pentest scan
AI-prioritized findings with CVSS 3.1
Proof-of-exploit per finding
Audit-ready PDF report
Regulatory mapping (DORA, NIS2, ISO 27001)

Unlimited scans (up to 3 domains)
Continuous monitoring
CI/CD integration (GitHub, GitLab)
All regulatory mappings
Priority support

Start Starter →

Growth

€799 / month

Unlimited scans + domains
Authenticated / White-Box testing
API & cloud infrastructure tests
Dedicated security account manager
24h SLA response time

Contact for Growth →

Najczęstsze pytania dotyczące testu penetracyjnego DORA

Kogo dotyczy obowiązek testu penetracyjnego DORA Art. 24?

Art. 2 DORA definiuje zakres zastosowania: instytucje kredytowe, instytucje płatnicze, instytucje pieniądza elektronicznego, firmy inwestycyjne, zakłady ubezpieczeń, agencje ratingowe, repozytoria transakcji, systemy obrotu, dostawcy usług w zakresie krypto-aktywów (zgodnie z MiCA), dostawcy usług w zakresie danych oraz krytyczni zewnętrzni dostawcy usług ICT. Nie są wprost wyłączeni także dostawcy oprogramowania, którzy mogą zostać sklasyfikowani jako 'krytyczni zewnętrzni dostawcy usług ICT'. Małe i średnie przedsiębiorstwa (Art. 3 DORA) podlegają uproszczonym wymaganiom, ale i tu obowiązuje zasada regularnych testów technicznych.

Jaka jest różnica między pentestem DORA Art. 24 a TLPT zgodnie z Art. 26?

Art. 24 nakazuje ogólne testy penetracyjne dla wszystkich objętych podmiotów finansowych - częstotliwość, zakres i głębokość są oparte na ryzyku, ale musi istnieć udokumentowany raport pentestu. Art. 26 TLPT (Threat-Led Penetration Testing) to dalej idący wymóg tylko dla 'istotnych' podmiotów (systemowo istotne banki, istotni ubezpieczyciele): co najmniej raz na trzy lata pełny test Red Team, gdzie akredytowany dostawca wyprowadza metodykę z rzeczywistej threat intelligence i atakuje bez zapowiedzi. TLPT kosztuje zazwyczaj €80.000-€250.000; standardowy pentest DORA jest możliwy do spełnienia platformą pentestu AI taką jak Matproof Sentinel lub dostawcą butikowym (€8.000-€25.000).

Jak często musi być przeprowadzany pentest DORA?

Sam DORA nie podaje stałej częstotliwości - Art. 24 ust. 1 mówi o 'regularnie'. Interpretacja organów nadzoru i wytyczne EBA zazwyczaj zakładają co najmniej coroczne testy dla systemów krytycznych i po istotnych zmianach. Art. 26 TLPT dla objętych podmiotów wprost nakazuje co najmniej raz na trzy lata. Rekomendacja: coroczny pełny pentest + ciągłe skanowanie (np. przez Matproof Sentinel) po każdym major release.

Co musi zawierać raport pentestu DORA?

Art. 24 ust. 7 DORA wymaga: udokumentowanego zakresu (które systemy były testowane), użytej metodyki, stwierdzonych podatności z poziomem krytyczności, zaleceń naprawczych i statusu (naprawione / w naprawie / zaakceptowane). Krajowe organy nadzoru zalecają dodatkowo: kwalifikację testera (OSCP/CREST lub równoważne), użyte ramy testowe (PTES, OWASP Testing Guide), Proof-of-Exploit dla wyników krytycznych i wysokich. Matproof Sentinel dostarcza wszystkie te elementy w raporcie PDF.

Czy Matproof Sentinel może zastąpić test TLPT DORA Art. 26?

Nie - DORA Art. 26 TLPT wymaga dla systemowo istotnych podmiotów akredytowanego przez EBC dostawcy Red Team. Matproof Sentinel to platforma pentestu wspierana przez AI i doskonale nadaje się do regularnego pentestu DORA Art. 24, przygotowania do TLPT (analiza luk, bazowy stan podatności) oraz ciągłych testów bezpieczeństwa między cyklami TLPT. Dla TLPT chętnie pośredniczymy w kontakcie z akredytowanymi partnerami.

Co się dzieje, gdy podmiot finansowy nie może wykazać pentestu DORA?

KNF i EBC mogą za naruszenia wymagań DORA nakładać kary pieniężne do 1 % globalnego dziennego obrotu (Art. 50 DORA). Przy powtarzających się lub poważnych naruszeniach możliwe jest również zawieszenie działalności gospodarczej. Ponadto zarząd odpowiada osobiście (Art. 5 DORA). W praktyce brak dowodów pentestu przy kontrolach nadzorczych (badanie sprawozdania rocznego, kontrole specjalne) jest klasyfikowany jako istotny brak, który uruchamia obowiązki naprawcze i wykazujące.

Czy zewnętrzni dostawcy ICT (chmura, SaaS) również muszą przeprowadzać pentesty DORA?

Bezpośrednio: tak, jeśli są sklasyfikowani jako 'krytyczni zewnętrzni dostawcy usług ICT' zgodnie z Art. 31 DORA (klasyfikacja przez EBA/ESMA/EIOPA). Podlegają wtedy bezpośrednio nadzorowi DORA. Pośrednio: wszyscy pozostali zewnętrzni dostawcy ICT muszą poprzez klauzule umowne (Art. 30 DORA) spełniać minimalne wymagania bezpieczeństwa, które mogą obejmować testy penetracyjne. Podmiot finansowy musi zgodnie z Art. 28 DORA zapewnić, że jego krytyczni dostawcy zewnętrzni prowadzą odpowiednie testy bezpieczeństwa.

Jak DORA i NIS2 są ze sobą powiązane - które prawo obowiązuje kogo?

DORA to sektorowe prawo specjalne dla podmiotów finansowych i jako lex specialis ma pierwszeństwo przed NIS2, w zakresie w jakim dotyczy podmiotów finansowych. NIS2 obowiązuje ogólnie dla podmiotów kluczowych i ważnych w sektorach krytycznych (Art. 3 dyrektywy NIS2), ale Art. 4 dyrektywy NIS2 wyjaśnia, że sektorowe prawo UE (takie jak DORA) ma pierwszeństwo. Przedsiębiorstwa, które podlegałyby zarówno DORA, jak i NIS2, muszą spełniać tylko DORA - regulator zakłada, że zgodność z DORA w pełni pokrywa NIS2.

Go deeper — related blog articles

Rozpocznij teraz pentest zgodny z DORA

Otrzymaj w 3 minuty pierwszą ocenę swojej sytuacji bezpieczeństwa ICT - bez logowania, bez umowy. Pełny pentest Matproof Sentinel dostarcza raport gotowy do audytu, który spełnia wymagania DORA Art. 24 ust. 7. Dla TLPT zgodnie z Art. 26 pośredniczymy w kontakcie z akredytowanymi partnerami.