Docs

Appearance

Testing and third-party risk — DORA Articles 24–30 ​

This page covers Articles 24–27 (digital operational resilience testing, including TLPT) and Articles 28–30 (ICT third-party risk management, including the register of information, contractual provisions, and subcontracting). Articles 31–44 (the EU oversight framework for designated critical ICT third-party providers) are summarised at the end with cross-references.

Quick decision ​

  • Setting up the testing programme → Article 24 sets the general requirements (for financial entities other than microenterprises); Article 25(1) lists the test types, and Article 24(6) sets the at-least-yearly baseline for systems supporting critical or important functions. Delegated Regulation 2024/1774 also contains technical detail on testing within the ICT risk management framework.
  • In scope of TLPT → Article 26(1) binds entities other than Article 16(1) entities and microenterprises that the competent authority identifies under Article 26(8), third subparagraph — based on impact-related factors, financial-stability considerations, and the entity's ICT risk profile and maturity. Article 27 sets tester-qualification rules; pooled testing sits in Article 26(4). Delegated Regulation 2025/1190 carries the technical standards.
  • Maintaining the ICT third-party register → Article 28(3) is the obligation; Implementing Regulation 2024/2956 carries the standard templates. The register distinguishes ICT services supporting critical or important functions from other ICT services.
  • Drafting or reviewing ICT TPP contracts → Article 30 sets the contractual baseline; Article 30(2) is the all-contracts baseline; Article 30(3) adds the heightened requirements for ICT services supporting critical or important functions. Delegated Regulation 2024/1773 specifies the policy for ICT services supporting critical or important functions; Delegated Regulation 2025/532 specifies subcontracting elements under Article 30(5).
  • ICT third-party service provider potentially designated critical → Articles 31–44 set the EU oversight framework. The Lead Overseer regime applies once designation occurs.

TL;DR ​

  • Articles 24–25 establish the digital operational resilience testing programme for financial entities other than microenterprises — risk-based, with at-least-yearly testing of all ICT systems and applications supporting critical or important functions (Art 24(6)) and the Article 25(1) catalogue of appropriate tests; microenterprises test on the proportionate Article 25(3) basis, and Article 16(1) entities under Article 16(1)(g).
  • Articles 26–27 add TLPT for entities meeting the Article 26 criteria. Delegated Regulation (EU) 2025/1190 specifies the TLPT technical standards.
  • Article 28 is the ICT third-party risk management cornerstone. Article 28(3) requires the register of information; Implementing Regulation (EU) 2024/2956 specifies the standard templates. Article 28(9) is the ITS mandate.
  • Article 30 sets the contractual baseline — Article 30(2) for all contractual arrangements, Article 30(3) for those covering ICT services supporting critical or important functions. Delegated Regulation (EU) 2024/1773 specifies the policy under Article 28(10); Delegated Regulation (EU) 2025/532 specifies subcontracting elements under Article 30(5).
  • Articles 31–44 establish the EU oversight framework for designated critical ICT third-party service providers, with a Lead Overseer regime run by the ESAs.

Primary source

Regulation (EU) 2022/2554 on EUR-Lex (CELEX 32022R2554) — Articles 24–44 · Delegated Regulation (EU) 2024/1773 · Implementing Regulation (EU) 2024/2956 · Delegated Regulation (EU) 2025/532 · Delegated Regulation (EU) 2025/1190

Articles 24–25 — digital operational resilience testing ​

DORA's testing duty is not uniform — it splits into three cohorts, and the addressee carve-outs in the operative text matter:

  1. Full testing programme — financial entities other than microenterprises. Article 24(1) requires financial entities, other than microenterprises, to establish, maintain and review a sound and comprehensive digital operational resilience testing programme as an integral part of the Article 6 ICT risk management framework. Articles 24(3)–(6) add the risk-based approach, tester independence, remediation procedures, and the duty to ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions. Article 25(1) lists the test types the programme provides for — 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. Article 25(2) adds a pre-deployment vulnerability-assessment duty for central securities depositories and central counterparties.
  2. Microenterprises — Article 25(3). Microenterprises perform the Article 25(1) tests by combining a risk-based approach with strategic planning of ICT testing, balancing resources and time against the urgency, type of risk, criticality of information assets and services, and other relevant factors. They are not required to operate the full Article 24 programme.
  3. Article 16(1) simplified-regime entities. Their testing duty derives from Article 16(1)(g) — regular testing of the Article 16(1)(f) continuity, response and recovery plans and measures, as well as of the effectiveness of the controls implemented under points (a) and (c) — with the technical detail in Title III of Delegated Regulation 2024/1774 (ICT security testing at its Article 36; ICT business continuity testing within Article 40), not from the Article 24 programme (see recital 43 and the Applicability and governance spoke for the regime split).

