DORA RTS & ITS Technical Standards Tracker: Complete Batch 1 and Batch 2 Overview

The Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — establishes the high-level requirements for digital operational resilience in the EU financial sector. However, DORA itself is a Level 1 regulation. The detailed, technically specific requirements that financial entities must actually implement are contained in the Level 2 measures: Regulatory Technical Standards (RTS), Implementing Technical Standards (ITS), delegated acts, and guidelines developed by the three European Supervisory Authorities (ESAs) — the European Banking Authority (EBA), the European Securities and Markets Authority (ESMA), and the European Insurance and Occupational Pensions Authority (EIOPA).

Understanding these Level 2 standards — what each one covers, how they map to DORA's five pillars, what changed between draft and final versions, and when they apply — is essential for any financial entity building or validating its DORA compliance programme. This article provides a comprehensive tracker of all DORA RTS and ITS, organised by batch, pillar, and implementation status.

What Are DORA RTS and ITS?

In the EU legislative framework, RTS and ITS are secondary legislation developed by ESAs and adopted by the European Commission. They differ in function:

• Regulatory Technical Standards (RTS) define the substantive requirements — the "what." They specify what financial entities must do, what controls they must implement, what thresholds they must meet, and what governance structures they must establish. RTS are legally binding once adopted by the Commission through delegated regulation.
• Implementing Technical Standards (ITS) define the procedural and reporting requirements — the "how." They specify the templates, formats, and procedures for reporting to supervisory authorities, for submitting information, and for standardised communication. ITS are adopted by the Commission through implementing regulation.

For DORA, the ESAs received 13 mandates to develop RTS and ITS (plus additional mandates for delegated acts and guidelines). These mandates were divided into two batches based on priority and development timeline.

The Five Pillars of DORA

Before examining the individual standards, it is important to understand the five-pillar structure that DORA uses to organise its requirements. Each RTS and ITS maps to one or more of these pillars:

Pillar 1: ICT Risk Management (Articles 5–16)

The foundation of DORA. Financial entities must establish and maintain an ICT risk management framework that is comprehensive, documented, and integrated into their overall risk management structure. This pillar covers identification, protection, detection, response, recovery, and learning from ICT-related incidents. The management body must approve and oversee the framework.

Pillar 2: ICT-Related Incident Management, Classification, and Reporting (Articles 17–23)

Financial entities must establish processes to detect, manage, and report ICT-related incidents. This pillar introduces mandatory incident classification criteria and a multi-stage reporting process (initial notification within 4 hours of classification, intermediate report, and final report within one month). Major ICT-related incidents must be reported to the competent authority.

Pillar 3: Digital Operational Resilience Testing (Articles 24–27)

Financial entities must establish a digital operational resilience testing programme that includes a range of tests — vulnerability assessments, network security assessments, performance testing, penetration testing, and source code reviews. Significant financial entities must also conduct Threat-Led Penetration Testing (TLPT) at least every three years. TLPT must be conducted in accordance with the TIBER-EU framework.

Pillar 4: ICT Third-Party Risk Management (Articles 28–44)

Financial entities must manage the risks arising from their use of ICT third-party service providers. This pillar includes the Register of Information (RoI), pre-contractual due diligence, mandatory contractual provisions, ongoing monitoring, and exit strategies. It also establishes the oversight framework for Critical ICT Third-Party Providers (CTPPs) designated by the ESAs.

Pillar 5: Information Sharing (Article 45)

Financial entities may participate in voluntary information-sharing arrangements to exchange cyber threat intelligence and information among themselves. This pillar is the least prescriptive but provides a legal framework for sharing that was previously uncertain under data protection and competition law constraints.

Batch 1 Standards: Overview

Batch 1 standards were the first set developed by the ESAs. Draft versions were published for public consultation in mid-2023, and final versions were submitted to the European Commission in January 2024. These standards address the most foundational and time-critical areas of DORA implementation.

RTS on ICT Risk Management Framework (Article 15)

