DORA RTS & ITS: Regulatory Technical Standards

What are DORA RTS and ITS?

The Digital Operational Resilience Act (DORA) is supplemented by detailed Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) developed by the European Supervisory Authorities (ESAs) - EBA, EIOPA, and ESMA. New to the regulation? Start with our complete guide to what DORA is, then return here for the technical detail.

Key Areas Covered by DORA RTS

DORA RTS Implementation Timeline

The Complete RTS & ITS Catalogue (13 Standards)

DORA is supplemented by 13 binding technical standards developed jointly by the EBA, ESMA and EIOPA (the European Supervisory Authorities, or ESAs). The standards were delivered in two batches: the "first batch" submitted to the European Commission in January 2024, and the "second batch" finalised mid-2024. Once adopted by the Commission as Delegated Regulations or Implementing Regulations, the standards are directly applicable across all 27 Member States — no national transposition required.

First batch RTS (January 2024)

1. RTS on ICT risk management framework (Article 15) — Commission Delegated Regulation (EU) 2024/1774 — comprehensive minimum content for security policies, access management, encryption, cryptography, network segmentation, ICT change management, business continuity policy and crisis communication.
2. RTS on simplified ICT risk management framework (Article 16(3)) — proportionate framework for entities qualifying as small and non-interconnected. Reduced requirements but core principles (board accountability, incident management, third-party rules) preserved.
3. RTS on classification of major ICT-related incidents and significant cyber threats (Article 18(3)) — six primary criteria + three secondary criteria for "major" classification, plus criteria for "significant cyber threat" reporting. Defines the thresholds that determine whether the 4h/72h/1m clock starts.
4. RTS on policy on ICT services performed by ICT third-party service providers (Article 28(10)) — what the third-party policy must contain, board ownership, integration with overall risk management.
5. ITS on Register of Information (Article 28(9)) — XBRL/XML template, taxonomy of ICT services, mandatory fields, submission cadence and quality expectations.

Second batch RTS & ITS (mid-to-late 2024)

6. RTS on subcontracting of critical or important functions (Article 30(5)) — final version published Q3 2024 after extended consultation. Covers conditions under which financial entities allow ICT third-party providers to subcontract, including notification, sub-outsourcing register, concentration risk, data location transparency.
7. RTS on threat-led penetration testing (Article 26(11)) — TIBER-EU-aligned methodology: threat intelligence, red teaming, scope definition, white team/blue team controls, reporting to NCAs, supervisory attestation.
8. RTS on harmonisation of conditions enabling the conduct of oversight activities (Article 41(1)) — operational rules for the Lead Overseer regime: how the ESAs supervise designated CTPPs, joint examination teams, information requests, recommendations.
9. RTS specifying the criteria for the designation of CTPPs (Article 31(6)) — quantitative criteria for designation: aggregate value of services, number of financial entities served, systemic impact if disrupted, substitutability rating.
10. RTS on the content and format of the supervisory examination report on subcontracting arrangements — supporting the Lead Overseer regime.
11. ITS on incident reporting templates and procedures (Article 20) — harmonised template across all financial sectors, submission via NCA portals, fields, validation rules.
12. RTS on aggregated costs and losses from major ICT-related incidents (Article 11(11)) — methodology for aggregating direct and indirect costs of ICT incidents for supervisory and risk reporting purposes.
13. Joint Guidelines on cooperation between ESAs and NCAs — operational coordination for cross-border incidents and supervisory dialogue.

Detailed RTS Requirements by Pillar

1. ICT Risk Management RTS

The RTS on ICT risk management framework (Commission Delegated Regulation 2024/1774) is the densest and most operationally significant of the technical standards. It runs to 70+ recitals and articles, covering the full ICT control surface a financial entity must maintain. Key chapters include security policies and procedures (governance level), human resources policy and security awareness, identity management and access control with multi-factor authentication for privileged access, cryptographic controls including key management, network security (segmentation, monitoring, secure configuration), ICT operations (change, capacity, vulnerability), ICT project management and acquisition, ICT business continuity policy with documented RTOs/RPOs, and crisis communication.

2. Incident Reporting RTS

Financial entities must classify ICT-related incidents based on specific criteria:

• Initial notification: Within 4 hours of detection for major incidents
• Intermediate report: Within 72 hours with detailed impact assessment
• Final report: Within one month including root cause analysis and remediation

3. TLPT (Threat-Led Penetration Testing) RTS

Advanced testing framework for entities identified as significant:

