DORA Penetration Testing Requirements: Fintech CISO Guide

DORA penetration testing requirements come in two tiers, and almost every fintech that panics about the first one actually sits in the second. DORA applies to essentially all EU financial entities, but threat-led penetration testing (TLPT) under Article 26 applies only to entities designated by their national competent authority against significance thresholds set in Commission Delegated Regulation (EU) 2025/1190. The obligation that applies to everyone else is Article 24(6): at least yearly testing of all ICT systems and applications supporting critical or important functions, using the test types enumerated in Article 25(1). Those are two very different purchases.

The Sentence That Sent You Down the Wrong Path

Someone told you "DORA requires threat-led penetration testing every three years." That sentence is true. For the median reader of this post, it is also irrelevant, and acting on it will commit you to a six-figure engagement, often well into several hundred thousand euros once threat intelligence, red team and closure phases are priced separately, that you never needed to buy.

The confusion is structural. Regulation (EU) 2022/2554 has a chapter on digital operational resilience testing containing two distinct obligations stacked on top of each other. The base layer applies to every financial entity in DORA's scope, microenterprises included on a proportionate basis. The advanced layer, TLPT, applies only to a small population that their supervisor formally designates. Law firm explainers lead with TLPT because it is the novel part. Vendors lead with TLPT because it carries a much larger price tag.

The cost of getting this wrong runs both ways. Over-buy and you have procured a twelve-week red team, a separate threat intelligence provider, and a purple teaming closure phase for an obligation you never had. Under-buy and you have a supervisory finding: no documented testing programme, no evidence that the systems behind your critical or important functions were tested in the last twelve months, no remediation tracking. The second failure is far more common.

So before you talk to anyone about scoping, you need to answer one question: which tier are you in?

The DORA Penetration Testing Requirements, in Four Articles

The testing chapter is short. Four articles carry almost all of the operational weight, and reading them in order makes the two-tier structure obvious.

Article 24: The Resilience Testing Programme

Article 24 requires you to establish, maintain and review a sound and comprehensive digital operational resilience testing programme as part of your ICT risk management framework. Three paragraphs matter most. Article 24(3) requires a risk-based approach for all financial entities other than microenterprises, taking account of the evolving ICT risk landscape. Article 24(4) requires that tests are undertaken by independent parties, internal or external, with conflicts of interest avoided where the tester is internal. Article 24(6) is the sentence most people are actually looking for: financial entities other than microenterprises shall ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions.

That is your annual obligation. It is not TLPT, and it does not become TLPT.

Article 25: Testing of ICT Tools and Systems

Article 25(1) tells you what counts as a test. It sets out an open list of accepted types: vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing.

Read that list again, because it is more permissive than most buyers assume. Penetration testing is one item on a menu of twelve, not a standalone mandate. What the regulation asks is that you select appropriate test types for each asset, in proportion to risk, and document why. A scoped penetration test against your payment API, plus authenticated vulnerability assessment across supporting infrastructure, plus source code review of the settlement service, is a defensible Article 25(1) programme. A single annual scan of your marketing site is not.

Article 25(2) adds a specific pre-deployment vulnerability assessment obligation for central securities depositories and central counterparties. Article 25(3) is the microenterprise carve-out, letting microenterprises apply the test types according to urgency, risk type, criticality of assets and services, and their capacity to take calculated risks.

Article 26: Threat-Led Penetration Testing

Article 26(1) requires designated entities to carry out TLPT at least every three years. Article 26(2) requires each test to cover several or all critical or important functions and to run on live production systems. Note who is carved out before you go further: Article 26(1) excludes microenterprises and the entities listed in Article 16(1), so a small, non-interconnected investment firm is outside the TLPT tier by construction.

Two paragraphs carry the scoping machinery, and they are frequently conflated. Article 26(8) is the one that puts the designation decision in your competent authority's hands, directing it to identify entities on an assessment of impact on the financial sector, financial stability concerns including systemic character, and the entity's specific ICT risk profile and maturity. Article 26(11) is the mandate for the joint regulatory technical standards that specify those criteria further, which is what became Delegated Regulation (EU) 2025/1190. So you do not read Article 26 to find out whether you are in scope. You read the delegated regulation, then wait for your supervisor to tell you.