In Modulos: ORF-382 (governance) and MRF-305 (execution). ORF-382 states the three cohorts as separate limbs in its Applicability section, with DORA Addressee tags (Other than microenterprises, Microenterprises only, Simplified (Art 16(1) entities)) marking which limb binds which cohort.

Articles 26–27 — threat-led penetration testing (TLPT) ​

The TLPT duty has the narrowest addressee in DORA's testing chapter. Article 26(1) carries a double carve-out plus an identification gate: it binds financial entities other than Article 16(1), first subparagraph, entities and other than microenterprises — and, within that cohort, only those identified by the competent authority in accordance with Article 26(8), third subparagraph. Identified entities carry out TLPT at least every 3 years; the competent authority may, based on the risk profile and operational circumstances, request a reduced or increased frequency. Each test covers several or all critical or important functions and is performed on live production systems supporting those functions, with the scope assessment validated by the competent authorities.

Article 27(1) sets the requirements for testers: suitability and reputability (a); expertise in threat intelligence, penetration testing and red-team testing (b); certification by an accreditation body in a Member State, or adherence to formal codes of conduct or ethical frameworks (c); independent assurance or an audit report on TLPT risk management (d); and professional indemnity insurance (e). Article 27(2) sets the conditions for using internal testers; Article 27(3) the external-tester contract requirements. Two related rules sit in Article 26(8): financial entities using internal testers must contract external testers every three tests (first subparagraph), and credit institutions classified as significant under the SSM Regulation use only external testers (second subparagraph). Pooled TLPT — one test involving several financial entities served by the same ICT third-party provider — is provided for in Article 26(4).

Delegated Regulation (EU) 2025/1190 specifies the technical standards for TLPT under the Article 26(11) mandate, which directs the ESAs to develop them in accordance with the TIBER-EU framework.

In Modulos: ORF-383 (governance) and MRF-306 (execution). The ORF-383 overlay controls stage the TLPT lifecycle in three phases — applicability gating, scoping and preparation; tester governance and test execution (threat-intelligence and red-team phases); and closure, remediation planning, and authority attestation.

Article 28 — ICT third-party risk: general principles + register of information ​

Article 28 sets out the general principles for managing ICT third-party risk. Financial entities are required to manage ICT third-party risk as an integral component of ICT risk within their ICT risk management framework. The management body approves and periodically reviews the policy on arrangements regarding the use of ICT services provided by ICT third-party service providers (Article 5(2)(h)) and regularly reviews the risks identified in respect of arrangements supporting critical or important functions (Article 28(2)). Article 28 also addresses concentration risk and the financial-entity's responsibilities in performing the preliminary assessment of an ICT third-party service provider before entering into a contractual arrangement, with heightened requirements for arrangements covering critical or important functions.

Article 28(2) — strategy on ICT third-party risk. Article 28(2) requires financial entities — other than Article 16(1), first subparagraph, entities and other than microenterprises — to adopt, and regularly review, a strategy on ICT third-party risk, taking into account the multi-vendor strategy referred to in Article 6(9) where applicable. The strategy must include a policy on the use of ICT services supporting critical or important functions provided by ICT third-party service providers, applied on an individual basis and, where relevant, on a sub-consolidated and consolidated basis; Delegated Regulation (EU) 2024/1773 specifies the detailed content of that policy. The management body regularly reviews the risks identified in respect of contractual arrangements on the use of ICT services supporting critical or important functions. The lifecycle duties in Article 28(1) and 28(4)–(8) bind all financial entities; the 28(2) strategy duty is the carved-out exception.

Article 28(3) — register of information. Article 28(3) requires financial entities to maintain and update at entity level, and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers. The register must distinguish between contractual arrangements that cover ICT services supporting critical or important functions and those that do not. Implementing Regulation (EU) 2024/2956 specifies the standard templates of the register under Article 28(9).

In Modulos: ORF-393 (ICT third-party risk strategy governance, Article 28(2) with Delegated Regulation 2024/1773), ORF-384 (general lifecycle governance, Articles 28(1), 28(4)–(8) and 29), ORF-386 (register of information governance), and MRF-307, MRF-309 (execution).

