A Guide to Meeting the DORA Penetration Testing Requirements

Introduction: What is DORA and Who It Applies To

DORA is the EU’s main regulation for managing digital and ICT risks in the financial sector, introduced as financial stability became tightly linked to technology, cloud environments, software supply chains, and third-party vendors. Because a single outage in these systems can disrupt core financial services, fragmented oversight was no longer workable. Before DORA, EU financial entities operated under inconsistent cyber security rules across different jurisdictions, creating gaps and uneven resilience. DORA addressed this by establishing the first unified framework covering all financial institutions and critical CTTP. As of

January 17, 2025, the EU now operates under one common rulebook for digital operational resilience.

DORA is built to keep the financial system running even when things break. It pushes firms to take ICT risks seriously at the board level, understand their third-party exposure, report incidents quickly, and test their systems in ways that reflect real attacks. The goal is simple: one outage or breach should not trigger a wider collapse. DORA forces firms to plan for failure, test for it, and recover fast.

DORA applies across the financial ecosystem, covering institutions whose operations depend on digital systems and shared technology. This includes banks, insurance firms, investment brokers, payment and e money institutions, crypto asset service providers, and other regulated entities. The scope extends beyond financial firms to the critical third-party service providers (CTTP) that support them, since operational resilience depends on the full-service chain. Cloud providers are included even when they are located outside the EU, reflecting the cross-border nature of modern financial infrastructure.

This creates a stable and predictable environment for the entire financial system, making it easier to navigate tough times and restore systems as quickly as possible.

DORA’s New Standard for Penetration Testing

Traditional penetration testing focuses on single systems and fixed points in time, often reducing security to a checklist exercise. This static approach breaks down because attackers do not operate this way. Real attacks are continuous and multi stage, shaped by intent and technique rather than compliance milestones.

DORA changes the game by introducing Threat Led Penetration Testing, known as TLPT. TLPT simulates real adversaries using real attack chains and real intelligence, and it targets the live systems that keep the business running.

Alongside TLPT, DORA is the broader yearly testing requirement that covers vulnerability assessments, configuration reviews, and technical tests across the environment. It is lighter than TLPT, but it keeps firms continuously tested between the TLPT cycles.

The key difference is that TLPT is a deep, adversary level exercise conducted every three years, while DORA represents the ongoing baseline of technical testing performed each year. TLPT is designed to recreate how a capable attacker would breach defenses and move through critical functions, testing the organization under realistic pressure. DORA, in contrast, focuses on keeping day to day security hygiene and operational resilience in check through regular validation. One simulates a full attack end to end, while the other ensures continuous maintenance and readiness.

DORA sets itself apart from older rules by shifting the purpose of penetration testing. Older frameworks tried to prove that systems were “secure on paper” through isolated checks that rarely matched real threats. DORA pushes firms to test how their defenses behave under real pressure across people, processes, and production systems.

 TLPT exists because traditional testing kept missing the attacks that matter. Real intrusions are messy and unpredictable, and regulators accepted that box ticking was not protecting anyone. TLPT brings real threat intelligence and attacker logic into the test. It is tougher, but it shows true resilience instead of a clean audit story.

Below is a comparison between traditional pen-testing and TLPT:

DORA Requirements for Financial Entities

ICT Risk Management Framework

The ICT risk framework should be part of the business plan, not a separate compliance document. It needs to reflect how the organization actually operates and the level of risk it is willing to accept. This requires clear visibility into assets, system dependencies, and weak points, supported by practical security controls and ongoing monitoring. Incident response and recovery plans must be tested in real conditions, reviewed by management, and improved continuously using lessons learned from past incidents.

ICT Incident Reporting

Incidents must be assessed and classified by severity so the response is proportional to their impact. When an incident is major, authorities must be notified on time, starting with an initial alert and followed by detailed and final reports. Standard reporting formats and centralized records make audits possible, while clear traceability ensures that every decision, action, and timeline can be reviewed later.

Digital Operational Resilience Act (DORA / TLPT)

Testing under DORA is meant to reflect how real attacks unfold, not just how systems look at a single moment. Regular vulnerability scans, penetration tests, and threat led exercises should be used to simulate realistic attack paths. These exercises must cover people, processes, and technology together, since failures rarely stay confined to one layer. Findings should be documented, fixed within defined timelines, and retested, with solid evidence kept for regulatory review.

CTTP Risk Management