• Testing must be performed at least every 3 years
• Use of TIBER-EU framework or equivalent
• Involvement of independent testers
• Red team exercises simulating real attack scenarios
• Comprehensive remediation plans post-testing

4. Third-Party Oversight RTS

Detailed requirements for managing ICT third-party service providers:

5. RTS on Subcontracting

The RTS on subcontracting is the late-2024 standard that operationalises Article 30 paragraphs on sub-outsourcing of critical or important functions. Key obligations:

• Notification to the financial entity of any planned material change to the sub-outsourcing chain, with sufficient lead time to assess and object
• Right of the financial entity to oppose specific subcontracting arrangements where they create unacceptable risk
• Sub-outsourcing register maintained by the ICT third-party provider, available to the financial entity
• Visibility down to all material sub-contractors performing parts of the service — typically Tier 3 or deeper
• Concentration risk assessment at the chain level, not just at vendor level
• Data location transparency throughout the chain, including processing, storage, support and back-up locations

How RTS & ITS Become Binding Law

One of the most misunderstood aspects of the DORA framework is the legal pathway by which the technical standards become binding obligations. Unlike Directives, which require national transposition, DORA itself is a Regulation under Article 288 TFEU — directly applicable in all Member States with no need for national legislation. The RTS and ITS follow a similar route but with one extra step:

1. Drafting: The ESAs (EBA, ESMA, EIOPA) draft the technical standards, often in joint mandate working groups, after public consultation.
2. Submission to the Commission: The draft standards are submitted to the European Commission for adoption.
3. Commission adoption: The Commission adopts the standards as Delegated Regulations (for RTS) or Implementing Regulations (for ITS), subject to a non-objection right by the European Parliament and Council.
4. Publication and entry into force: The Commission Regulation is published in the Official Journal of the European Union and enters into force on the specified date — typically 20 days after publication, with potential delayed application.
5. Direct effect: Once in force, the RTS/ITS are directly applicable in all Member States. Financial entities must comply without waiting for any national implementing legislation.

This means the question "is this RTS in force?" has a binary answer that you can verify on EUR-Lex. There is no national grace period, no transposition delay. The 17 January 2025 application date for DORA itself was the trigger — most RTS applied from that date or shortly after.

How RTS Interact with Existing Frameworks

For most financial entities, DORA RTS arrive in a regulatory landscape already shaped by sector-specific guidance from the ESAs, national supervisors, ENISA, NIS2 and global standards (ISO 27001, NIST CSF). Understanding the interaction matters for implementation efficiency.

EBA Guidelines on ICT and security risk management (EBA/GL/2019/04)

Largely superseded by the RTS on ICT risk management framework. The EBA opened a consultation in 2024 on repealing or amending these guidelines. In practice, banks should treat DORA + RTS 2024/1774 as authoritative; legacy EBA guidelines remain useful as implementation depth on specific topics (network segmentation, secure development) but no longer add binding obligations beyond what DORA mandates.

EBA Outsourcing Guidelines (EBA/GL/2019/02)

Partially superseded for ICT outsourcing by DORA Articles 28-30 plus the RTS on subcontracting. Non-ICT outsourcing (e.g., physical document management, certain operational outsourcing) continues to follow the EBA Outsourcing Guidelines. Banks need to maintain two parallel registers in many cases — DORA Register of Information for ICT and the EBA outsourcing register for non-ICT.

EIOPA Guidelines on outsourcing to cloud service providers

Under consultation in 2024 for repeal or alignment with DORA. Practically replaced by DORA Articles 28-30 + RTS on subcontracting for cloud outsourcing.

NIS2 Directive (Directive (EU) 2022/2555)

NIS2 covers a broader universe (energy, transport, health, digital infrastructure, financial services, public administration) but for financial entities DORA acts as lex specialis under NIS2 Article 4(1) — DORA prevails over NIS2 obligations where they overlap. Financial entities subject to both DORA and NIS2 (e.g., a bank with a separately authorised data centre operator subsidiary) must navigate the dual framework carefully.

ISO 27001 and NIST CSF

Not binding under EU law but widely adopted. ISO 27001 controls map well to many DORA requirements; supervisors generally accept ISO 27001 certification as evidence of control design but require independent validation that DORA-specific requirements (e.g., incident classification, register of information) are met. NIST CSF provides a useful taxonomy but does not satisfy DORA on its own.

RTS & ITS FAQ

Official RTS/ITS Resources

Access authoritative sources for DORA technical standards:

Need Help with DORA RTS Compliance?

Implementing DORA RTS requirements can be complex. Our experts can help you:

Related Resources