DORA’s testing programme: what a financial entity has to prove, and how often

Of DORA’s several strands, the testing one is where the regulation stops being a governance exercise and starts making demands on an engineering calendar. It is also the strand most often described inaccurately, usually by collapsing two quite different obligations into a single phrase about penetration testing.

Regulation (EU) 2022/2554 has applied since 17 January 2025 to financial entities across the Union, a category drawn widely enough to include banks, payment and electronic money institutions, investment firms, insurers and intermediaries, trading venues, fund managers and crypto-asset service providers. Being a regulation rather than a directive, it applies directly, without waiting for national transposition.

Two obligations, not one

The first is a standing testing programme that every in-scope entity must run, proportionate to its size and risk profile. The second is threat-led penetration testing, which only applies to entities that competent authorities identify for it, and which is a materially heavier exercise with its own rules about who may carry it out.

Conflating them produces two opposite errors. Smaller entities assume they owe an elaborate red-team engagement they do not; larger ones assume their annual assessment satisfies a requirement it does not touch.

Everyone in scope owes a testing programme. A subset owes threat-led penetration testing on top of it, performed by testers who meet criteria the regulation states explicitly.

The standing programme

The programme has to be part of the ICT risk-management framework rather than a separate activity, it has to be risk-based, and it has to cover the systems and applications that support critical or important functions. Those functions are tested at least once a year, and the results feed back into remediation with priorities recorded.

That phrase, critical or important functions, is doing most of the work. Scoping the programme means first deciding which business functions would cause material harm if they were disrupted, then mapping those to the systems, applications and third-party services underneath them. Teams that skip the mapping test what they already had tooling for, which is a different set.

What counts as a test

The regulation names a range of test types rather than a single method, which is unusually helpful. An engineering team reading the list will recognise most of it as work it already does under other names.

• Vulnerability assessments and scans across the estate supporting the functions in scope.
• Open source analyses and reviews of the components you did not write.
• Network security assessments and gap analyses against the controls you believe you have.
• Physical security reviews, questionnaires and scanning tooling.
• Source code reviews where that is feasible.
• Scenario-based testing, compatibility testing, performance testing and end-to-end testing.
• Penetration testing.

Two of those deserve emphasis because they are routinely under-scoped in financial products. End-to-end testing means following a transaction across every system it touches rather than checking each component in isolation, which is where reconciliation errors live. And scenario-based testing means deliberately producing the failure states that a happy-path suite never reaches, which for financial products means timeouts, retries, partial failures and duplicate submissions exercised on purpose.

Who is allowed to run it

Tests must be undertaken by parties that are independent, and the regulation permits those parties to be internal or external. Internal testing is not a loophole: where it is used, the entity has to devote sufficient resources to it and ensure that conflicts of interest are avoided throughout the design and execution of the test.

Read practically, that rules out the arrangement most teams default to, in which the squad that built a service also signs off its security testing. Separation can be organisational rather than contractual, but it has to be real and it has to be documented.

Threat-led penetration testing

The heavier obligation applies to financial entities identified by their competent authority as significant enough to warrant it, based on risk profile and systemic relevance. Where it applies, the test is carried out at least every three years, and its character is different from a routine assessment in four ways.

1. 01It is intelligence-led. The scenarios come from threat intelligence about actors plausibly interested in that entity, rather than from a generic methodology, and the approach draws on the European framework developed for exactly this kind of testing.
2. 02It runs against live production systems, not a staging copy, which is what makes it demanding to organise and genuinely informative when it is done.
3. 03It covers several or all of the critical or important functions together, so it tests the seams between them rather than each in isolation.
4. 04Third parties are pulled in. ICT service providers supporting the functions in scope have to participate and cooperate, which for a supplier means being named in someone else’s test plan.

The rules on testers are the part that decides who can bid for this work. External testers must be of high standing and demonstrable technical and organisational capability, must be certified by an accreditation body in a member state or adhere to formal codes of conduct or ethical frameworks, must provide independent assurance about the management of risk during the test, and must carry professional indemnity cover. Internal testers may be used subject to conditions, including the periodic use of external ones.

So the boundary here is unambiguous, and we would rather state it than let a procurement process discover it. We are not an accredited provider of threat-led penetration testing and we do not bid for it. An OWASP-based assessment is a contribution to the standing programme, not a substitute for a test the regulation defines by who performs it.

What reaches a software supplier

DORA devotes a whole strand to ICT third-party risk, and the effect on suppliers is direct. Financial entities must maintain a register of their ICT service arrangements, and their contracts with providers have to contain specified provisions covering service descriptions, locations, data handling, access and audit rights, incident cooperation, exit strategies and termination triggers.

• Expect to be asked to name where the service runs and where data is processed, at a level of specificity that a contract can carry.
• Expect audit and access rights, exercisable by the entity, its auditors and its competent authority.
• Expect obligations to assist during incidents, on the entity’s clock rather than yours.
• Expect an exit plan to be a contractual artefact, because the regulation treats concentration and lock-in as risks in their own right.
• Expect to be asked for evidence of your own testing, particularly around the interfaces the entity depends on. Contract-level API testing and application security work is the material that answers it.

None of that requires the supplier to be in scope of DORA itself. It arrives as terms, in the same way the supply-chain obligations of other EU instruments do, and it is negotiated at renewal by people who are themselves being supervised.

The engineering reading

Strip away the vocabulary and the programme asks a delivery team for four capabilities: know which systems sit behind the functions that matter, test them on a stated cadence with someone independent, record what was found and what was done about it, and be able to show the trail afterwards. Most of that is ordinary security and quality practice with the evidence kept.

The part that is genuinely additional is the discipline of scoping by business function rather than by repository, and the requirement that whoever tests is not whoever built. Both are organisational decisions, and both are cheaper to make before an authority asks how the programme was designed.