Prepare for DORA Part 4 – Cyber Resilience Testing & Operational Preparedness

Chenyun Chu
Mar 12
4 min read

Updated: Mar 19

With DORA now in effect, financial institutions must go beyond basic cybersecurity measures and actively test their resilience against cyber threats. One of the most significant requirements under DORA is cyber resilience testing, ensuring that financial entities can withstand, respond to, and recover from ICT-related disruptions.

DORA mandates a structured cyber resilience testing framework, including:

Regular penetration testing & vulnerability assessments (DORA Article 25)
Threat-led penetration testing (TLPT) for critical functions (DORA Article 26)
Continuous monitoring of operational resilience
Testing across the ICT supply chain, including third-party vendors

Financial institutions must apply these resilience testing requirements not only to their own systems but also to ICT service providers, ensuring that outsourced services do not introduce vulnerabilities into the financial ecosystem.

In this installment of our "Prepare for DORA" series, we’ll break down:

DORA’s key resilience testing requirements
The difference between automated penetration testing & TLPT
The role of AI in red teaming and its current limitations
What operational preparedness means under DORA
How to enforce testing requirements on ICT providers via contracts

1. Why Cyber Resilience Testing Matters Under DORA

Traditionally, financial institutions focused on preventing cyber incidents, but DORA shifts the focus to resilience. This means organizations must be prepared for inevitable cyberattacks or ICT disruptions and ensure that systems remain operational even under attack.

Resilience testing ensures that:

Security gaps are proactively identified before attackers exploit them.
Incident response plans are tested in real-world conditions.
Third-party ICT service providers meet resilience standards.
Regulators receive assurance that financial institutions can withstand disruptions.

DORA’s requirements are not just a regulatory checkbox—they are designed to strengthen the entire financial ecosystem’s security posture.

2. Regular Penetration Testing vs. Threat-Led Penetration Testing (TLPT)

DORA introduces two types of security testing, outlined in Article 25 & 26:

2-1. Regular Automated Penetration Testing & Vulnerability Scanning (Article 25)

Regular penetration testing aims to continuously test security defenses to uncover vulnerabilities before attackers do. These tests are preferred to be automated, frequent, and provide broader coverage.

Conducted multiple times per year or continuously to catch vulnerabilities in real-time.
Uses automated penetration testing tools as much as possible to simulate cyberattacks at scale.
Identifies security flaws in networks, applications, cloud environments, and endpoints.
Evaluates how well security teams detect and respond to simulated attacks.

Example of Automated Penetration Testing Use Cases:

Testing for SQL injection or cross-site scripting vulnerabilities in web applications.
Scanning cloud configurations for security misconfigurations.
Checking for unpatched software and outdated security protocols.

Since automated penetration testing can be run continuously, it plays a key role in early detection of security risks and ensures financial institutions maintain continuous compliance with DORA’s resilience requirements.

2-2. Threat-Led Penetration Testing (TLPT) for Critical Financial Services (Article 26)

For larger financial institutions and those providing critical financial services, DORA mandates Threat-Led Penetration Testing (TLPT)—also known as red teaming.

Key differences between TLPT and regular penetration testing:

Feature	Regular Penetration Testing	Threat-Led Penetration Testing (TLPT)
Goal	Identify vulnerabilities	Simulate a real-world attack scenario
Testing Scope	Broad, automated, frequent	Targeted, manual, high-risk areas
Frequency	Quarterly or continuous	At least once every 3 years for critical functions
Execution Method	Automated tools or Human-led	Human-led, real adversary simulation
Response Assessment	No response validation	Tests how teams detect & react to attacks

Example of TLPT Use Cases:

Simulating a persistent insider threat attempting to steal customer data.
Testing bank payment systems for weaknesses that could be exploited in fraud schemes.
Launching a DDoS attack simulation to assess system resilience under stress.
Gaining unauthorized access to privileged financial transactions through social engineering.

With the advancement of AI-driven security testing, more aspects of red teaming can now be automated, including:

AI-generated attack simulations that mimic advanced persistent threats (APTs).
Automated reconnaissance and exploitation of vulnerabilities.
Real-time response analysis to evaluate security team effectiveness.

However, AI still has limitations in fully replacing human-led red teaming, as human intuition, adaptive attack strategies, and deep contextual understanding remain critical to advanced threat simulations. For now, AI enhances efficiency but cannot replace human expertise in TLPT.

3. Operational Preparedness: Beyond Just Testing

DORA does not stop at testing—it requires financial institutions to demonstrate operational preparedness, meaning:

Proactively identifying vulnerabilities before they become threats.
Ensuring IT & security teams can detect and respond to cyber incidents in real time.
Running tabletop exercises to prepare for different attack scenarios.
Assessing business continuity and disaster recovery readiness.

Example: A Swiss bank simulates a ransomware attack scenario

The IT team tests data backup recovery times.
The security team evaluates how quickly they can detect and isolate the attack.
The executive team reviews crisis communication strategies.
The compliance team ensures regulators receive timely incident reports.

Operational preparedness ensures that financial services remain available, even during disruptions.

4. Special Topic: How to Enforce Resilience Testing in ICT Vendor Contracts

To ensure ICT providers comply with resilience testing requirements, financial institutions should include contract clauses that mandate security testing.

Example Contract Clause: Mandatory Penetration Testing
- "The ICT Service Provider shall conduct annual penetration testing on its infrastructure, applications, and APIs to identify and remediate security vulnerabilities. The results of such testing shall be shared with the Financial Institution within 30 days of completion."
Example Contract Clause: Threat-Led Penetration Testing (TLPT) Participation
- "The ICT Service Provider shall cooperate with the Financial Institution’s red team testing exercises by providing controlled access to simulated attack environments. TLPT results shall be used to enhance joint security measures."
Example Contract Clause: Third-Party Resilience Testing Compliance
- "The ICT Service Provider must provide evidence of compliance with DORA resilience testing requirements, including participation in security audits, tabletop exercises, and business continuity simulations."