DORA and continuous penetration testing

Discussions about DORA penetration testing often revolve around threat-led penetration testing (TLPT): the three-year cycle, red-team requirements, and supervisory oversight.

TLPT does deserve that attention. It is one of the most complex practices and demanding security obligations a financial entity can face.

However, there are questions that discussions rarely cover, at least in depth, but that are more consequential for day-to-day security operations:

• Does continuous penetration testing have a place inside DORA’s framework at all?
• If it does, what does it look like in practice?

Both answers matter more than most DORA compliance guides acknowledge.

DORA requirements for penetration testing in financial services

DORA came into force in the EU on 17 January 2025. It brought harmonized operational resilience rules to the financial sector, covering 20 types of financial entities and ICT third-party service providers.

When it comes to security testing, the regulation sets two levels of obligation.

Broad obligation: a digital operational resilience testing program

The broad obligation applies to all financial entities. It is described in Article 24 and Article 25, which require organizations to have digital operational resilience testing programs that, among others, include:

• Vulnerability assessments
• Gap analyses
• Source code reviews
• Scenario-based tests
• Penetration testing

According to these two articles, financial entities operating in the EU must test ICT systems and applications supporting critical or important functions at least once a year, using methods appropriate to the system and its risk profile.

Narrow obligation: threat-led penetration testing

DORA Article 26 requires threat-led penetration testing of live production systems, targeting the critical and important functions that underpin them. It is different from the pentesting referred to under the broader testing program. TLPT is a comprehensive, threat intelligence-led exercise that requires a great deal of time and resources.

This narrow obligation doesn’t apply to every financial entity. Regulators identify whether an entity falls within its scope based on its systemic importance and ICT risk profile.

Due to the complex nature of TLPT, financial entities in scope needed a separate technical standard that specifies how to put it into practice. That standard, Commission Delegated Regulation (EU) 2025/1190, was published after DORA had come into force, becoming enforceable on 8 July 2025. It covers key aspects of the TLPT obligation, such as:

• Who falls in scope
• How you should structure tests
• What should the results show
• How supervisory authorities cooperate across borders
  
  

It might look like DORA mandates “once a year” or “once every three years” penetration testing. But those are the minimum cadences.

The regulation, instead, keeps returning to a far more fundamental idea: testing should help you understand where you are exposed, fix what you find, and prove that the fixes have taken effect. And for that, point-in-time tests are insufficient.

Continuous penetration testing: the proof trail for DORA compliance

Continuous penetration testing can strengthen both the broad and the narrow DORA obligation. But not as a replacement for TLPT or even for the bare minimum of once-a-year traditional pentest. Rather, as a necessary response to a radically changed threat landscape, where agentic attackers and a mean time-to-exploit of 1 hour are becoming a reality.

That is why Gartner, to which we’ve become accustomed for predicting and setting industry trends, recently introduced the COST (continuous offensive security testing) model in “The Future of Pen Testing Is Continuous Offensive Security Testing” (Poole et al., 2026). What continuous penetration testing, as a form of COST, can do for you is build and maintain the proof trail that both obligations require.

A useful DORA penetration testing record must show how one decision led to the next. A good record answers eight questions:

1. Which threat, incident lesson, or ICT risk triggered the test?
2. Which critical function could suffer?
3. Which apps, APIs, ICT systems, user roles, and ICT providers were included?
4. What did the testers try?
5. Which security controls failed?
6. What evidence showed the impact, or how attackers could exploit it?
7. Who fixed the problem?
8. What retest confirmed that the issue was resolved?

This way, it serves multiple groups at once. Developers get enough detail to reproduce and fix the real problem. Security teams get proof rather than a vague risk note. CISOs get a direct link between a test finding and the risk register. Compliance teams get a record that maps to a specific DORA requirement.

A vulnerability in an unused admin panel and a vulnerability in a live payment flow may fall under the same category. However, their business meaning and operational impact could be very different. DORA cares more about these details — functionalities and assets that fail in the wild with damaging consequences — rather than the vulnerability category in a vacuum.

Therefore, a reliable risk validation security mechanism, one that provides proofs of concept and allows you to track changes and security risks in your environment across time, like continuous penetration testing, is what keeps your compliance evidence current between formal tests.

More on why the continuous penetration testing proof trail matters now

The numbers make the case clearly. For instance:

• Exploitation of security vulnerabilities as an initial access vector grew again in Verizon’s 2025 Data Breach Investigations Report. It reached a 34% year-over-year increase, after nearly tripling in the 2024 report.
• ENISA’s finance sector threat report from 2025 (covering security incidents recorded between January 2023 and June 2024) found that attacks on suppliers led to:
  • Sale or exposure of sensitive data in 63% of cases
  • Operational disruption in 26%
  • Financial loss in 11%

In case you were wondering, these last numbers matter for DORA compliance because most financial services depend on third parties, APIs, cloud services, identity tools, and shared data flows.

Continuous automated penetration testing findings can provide the exact data that shows where a weakness touches a provider link, a service path, a customer record, a money movement, or a control point. Without that data, you are guessing at your exposure. With it, you can act on it.

How to run continuous penetration testing inside a DORA compliance program

Not every test cycle requires the same scope. Some can focus on a single workflow, application, or API endpoint, while others cover more. What is important is that each test has a clear trigger.

Some useful triggers:

• A fix for a previous penetration testing finding
• A new authentication or authorization model
• A new API that supports a critical function
• A new ICT provider added to a service path
• A change to logging, rate limits, or access rules
• An alert about a threat that affects the company’s systems
• A TLPT task that needs proof of completion
• Lessons learned from ICT incidents or close calls

Also, for continuous testing to be compatible with DORA, four governance principles must be in place:

• Independence. The testing process must remain independent of the teams responsible for the systems, processes, or controls being tested.
• Severity classification. The testing must rank each finding against the company’s ICT risk criteria, not return an unranked list of issues.
• Remediation tracking. The owner of the affected application, system, or service must fix the issue, and the testing process must confirm the fix before closure.
• Evidence retention. Regulators need to see what ran, what the testers found, and what the team did about it.

Equixly and DORA penetration testing

Equixly focuses on continuous penetration testing for applications and APIs.

The platform uses agentic AI to automatically test live systems, chain API calls and workflows, validate exploitability, and provide proofs of concept along with remediation guidance. Moreover, it integrates with CI/CD pipelines and supports retesting in development as well as production.

Regarding DORA, these capabilities support the evidence, remediation, and testing records that feed your compliance program. That means Equixly enables financial entities and ICT providers to

• Continuously test apps and APIs tied to critical or important functions.
• Turn findings about API-based systems — from web apps to GenAI systems to MCP implementations — into verifiable evidence of exploitability.
• Retest fixes after remediation or mitigation and confirm closure.
• Support ICT risk management with always current testing evidence.
• Prepare cleaner scope data before a formal DORA TLPT.
• Give developers reliable findings they can act on promptly.

Consider that the platform does not determine whether an entity falls within the scope of TLPT. It does not replace competent authorities, the DORA RTS (Regulatory Technical Standards), a threat intelligence provider, or qualified TLPT testers, as required by DORA. Rather, its role is clearly defined elsewhere, sitting in the proof trail:

1. Test the path.
2. Show the effect.
3. Support the fix.
4. Validate the result.

Final thoughts

DORA imposes a regulatory duty on financial entities to test the ICT systems and applications that support critical functions. TLPT adds deeper threat-led penetration testing for selected entities.

Continuous penetration testing helps maintain a working proof trail between those formal obligations. Not as a shortcut around them, but as the operational layer that keeps evidence current as systems change.

Reports are key for compliance. And the proof trail based on them is what drives your compliance work forward.

Start your pentest with Equixly. Build your DORA proof trail.

FAQs

Does continuous penetration testing count as DORA TLPT?

No, continuous penetration testing supports TLPT preparation and remediation evidence. But the financial entities that fall within the scope of the TLPT requirement must still follow the formal DORA TLPT process and the DORA RTS.

What should DORA penetration testing evidence include?

Each piece of evidence should link the

• Tested system
• Critical function at risk
• Threat that justified the test
• Exploit proof
• Fix owner
• Retest result
• And a residual risk decision

Should application penetration testing include APIs under DORA?

Absolutely, application penetration testing must cover APIs whenever they support critical or important functions, handle sensitive data, or connect the financial entity to an ICT third-party provider.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.

Gavin Sutton

Head of Marketing

Gavin is marketing leader with more than a decade of experience in the cybersecurity industry helping startups and scale ups grow internationally. He has a passion for working with disruptive technology companies who can reshape the security landscape with their innovative solutions.