Article 27: Who Is Allowed to Test

Article 27 sets the bar for TLPT testers specifically. They must be of the highest suitability and reputability, demonstrate expertise in threat intelligence, penetration testing and red teaming, be certified by a Member State accreditation body or adhere to formal codes of conduct, provide independent assurance on their own risk management, and carry professional indemnity insurance covering misconduct and negligence. Internal testers may only be used with the prior approval of the relevant authority, the threat intelligence provider must be external in every case, and an external tester must be used at least every three tests. Credit institutions classified as significant under the SSM must use external testers only.

Note the asymmetry. Article 27's accreditation bar applies to TLPT. For Article 24 and 25 testing, the requirement is the lighter one in Article 24(4): independence and absence of conflict of interest. That distinction is worth a great deal of money.

Lighter is not the same as absent, and this is where cheap programmes fail. Article 24(4) rules out the most tempting option on the table: your own engineers running a scanner against systems they built and writing up the output. A test scoped and run by an outside party, with the independence basis recorded in the engagement letter, clears Article 24(4). A self-run scan does not, however good the tooling is.

Are You in TLPT Scope? The Thresholds, in One Table

TLPT designation is driven by the identification criteria in Commission Delegated Regulation (EU) 2025/1190, which builds on the ESAs' joint final report JC 2024-29. Here is the shape of it.

Why Most Fintechs Fall Below the Line

Run your own numbers against the payment institution threshold and the answer arrives in about ten seconds.

A payment institution processing EUR 3bn in annual transaction volume is at 2.5% of the EUR 120bn threshold. To reach it, that firm would need to grow fortyfold and sustain it for two consecutive financial years. A fast-growing e-money institution with EUR 400m in outstanding balances is at 1% of the EUR 40bn limb. A crypto-asset service provider authorised under MiCA is reached through the Article 85 significance threshold (15 million or more active users on average per calendar year), which in practice means the very largest platforms; a CASP below that line enters TLPT scope only by discretionary designation.

This is not a marginal call. The thresholds were set to capture institutions whose failure would transmit stress into the wider financial system. A 400-person payments company with EUR 2bn in annual volume and eleven engineers is not that institution, and the regulation is not pretending it is.

The Catch-All: NCA Discretion

There is one important qualification. TLPT designation is a decision made by your national competent authority and notified to you. It is not something you self-assess and record in a policy document.

The identification criteria give supervisors discretion to designate entities on the basis of ICT risk profile, systemic relevance in the national market, and criticality of services provided, even where the numeric thresholds are not met. Practically, this catches firms that are small on the balance sheet but structurally important in one Member State: the payments provider clearing a meaningful share of domestic e-commerce, the CASP that dominates a national market, the specialist insurer everyone reinsures through.

If you are plausibly in that territory, do not wait to find out. Write to your NCA, describe your services and volumes, and ask whether you fall within their expected designation population for the first TLPT cycle. Supervisors would rather have that conversation early than discover an unprepared entity at notification time, and the answer gives you something concrete to put in front of your board.

If You Are in Scope: What a TLPT Actually Involves

If your NCA does designate you, be clear about what you have bought, because it is not a larger version of the penetration test you ran last year.

A scoped application penetration test asks: can an attacker compromise this specific asset, given this scope, in this timebox? It is bounded, it is announced, and its output is a findings register you hand to engineering. A TLPT asks a different question: using intelligence about adversaries who actually target entities like you, can a red team achieve a defined objective against live production systems without your defenders knowing a test is happening? The scope is the function, not the asset. Only a small control team knows the test is running; your defenders do not. The output is as much about detection and response as about vulnerabilities.

The delegated regulation, adopted 13 February 2025, published in the Official Journal on 18 June 2025 and applicable from 8 July 2025, sets the mechanics. Active red team testing must run a minimum of twelve weeks. Purple teaming is mandatory in the closure phase, with red and blue teams jointly replaying offensive and defensive actions. Your threat intelligence provider must be external to your firm and separate from your red team provider, and that holds even where the red team is internal. Testing runs against live production, which means a formal risk management plan and control team oversight throughout. TIBER-EU is the reference methodology, already localised in most Member States.