Article 30 — key contractual provisions ​

Article 30 sets out the contractual baseline.

  • Article 30(1) requires the rights and obligations of the financial entity and the ICT third-party service provider to be clearly allocated and set out in writing, with the full contract (including service level agreements) documented in one written document available to the parties in a durable, accessible format.
  • Article 30(2) lists the elements every contractual arrangement on the use of ICT services must include, at points (a)–(i): a clear and complete description of all functions and ICT services, indicating whether subcontracting of an ICT service supporting a critical or important function is permitted and on what conditions (a); the locations (regions or countries) where functions and ICT services are provided and data is processed, with advance notification of changes (b); provisions on availability, authenticity, integrity and confidentiality in relation to data protection, including personal data (c); provisions ensuring access, recovery and return of personal and non-personal data on the provider's insolvency, resolution or business discontinuation, or on termination (d); service level descriptions, including updates and revisions (e); the provider's obligation to assist when an ICT incident related to the service occurs, at no additional cost or at a cost determined ex ante (f); the provider's obligation to fully cooperate with the competent authorities and resolution authorities of the financial entity (g); termination rights and related minimum notice periods in line with supervisory expectations (h); and the conditions for the provider's participation in the entity's ICT security awareness programmes and digital operational resilience training under Article 13(6) (i).
  • Article 30(3) adds the heightened elements for ICT services supporting critical or important functions, at points (a)–(f): full service level descriptions with precise quantitative and qualitative performance targets (a); notice periods and reporting obligations, including notification of developments that might materially impact the provider's ability to provide the services (b); requirements to implement and test business contingency plans and maintain ICT security measures, tools and policies (c); the obligation to participate and fully cooperate in the financial entity's TLPT under Articles 26–27 (d); the right to monitor performance on an ongoing basis, including unrestricted rights of access, inspection and audit (e); and exit strategies, in particular a mandatory adequate transition period (f).

Delegated Regulation (EU) 2024/1773 specifies the detailed content of the policy that financial entities adopt under Article 28(2) for ICT services supporting critical or important functions; Article 28(10) is the mandate under which the RTS was adopted.

In Modulos: ORF-385 and MRF-308 (contractual baseline).

Article 30(5) — subcontracting ​

The substantive subcontracting duties sit in Article 30(1) (rights and obligations clearly allocated and set out in writing) and Article 30(2)(a) (the contract states whether subcontracting of an ICT service supporting a critical or important function is permitted and, if so, on what conditions). Article 30(5) is the RTS mandate: the ESAs were directed to specify further the elements referred to in Article 30(2)(a) which a financial entity needs to determine and assess when subcontracting ICT services supporting critical or important functions.

Delegated Regulation (EU) 2025/532, adopted under that mandate, specifies those elements — covering the conditions for subcontracting, risk assessment and due diligence across the subcontracting chain, monitoring, and the contractual implementation including termination rights.

In Modulos: ORF-387 and MRF-310.

Articles 31–44 — EU oversight framework for critical ICT third-party providers ​

Articles 31–44 establish an EU-level oversight framework for ICT third-party service providers designated as critical.

  • Article 31 sets out the designation criteria — based on systemic impact on financial-stability and operations, the criticality of the financial entities relying on the provider, and the degree of substitutability of the provider's services.
  • The Lead Overseer (one of the ESAs) is appointed as part of the Article 31 designation decision (Article 31(1)(b)); the Oversight Forum is established by Article 32 and the Joint Oversight Network by Article 34.
  • Articles 33 and 35–44 set out the Lead Overseer's tasks and powers (including general investigations and inspections, recommendations, and periodic penalty payments under Article 35(6)–(11)), and the framework for cooperation with competent authorities and with critical TPPs themselves.

In Modulos: financial-entity-side execution is covered by the Articles 28–30 requirements (ORF-384 to ORF-387; MRF-307 to MRF-310). Designation-side and Lead-Overseer-side activities sit with ESAs and the designated critical TPPs themselves — not with financial entities.

How to operationalize Articles 24–30 in Modulos ​