This RTS specifies the detailed elements of the ICT risk management framework that financial entities must establish. It covers: ICT security policies and procedures, ICT operations security, network security, access control, encryption and cryptographic controls, ICT project management, ICT change management, physical and environmental security, HR security policies, identity management, detection capabilities, and business continuity management. This is the broadest RTS and forms the foundation for the majority of operational compliance work. The final version provides more explicit proportionality guidance than the draft, recognising that the framework must be scalable across entity sizes.

RTS on Simplified ICT Risk Management Framework (Article 16(3))

This RTS provides a reduced set of requirements for financial entities that qualify for the simplified framework — principally small and non-interconnected investment firms, small insurance undertakings, and small IORPs. The simplified framework retains the core risk management principles but reduces the documentation, governance, and testing requirements. Qualification criteria are specified in the relevant sectoral legislation (e.g., MiFID II for investment firms, Solvency II for insurance).

RTS on Incident Classification Criteria (Article 18(3))

This RTS establishes the criteria and materiality thresholds for classifying ICT-related incidents as "major" (triggering mandatory reporting) or "significant" (potentially requiring internal escalation). Classification criteria include: the number of clients affected, the duration of the incident, the geographical spread, the data losses involved, the criticality of the services affected, and the economic impact. The final version refined the thresholds to reduce the volume of reportable incidents while maintaining supervisory visibility over genuinely significant events.

RTS on Threat-Led Penetration Testing — TLPT (Article 26(11))

This RTS specifies the requirements for conducting TLPT, including: scoping criteria (which entities must perform TLPT and how the testing scope is determined), the testing methodology (aligned with TIBER-EU), the roles and responsibilities of the threat intelligence provider and the red team, the requirements for the control team, and the rules for pooled testing where multiple entities share a common ICT third-party provider. The final version provides additional clarity on mutual recognition — allowing TLPT results to be recognised across Member States — and on the circumstances under which internal testers may be used.

ITS on Register of Information (Article 28(9))

This ITS specifies the templates and data formats for the Register of Information. It defines the multi-table structure (entity information, contractual arrangements, provider information, service descriptions, data locations, and sub-outsourcing chains), the mandatory data fields, the validation rules, and the machine-readable format for submission. This ITS has been the subject of extensive industry feedback, particularly regarding the granularity of data location requirements and the practicality of sub-outsourcing chain documentation.

ITS on Incident Reporting (Article 20)

This ITS specifies the templates and formats for incident notification and reporting. It defines the content of the initial notification, the intermediate report, and the final report, along with the data fields, submission format, and transmission mechanism. The ITS ensures consistency in incident reporting across all financial entities and Member States, enabling meaningful aggregation and cross-border analysis by the ESAs.

Batch 2 Standards: Overview

Batch 2 standards were submitted to the European Commission in July 2024. They address additional DORA requirements that, while equally mandatory, were considered less foundational than Batch 1 and therefore given a longer development timeline.

RTS on ICT Third-Party Contractual Provisions (Article 30(5))

This RTS specifies the detailed elements that must be included in contractual arrangements between financial entities and ICT third-party service providers. For all arrangements, this includes provisions on service descriptions, performance targets, audit and access rights, notification obligations, exit provisions, and data protection. For arrangements supporting critical or important functions, additional requirements include specific SLA metrics, guaranteed levels of availability, incident support obligations, and the provider's obligation to cooperate with supervisory authorities.

RTS on Sub-Outsourcing Oversight (Article 30(5))

