DORA Penetration Testing Requirements, in Plain Terms

DORA requires EU financial entities to run a risk-based resilience testing programme, with appropriate tests at least yearly on every ICT system and application that supports a critical or important function, carried out by independent testers. Entities their authority identifies must also carry out threat-led penetration testing (TLPT) on live production systems at least every three years, under detailed rules in Commission Delegated Regulation (EU) 2025/1190. DORA does not regulate a UK testing firm directly, but its tester, evidence and data rules reach you through your EU clients' contracts.

Who it applies to, and the UK angle

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. Article 2 lists twenty kinds of financial entity, from credit institutions, payment and e-money institutions and investment firms to insurers, crypto-asset service providers, central counterparties, trading venues, fund managers and credit rating agencies, and adds ICT third-party service providers for its oversight regime.

It is proportionate. Microenterprises test on a lighter, risk-based footing, and both they and entities on the simplified regime under Article 16 are outside threat-led testing.

A UK company is not in scope as such, though an EU-authorised subsidiary of a UK group is. A UK testing firm meets DORA as a supplier: the obligations sit on the client, and much of the evidence comes from you. This is not legal advice. National supervisors interpret DORA, so have a solicitor check your own terms before you sign an EU financial client's contract.

The annual testing programme

Articles 24 and 25 set the baseline for every financial entity except microenterprises:

• A programme within the ICT risk management framework, mixing assessments, tests and tools chosen on a risk basis.
• Appropriate tests from a long list running from vulnerability assessments, open source analyses, network security assessments and gap analyses through source code reviews, where feasible, and scenario-based and end-to-end testing to penetration testing.
• Independent testers, internal or external. An internal tester needs dedicated resources and no conflict of interest in design or execution.
• Remediation discipline: procedures to "prioritise, classify and remedy all issues", and internal validation that every weakness is fully addressed.
• A yearly floor: appropriate tests, at least yearly, on all ICT systems and applications supporting critical or important functions.

Central securities depositories and central counterparties must also run vulnerability assessments before any deployment or redeployment of applications, infrastructure or ICT services that support critical or important functions.

DORA is less prescriptive than PCI DSS requirement 11.4. "Appropriate tests" does not mean a penetration test of everything every year. It means every system supporting a critical or important function is tested by something proportionate each year, with penetration testing where the risk justifies it. The arguments happen at the edges: which systems support those functions, and whether last year's test still counts for a system that has changed since. Settle both in the scope document.

Threat-led penetration testing every three years

Article 26 requires identified entities to carry out TLPT at least every three years, though the authority can shorten or lengthen that. Each test covers several or all critical or important functions, runs on live production systems, and brings in any ICT third-party provider within its scope.

The detail sits in Delegated Regulation 2025/1190, adopted on 13 February 2025, published on 18 June 2025 and in force since 8 July 2025. It names who must test unless their impact does not justify it: banks designated as globally or otherwise systemically important (G-SIIs and O-SIIs), central securities depositories, central counterparties, payment institutions above EUR 150 billion of transactions in each of the two previous calendar years, e-money institutions above that or EUR 40 billion of outstanding e-money, the largest trading venues and the largest insurers. Authorities can add others on impact, systemic and ICT risk grounds.

What DORA asks of testers

Article 27 says TLPT testers must be of the highest suitability and reputability; have specific expertise in threat intelligence, penetration testing and red teaming; be certified by an accreditation body in a member state or adhere to formal codes of conduct or ethical frameworks; give independent assurance or an audit report on how they manage the risks of TLPT, including protection of the client's confidential information; and carry professional indemnity insurance covering misconduct and negligence.

The delegated regulation turns that into a checklist the client's control team keeps on file: CVs and copies of certifications appropriate under recognised market standards, at least five references from previous penetration and red team assignments, and a red team led by a manager with at least five years' experience plus at least two testers with two years each, who between them have taken part in at least five previous assignments. Testers must clean up afterwards, including secure deletion of compromised credentials and secure storage and disposal of the data collected, and must never include out-of-scope systems or disclose results without authorisation.

Internal testers are allowed with the authority's approval, but the threat intelligence provider must then be external, and external testers must run every third test. Credit institutions classed as significant must use external testers only.

For a UK firm, the certification limb is awkward because the accreditation body must be in a member state. The code of conduct limb is the natural route, and a scheme code such as the one CREST members sign on joining and again at each renewal is the obvious evidence to offer. None of this formally applies to tests in the annual programme, which only need independence, but expect clients to borrow it.

TIBER-EU and CBEST

DORA required the technical standards on TLPT to be written "in accordance with the TIBER-EU framework", and the ECB has since updated TIBER-EU for full alignment with them. TIBER-EU is a framework rather than law, and the ECB says it "can also assist" entities with DORA's TLPT requirements; its 2025 guidance documents, from the scope specification and targeted threat intelligence report to the red team test plan, blue team report, purple teaming, test summary report and attestation, are the most practical templates available.

The UK equivalent is CBEST, the regulator-led framework used by the Bank of England, the PRA and the FCA, whose providers must be accredited by the Bank, be CREST members and employ certified individuals; our comparison of CHECK and CREST covers that ground. DORA's attestation exists so that competent authorities, which are EU authorities, can recognise each other's tests; nothing in it makes a CBEST assessment count. A UK group with an EU entity may need both, and scoping them together saves real effort.

What the evidence must show

For the annual programme, the record should show each system supporting a critical or important function, when it was last tested and by whom, why that tester was independent, how each finding was prioritised and classified, and proof that the fix worked. In our experience that last item is the one most often missing, and a properly run retest is what supplies it. Agreed fix times by severity, as set out in our guide to vulnerability remediation timelines, make the prioritisation visible.

For TLPT, Article 26(6) asks for a summary of the relevant findings, the remediation plans and documentation showing the test met the requirements. The delegated regulation specifies the test summary report: the validated scope and the reasoning behind it, scenarios, attack paths and techniques at summary level, flags captured and missed, deviations, blue team detections, leg-ups given, risk controls, vulnerabilities with their criticality, root cause analysis, a high-level remediation plan and lessons learned. The authority then issues an attestation recording the dates, functions covered and not covered, third parties involved, whether internal testers were used, and how many days active testing lasted.

Write findings for that reader. Each should name the critical or important function it affects, its criticality and its root cause, and the report should say what was not tested and why.

What UK firms testing EU clients should expect

• Due diligence before a TLPT. CVs, certifications, references and insurance certificates, kept on file by the client's control team.
• Contract terms on results. Article 27(3) requires contracts to ensure that processing of TLPT results, "including any generation, store, aggregation, draft, report, communication or destruction", does not create risks to the client. You will be asked where every copy lives.
• Secrecy. Need-to-know access to anything about the test, and code names where possible.
• Personal data. Transfers from the EU to the UK rely on the Commission's adequacy decision for the UK, renewed on 19 December 2025. DORA's confidentiality duties sit on top of that; our post on UK GDPR for testing firms covers your side.
• Third-party clauses. DORA defines ICT services as provided "on an ongoing basis", so whether a one-off test is an ICT third-party arrangement is a legal reading. Expect some clients to send their DORA contract schedule anyway.