DORA Penetration Testing: What CTOs and CISOs Need to Know

The Digital Operational Resilience Act (DORA) is the EU’s response to the increasing operational risks posed by an interconnected financial system. It’s about more than cybersecurity; it’s about proving that financial institutions can keep critical services running through disruption.

That’s where DORA penetration testing fits in. It shifts testing from a technical task to a strategic control, one that connects technology, risk, and business continuity. Understanding who is in scope, what is required, and how to operationalize it is now essential.

What is DORA Penetration Testing?

DORA penetration testing is a structured, risk-driven simulation designed to emulate real-world threat conditions. Depending on the criticality of the entity and its functions, DORA defines two key layers of penetration testing: baseline annual testing for all financial entities, and threat-led penetration testing or TLPT for institutions deemed systemically important. 

These requirements signal a shift in regulatory expectations from vulnerability identification to operational proof of cyber resilience.

Article 24: Annual Testing Program for All Financial Entities

DORA’s testing framework begins with a broad mandate that states all regulated financial entities must run an annual security test tailored to the nature, scale, and complexity of their ICT landscape, explicitly calling for the prioritization of systems supporting critical functions with a threat-informed lens. 

Penetration testing isn’t a standalone task here. It must be part of a broader risk strategy, where you choose what to test based on the potential damage an attack could cause, whether that’s from data loss, business disruption, or service downtime. Simply put, this article applies to:

1. All regulated financial entities, including:

• Banks (retail, investment, and commercial),
• Insurance undertakings,
• Investment firms and asset managers,
• Payment institutions and e-money institutions,
• Credit rating agencies,
• Crowdfunding service providers, and
• Crypto-asset service providers (if within the scope of EU MiCA regulation).

2. Microenterprises, albeit with proportional expectations, where testing programs can be scaled down based on:

• Business model,
• Size of ICT estate, and
• Degree of digital exposure.

Overall, Article 24 encourages financial firms to adopt more consistent and disciplined testing practices to guide top-level decision-making, shape remediation plans, and enhance resilience over time. 

Article 26

Institutions identified as having systemic relevance to financial stability are subject to TLPT, a more rigorous, intelligence-driven assessment conducted at least every three years that replicates the tactics, techniques, and procedures of advanced threat actors. 

Unlike traditional penetration testing, TLPT seeks to understand how far an attacker could realistically penetrate, what could be accessed, how long they could remain undetected, and whether incident handling mechanisms are capable of containing the threat promptly. Entities likely to qualify for TLPT include:

1. Top-tier banking groups and central clearing counterparties, such as:

• Major retail and investment banks (e.g., BNP Paribas, Deutsche Bank)
• Globally Systemically Important Banks (G-SIBs)
• Central securities depositories and settlement infrastructures

2. Market infrastructure providers, including:

• Stock exchanges (e.g., Euronext)
• Payment systems operators (e.g., TARGET2, SEPA processors)
• Large custodians or transaction processors

3. Significant insurance groups, particularly those offering services across multiple jurisdictions or managing large-scale digital underwriting and claims systems

4. Critical third-party providers, when supporting essential functions for multiple financial entities, are subject to inclusion in TLPT scoping under collaborative arrangements.

Moreover, it requires resilience engineering through simulated conflict to be conducted by independent, certified testers, with oversight from national competent authorities that ensures operational transparency and a level of assurance that goes beyond internal declarations or third-party attestations.

What Does the RTS Clarify? (And What They Don’t)

While the above articles outline the broad contours of pentesting requirements under DORA, the Regulatory Technical Standards (RTS), developed by the European Supervisory Authorities (ESAs), are crucial for understanding their implementation. They provide detailed clarity on operational elements while deliberately leaving room for institutional interpretation in others.

Key Areas Where RTS Provides Clarity

1. Testing Scope and Frequency

• Annual penetration testing is the baseline requirement under Article 24.
• TLPT must be conducted at least once every three years for qualifying institutions.
• Testing must be risk-based, i.e., it must calibrate scope & intensity per system criticality and threat exposure.

2. Critical Functions and System Mapping

• RTS requires identification and documentation of critical and important functions (CIFs).
• Institutions must maintain an up-to-date inventory of ICT assets, including their interdependencies and third-party integrations.

3. Independence and Qualifications of Testers

• Penetration testers for TLPT must be independent of the systems they test and certified by a recognized authority such as CREST, OSCP, or TIBER-EU.
• Institutions must document how such independence is ensured, including policies for rotation and conflict of interest declarations.

