DORA Penetration Testing: Who Is in Scope, What Threat-Led Testing Means, and How to Prepare

What DORA penetration testing is

DORA is the newest of the major frameworks, and for EU financial entities it changes the conversation about testing entirely.

DORA penetration testing is the testing you run to satisfy the Digital Operational Resilience Act, Regulation (EU) 2022/2554, which has applied since January 2025. DORA exists because the EU decided that financial stability now depends on digital resilience, and that hoping firms tested themselves was not good enough. So it wrote the expectation into law, with real supervisory teeth behind it.

Unlike SOC 2 or HIPAA, DORA does not tiptoe around the word “test”. It has a whole chapter on digital operational resilience testing. And unlike the others, it does not stop at “run some testing”. For the entities that matter most to financial stability, DORA penetration testing means threat-led testing — a controlled exercise that mimics a real, capable adversary attacking your live systems.

DORA is not a nice-to-have. It is enforced.

For a European security company this is home ground, not a foreign standard translated for a local audience. DORA penetration testing is written in the regulatory language SelfHack AI was built around, and this guide explains who it applies to, what the two tiers demand, and how to be ready rather than rushed.

Who is in scope

DORA penetration testing applies far more broadly than people first assume, because DORA’s definition of a financial entity is wide.

It covers the obvious: banks, insurers and reinsurers, investment firms. It also covers payment institutions, electronic money institutions, crypto-asset service providers, trading venues, fund managers, and more. If you are a regulated financial entity operating in the EU, DORA almost certainly applies to you, and with it the obligation to run DORA penetration testing appropriate to your size and risk.

Importantly, DORA also reaches critical ICT third-party providers — the cloud platforms, data services and technology vendors that financial entities depend on. If you supply critical technology to EU finance, DORA’s expectations flow to you through your customers’ contracts and, for designated critical providers, through direct oversight. So DORA penetration testing is not only a bank’s problem; it is the problem of everyone in the bank’s technology supply chain.

The two tiers: basic testing and threat-led testing

DORA penetration testing comes in two levels, and knowing which applies to you is the first thing to establish.

The first tier applies to all in-scope entities. DORA requires a testing programme covering a range of assessments — vulnerability assessments, scans, and testing of ICT systems and applications — carried out regularly on the systems that support critical or important functions. This is the baseline: a structured, recurring testing programme, not an ad-hoc scan when someone remembers.

The second tier applies to significant entities, identified by the authorities based on their size, risk profile and importance to the financial system. These entities must additionally undergo threat-led penetration testing, or TLPT: an advanced exercise, aligned with the European TIBER-EU framework, run at least every three years. TLPT is a different order of testing from a scan — it is a controlled simulation of a real attack.

So there are two questions, not one. Which tier are you in? And are you ready for it? Most firms answer the first and forget the second.

The practical point is that both tiers are recurring, and both reward being continuously ready. The baseline tier is explicitly a regular programme. The advanced tier is periodic but so demanding that walking into it cold is a mistake. DORA penetration testing at either level is not something you improvise the month before.

What threat-led penetration testing actually involves

Threat-led penetration testing is the part of DORA that makes seasoned security teams pay attention, because it is far closer to a real attack than a normal engagement.

The “threat-led” part means the exercise starts from genuine threat intelligence about who would actually attack you and how. Testers then act as that adversary would — a red team working against your live production systems, over an extended period, trying to reach defined critical functions without your defenders necessarily knowing the exercise is underway. It tests not just your technology but your detection and response, because a real attack tests those too.

This is a serious undertaking, which is why DORA reserves TLPT for significant entities and aligns it with TIBER-EU, the established European framework for exactly this kind of exercise. The bar is high: realistic adversary emulation, live systems, defined critical functions, and a formal process with the authorities involved.

Here is the honest implication. You do not pass threat-led DORA penetration testing by preparing for the test. You pass it by being resilient the rest of the time, so that when the red team comes, they meet an estate that has already been hardened against exactly the weaknesses they will try. Continuous testing is how you get there.

The third-party dimension DORA adds

DORA penetration testing does not stop at your own perimeter, and this is where it differs most from the older frameworks.

DORA is built around the recognition that financial entities depend heavily on ICT third parties, and that a failure in a critical provider is a failure of the financial entity’s resilience. So DORA imposes expectations on how you manage, monitor and test the resilience of those dependencies, and it establishes direct oversight of designated critical ICT third-party providers.

