DORA Operational Resilience Testing and TLPT: Pillar 3 Requirements

Introduction to Pillar 3: Digital Operational Resilience Testing

Pillar 3 of DORA (Articles 24-27) establishes the requirements for digital operational resilience testing. The premise is straightforward: resilience cannot be assumed — it must be validated through rigorous, regular testing that simulates real-world conditions and threats.

DORA's testing requirements go significantly beyond the penetration testing and vulnerability assessments that most financial entities already perform. The Regulation mandates a comprehensive testing programme covering 12 specific testing types, and for identified entities, advanced threat-led penetration testing (TLPT) that simulates the tactics, techniques, and procedures of real-world threat actors targeting the financial sector.

This guide provides a practical walkthrough of both tiers of DORA testing. For basic testing, we cover each of the 12 required testing types with practical implementation guidance. For TLPT, we explain the identification criteria, TIBER-EU alignment, the phases of a TLPT exercise, provider selection, pooled testing, and documentation requirements.

Testing Programme Requirements (Article 24)

Article 24 requires all in-scope financial entities to establish, maintain, and review a sound and comprehensive digital operational resilience testing programme. The programme must be proportionate and risk-based.

Programme Fundamentals

• The testing programme must be an integral part of the ICT risk management framework
• It must cover all critical and important functions and ICT systems supporting them
• Testing must be risk-based — more critical systems require more rigorous and frequent testing
• The programme must be documented, approved by the management body, and reviewed at least annually
• Testing must be performed by qualified testers — internal testers must be independent from the function being tested
• The entity must establish follow-up processes to ensure findings are remediated

Proportionality in Testing

The testing programme applies proportionately based on entity size and risk profile:

• Large, complex entities: Full testing programme across all 12 types; annual testing of all critical systems; TLPT if identified
• Medium entities: Full testing programme; annual testing of critical systems; risk-based selection of testing types for non-critical systems
• Small entities and micro-enterprises: Proportionate programme; focus on vulnerability assessments, scenario testing, and basic penetration testing; reduced frequency for non-critical systems

Basic Testing Types (Article 25)

Article 25 specifies 12 types of testing that should form part of the digital operational resilience testing programme. Not every entity must perform all 12 types to the same depth, but the testing programme must address each type proportionately.

Vulnerability Assessments and Scanning

Vulnerability assessments form the foundation of the testing programme. They provide continuous visibility into the security posture of the entity's ICT infrastructure.

Requirements

• Automated vulnerability scanning of all networked systems, including servers, endpoints, network equipment, and applications
• Scanning must cover both internal and external-facing assets
• Results must be risk-rated and prioritised for remediation
• Critical vulnerabilities in critical systems must be remediated within defined timelines
• Scanning frequency should be at least quarterly for all systems, monthly for internet-facing and critical systems
• Open-source component analysis should be integrated into the vulnerability management programme

Open-Source Analysis

DORA specifically calls out open-source analysis as a testing type. This reflects the widespread use of open-source software in financial services and the risks associated with vulnerabilities and supply chain compromises in open-source components. Entities should:

• Maintain a software bill of materials (SBOM) for critical applications
• Monitor open-source components for newly disclosed vulnerabilities
• Assess licence compliance for open-source usage
• Have processes to rapidly update or replace vulnerable open-source components

Penetration Testing

Penetration testing under DORA goes beyond standard vulnerability scanning to include simulated attacks that test the entity's ability to detect and respond to exploitation attempts.

Penetration Testing Requirements

• Annual penetration testing of all critical and important ICT systems
• Testing should cover both external (internet-facing) and internal attack surfaces
• Testing methodology should be risk-based, focusing on the most critical systems and attack vectors
• Testing must include application-layer testing, not just infrastructure
• Social engineering testing (phishing, pretexting) should be included where appropriate
• Findings must be classified by severity and remediated within defined timelines
• Remediation must be validated through re-testing

Penetration Testing vs. TLPT

It is important to distinguish basic penetration testing (required for all entities) from TLPT (required only for identified entities). Key differences:

• Scope: Penetration testing focuses on finding vulnerabilities; TLPT simulates realistic threat actor campaigns
• Intelligence: Penetration testing uses standard methodologies; TLPT is driven by bespoke threat intelligence
• Duration: Penetration tests typically last 2-4 weeks; TLPT campaigns run for 12-16 weeks
• Oversight: Penetration tests are managed internally; TLPT involves competent authority oversight
• Testers: Penetration testing may use internal testers; TLPT requires qualified external providers

Scenario-Based Testing

Scenario-based testing validates the entity's ability to respond to specific disruption scenarios, bridging the gap between technical testing and business continuity exercises.

Scenario Categories

