Resilience testing under DORA: planning and evidencing the programme

This page applies to both frameworks: to financial entities under the full framework of Articles 5 to 15 DORA and to entities under the simplified framework of Article 16, including, from 1 January 2027, the institutions under Section 1a(2a) of the German Banking Act (KWG) (here: KWG group) such as factoring and leasing firms. Which framework applies to you is covered on our page DORA applicability. Chapter IV of the Regulation governs testing in four articles: Articles 24 and 25 for the testing programme, Articles 26 and 27 for TLPT.

What does Article 24 DORA require of the testing programme?

A programme that identifies weaknesses, deficiencies and gaps in digital operational resilience and triggers corrective measures. It is an integral part of the ICT risk management framework and is established, maintained and reviewed (Article 24(1)). The six paragraphs at a glance:

Which functions are critical or important is set by your list of functions. Without it, paragraph 6 cannot be planned.

Which tests does Article 25 list?

Article 25(1) lists the tests as examples (“such as”). Which of them you carry out and how often depends on your risk profile. For some of them, Delegated Regulation (EU) 2024/1774 (“RTS” below) sets more specific requirements under the full framework:

DORA sets no fixed frequency for penetration tests.

What does “test at least yearly” under Article 24(6) mean?

Every ICT system and application that supports a critical or important function is tested appropriately at least once a year, even if a service provider runs it. DORA does not specify which test. In our assessment it should match the risk of the system, for example a penetration test for a customer portal, or an end-to-end or performance test for a processing chain. Whether Article 24(6) applies under the simplified framework is open (see below).

How much testing is appropriate?

That depends on your size, overall risk profile and the complexity of your business. For Chapter IV, the principle of proportionality applies only where the provisions expressly provide for it (Article 4(2)). Articles 24 and 25 do: the programme takes the criteria from Article 4(2) into account, the approach is risk-based and the tests are “appropriate”.

Microenterprises test under Article 25(3): they combine a risk-based approach with strategic planning of ICT testing and weigh resources and time against urgency, risk and criticality. Paragraphs 1 and 3 to 6 of Article 24 are not addressed to them. Whether your firm is a microenterprise is checked against both size criteria, see DORA applicability.

What applies under the simplified framework of Article 16?

An ICT security testing plan under RTS Article 36. It validates the effectiveness of the security measures under RTS Articles 33 to 35, 37 and 38 and considers the threats and vulnerabilities identified in risk management under RTS Article 31 (paragraph 1). Testing takes into account the overall risk profile of the ICT assets (paragraph 2). You turn findings on systems supporting critical or important functions into updated measures without undue delay (paragraph 3). The RTS also requires automated vulnerability scanning (RTS Article 34(d)), but sets no fixed frequency for it as under the full framework.

Articles 24 and 25 contain no exemption for Article 16 entities. That the testing programme therefore also applies here is our reading. Reasoning, counter-argument and recommendation are on our page DORA Article 16: the simplified framework. The yearly tests of the business continuity plans under RTS Article 40 are covered on our page ICT business continuity.

TLPT: who must carry out threat-led penetration testing

Only financial entities that the authority identifies for it. They carry out TLPT at least every three years, and the authority may adjust the frequency based on the risk profile (Article 26(1)). Entities under Article 16(1) and microenterprises are excluded. For the KWG group, Section 1a(2a) sentence 2 no. 2 KWG expressly excludes Articles 26 and 27, so TLPT never applies to them.

Who is identified: The authority assesses the impact on the financial sector, financial stability concerns and the ICT risk profile (Article 26(8)). Delegated Regulation (EU) 2025/1190 (RTS on TLPT) specifies this in Article 2(1) with criteria such as size, interconnectedness, substitutability, threat situation and maturity of security controls. Under Article 2(2), the authority as a rule requires TLPT from systemically important credit institutions, large payment and e-money institutions, central securities depositories, central counterparties, certain trading venues and large insurers, unless its assessment concludes otherwise.

Who is responsible in Germany: For institutions under the KWG, BaFin cooperates with the Deutsche Bundesbank on the tasks under Articles 26 and 27, and the Bundesbank carries out the operational tasks (Section 6(1g) KWG). Under recital 1 of the RTS on TLPT, entities required to test may apply the TIBER-EU framework or a national implementation such as the Bundesbank’s TIBER-DE, provided these are consistent with Articles 26 and 27 DORA and the RTS.

How TLPT works:

• Preparation: the management body approves the scope specification document (RTS on TLPT Article 9(6)), and the authority validates the scope. Several or all critical or important functions are tested on live production systems (Article 26(2) DORA).
• Threat intelligence and testing: at least three scenarios (RTS on TLPT Article 10(3)), an active red team testing phase of at least twelve weeks (Article 11(5) RTS (EU) 2025/1190).
• Closure: red team and blue team reports, purple teaming (RTS on TLPT Article 12), a remediation plan (Article 13 RTS (EU) 2025/1190) and the attestation from the authority (Article 26(7) DORA).

Testers must meet the requirements of Article 27, and additional rules apply to internal testers (Article 26(8), see FAQ). You contractually oblige service providers that support critical or important functions to participate in your TLPT (Article 30(3)(d)).

Example: 2027 test plan of Muster-Kreditbank AG

Fictitious example, not a client. Muster-Kreditbank AG is the CRR credit institution from the example on our page ICT risk management: 140 employees, full framework, a data centre service provider runs the core banking system with online banking, and a managed service provider (MSP) runs workstations and the network. Added for this example: an online loan application process developed in-house. The critical or important functions are payments, credit decisions and disbursement, and regulatory reporting. The bank does not plan TLPT: it belongs to none of the groups under Article 2(2) of the RTS on TLPT and has not been identified.

The bank checks coverage under Article 24(6) in a column of its list of functions: each of the three functions is covered by a suitable test at least once a year. For findings under Article 24(5) it uses four classes. The deadlines are example values, DORA sets none:

If a deadline is missed, the management board decides on an exception or escalation. Under the full framework, RTS Article 10(4)(d) also requires deadlines and escalation for patches.

Three typical gaps

How we help

For entities under the full framework, the DORA gap analysis shows where your testing programme stands against Articles 24 and 25 and the RTS. Institutions of the KWG group moving from BAIT (BaFin’s supervisory requirements for IT in banks) on 1 January 2027 implement the test plan under RTS Article 36 in the transition from BAIT to Article 16. Other institutions under the simplified framework, such as small investment firms, small IORPs or insurance holding companies, start with the Article 16 gap analysis. We offer penetration tests under Article 25 (not TLPT under Article 26) on our company page on penetration testing.