For your DORA penetration testing programme, that means scope has to consider the critical services you rely on, not just the systems you build. It also means that if you are a technology provider to EU finance, your customers will increasingly require evidence of your own testing and resilience as a condition of the contract. The supply chain is inside the boundary now, in both directions.

What DORA penetration testing should cover

A DORA penetration testing programme has to be organised around critical or important functions, because that is how DORA itself thinks.

Start by identifying the functions whose disruption would materially harm your ability to operate or would threaten financial stability. Then map the ICT systems that support them: the customer-facing applications, the APIs, the core processing systems, the infrastructure, and the third-party services in the path. Those systems are where DORA penetration testing has to focus, because those are the ones the regulation cares about protecting.

From there, the testing mirrors a real attacker’s approach: external entry, internal movement, escalation toward the critical function, and the question of whether your detection and response actually notice. As always, the value is in following the chain to the function that matters — proving whether an attacker can actually disrupt a critical service, not merely that a vulnerability exists somewhere. Before you scope, enumerate what you truly expose; our free security checks guide helps.

Common gaps DORA testing exposes

DORA penetration testing tends to expose a particular class of weakness: the ones that only matter when you care about resilience, not just confidentiality.

Some of these are unique to a resilience regulation. Concentration risk is a big one. A single third-party dependency that, if it failed or were compromised, would take a critical function down with it — and no tested fallback. DORA cares about this deeply, and testing that maps the real dependency chain surfaces it.

Then the detection-and-response gaps that threat-led testing is designed to find. A red team reaching a critical function without anyone noticing is not just a technical finding; under DORA it is a resilience failure. Slow or absent detection, unrehearsed response, and recovery procedures that have never actually been exercised all surface when DORA penetration testing behaves like a real adversary rather than a checklist.

And the familiar technical set underneath: exposed interfaces, weak authorisation, over-privileged access and unpatched systems in the path to a critical function. None are exotic. All become resilience issues the moment they sit between an attacker and a function DORA wants protected.

Why DORA is different from the frameworks before it

It helps to name what makes DORA penetration testing unlike SOC 2 or ISO.

It is law, not a voluntary standard. A supervisor can act on it.

It is about resilience, not just confidentiality. The question is whether a critical function keeps running, not only whether data stays secret.

It tests your defenders, not just your systems. Threat-led testing checks whether anyone notices the attack.

And it pulls your suppliers inside the boundary. Your resilience now includes theirs.

Put together, those four shifts make DORA penetration testing a resilience exercise rather than a compliance snapshot. That is a higher bar, and it rewards firms that were already testing continuously rather than annually.

What DORA penetration testing will not do

Being honest about the limits keeps the rest credible.

A test does not make you resilient on its own. Resilience is governance, response, recovery and testing together. DORA penetration testing evidences one part.

A single exercise does not keep you compliant either. DORA expects an ongoing programme. One test, however good, is a moment.

And a test fixes nothing by existing. The finding is the diagnosis. The fix is the cure. The retest is the proof. A supervisor reads for that loop.

None of this argues against DORA penetration testing. It argues for running it continuously, as part of a resilience programme, rather than treating any single exercise as the whole obligation.

Cadence, and the readiness problem

DORA sets cadence at two speeds. The baseline testing programme is regular and ongoing. Threat-led penetration testing is at least every three years for significant entities.

That three-year figure is where teams misjudge DORA penetration testing. A multi-year cycle sounds relaxed, so firms treat TLPT as a distant event. But the exercise is so realistic and so consequential that arriving unprepared is a genuine risk — and the baseline programme, which is supposed to run continuously in between, is where the real ongoing work lives.

The honest reading is that DORA rewards continuous readiness over periodic panic. The baseline programme is explicitly meant to be regular. The threat-led exercise is best faced by an estate that has been continuously tested and hardened, so the red team finds a mature target rather than a soft one. DORA penetration testing, done well, is a steady state, not a three-yearly scramble.

The evidence gap between formal exercises

Consider how a firm might run DORA penetration testing badly: a baseline scan once a year, a threat-led exercise once every three, and long quiet stretches in between with little testing.

Those quiet stretches are the problem. Financial systems change constantly — new products, new integrations, new third parties, new exposures. Between formal exercises, all of that goes untested, and the resilience DORA wants you to maintain quietly degrades. When the next exercise or a supervisory review arrives, the gap between your last real test and your current systems is exactly what gets scrutinised.

The truth is, DORA is a resilience regulation, and resilience is a continuous property, not a periodic one. You cannot be resilient only in the months around a test. DORA penetration testing that runs continuously underneath the formal exercises is what turns “resilient on test day” into “resilient”, which is what the regulation actually asks for.

