DORA Is Now in Force: Testing Requirements for Financial Entities

For several years, the financial sector focused on DORA’s January 2025 application date. That date has passed. The regulation is now enforceable, and supervisors expect financial entities to show that testing programs are operational — not just planned, documented, or scheduled for a future cycle.

Many organizations invested heavily in governance documentation, ICT risk management frameworks, and policy alignment during the preparation period. That work is necessary, but it is not enough. DORA compliance also requires evidence that digital operational resilience is tested in practice: periodically, proportionately, and with results that can be reviewed by competent authorities.

The testing obligation is not the same for every entity. All in-scope financial entities must meet the standard digital operational resilience testing requirements under DORA Article 26. A smaller group, designated by competent authorities, must also conduct Threat-Led Penetration Testing under DORA Article 27. These are separate obligations with different scope, depth, methodology, and regulatory involvement.

This article explains how DORA testing requirements work in practice: which entities are in scope, how Article 26 differs from Article 27 TLPT, what TIBER-EU means for designated entities, where testing programs most often fall short, and how independent penetration testing supports defensible DORA compliance.

What Is DORA and Who Does It Apply To?

The Digital Operational Resilience Act — formally EU Regulation 2022/2554 — establishes a unified framework for ICT risk management, incident reporting, operational resilience testing, and third-party risk oversight across the EU financial sector. It entered into force on 16 January 2023 and has applied in full since 17 January 2025.

DORA applies to 20 types of financial entities. The scope is intentionally broad: the regulation was designed to reduce fragmentation across the EU financial sector and bring different types of financial institutions under a more consistent operational resilience framework.

For most financial entities, DORA creates a direct testing obligation. For ICT third-party service providers designated as “critical” by the European Supervisory Authorities, the oversight regime is different: they are subject to direct supervision by the ESAs — EBA, EIOPA, and ESMA — rather than national competent authorities.

What DORA Requires: The Five Pillars

Testing is one part of a broader framework. DORA organizes its requirements across five main areas, and financial entities need to address all of them. This matters because testing does not exist separately from the rest of the regulation. It validates whether the controls, processes, and third-party arrangements required by the other pillars actually work.

This article focuses on the testing pillar — Articles 24 to 27 — because it is where many financial entities have the most operational work to complete. Governance and policy documents can define the framework, but digital operational resilience testing is where the organization proves whether that framework holds under technical pressure.

DORA Testing: Two Distinct Obligations

DORA testing requirements are set out in Chapter IV. The two key obligations are not equivalent in scope, frequency, or regulatory involvement.

Every in-scope financial entity must meet DORA Article 26 requirements. A narrower group — entities designated by their competent authority — must also conduct Threat-Led Penetration Testing under DORA Article 27.

The distinction is important. Article 26 creates the baseline testing requirement for financial entities. Article 27 adds a more intensive, threat-led exercise for entities whose disruption could create wider systemic risk.

Article 26: Standard Digital Operational Resilience Testing

DORA Article 26 requires all in-scope financial entities to maintain a sound and comprehensive digital operational resilience testing program. This is not a one-off assessment. It is an ongoing program designed to identify weaknesses in ICT systems before adversaries do.

The regulation lists several types of testing that may form part of a compliant program. These include vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and software scanning solutions, source code reviews, scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing.

Not every test type applies to every entity or every cycle. DORA requires the program to be proportionate to the entity’s size, business and risk profile, and the criticality of the ICT systems in scope.

For a smaller entity, Article 26 obligations may be addressed through an annual penetration test, vulnerability assessment, and documented remediation process. For a larger financial institution with a complex ICT landscape, testing will usually need to be broader, more frequent, and mapped more closely to critical and important functions.

What Article 26 Compliance Looks Like in Practice

A compliant Article 26 program has three defining characteristics.

First, it is documented. Scope, methodology, testing dates, findings, risk ratings, remediation actions, and re-test evidence must be recorded and available to competent authorities. A policy that says testing will happen is not enough. The organization needs evidence that testing did happen and that the results were acted on.

Second, it is risk-based. Testing should target the ICT systems and functions most important to operational resilience, not only the systems that are easiest to test. External perimeter testing alone will rarely be enough if critical business processes depend on internal systems, cloud services, APIs, or third-party integrations.