4. Governance and Oversight

• Testing programs must be formally approved by senior management.
• Results must be integrated into risk management, incident response, and remediation planning workflows to ensure effective management.
• TLPT exercises must include regulatory notification and, in some cases, supervisory coordination (e.g., approval of scope, observer rights).

5. Reporting and Documentation

Institutions are required to maintain detailed testing reports, including:

• Objectives and scope
• Methodologies used
• Findings and severity ratings
• Root cause analysis
• Remediation actions and timelines

Where the RTS Leaves Room for Interpretation

Despite the technical depth, RTS intentionally avoids excessive rigidity. This is to accommodate the diversity of entity sizes, business models, and technological architectures across the European financial sector. 

Area of Interpretation	What the RTS States	What This Means in Practice
Granularity of TLPT Scenarios	Requires realistic adversary emulation but does not mandate a standard threat library or attack set.	Institutions must develop tailored scenarios using relevant threat intelligence and sector-specific risks.
Definition of "Proportionality"	Recognizes that smaller entities can scale testing efforts, but provides no fixed thresholds.	Microenterprises must apply judgment in reducing test scope or frequency without compromising core resilience.
Tooling and Methodology	Does not prescribe a specific framework for baseline testing.	Entities must select industry-accepted methodologies (e.g., OWASP, NIST, OSSTMM) aligned with ICT complexity.
Integration with External Frameworks	Acknowledges frameworks like TIBER-EU, CBEST, and iCAST but stops short of prescribing how they should be integrated.	Institutions may adopt or align with these frameworks, but must ensure coherence with DORA’s core requirements.

TLPT vs. Traditional Penetration Testing

Dimension	Traditional Penetration Testing	Threat-Led Penetration Testing (TLPT)
Objective	Identify technical vulnerabilities	Emulate real-world threat scenarios to test resilience
Approach	Checklist- or tool-based; follows known attack paths	Intelligence-driven; mimics TTPs of specific threat actors
Scope	Defined by asset inventory or technical boundaries	Scoped to critical functions and systems based on risk/threat mapping
Frequency	At least annually (under DORA Article 24)	At least every three years (under DORA Article 26)
Depth	Surface-to-mid-layer testing	Deep, lateral movement across systems and users
Testing Team	Internal or external testers	Certified, independent red teams
Regulatory Involvement	Minimal, mostly internal reporting	Regulatory oversight and notification are required
Test Basis	Technical configurations, OWASP Top 10, CVE libraries	Sector-specific threat intelligence and adversary emulation
Outcomes	Vulnerability list and remediation plan	Operational insight into detection, response, and containment capability
Post-Test Actions	Fix technical issues; update patch cycles	Improve response playbooks, escalation chains, and monitoring controls

How TLPT Aligns with TIBER-EU and Intelligence-Led Testing Frameworks

TLPT under DORA isn’t a brand-new concept; it closely mirrors the TIBER-EU framework developed by the European Central Bank. Like TIBER-EU, TLPT is designed to simulate realistic, high-impact cyberattacks against critical business services using actual threat intelligence.

Here’s what TLPT (and TIBER-EU) have in common:

• Tests are based on actual threat actors, not guesswork.
• They look at people, processes, and technology, not just software.
• There’s close coordination with regulators on scope, safety, and reporting.
• Internal “white teams” monitor the test to keep it controlled and safe.
• You get insights into your full response cycle: detection, containment, communication, and recovery.

DORA doesn’t say you have to use TIBER-EU. But if you’re already doing it—or using CBEST (UK) or iCAST (Asia), you’re most of the way there.

Who Can Perform TLPT?

DORA sets strict rules about who’s allowed to perform TLPT. Only qualified, independent red teams are permitted. Here’s what’s required:

• Independence: The testers must have no role in building or managing the systems being tested.
• Certification: Teams must be credentialed by recognized bodies, such as:
  • TIBER-EU certified providers
  • CREST-accredited red teams
  • OSCP/OSCE-certified professionals with red teaming experience
• Experience: Vendors must demonstrate a proven track record with high-stakes, regulated systems, particularly those associated with critical infrastructure.

In addition:

• Institutions must carry out formal due diligence on TLPT vendors.
• Vendor selection should be documented and justifiable.
• Regulators may require involvement in scope-setting, and firms must be prepared to share results as part of the oversight process.

Are You on the Hook? Who Must Comply with DORA’s Testing Mandates