• Cyber attack scenarios: Ransomware, data breach, DDoS, advanced persistent threat, supply chain compromise
• System failure scenarios: Hardware failure, software defect, database corruption, network outage
• Third-party failure scenarios: Critical provider outage, service degradation, data breach at provider
• Natural disaster scenarios: Data centre loss, power failure, communications disruption
• Combined scenarios: Multiple simultaneous disruptions testing resilience under compound stress

Scenario Testing Methodology

• Scenarios should be based on realistic threats relevant to the financial sector
• Include both tabletop exercises (discussion-based) and simulation exercises (technical validation)
• Involve all relevant functions: IT, Security, Business Continuity, Communications, Legal, and Senior Management
• Test recovery time objectives (RTOs) and recovery point objectives (RPOs) in practice
• Document outcomes, lessons learned, and improvement actions
• Report results to the management body

Other Required Testing Types

Network Security Assessments

Review network architecture for security weaknesses including segmentation effectiveness, firewall rule analysis, wireless security, and remote access controls. Network security assessments should validate that the network architecture supports the protection requirements identified in the ICT risk management framework.

Physical Security Reviews

Assess physical security controls protecting ICT infrastructure including data centres, server rooms, network equipment locations, and backup storage facilities. Reviews should cover access controls, environmental controls, CCTV, and visitor management.

Compatibility Testing

Test interoperability between systems, particularly following changes, upgrades, or introduction of new components. This is especially important for entities with complex, multi-vendor ICT environments and significant third-party integrations.

Performance Testing

Validate that ICT systems can handle expected and peak transaction volumes. Performance testing should include load testing (normal peak), stress testing (beyond normal peak), and capacity planning validation. Testing should cover end-to-end transaction paths including third-party service integrations.

Advanced TLPT: Overview

Threat-Led Penetration Testing (TLPT) is DORA's most demanding testing requirement. It represents a significant step up from conventional penetration testing, simulating the tactics, techniques, and procedures (TTPs) of real-world threat actors that target the financial sector.

TLPT Objectives

• Test the entity's detection and response capabilities against realistic, intelligence-driven attack scenarios
• Identify vulnerabilities that conventional testing may miss due to the adversarial simulation approach
• Validate the effectiveness of the entity's people, processes, and technology against sophisticated threats
• Provide supervisors with confidence in the entity's resilience against real-world cyber threats

Who Must Perform TLPT

Article 26(8) requires competent authorities to identify the financial entities that must carry out TLPT. The identification criteria consider:

• Systemic importance: Entities whose disruption would significantly affect financial stability or market functioning
• Overall risk profile: The entity's ICT risk profile, including complexity, interconnectedness, and dependency on ICT
• Criticality of ICT systems: The importance of the entity's ICT systems to the broader financial system

Typically Identified Entities

• Systemically important credit institutions (G-SIBs, O-SIBs)
• Central counterparties (CCPs)
• Central securities depositories (CSDs)
• Trading venues operating regulated markets
• Large payment institutions and electronic money institutions
• Other entities identified by competent authorities based on risk assessment

TIBER-EU Alignment

DORA Article 26(1) requires TLPT to be carried out in accordance with the TIBER-EU framework. TIBER-EU (Threat Intelligence-Based Ethical Red-Teaming) is the European framework for controlled, bespoke, intelligence-led red team tests of financial entities' critical live production systems.

TIBER-EU Principles

• Intelligence-led: Tests are driven by bespoke threat intelligence specific to the entity, not generic attack playbooks
• Live production: Tests are conducted against live production systems (not test environments) to provide realistic results
• Controlled: Tests are conducted with strict controls to prevent unintended disruption to financial services
• Confidential: Test details, findings, and results are highly confidential with limited distribution
• Collaborative: Tests involve collaboration between the entity, threat intelligence provider, red team, and competent authority

TIBER-EU Adaptations Under DORA

While DORA builds on TIBER-EU, it introduces some adaptations:

• DORA makes TLPT mandatory for identified entities (TIBER-EU was voluntary in most jurisdictions)
• DORA introduces pooled testing provisions not in the original TIBER-EU framework
• DORA aligns TLPT with the broader ICT risk management framework and incident reporting obligations
• The RTS on TLPT specifies additional detailed requirements beyond TIBER-EU guidance

TLPT Phases

A TLPT exercise follows a structured lifecycle with three main phases:

Phase 1: Preparation and Scoping

• Competent authority notification and engagement
• Scoping: identifying the critical functions and ICT systems to be tested
• Risk assessment: evaluating potential impact of testing on live production systems
• Provider selection: appointing qualified threat intelligence and red team providers
• Establishing the control team (white team) within the entity
• Defining rules of engagement, escalation procedures, and abort criteria

Phase 2: Threat Intelligence and Red Team Execution

Threat Intelligence Phase (4-6 weeks):