Third, it is independent enough to be credible. DORA does not mandate external testing for every standard Article 26 assessment, but the quality of evidence is stronger when testing is conducted by a party without organizational interest in the outcome.

Annual DORA penetration testing often becomes the backbone of an Article 26 program. A well-scoped penetration test covering the external network perimeter, web applications supporting critical functions, API endpoints, internal network access controls, cloud configuration, and relevant third-party integration points produces the type of evidence supervisors expect: real findings, real risk, and documented remediation.

Article 27: Threat-Led Penetration Testing (TLPT)

Threat-Led Penetration Testing is not a standard penetration test with a more formal name. It is a different type of assessment: broader in scope, longer in duration, and built around a realistic adversary simulation rather than a vulnerability checklist.

A TLPT engagement has three core phases.

In the threat intelligence phase, external threat intelligence providers research the entity’s threat landscape: the adversary groups most likely to target this type of organization, their known tactics and techniques, and the ICT functions most likely to be targeted. This analysis shapes the red team’s approach. The goal is not to run a generic red team exercise, but to test whether the entity can withstand the threats it is realistically expected to face.

In the red team phase, external testers attempt to compromise the entity’s live production environment using the techniques identified in the intelligence phase. This is not testing against a sanitized staging clone or a narrow technical subset. The red team operates with limited advance disclosure to internal teams, simulating real attack conditions. Findings go beyond technical vulnerabilities and may include gaps in detection, escalation, response procedures, and human decision-making.

In the closure phase, the red team and the entity’s internal blue team review the findings together. This purple team exercise helps transfer knowledge, improve detection and response capability, and produce the documented evidence competent authorities require.

TIBER-EU: The Regulatory Framework Behind TLPT

DORA mandates that TLPT be conducted in accordance with the TIBER-EU framework, or an equivalent national framework where one exists. TIBER-EU — the European framework for Threat Intelligence-Based Ethical Red Teaming — was developed by the European Central Bank and defines the standards for threat intelligence providers, red team providers, and the governance of TLPT engagements.

TIBER-EU compliance means that both the threat intelligence provider and the red team provider must meet defined qualification criteria. It also means the threat intelligence report must be produced by a provider independent from the red team. The engagement must follow a structured process from scoping to closure, with documented evidence at each stage that competent authorities can review.

For designated entities, this governance structure is part of the obligation. TLPT is not simply a procurement exercise for a red team. It requires coordination between the entity, external providers, the TLPT coordinator, and the relevant competent authority.

Which Entities Are Subject to TLPT?

Not all DORA-regulated entities are required to conduct TLPT. Competent authorities — national supervisors and, for certain entities, the ESAs — designate which entities must undertake TLPT based on criteria that include systemic importance, the nature and scale of ICT activity, and risk profile.

In practice, TLPT designation typically applies to larger banks, insurance groups, central counterparties, and payment infrastructure operators that represent higher systemic risk in their jurisdiction. Entities that have not been notified of TLPT designation remain subject to Article 26 standard testing requirements only.

An entity designated for TLPT retains its Article 26 obligations alongside the Article 27 cycle. TLPT does not replace annual testing. It supplements it.

Where Financial Entities Currently Fall Short

Based on our work with financial entities across the EU, several patterns recur. These are not isolated gaps. They are the areas where Article 26 compliance is most frequently incomplete and where TLPT-designated entities are often least prepared.

Testing programs exist on paper but not in practice.
Many entities created digital operational resilience testing policies during the 2023–2024 preparation period, but the policy was never turned into a running program. Competent authorities will ask for test reports, remediation tracking, and evidence of follow-up — not only policy documents.

Scope is too narrow.
Article 26 requires testing of ICT systems supporting critical or important functions. Entities often test only their external-facing infrastructure: perimeter firewalls, public-facing applications, or selected internet-facing assets. Internal systems, cloud configuration, APIs, identity and access controls, and supply chain interfaces are often left outside the scope. A penetration test that excludes internal access paths may not produce the evidence DORA requires.

Independence is compromised.
Internal teams conducting their own assessments, or GRC consultants testing controls they helped design, cannot produce the same level of independent evidence as an external adversarial assessment. This is not just a procedural concern. It changes what the assessment can realistically reveal about operational resilience.