CTTP risk starts before a provider is onboarded and continues throughout the relationship. Every provider should be registered and assessed based on risk, with proper due diligence done upfront. Contracts must clearly define security requirements, service levels, audit rights, exit strategies, and controls over subcontracting. After onboarding, providers need ongoing monitoring to confirm that controls are actually working, while risks and dependencies are tracked across the full supply chain to prevent blind spots.

DORA Requirements for Critical Third-Party Service Providers (CTTP)

Designation and Oversight

Under DORA, certain CTTP are designated as critical because of their scale or the impact they have on the financial sector. Once designated, they fall under the supervision of a lead authority and are expected to accept inspections, share relevant data, and cooperate with regulators across borders. This oversight may also include the payment of supervisory fees, reflecting their systemic importance.

Contractual and Operational Duties

Clear and enforceable contracts sit at the center of DORA’s approach to third party risk. Agreements must define the services being delivered, SLAs, security controls, audit rights, and limits on subcontracting so expectations are unambiguous. Providers are also required to report significant incidents or material changes, maintain workable exit and data access plans, and ensure operational stability throughout the relationship.

Resilience and Reporting

Beyond contracts, providers must demonstrate ongoing operational resilience in practice. This includes running DORA aligned incident management processes, reporting regularly on governance and risk exposure, and actively monitoring subcontractors across the supply chain. Identified issues must be addressed within defined timelines, with reporting obligations met consistently to maintain regulatory confidence.

TLPT under DORA is scenario based. Each entity must select at least three attack scenarios. These scenarios come from threat intelligence, past incidents, industry reports, and attacker behavior. One scenario can be non-threat led for future risk analysis. The scenarios are provided by an external Threat Intelligence provider, an independent team that meets DORA’s standards.

The testing follows EU TIBER style methods. It uses steps that mimic advanced threat groups. It hits live production systems that support critical operations like payments, trading, identity systems, authentication flows, customer data, and settlement processes.

The testing period usually sits around twelve weeks. It involves planning, threat intelligence gathering, scenario building, approvals from Control Teams, and attack execution. Internal testers can join only under strict independence rules.

Weekly coordination ensures safety. All steps are monitored. The testing stays hidden from most operational teams until the replay or purple team phase.

After testing, organizations must fix issues, retest, and complete regulatory reporting.

Core TLPT requirements include:

•  At least three attack scenarios

•  Alignment with TIBER style methodology

•  Production systems in scope

•  About twelve weeks active testing

•  Independence requirements for testers

•  Controlled oversight and secrecy procedures

•  Purple team replay after testing

•  Remediation and proof of closure

 Example Scenario of Threat Led Pentesting (TLPT):

 An attacker uses phished employee credentials to enter the identity system, moves through internal services without alerts, abuses a misconfigured service account to reach the payments environment, and attempts a small unauthorized transaction to test if the organization can detect and stop real activity on live production systems.

Differences in Frequency, Scope, and Applicability

DORA separates responsibilities clearly between financial entities and CTTP. This avoids confusion and keeps each group accountable for its own risks.

Frequency differences

Financial entities must follow the TLPT cycle every three years. They must also run annual resilience tests for important systems. They have strict deadlines for incident reporting.

CTTP only fall under the TLPT cycle when they are designated as critical. If they are not classified as critical, they are not subject to the three-year TLPT requirement. Their reporting obligations and frequency are likewise determined by this designation.

Scope differences

Financial entities cover end to end operations. This includes governance, incident handling, recovery planning, testing, supplier management, and full resilience reporting.

CTTP have a narrower scope tied directly to the services they deliver to financial entities. Their obligations focus on service continuity, incident reporting, transparency, and the technical resilience of their own systems.

Applicability differences

Some rules apply to everyone. Some apply only to financial entities. Some apply only to critical CTTP.

Examples:

• TLPT applies to all financial entities, but only to CTTP that are declared 'critical'

• Incident reporting rules apply to financial entities by default

• Oversight rules apply only to designated critical CTTP

• Governance and management accountability apply to financial entities, not CTTP This separation keeps responsibility clear and avoids finger pointing during incidents.

Automated tools become valuable in DORA when they enhance TLPT beyond what manual testing can achieve. Large financial systems produce massive amounts of data, making it impossible for human teams to spot every risk. Automated tools analyze threat intelligence, system logs, and past incidents to generate attack paths that mirror real attacker behavior, giving red teams scenarios that are both practical and high impact, while humans validate and execute them safely.