The timeline is what surprises boards. First NCA designation notifications are expected from late 2026 into early 2027. Once notified, you have three months to submit the initiation documents and six months for the scope specification document. Both clocks run from the notification, not from each other, so the scoping deadline is six months out and not nine. Add the threat intelligence phase, the twelve week minimum active phase, and a closure phase in which the blue team report falls due around ten weeks after the active phase ends: the regulated milestones alone put you near twelve months from designation, and practitioners running early tests report twelve to eighteen from board decision to submitted closure report.

One thing worth stating plainly: a TLPT is a specialist, accredited engagement, and CyberOrbit does not deliver one. If your NCA designates you, you need a provider meeting the Article 27 bar plus a separate threat intelligence firm, which is a different procurement from anything on our pricing page. Most readers will never be designated, and the advice that matters to them is in the next section.

If You Are Not in Scope: The Obligation You Do Have

For the great majority of DORA-regulated entities, which will never be designated for TLPT, here is the obligation translated into procurement language.

At least once every twelve months, on every ICT system and application supporting a critical or important function, run appropriate tests drawn from the Article 25(1) list, conducted by an independent party, with findings prioritised, classified and remediated under a documented procedure. That is Articles 24(4), 24(5), 24(6) and 25(1) working together. It is a real obligation with real evidence requirements, and it is entirely satisfiable without a red team.

One honest caveat before you treat that as a single purchase order. An external, scoped assessment, ours included, covers the internet-facing systems and applications behind your critical or important functions. Several test types on the Article 25(1) list sit outside that boundary: physical security reviews, performance and compatibility testing, source code review of systems a tester is not given access to, and anything on a purely internal estate. Article 24(6) asks for a programme, not one engagement. Buy the external test from a provider like us, and evidence the remaining test types deliberately rather than assuming one report covers the chapter.

Defining "Critical or Important Functions"

This scoping decision determines everything downstream: cost, duration, and whether your evidence survives supervisory review. DORA defines a critical or important function as one whose disruption would materially impair your financial performance, the soundness or continuity of your services and activities, or your continued compliance with the conditions and obligations of your authorisation.

Work it through for a typical payments fintech. In scope: payment authorisation and settlement, the ledger, the customer-facing API gateway, the authentication stack behind the customer app, the KYC and AML screening pipeline (disruption there stops onboarding and breaches an authorisation condition), fraud detection, and the cloud infrastructure and deployment pipeline those services run on. Out of scope: HR and payroll SaaS, the marketing CMS, the internal wiki, the sales CRM, marketing analytics. None of those, dark for a week, would impair the soundness of your regulated services.

The grey zone is usually support tooling and internal admin consoles. If your support platform holds transaction data and your admin console can move money or change customer risk profiles, treat it as in scope. Document the reasoning either way: a supervisor can disagree with your conclusion and still accept your process, but cannot accept a process that does not exist. A subdomain enumeration pass against your primary domains is a cheap starting point, because it routinely surfaces staging environments and forgotten admin panels that belong to an in-scope function and never made the asset register.

What Your Supervisor Expects as Evidence

Supervisors are not asking to see scan output. Across NCA communications and the ESAs' published expectations, four elements recur: a documented methodology explaining what was tested and why those test types were chosen, findings with a consistent severity rating so prioritisation is auditable, remediation tracking connecting each finding to an owner and a date, and retest evidence proving closed findings were verified as closed rather than marked closed.

That last one catches people. A register with everything marked "remediated" and no verification step is the most common evidence gap we see. If you rate findings with CVSS or the OWASP Risk Rating methodology, say so in the methodology: a consistent, named scoring system is what makes prioritisation defensible. The same expectations show up almost verbatim in SOC 2 penetration testing requirements.

Turning that into a repeatable annual exercise is five steps.

Everything that process produces lands in one place. This is the pack to have ready before your supervisor asks for it.

Annual Snapshot vs Continuous: Why "At Least Yearly" Is a Floor, Not a Ceiling

Article 24(6) says "at least yearly." Article 24(3) says the programme must be risk-based and must take account of the evolving ICT risk landscape. Those two sentences are in tension for any entity that ships code more than once a year, and the resolution is not in DORA's text. It is in your own risk assessment.