TLPT readiness is underestimated.
Entities that have been notified of TLPT designation — or expect to be — often underestimate what the engagement requires. TIBER-EU compliance is not achieved by scheduling a red team exercise with an existing pentest provider. Threat intelligence must be produced by a qualified, independent provider. The red team must operate against live production systems. The governance process is structured, documented, and coordinated with the relevant authority. Preparation often takes months.

Findings are not tracked to closure.
A penetration test report filed away without a remediation plan and follow-up testing does not demonstrate operational resilience. DORA expects findings to be acted upon, tracked, and resolved — or formally accepted with documented rationale.

How Iterasec Supports DORA Compliance

Iterasec operates at the validation layer. We do not design governance frameworks, write risk policies, or implement controls. Our role is independent adversarial testing: producing evidence that shows whether implemented controls actually work under realistic conditions.

We support financial entities under both DORA testing tracks.

Article 26: Annual Penetration Testing for Financial Entities

For financial entities subject to Article 26 standard testing requirements — the majority of in-scope organizations — Iterasec provides structured annual penetration testing engagements aligned with DORA’s scope and documentation expectations.

Our Article 26 engagements cover ICT systems supporting critical and important functions: external perimeter, web and API applications, internal network access controls, cloud infrastructure configuration, and third-party integration points where appropriate. We scope each engagement against the entity’s ICT risk register and business-critical functions, not a generic testing template.

Reports are structured to support DORA compliance evidence: documented methodology, CVSS-scored findings, business impact assessment, reproduction steps, affected systems, and a prioritized remediation roadmap. Findings are traceable to specific systems and functions. Re-testing is available to confirm that critical findings have been resolved before the next supervisory review.

We do not produce reports that satisfy a checkbox. We produce evidence that reflects what we actually found.

Article 27: TLPT for Designated Critical Entities

For entities designated by their competent authority as subject to Threat-Led Penetration Testing, Iterasec provides TLPT engagements aligned with the TIBER-EU framework.

Our TLPT capability covers all three phases of a compliant engagement: the threat intelligence phase, conducted by a qualified and independent threat intelligence provider; the red team phase, conducted against live production systems using tactics derived from the threat intelligence report; and the purple team closure, which transfers knowledge to the entity’s internal teams and produces the documented evidence required for regulatory review.

TLPT engagements operate under the governance structure TIBER-EU requires: independent scoping, documented oversight, formal coordination, and structured closure that competent authorities can validate. We coordinate with the entity’s designated TLPT coordinator and support the regulatory reporting process.

If your organization has been designated for TLPT — or is assessing readiness ahead of a likely designation — planning should begin early. TIBER-EU engagements require significant preparation time for the entity, the threat intelligence provider, the red team, and the internal teams involved in oversight and closure.

DORA Testing: What to Do Now

DORA’s application date has passed. For financial entities that have not yet established a compliant testing program, the gap is not a future planning item. It is a current supervisory exposure.

The practical steps are clear. Entities subject to Article 26 need an annual digital operational resilience testing program scoped to critical ICT systems, conducted with sufficient independence, and supported by DORA-aligned documentation. Entities subject to Article 27 need a TIBER-EU compliant TLPT engagement on the three-year cycle, with the appropriate governance structure in place.

The question is not whether testing is worthwhile. The question is whether the current testing program would survive review by a competent authority.

Conclusion

DORA has shifted operational resilience from policy intent to evidence. Financial entities now need to show that ICT systems supporting critical or important functions are tested, that findings are tracked, and that remediation decisions are documented.

For most organizations, this starts with Article 26: a proportionate, risk-based testing program that produces usable technical findings and defensible compliance evidence. For designated entities, Article 27 adds a more demanding TLPT obligation built around realistic threat intelligence, live production testing, and structured regulatory oversight.

A DORA testing program does not need to be overcomplicated, but it does need to be real. Scope, methodology, independence, reporting, and remediation tracking all matter. Without them, testing becomes difficult to defend — even if individual assessments were performed.

Get in touch to discuss how Iterasec can structure a DORA-aligned testing engagement for your organization — whether that means an Article 26 annual program, TLPT under Article 27, or an assessment of what your current program is missing.