LayerModulos surfaceCoverage
Resilience testing programme (three cohorts)OFF-16 ORF-382; MFF-16 MRF-305Articles 24–25; Art 16(1)(g) + Delegated Reg 2024/1774 Title III for simplified entities
TLPTOFF-16 ORF-383; MFF-16 MRF-306Articles 26–27 + Delegated Reg 2025/1190 (RTS under Art 26(11))
ICT TPP risk strategyOFF-16 ORF-393Article 28(2) + Delegated Reg 2024/1773 (binds other than Art 16(1) entities and microenterprises)
ICT TPP lifecycleOFF-16 ORF-384; MFF-16 MRF-307Articles 28(1), 28(4)–(8), 29
ICT TPP contractual baselineOFF-16 ORF-385; MFF-16 MRF-308Article 30(2)–(3)
Register of informationOFF-16 ORF-386; MFF-16 MRF-309Article 28(3) + Implementing Reg 2024/2956
SubcontractingOFF-16 ORF-387; MFF-16 MRF-310Article 30(5) + Delegated Reg 2025/532

A typical setup:

  1. Requirements — each obligation is recorded as a requirement on the relevant project. Fulfilment tracks through Not fulfilled → Fulfilled.
  2. Controls — testing programme document, TLPT participation procedure, ICT-TPP due-diligence checklist, contract-template checklist, register-of-information template (per Implementing Regulation 2024/2956), subcontracting-assessment procedure are documented as named controls.
  3. Evidence — testing plan + outcomes, TLPT scope memo + tester assurance + remediation records, due-diligence reviews, concentration-risk analyses, signed ICT-TPP contracts with the Article 30 provisions, register-of-information entries, subcontracting assessments are recorded once and linked to multiple controls.
  4. Readiness + fulfilment attestation — when controls are in a final state, the requirement becomes ready for review and the owner attests fulfilment.
  5. What Modulos does not provide:
    • a dedicated register-of-information UI — register entries are stored as evidence linked to ORF-386 and MRF-309;
    • a dedicated TLPT workflow surface — TLPT outputs are evidence artefacts attached to the TLPT requirements.

Cross-framework mapping (preview) ​

DORA areaNIS2 (Directive (EU) 2022/2555)ISO/IEC 27001:2022 (Amd 1:2024)
Art 24–25 testing(no direct equivalent; Art 21(2)(f) effectiveness assessment is closest)Clause 9.1 (monitoring), 9.2 (internal audit), A.8.29 (security testing)
Art 26–27 TLPT(no direct equivalent — sector-specific)A.8.29 (security testing in development and acceptance)
Art 28 ICT TPP general + registerArt 21(2)(d) supply chain + Art 21(3)A.5.19, A.5.20, A.5.21 supplier-relationship family
Art 30 contractual provisionsArt 21(2)(d)A.5.20 (information security in supplier agreements)
Art 30(5) subcontractingArt 21(2)(d) + Art 21(3)A.5.22 (managing information security in the ICT supply chain)
Arts 31–44 oversight of critical TPPs(no direct equivalent)(no direct equivalent)

For the pairwise NIS2↔DORA treatment see NIS2 vs DORA.

DORA overview

Framework structure, dates, OFF-16 / MFF-16 split

Applicability and governance

Articles 1–6, 16 — scope, proportionality, management body, ICT RMF foundation

ICT risk and resilience operations

Articles 5–23 — RMF substance, incident process, classification, reporting

Information sharing and Level 2 acts

Article 45 + the eight Commission Delegated / Implementing Regulations

NIS2 vs DORA

Where each applies, sector-specific Union legal act interaction

Source attribution ​

Regulation (EU) 2022/2554 (DORA) is published in the Official Journal of the European Union L 333, 27.12.2022, pp. 1–79. Articles 24–44 substance on this page is paraphrased from the operative provisions; for paragraph-level wording consult the EUR-Lex text. Commission Delegated Regulation (EU) 2024/1773 of 13 March 2024 specifies the technical standards for the policy on ICT services supporting critical or important functions. Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024 specifies the standard templates for the register of information. Commission Delegated Regulation (EU) 2025/532 specifies subcontracting elements under Article 30(5). Commission Delegated Regulation (EU) 2025/1190 specifies the technical standards for threat-led penetration testing under the Article 26(11) mandate.

Disclaimer

This page is for general informational purposes and does not constitute legal advice. DORA applies directly in every Member State; binding obligations and supervisory authorities for any specific financial entity are determined by the Regulation, the applicable Level 2 acts, and the competent authority designated under Article 46. For binding interpretation in your jurisdiction, consult the published EUR-Lex text and qualified counsel.