DORA Penetration Testing: What CTOs and CISOs Need to Know
Key Takeaways
- DORA uses penetration testing to prove that systems can withstand real-world cyber threats, not just find vulnerabilities.
- Every financial entity is in scope; systemically important ones face stricter, threat-led testing requirements.
- Tests must be risk-driven, intelligence-informed, and tied to governance, with clear documentation and remediation.
- Third-party vendors and non-EU providers aren’t exempt if they support critical functions.
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:
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).
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. |
Note: Microenterprises are subject to DORA’s penetration testing requirements but may apply proportionality based on size and ICT complexity. Testing can be scaled, but not skipped.
Meanwhile, Third-party ICT service providers, particularly those supporting CIFs, are increasingly under scrutiny. While not regulated directly under DORA, they may be:
- Included in TLPT exercises as part of cross-organizational threat scenarios.
- Required to support access, documentation, and coordination during testing.
- Subject to oversight under DORA’s critical third-party oversight framework (e.g., cloud infrastructure, core banking platform, etc.)
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.
Subcontractors, Shared Risk, and the Compliance Blind Spot
DORA makes it clear that regulated entities are accountable for the resilience of their vendors. If your service underpins theirs, you may be pulled into their testing scope.
Implications:
- SLAs and contracts must support test participation
- Architecture must allow safe, observable testing
- Test refusal or fragility could become a deal-breaker
Resilience is no longer internal. It’s shared and visible.
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 |
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
How is TLPT different from regular penetration testing?
TLPT simulates real-world attacks based on current threat intelligence and adversary tactics. Unlike regular pentests, which are scoped and checklist-driven, TLPT tests resilience by mimicking sophisticated threat actors to assess detection, response, and recovery capabilities across systems, people, and processes.
Who needs to do TLPT under DORA?
Under DORA, TLPT is mandatory for critical financial entities designated by European supervisory authorities. This includes major banks, payment institutions, clearing houses, and certain ICT third-party providers whose disruption could impact financial stability or operational continuity across the EU.
What’s the testing frequency under DORA?
Entities must conduct TLPT at least once every three years, unless regulators specify otherwise. However, frequency may be adjusted based on risk level, previous test outcomes, or material changes in the threat landscape or operational structure.
Does DORA apply to SaaS vendors?
Yes, if your SaaS solution supports core financial operations or serves regulated financial entities, DORA may apply. ICT third-party service providers, including cloud and SaaS vendors, may fall under oversight, especially if they’re deemed critical to financial sector stability or continuity.