This RTS specifies the requirements for monitoring and managing sub-outsourcing by ICT third-party service providers. It covers notification obligations (providers must inform financial entities of sub-outsourcing changes), risk assessment requirements (financial entities must assess the impact of sub-outsourcing on their risk profile), and contractual provisions (contracts must address the financial entity's right to object to sub-outsourcing changes that could impact service quality or security).

RTS on Aggregated Cost Reporting (Article 31(6))

This RTS specifies how financial entities must report the costs associated with ICT-related incidents to supervisory authorities. It covers the methodology for calculating direct and indirect costs, the reporting format, and the aggregation approach. This standard supports the ESAs' mandate to monitor the financial impact of ICT incidents across the sector.

RTS on CTPP Oversight Fees (Article 43(2))

This RTS specifies the methodology for calculating the oversight fees that Critical ICT Third-Party Providers must pay to the Lead Overseer (the ESA responsible for their oversight). The fees fund the oversight activities and are proportionate to the provider's annual turnover and the extent of their provision of services to the EU financial sector.

ITS on Major Incident Notification Content (Article 20)

This ITS supplements the Batch 1 incident reporting ITS by specifying the detailed content requirements for major incident notifications. It defines the minimum information that must be included at each reporting stage and the technical standards for data transmission.

Guidelines on CTPP Designation Criteria (Article 31)

These guidelines specify the criteria and methodology the ESAs use to designate ICT third-party service providers as "critical." Criteria include the systemic impact of a failure or disruption of the provider's services, the number of financial entities dependent on the provider, the degree of concentration, and the substitutability of the provider's services. These guidelines are not legally binding in the same way as RTS/ITS but represent the ESAs' supervisory expectations.

Complete Standards Tracker Table

The following table provides a consolidated reference for all DORA Level 2 standards, their batch, type, pillar mapping, and status.

Key Changes from Draft to Final

The ESAs conducted extensive public consultations on both Batch 1 and Batch 2 standards. The consultation process resulted in meaningful changes between draft and final versions. Understanding these changes is important because many organisations began their compliance programmes based on draft standards and need to verify that their implementation reflects the final requirements.

ICT Risk Management Framework — Proportionality Clarification

The draft RTS applied uniform requirements across all entity sizes, which drew significant industry criticism. The final version includes explicit proportionality provisions that allow smaller and less complex entities to implement the framework in a manner commensurate with their size, risk profile, and the complexity of their ICT environment. The principles remain the same, but the expected depth of documentation and formality of processes is explicitly scalable.

Incident Classification — Threshold Refinement

The draft incident classification criteria would have resulted in a high volume of reportable incidents, creating operational burden for financial entities and analytical burden for supervisory authorities. The final version raised certain materiality thresholds — particularly for client impact and economic impact — to focus mandatory reporting on genuinely significant incidents. The "significant but non-major" incident category was clarified to require internal tracking and escalation but not external reporting.

TLPT — Mutual Recognition and Internal Testers

The draft TLPT RTS was ambiguous on whether TLPT results conducted in one Member State would be recognised by authorities in another. The final version establishes a mutual recognition framework, reducing duplication for cross-border entities. Additionally, the final version provides clearer guidance on when internal red teams may conduct TLPT (subject to certain conditions, including independence and capability requirements) and when external testers must be used.

Register of Information — Data Field Practicality

The draft RoI ITS contained data fields that industry respondents flagged as impractical to collect — particularly certain data location fields at sub-outsourcing levels. The final version retained the structure but provided additional guidance on proportionality for non-critical arrangements and clarified the expected level of granularity for data location reporting, particularly for cloud-based services where data locations may be dynamic.

Contractual Provisions — Flexibility for Existing Contracts

The draft RTS on contractual provisions implied that all existing contracts would need immediate amendment to include the specified provisions. The final version acknowledges that contract renegotiation takes time and provides a framework for phased alignment, prioritising contracts supporting critical or important functions. New contracts must include all provisions from the outset.

Mapping Standards to the Five Pillars

Understanding how each standard maps to DORA's five pillars helps financial entities organise their compliance programmes by workstream. The following mapping shows which standards are relevant to each pillar:

Pillar 1 — ICT Risk Management

• RTS on ICT Risk Management Framework (primary)
• RTS on Simplified ICT Risk Management (for qualifying entities)

Pillar 2 — Incident Management and Reporting

• RTS on Incident Classification Criteria
• ITS on Incident Reporting Templates
• ITS on Major Incident Notification Content
• RTS on Aggregated Cost Reporting

Pillar 3 — Digital Operational Resilience Testing

• RTS on Threat-Led Penetration Testing (TLPT)

Pillar 4 — ICT Third-Party Risk Management

• ITS on Register of Information Template
• RTS on ICT Third-Party Contractual Provisions
• RTS on Sub-Outsourcing Oversight
• RTS on CTPP Oversight Fees
• Guidelines on CTPP Designation Criteria

Pillar 5 — Information Sharing

• No specific RTS/ITS — the Article 45 framework is self-executing with guidance from the ESAs

The concentration of standards in Pillars 2 and 4 reflects the regulatory priority placed on incident reporting (for systemic risk monitoring) and ICT third-party risk management (given the sector's concentration on a small number of major cloud and technology providers).

Implementation Timeline

Despite the staggered development of Batch 1 and Batch 2 standards, all DORA requirements — including all RTS and ITS — became applicable from a single date: 17 January 2025. This is the date DORA became fully applicable across the EU financial sector.

Key dates in the overall DORA timeline:

• 16 January 2023: DORA entered into force (24-month implementation period begins)
• June–September 2023: Batch 1 draft standards published for consultation
• January 2024: Batch 1 final standards submitted to the European Commission
• December 2023–March 2024: Batch 2 draft standards published for consultation
• July 2024: Batch 2 final standards submitted to the European Commission
• September–December 2024: Commission adoption of Batch 1 and Batch 2 standards (Delegated Regulations and Implementing Regulations published in the Official Journal)
• 17 January 2025: DORA fully applicable — all requirements, including all RTS and ITS, take effect

The compressed timeline between Batch 2 finalisation (July 2024) and DORA application (January 2025) created a challenging implementation window for financial entities. Organisations that waited for final Batch 2 standards before beginning implementation had approximately six months to build and operationalise complex processes such as contractual remediation, sub-outsourcing oversight, and aggregated cost reporting.

Simplified Framework for Smaller Entities

DORA Article 16 provides a simplified ICT risk management framework for certain categories of smaller financial entities. The corresponding RTS specifies reduced requirements that reflect the lower complexity and systemic significance of these entities.

Entities eligible for the simplified framework include:

• Small and non-interconnected investment firms as defined in Article 12(1) of Regulation (EU) 2019/2033
• Payment institutions exempt under Directive (EU) 2015/2366
• Institutions exempt under Directive 2013/36/EU
• Electronic money institutions exempt under Directive 2009/110/EC
• Small institutions for occupational retirement provision (IORPs)

The simplified framework reduces requirements in several areas: governance formality (fewer committees and reporting layers), documentation depth (principles-based rather than prescriptive documentation), testing scope (basic resilience testing rather than full TLPT), and monitoring frequency (risk-based review cycles rather than continuous monitoring). However, critical obligations remain:

• Incident reporting obligations apply in full — all major incidents must be reported per the standard classification and timeline
• The Register of Information must be maintained — all ICT third-party arrangements must be registered
• ICT third-party risk management contractual provisions apply — including for critical or important functions
• The management body must approve and oversee the ICT risk management framework

Practical Implications for Financial Entities

Understanding the standards tracker is a necessary first step, but translating that knowledge into an effective compliance programme requires additional considerations.

Programme Organisation by Pillar and Workstream

The most effective compliance programmes align their workstreams to DORA's five pillars, with dedicated teams or owners for each. This mirrors the structure of the standards themselves and enables efficient tracking of progress against specific RTS/ITS requirements. Cross-pillar dependencies — such as the relationship between the ICT risk management framework (Pillar 1) and the contractual provisions for third parties (Pillar 4) — must be actively managed to avoid inconsistencies.

Monitoring for Updates and Amendments

The Level 2 standards are not static. The ESAs are expected to issue additional guidance, Q&As, and potentially amend standards as supervisory experience accumulates. Financial entities should establish a regulatory monitoring process that tracks ESA publications, Commission decisions, and competent authority guidance relevant to their DORA obligations.

Evidence and Documentation Strategy

Each RTS and ITS implies specific documentation and evidence requirements. Financial entities should map the documentation requirements of each standard to their existing policy and procedure framework, identify gaps, and create or update documents accordingly. The evidence base should be designed to withstand supervisory inspection — organised, current, and readily accessible.

Frequently Asked Questions