DORA’s testing requirements apply not only to banks and insurance firms but also to other financial institutions. They cover the full operational footprint of the EU financial sector, including vendors, platforms, and non-EU tech providers that enable critical functions.

Financial Entities: From Systemically Important to Payment Startups

All regulated financial entities in the EU fall under DORA. This includes major banks and insurers, as well as fintechs, payments firms, and cryptocurrency platforms. Scale does not exempt. If you operate in the EU financial system, you’re expected to test ICT resilience proportionately, but rigorously.

SaaS & ICT Vendors: Direct or Indirect Responsibility

Vendors that enable or host critical functions, via APIs, cloud services, or core infrastructure, are increasingly within scope. Even without direct regulatory exposure, you may be required to:

• Participate in a client’s threat-led test
• Support secure access and test environments
• Provide evidence of your testing discipline

Expect DORA-aligned clauses in contracts and security reviews. Engineering and product leaders must design systems for testability and transparency, not just performance. To assess and operationalize vendor readiness:

• Map critical dependencies to understand which vendors support regulated functions.
• Update contracts to include provisions for testing participation, data sharing, and access to simulations.
• Request evidence of their testing programs and how they support TLPT readiness (e.g., isolated environments, audit logs).
• Evaluate coordination capability, how vendors will respond to simulated threats, manage communications, and support investigation.
• Include third parties in joint tabletop exercises to validate their integration in your detection and response chain.

DORA treats digital resilience as a shared obligation. Your vendors are either an extension of your strength or a source of unmanaged risk.

What If You’re a Non-EU Company Serving EU Banks?

Location offers no immunity. If you serve EU-regulated clients, you may be asked to support red teaming exercises, enable access for supervised testing, or demonstrate resilience controls.

Prepare to offer isolated test environments, support client-led simulations, and show readiness for joint operational testing. DORA is quickly becoming a procurement filter, where non-compliance will impact access to European financial clients.

The “Criticality” Test: What Triggers TLPT

Supervisors apply a risk-based lens to determine who must undergo threat-led testing. Factors include:

• Role in critical transactions or services
• Interconnection with other institutions
• Operational impact in case of disruption

If your system enables core processes, such as payments, trading, and credit decisions, you may be subject to TLPT, either directly or through client integration.

What Regulators Expect: Reporting and Documentation Requirements

Regulatory Requirement	What It Means	Documentation Required
Defined Testing Strategy	Annual testing aligned with risk profile and business functions	Testing policy, annual test plan, risk classification of ICT assets
Clear Scope and Criticality Mapping	Focus on systems supporting critical functions	Asset inventory with business impact mapping, critical function registry
Qualified & Independent Test Execution	Internal or external testers must be qualified and demonstrably independent	Tester credentials, independence declarations, vendor assessments
Methodology Transparency	Use of structured frameworks for pen testing and TLPT	Methodological framework (e.g., TIBER-EU, NIST), test scripts, threat models
Evidence of Testing and Findings	Testing must generate actionable insights and demonstrate coverage	Test reports, logs, screenshots, lateral movement paths, root cause summaries
Remediation and Risk Treatment	Gaps must be tracked, prioritized, and resolved on time	Remediation tracker, ticketing logs, sign-offs, risk acceptance statements
Governance and Reporting Oversight	Senior management must review and own testing outcomes	Board or committee briefings, risk reports, corrective action dashboards
Regulator Coordination (TLPT)	Pre-approval and observation may be required for high-impact institutions	Communications with competent authorities, scope sign-off, observer notes

How Can Astra Help?

As a CREST-accredited and PCI ASV-certified platform, Astra Security helps organizations meet DORA’s security testing and resilience requirements through continuous, automated, and manual VAPT. Its PTaaS platform offers web app, API, and cloud infrastructure testing, all mapped to real-world risk and compliance needs.

With 15,000+ test cases, expert-validated findings, and audit-ready reports, Astra enables ongoing threat exposure management, fix validation, and incident readiness. Built-in CI/CD integration, role-based access, and compliance tracking ensure that security is embedded into digital operations, as mandated by DORA.

Final Thoughts

DORA penetration testing is a signal that operational resilience is now a board-level, engineering-deep mandate. The challenge ahead isn’t whether to act, but how quickly and confidently you can align testing with real-world threats and regulatory scrutiny.

From here, the priority is clarity: clarity on what is critical, who is responsible, and how resilience will be demonstrated under pressure. Organizations that treat this as a strategic capability (not a regulatory chore) will be the ones trusted to lead in a digitized, high-stakes financial system.

FAQs