How SelfHack AI keeps you continuously ready

SelfHack AI is an autonomous penetration testing platform built in Europe, and for DORA penetration testing it targets the readiness problem directly.

Because it tests continuously, the baseline resilience-testing obligation stops being a periodic task and becomes a standing programme — systems supporting critical functions are tested on an ongoing basis, and new products or third-party integrations get tested as they arrive rather than at the next annual pass. That is much closer to what DORA’s baseline tier actually describes than a once-a-year scan.

For the threat-led tier, continuous testing changes the odds. When a TLPT exercise comes, the red team meets an estate that has already been probed and hardened against the weaknesses they will try, because those weaknesses were found and fixed continuously rather than left waiting for the three-yearly exercise to reveal them. You face the formal test as a mature target, not a soft one.

And it produces standing resilience evidence: what was tested, what reached a critical function, what was fixed, and when — the kind of record a supervisor or a demanding customer expects. This does not replace a formal TLPT provider or your competent authority’s process — keep those for the formal exercise. It replaces the quiet stretches in between, where resilience is either maintained or quietly lost. See how the platform compares in our AI pentest tools overview, and how DORA fits alongside the other frameworks in the compliance penetration testing hub.

Related compliance testing

DORA rarely stands alone for a financial entity, and the same testing capability serves the frameworks alongside it.

If you take card payments, PCI DSS penetration testing applies to that flow. If you sell software into finance, customers will ask for SOC 2 penetration testing or ISO 27001 penetration testing. One continuous testing programme can feed all of them, because the underlying question — can you be broken into, and how far does it go — is shared across every framework. Building DORA penetration testing as a continuous capability, rather than a set of separate exercises, is what keeps a financial entity’s whole compliance load manageable.

FAQ

Does DORA require penetration testing?

Yes. DORA requires a digital operational resilience testing programme for all in-scope financial entities, and threat-led penetration testing (TLPT) for significant entities at least every three years. Unlike some frameworks, DORA names testing explicitly and gives supervisors real authority behind it. Confirm your exact obligations with your competent authority, as details sit in the regulatory technical standards.

What is threat-led penetration testing under DORA?

It is an advanced exercise, aligned with the TIBER-EU framework, in which testers emulate a real, intelligence-led adversary against your live production systems and critical functions, testing your defences and response as well as your technology. It is reserved for significant entities because of its depth and consequence, and it is a different order of exercise from a routine scan or standard test.

Who counts as a significant entity for DORA TLPT?

Authorities designate which entities must undergo threat-led DORA penetration testing based on factors such as size, risk profile and systemic importance. Not every in-scope firm will be required to run TLPT, but all in-scope firms must run the baseline testing programme. Your competent authority is the source of truth on your designation.

Does DORA apply to technology vendors, not just financial firms?

Effectively, yes. DORA reaches critical ICT third-party providers directly through oversight, and reaches other providers indirectly through their financial-entity customers’ contractual requirements. If you supply technology to EU finance, expect DORA penetration testing evidence and resilience commitments to appear in your contracts. For a technology vendor, that turns testing from an internal hygiene matter into a commercial requirement — a signed customer may make it a condition of the deal.

How does continuous testing help with a three-yearly TLPT?

TLPT is periodic, but resilience is continuous. Continuous DORA penetration testing hardens your estate against the weaknesses a threat-led exercise will probe, so the red team meets a mature target, and it keeps the baseline testing obligation satisfied in between. It complements the formal exercise rather than replacing it.

The verdict

DORA penetration testing is the most demanding of the compliance tests and the one written most explicitly into law. For all financial entities it means a real, recurring testing programme; for significant ones it means threat-led testing that behaves like an actual attack.

The mistake is treating a multi-year cycle as permission to relax. DORA is a resilience regulation, and resilience is continuous. You cannot be resilient only around the dates of a formal exercise. Continuous testing keeps you ready for the exercise and resilient in between, which is what the regulation actually wants.

Being ready is cheaper than scrambling. It is also calmer. And it is what the regulation actually asks for.

If you would rather face your next DORA exercise as a hardened, continuously tested target than a firm scrambling to prepare, talk to us.

Sources & methodology: testing methodology references the OWASP Web Security Testing Guide and NIST SP 800-115. DORA requirements (the resilience testing programme and threat-led penetration testing) are summarised from Regulation (EU) 2022/2554 and the TIBER-EU framework; the authoritative source is the current regulation, its regulatory technical standards, and your competent authority. General guidance, not legal advice. Only test systems you own or are authorised to test.