DORA Penetration Testing & TLPT

Article 24 requires every in-scope entity to establish a sound, comprehensive digital operational resilience testing program as part of its ICT risk-management framework. Article 25 lists the tools that program can use, including vulnerability assessments, network security assessments, penetration testing, and source-code reviews where relevant. This is the layer most financial entities live at, and it maps directly onto the web, network, API and cloud testing we run every week.

Article 26 introduces advanced testing through TLPT for the entities identified as significant enough to warrant it. It sets the ground rules: testing on live production systems, covering several critical functions, carried out at least every three years. Article 27 sets the requirements for the testers and the threat intelligence behind the test, and the accompanying RTS on threat-led penetration testing fills in the detail on scope, methodology and the tester pool.

What TLPT demands of a provider

The RTS expects the red team and the threat intelligence to meet specific competence and independence standards, and expects the exercise to be coordinated with the relevant authority. We deliver the red team and intelligence component to that standard. We do not claim to grant our own regulatory accreditation, and a formal DORA TLPT is coordinated with your authority, drawing on the TIBER-EU model that many European supervisors use as the operating framework.

We identify the systems that support your critical functions, agree rules of engagement, and map the external surface with tooling such as nmap and passive reconnaissance before anything intrusive runs.

Burp Suite drives the web and API work; custom tooling and hands-on tradecraft cover network, cloud and business-logic testing. We prove each weakness by exploiting it safely and chain findings to show the real path from the internet to a system that matters.

You receive an executive summary and a technical report, each finding scored with CVSS, evidenced and paired with a prioritized fix. After remediation we retest for free and confirm the issues are closed.

You form a small control group, we agree the critical functions in scope and the rules of engagement, and for a formal test your authority is involved from the start. The scope has to cover several critical or important functions, per Article 26.

A threat intelligence provider builds a targeted picture of the actors that attack your part of the financial sector, referenced to MITRE ATT&CK. The red team turns that into scenarios and executes them on live systems, attempting initial access, escalation and lateral movement toward the flags, staying stealthy enough to test your detection.

We disclose to your blue team, replay the whole attack path with them, and help produce the remediation plan and the test summary the authority reviews. A retest of the fixes is included.

In customer portals and banking APIs, we regularly find that one authenticated user can read or move another’s data by changing an identifier. It is the most common serious finding in web finance, and a scanner rarely catches it.

Weak multi-factor implementations, token handling mistakes and SSO misconfigurations that let an attacker bypass the login the business trusts.

Overly broad IAM roles, exposed storage, and flat networks that let one compromised system reach a payment or settlement platform.

DORA puts ICT third-party risk front and center, and for good reason. We look at the standing access your critical providers hold and what an attacker could reach through it.

An executive summary, a technical report with CVSS-scored findings, evidence and reproduction steps, and a mapping to the Chapter IV testing articles so your supervisor sees exactly how the test satisfies the regulation.

An attestation letter for your resilience program file, a prioritized remediation plan, and a free retest that produces the confirmation letter audit wants to see.

The regulation reaches credit institutions, payment and e-money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, trading venues, central securities depositories and more, plus the ICT third-party providers that serve them. Proportionality applies, so a small firm carries a lighter load than a systemic bank, but the baseline testing obligation is close to universal.

A resilience program is not a single test; it is a documented cycle. The sensible pattern is an annual baseline penetration test of the systems behind your critical functions, extra testing after any material change, and, for entities that reach the TLPT threshold, a threat-led exercise at least every three years. Starting a year ahead of any supervisory review gives you room to remediate and produce a clean retest letter rather than presenting open findings.

Coordinating a formal TLPT

Because a formal threat-led test is coordinated with your authority and typically runs on the TIBER-EU model, the lead time is long. Firms that expect to be in the TLPT population should open the conversation with us and their supervisor well before the deadline, so the intelligence and scoping are not rushed.