These tools also improve prioritization after the test. Manual reviews often produce long lists of findings, leaving teams unsure what truly matters. Automated analysis ranks weaknesses based on actual business impact, ensuring remediation focuses on vulnerabilities that could disrupt operations, not just low-level issues.

Automation supports continuous readiness between the three-year TLPT cycles. AI-driven simulations can run smaller, targeted exercises using insights from prior tests, keeping resilience active, while human teams handle interpretation, decision-making, and strategic adjustments. This combination uncovers subtle risks that purely manual testing would likely miss.

For example, a human team might manually build a TLPT scenario around phishing and

lateral movement, whereas automated tools can identify a more realistic attack chain where an attacker exploits a misconfigured cloud identity, chains it with a forgotten CI token, and reaches critical systems faster and more accurately than manual mapping would allow.

Key impacts:

 • Faster, realistic threat led testing

 • Risk based vulnerability prioritization

 • Continuous readiness, strategic focus

Cloud Security and its Role in DORA TLPT

Cloud is a core part of DORA because many critical financial systems now run in cloud environments, so TLPT must test identity flows, segmentation, exposed APIs, misconfigured storage, and cross-region access to show whether teams can detect, contain, and recover from an intrusion.

DORA also pulls cloud providers into the resilience chain. Firms must show regulators that they have visibility, audit access, and a working understanding of how their providers operate, especially when a provider is classified as critical. TLPT scenarios are expected to probe weak links that could disrupt core services, because DORA ties cloud stability directly to financial stability. In practice, that means testing what actually breaks systems, rather than what looks tidy on a policy document.

Most cloud failures still come from small mistakes that attacker's chain into something serious, and DORA treats that chain as the heart of the problem. TLPT follows that path end to end: a weak IAM rule turning into escalation, a pivot across workloads, and a push toward a critical function. The cloud is now part of the operational backbone, and under DORA it becomes an active attack surface that must be tested with the same realism as the attackers who target it.

Practical Challenges in DORA Testing

Mapping critical functions is hard, especially in legacy systems where dependencies are unclear, and this complexity spills into threat intelligence integration, which rarely fits cleanly. Resource limits then hit smaller firms hardest, while vendor resistance slows supplier testing. At the same time, manual processes do not scale, supervisory expectations vary across regulators, documentation gaps weaken audit readiness, and internal culture issues quietly slow everything down.

These challenges push firms to invest in automation, improve internal coordination, and take third party risk more seriously.

Resilience Metrics for DORA Audits

Key Performance Indicators (KPIs):

These indicators demonstrate the organizations stability and preparedness. Boards can utilize them to identify whether resilience is improving or beginning to decline.

Mean Time to Detect (MTTD):

This is the speed at which you identify an issue. Quicker recognition leads to issues being discovered earlier resulting in reduced harm and minimal interruptions.

Mean Time to Respond (MTTR):

This shows how fast you can handle and fix a problem once it’s spotted. Slow response usually means bigger impact.

Critical Asset Exposure:

It shows how vulnerable your most important systems and processes are. High exposure means attackers have easier targets.

Third-Party Resilience Scores:

These scores reflect how reliable and secure your vendors are. Weak scores mean higher dependency risks.

Testing Effectiveness:

It tracks what TLPT and resilience tests found and how quickly issues were fixed. It proves testing actually works, not just produces reports.

Incident Reporting Accuracy:

It shows whether reports were sent on time and with complete details. Bad accuracy creates regulatory trouble.

Operational Continuity Metrics:

These measure uptime, failover success, and backup recovery. Strong continuity means services stay online even when things break.

How RedSecLabs Can Help You Achieve DORA Compliance

RedSecLabs offers an end-to-end DORA Compliance Service. We guide firms across every step of the regulation. We map critical assets, assess gaps, and build governance frameworks. We set up reporting flows, classify incidents, and prepare firms for regulatory deadlines.

We also manage third party risk by reviewing contracts, assessing cloud setups, and enforcing resilience rules. Our TLPT and resilience testing services follow DORA driven methods. We provide continuous monitoring and board ready reports.

Most organizations reach initial readiness in about three to six months. We work closely with your teams to set scope, implement controls, execute tests, and build resilience.

Visit our DORA Compliance Services page to learn more:

https://www.redseclabs.com/services/dora-compliance-services

With RedSecLabs, you get stronger resilience, lower risk, and smoother compliance. You also get a partner that understands the real-world challenges behind DORA.

Contact: www.redseclabs.com | [email protected]