DORA and Penetration Testing: Digital Operational Resilience Testing for Financial Entities

On 17 January 2025, the EU's Digital Operational Resilience Act (DORA) entered into force. For the financial sector, this marks a culture shift in security testing: before DORA, a penetration test was a procurement decision; after DORA, it is a regulated obligation — audited, reported, and overseen by competent authorities.

This guide covers DORA's testing requirements (Articles 24-27), who falls under threat-led penetration testing (TLPT), what the June 2025 RTS 2025/1190 changed, and how non-EU providers are affected.

Who Does DORA Apply To?

DORA covers 20+ types of financial entities operating in the EU:

• Credit institutions (banks)
• Payment institutions and electronic money institutions
• Insurance and reinsurance undertakings
• Investment firms, crypto-asset service providers (licensed under MiCA)
• Credit rating agencies, fund managers, pension funds
• ICT third-party providers critical to the financial sector (cloud, data centres, managed services)

That last category matters beyond the EU: a Turkish software house, data centre, or managed service provider serving EU financial clients — without being a financial entity itself — can fall under DORA's third-party regime. Being headquartered outside the EU does not exempt you.

The Testing Layers: Articles 24 Through 27

DORA builds its testing obligation in two tiers:

Tier 1: Basic Testing Programme (Articles 24-25) — Everyone

All in-scope entities (except microenterprises) must run a testing programme integrated into their ICT risk management framework. Article 25 enumerates test types: vulnerability assessments and scans, network security assessments, source code reviews, performance testing, end-to-end testing, and penetration testing.

Expectations:

• At least annual testing of critical systems
• Risk-based depth: proportional to the entity's size, risk profile, and ICT criticality
• Event-based triggers: testing after major changes, upgrades, or incidents
• Organizational independence of testers (no conflict of interest)

Tier 2: TLPT (Articles 26-27) — Designated Entities

Threat-Led Penetration Testing is DORA's heavy artillery: an intelligence-led red team operation mimicking real threat actors' tactics, techniques and procedures, executed on live production systems.

Who is subject to it? Entities designated by their competent authority based on systemic importance, financial stability impact, and ICT risk profile. In practice: large banks (G-SIBs/O-SIIs), major payment institutions, insurers, and similar.

Core rules:

• At least every three years (the authority may adjust frequency)
• Executed per the TIBER-EU framework (mandated by RTS 2025/1190)
• External red teams only (Article 26(8)) — even with internal testers, an external tester contract is required every third test
• Threat intelligence providers (TIPs) and red teams must meet Article 27's independence and confidentiality requirements
• The test covers live production systems supporting critical or important functions
• A purple teaming exercise in the closure phase: replaying the attack and joint learning with the blue team

RTS 2025/1190: What Became Concrete in June 2025?

The Delegated Regulation, published 18 June 2025, fixed TLPT's operational details:

1. Selection criteria: quantitative criteria (e.g., market share) plus qualitative assessment (risk profile, systemic character). Credit institutions, payment/e-money institutions, CCPs, CSDs, trading venues, and insurers meeting the criteria are subject to TLPT by default — though the authority may exempt based on overall ICT risk assessment.
2. Crypto ASPs included: MiCA-licensed crypto-asset service providers can be brought into TLPT via qualitative assessment.
3. Tester requirements: TIP and red team independence, competence, and confidentiality must be documented pre-contract; the control team is responsible for verifying this.
4. Joint and pooled tests: entities in the same group, or sharing a third-party provider, may run joint or pooled TLPTs.
5. Process and deliverables: fixed phases from the notification letter (preparation → threat intelligence → red team testing → closure), mandatory reports (red team report, blue team report, test summary report, remediation plan), and supervisory cooperation.

The Non-EU View: Does DORA Concern You?

Three scenarios where it does:

1. You have an EU branch or licensed entity — you are directly in scope.
2. You provide ICT services to EU financial clients — the third-party regime: contractual obligations, exit strategies, audit cooperation, and the likelihood of being tested within your client's TLPT scope.
3. You are a financial institution trading with the EU — DORA doesn't apply directly, but clients and parallel regulators push the same direction. Being DORA-ready means being ready for the next regulation too.

Practical indicator: if an EU bank or payment institution sends you a vendor security questionnaire asking "have you been tested under TLPT, or would you be fit for it?" — you are already in the process.

Preparation Roadmap: 12 Months to TLPT Readiness

Months 1-2: Critical function inventory. List all ICT systems, processes, and third-party dependencies supporting "critical or important functions" in DORA's language. TLPT scope is selected from this inventory — if you don't have one, scope gets selected for you.

Months 3-4: Build the basic testing programme. The Article 24-25 obligation: annual pentest, vulnerability scanning, and source code review cadence. Provable basic hygiene is required before TLPT — authorities won't launch TLPT on a low-maturity entity, but they will separately penalize a missing basic programme.

Months 5-6: Blue team readiness. TLPT's value is not repelling the attack but learning from it. Log infrastructure, detection rules, incident response runbooks, and communication trees are what get tested. A poorly prepared blue team = wasted TLPT budget.

Months 7-9: Provider selection. Document TIP and red team providers' Article 27 compliance (independence, competence, confidentiality). The RTS makes this pre-contract verification the control team's responsibility.

Months 10-12: Scope validation and rehearsal. Internal rehearsal before scope validation with the authority: scenarios, target systems, safety-lock procedures.

Frequently Asked Questions

Who is subject to DORA TLPT?

Financial entities designated by their competent authority based on systemic importance, financial stability impact, and ICT risk profile. Per RTS 2025/1190, credit institutions, payment and e-money institutions, CCPs, CSDs, trading venues, and insurers meeting the criteria are subject by default; the authority may exempt based on overall risk assessment. MiCA-licensed crypto ASPs can also be included via qualitative assessment.

How often must DORA tests be performed?

Two tiers: the Article 24-25 basic testing programme (including penetration testing) at least annually for critical systems; TLPT (Article 26) at least every three years for designated entities. Major changes and incidents trigger event-based testing.

What are the penalties for DORA non-compliance?

DORA sets penalty frameworks at member-state level but draws upper bounds: periodic fines up to 1% of average daily worldwide turnover or €5 million for larger entities, plus daily administrative fines. The real cost is not the fine: the authority holds the management body personally accountable, can restrict business models, and non-compliant providers lose EU financial clients.

How does DORA affect a non-EU software company?

If you provide ICT services to EU financial entities, you enter DORA's third-party regime: contractual security commitments, audit cooperation, exit strategy, and incident notification obligations. Your systems may also be tested within your client's TLPT scope.

What's the difference between TLPT and a normal pentest?

A normal pentest hunts vulnerabilities in defined systems; TLPT is a full red team operation driven by real threat intelligence, executed on live production, targeting critical functions — under authority oversight, per TIBER-EU methodology, with external providers and a purple teaming closure phase.

Closing

DORA turns security testing in finance from "an annual report" into a continuous, intelligence-led, auditable operation. Whether or not you enter TLPT scope, the direction is the same: a provable testing programme, a ready blue team, and documented provider trust.

Eresus Security conducts TIBER-EU-aligned red team operations and pre-TLPT readiness assessments. To evaluate your entity's DORA testing maturity, request a scoping call.