Frame it on the regulation's terms, not on product features. If you deploy weekly, an annual test evidences your estate on one day out of roughly 250 working days. For the other 249, your documented position is that a risk-based programme concluded no further testing was warranted. That may hold for a stable estate. It is harder to argue for a payments platform that pushed 400 changes to an in-scope service since the last test. "How did your programme account for change between tests?" is a fair Article 24(3) question, and "we test in March" is not a complete answer.

Most entities land on the same middle ground: one deep independent test per year to satisfy Article 24(6), plus lightweight continuous coverage between tests to evidence Article 24(3). That second layer need not be expensive. TLS configuration drift on in-scope endpoints is checkable with an SSL checker, response header regressions with a header checker, and newly exposed hosts with a DNS analyzer. Evidence of monitoring is evidence of a programme.

Weigh the annual point-in-time test honestly before you build the programme around it.

DORA vs NIS2: Overlapping Obligations, Different Tests

Plenty of EU fintechs are caught by both DORA and NIS2, and the relationship is genuinely confusing until you know the rule.

DORA is lex specialis. Recital 16 of DORA states this expressly, Recital 28 of NIS2 mirrors it, and Article 4 of the NIS2 Directive gives it operative effect: where a sector-specific Union act imposes ICT risk management, incident reporting or resilience testing requirements at least equivalent to NIS2, the sectoral rules apply instead. For financial entities in DORA's scope, DORA's testing chapter displaces the equivalent NIS2 provisions. You do not run two parallel testing programmes for two regulators on the same subject matter.

That does not make NIS2 irrelevant. The displacement is scoped to the areas DORA actually covers. NIS2's governance and management accountability provisions, its supply chain expectations, and national implementations that go beyond the directive can still bite. If your group includes entities outside DORA's financial-entity definition, such as a technology subsidiary or a non-financial service line, those entities can be in NIS2 scope directly. Dutch fintech entities should note that the Cyberbeveiligingswet also entered into force on 15 August 2026 with no general grace period, so any group entity falling outside DORA's scope is already subject to it.

In practice, one programme satisfies both if you build it right. Scope it to critical or important functions as DORA defines them, use Article 25(1) test types, run it at least annually with independent testers, and keep methodology, severity ratings, remediation tracking and retest evidence. That pack meets DORA's requirements and comfortably covers what a NIS2 supervisor would ask of an essential or important entity. Build to the stricter standard once, then map the same artefacts to both regimes in your compliance register. If NIS2 is your primary concern, read Article 21 of Directive (EU) 2022/2555 alongside your Member State's transposing law, because national implementations diverge on testing cadence and on which entities count as essential rather than important.

Your 12-Month DORA Testing Plan

Here is the sequence to take to your board, ordered so the expensive decisions come after the cheap ones.

Confirm your entity classification and whether the microenterprise provisions apply. Map your critical or important functions and the ICT systems supporting each one, signed off by the business rather than only by security. Confirm your TLPT designation status with your NCA in writing, so the answer is on file rather than assumed. Establish the Article 24 programme document: risk-based rationale, test types per asset class, cadence, tester independence, and the remediation procedure required by Article 24(5). Schedule and run the annual Article 25(1) test against in-scope systems with an independent party. Then define what fills the gaps between tests, so Article 24(3) has an answer for the other eleven months.

Two notes for the board paper. Our 2026 penetration testing cost breakdown will reset expectations if your only reference point is traditional consultancy quoting, and how much of an Article 25(1) programme can responsibly be automated is worked through in when automated pentesting is enough. The short version: a large share of your external attack surface is testable at machine speed, which covers several of the Article 25(1) types well, while novel business-logic abuse, source code review and anything off the internet-facing estate still need people, so budget for both. On whether the resulting report survives scrutiny, what auditors accept in an AI-assisted pentest report covers the evidence standards.

Frequently Asked Questions

Start With the Obligation You Actually Have

The expensive mistake is buying a TLPT you were never designated for. The common one is having no documented Article 24(6) evidence at all. Confirm your designation status with your NCA in writing, then build the annual programme that almost certainly is your obligation.

This post is for informational purposes only and does not constitute legal advice. Confirm your entity classification and obligations with your NCA and qualified legal counsel.