• Develop bespoke threat intelligence report on threat actors targeting the entity
• Identify likely attack scenarios based on the entity's attack surface and threat landscape
• Deliver targeted threat intelligence report to the red team

Red Team Phase (8-12 weeks):

• Execute simulated attacks against live production systems based on threat intelligence scenarios
• Attempt to achieve predefined objectives (e.g., access to critical systems, data exfiltration)
• Document all activities, techniques used, and outcomes
• Maintain ongoing communication with the control team (white team)
• Adhere to rules of engagement and abort criteria

Phase 3: Purple Team and Closure

Purple Team Phase (2-4 weeks):

• Joint exercise between the red team (attackers) and blue team (defenders)
• Walk through red team attack paths and assess defensive detection and response effectiveness
• Identify detection gaps, response delays, and improvement opportunities
• Develop joint remediation recommendations

Closure Phase:

• Red team delivers comprehensive test report
• Entity develops remediation plan addressing findings
• Summary report shared with competent authority
• Competent authority provides attestation upon satisfactory completion
• Entity tracks and implements remediation actions

Pooled TLPT Testing

Article 26(4) introduces the concept of pooled testing, allowing multiple financial entities that rely on the same ICT third-party service provider to jointly conduct TLPT on the shared systems.

When Pooled Testing Applies

• Multiple identified entities use the same critical ICT service provider
• The provider's systems support critical or important functions for multiple entities
• Individual entity testing would create excessive burden on the provider
• Joint testing can achieve equivalent or better testing outcomes

Pooled Testing Requirements

• All participating entities must agree to the scope, objectives, and methodology
• The competent authorities of all participating entities must be involved
• One entity typically takes the lead in coordinating the exercise
• Results must be attributable to each participating entity for their individual compliance
• Each entity must develop its own remediation plan based on the findings
• Confidentiality arrangements must protect all participants' information

Pooled Testing Benefits

• Reduced cost through shared testing expenses
• Reduced burden on ICT service providers who would otherwise face multiple individual tests
• More comprehensive testing scope through combined resources
• Better understanding of systemic risks across multiple entities sharing infrastructure

Testing Frequency and Documentation

Minimum Testing Frequencies

Documentation Requirements

All testing activities must be documented. The documentation should include:

• Test plan: Scope, objectives, methodology, resources, and timeline
• Test report: Findings, severity classification, evidence, and recommendations
• Remediation plan: Actions, ownership, timelines, and verification approach
• Management body reporting: Summary of testing programme results, trends, and remediation status
• Supervisory evidence: Testing programme documentation, sample reports, and remediation tracking for evidence pack

Management Body Reporting

Article 24(6) requires testing results and remediation plans to be reported to the management body. This reporting should include:

• Summary of testing activities completed in the period
• Key findings and their severity
• Remediation status and any overdue items
• Trend analysis showing improvement (or deterioration) over time
• Recommendations for the next testing cycle
• TLPT outcomes and attestation status (where applicable)

Testing is not a compliance exercise — it is a continuous assurance mechanism. The most resilient financial entities treat testing as an investment in understanding their own vulnerabilities before threat actors exploit them. Build a culture where testing findings are welcomed as opportunities for improvement, not as failures.

Frequently Asked Questions

What types of testing does DORA require?

DORA requires two tiers of testing. Basic testing (mandatory for all in-scope entities) includes vulnerability assessments, open-source analysis, network security assessments, gap analysis, physical security reviews, questionnaire-based assessments, source code reviews, scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing. Advanced TLPT (for identified entities) requires threat intelligence-led red team exercises aligned with the TIBER-EU framework.

Who must perform TLPT under DORA?

Competent authorities identify entities for mandatory TLPT based on systemic importance, overall risk profile, and criticality of ICT systems. This typically includes significant credit institutions, central counterparties, central securities depositories, and other systemically important entities. Check with your national competent authority for specific obligations.

How often must DORA resilience testing be performed?

Basic testing of all critical ICT systems must be performed at least annually. TLPT must be conducted at least every three years for identified entities. Vulnerability scanning should be performed monthly or quarterly depending on system criticality. The actual frequency should be risk-based, with more critical systems tested more frequently.

Can TLPT be performed by internal testers?

The threat intelligence and red team phases of TLPT must use qualified external testers. Internal testers may participate in limited circumstances with competent authority approval, provided they demonstrate sufficient independence, competence, and absence of conflicts of interest. The purple team phase typically involves both internal defenders and external red team members collaborating.

What is pooled TLPT testing under DORA?

Pooled TLPT allows multiple financial entities that rely on the same ICT third-party service provider to jointly conduct TLPT on shared systems. This reduces testing burden and cost while still achieving the testing objectives. The RTS specifies conditions under which pooled testing is permissible and how results should be attributed to individual entities for compliance purposes.