DORA Art.55–64: Delegated Acts, Commission Review, Transitional Provisions, Sectoral Amendments, and Entry Into Force — Complete DORA Series Developer Guide 2026

Post #510 in the sota.io EU Cyber Compliance Series — DORA Series Complete

DORA (Regulation EU 2022/2554) opened with four general-provision articles and built chapter by chapter through ICT risk management (Art.5–16), incident reporting (Art.17–23), operational resilience testing (Art.24–27), third-party risk (Art.28–44), information sharing (Art.45), competent authorities and penalties (Art.46–54). Articles 55–64 close the regulation. They are shorter than the substantive chapters but operationally important: they determine how technical standards are issued, when the rules apply to contracts already in existence, which prior law is removed, and when the clock started.

For engineering teams, the key deliverable from this final chapter is a complete compliance matrix — mapping every DORA obligation you have tracked through this series to your internal owner, timeline, and evidence artefact. The 30-checkpoint matrix at the end of this post is designed for that purpose.

1. Art.55 — The Commission's Delegated-Act Power

1.1 What Delegated Acts Are

Throughout DORA, certain provisions end with phrases like "the Commission shall adopt, by means of delegated acts, further specifications...". These references give the Commission power to supplement DORA's primary-law obligations with detailed technical rules without returning to the full legislative procedure. Delegated acts are secondary legislation: they cannot contradict DORA's primary rules, but they can make them more precise.

Art.55 is the formal conferral of that power. Without it, the references scattered through DORA's substantive articles would be unenforceable.

1.2 Scope and Duration of the Delegation

Under Art.55(1), the power to adopt delegated acts is conferred on the Commission for a period of five years from 16 January 2023. The Commission must submit a report on the delegation of power no later than nine months before the end of that five-year period. The power is automatically renewed for the same duration unless the European Parliament or Council objects — meaning the practical effect is indefinite unless revoked.

What DORA articles trigger delegated acts from the Commission:

The European Supervisory Authorities (EBA, EIOPA, ESMA) draft the Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) that underpin these delegated acts. By the DORA application date (17 January 2025), the Commission had adopted a substantial package of delegated regulations based on ESA-drafted standards. Practitioners should monitor the Official Journal for further delegated regulations refining these areas as DORA's first operational years generate supervisory experience.

1.3 Parliamentary Oversight of Delegated Acts

Art.55(3) allows the European Parliament or the Council to revoke the delegation of power at any time. Art.55(5) gives them a two-month objection period after a delegated act is notified — extendable by a further two months. During that period the delegated act does not enter into force. This creates a practical pipeline:

1. ESA drafts RTS/ITS → submits to Commission
2. Commission adopts delegated regulation → notifies EP and Council
3. 2-month (extendable) scrutiny period
4. No objection → enters into force on OJ publication date
5. Objection → Commission must revise or withdraw

For compliance teams, this means delegated acts can be delayed or amended after publication of the base DORA text. Always check the most recent Official Journal version of a DORA-referenced RTS before treating it as final.

1.4 The RTS/ITS Landscape as of January 2025

The Commission adopted the DORA delegated regulations in batches. The main package published in the Official Journal on 17 January 2025 covers:

• Commission Delegated Regulation on ICT risk management (Joint Committee RTS under Art.15)
• Commission Delegated Regulation on ICT third-party risk (Art.28(9) and (10))
• Commission Delegated Regulation on major incident classification (Art.18(3))
• Commission Delegated Regulation on TLPT (Art.26(11))
• Commission Delegated Regulation on CTP designation (Art.31(6))
• Commission Delegated Regulation on oversight fees (Art.41)

A second batch of ITS covering reporting templates, registers of information, and oversight documents followed in the months after DORA's application date.

# Practical: check if an RTS/ITS has been finalised before treating it as binding
import datetime
from dataclasses import dataclass
from typing import Optional

@dataclass
class DORADelegatedAct:
    article_reference: str
    subject: str
    esa_draft_submitted: Optional[datetime.date]
    commission_adopted: Optional[datetime.date]
    oj_published: Optional[datetime.date]
    in_force: Optional[datetime.date]

    def is_final(self) -> bool:
        return self.in_force is not None

    def days_until_final(self) -> Optional[int]:
        if self.in_force:
            return (self.in_force - datetime.date.today()).days
        return None

    def status(self) -> str:
        if self.is_final():
            return f"IN FORCE since {self.in_force}"
        if self.commission_adopted:
            return "Commission adopted — awaiting OJ publication"
        if self.esa_draft_submitted:
            return "ESA draft submitted — awaiting Commission adoption"
        return "In preparation"

# Example registry
DORA_DELEGATED_ACTS = [
    DORADelegatedAct(
        article_reference="Art.15",
        subject="ICT risk management RTS (simplified + advanced)",
        esa_draft_submitted=datetime.date(2024, 1, 17),
        commission_adopted=datetime.date(2024, 12, 13),
        oj_published=datetime.date(2025, 1, 17),
        in_force=datetime.date(2025, 2, 6),
    ),
    DORADelegatedAct(
        article_reference="Art.28(9)(10)",
        subject="ICT TPR management policy and contractual provisions",
        esa_draft_submitted=datetime.date(2024, 1, 17),
        commission_adopted=datetime.date(2024, 12, 13),
        oj_published=datetime.date(2025, 1, 17),
        in_force=datetime.date(2025, 2, 6),
    ),
    DORADelegatedAct(
        article_reference="Art.31(6)",
        subject="CTP designation criteria",
        esa_draft_submitted=datetime.date(2024, 4, 30),
        commission_adopted=datetime.date(2024, 12, 13),
        oj_published=datetime.date(2025, 1, 17),
        in_force=datetime.date(2025, 2, 6),
    ),
]

for act in DORA_DELEGATED_ACTS:
    print(f"[{act.article_reference}] {act.subject}: {act.status()}")

2. Art.56 — Commission Review by 2028

2.1 The Review Mandate

Art.56 requires the Commission to submit a review report to the European Parliament and the Council by 17 January 2028 — three years after DORA's application date. The review must assess:

1. The oversight framework for Critical ICT Third-Party Providers. Has the CTP designation process worked? Are the oversight powers (Art.32–44) being exercised effectively? Should the regime be extended beyond the three ESAs or applied to additional categories of ICT service providers?

2. Whether the scope of DORA needs adjustment. DORA's Art.2 exemptions (microenterprises below certain thresholds, some ancillary service providers) may have created regulatory gaps. The review will examine whether any exempted entities should be brought into scope.

3. Digital operational resilience testing effectiveness. Have TLPT exercises (Art.26–27) produced measurable improvement in resilience? Should testing requirements be extended or modified based on operational experience?

4. The supervisory convergence achieved under Art.57. Have annual ESA convergence reports shown meaningful harmonisation in how NCAs apply DORA across Member States, or have national divergences persisted?

2.2 What the 2028 Review Means for Your Roadmap

The review creates a structured opportunity for DORA to expand in scope. Based on experience with similar review clauses in GDPR and NIS2, the most likely outcomes are:

The practical implication: build your DORA architecture to be modular. Hardcoding the exact thresholds from Art.18 or the exact contractual clauses from Art.30 into inflexible internal policies will require rework when the 2028 review triggers amendments.

3. Art.57 — Annual Supervisory Convergence Reports

Art.57 requires EBA, EIOPA, and ESMA to submit annual reports on their activities under DORA to the European Parliament, the Council, and the Commission. The first report was due by 17 January 2026 — one year after DORA's application date.

These reports cover:

• Supervisory findings from NCA activity under DORA (investigation outcomes, penalty statistics)
• Progress in harmonising NCA practices across Member States
• Areas where NCAs have diverged in interpreting DORA obligations
• Recommendations for legislative amendment

For compliance teams, these reports are the best leading indicator of where enforcement focus is likely to land in the following year. A pattern of NCAs finding consistent gaps in, say, incident classification accuracy (Art.18) or ICT continuity testing (Art.11) signals where your internal audit should concentrate. The ESA Joint Committee publishes these reports; they should be added to your regulatory calendar.

4. Art.58 — Transitional Provisions: The Legacy Contract Window

4.1 The Fundamental Rule

Art.58 is the most operationally significant of the final articles for any financial entity that had ICT third-party service contracts in place before 17 January 2025.

The rule: ICT third-party service contracts that were concluded before 17 January 2025 must be reviewed and, where necessary, supplemented with the DORA-compliant provisions by 17 January 2027 — or at the time of their next renegotiation or renewal if that falls before that date.

This gave financial entities a two-year runway from DORA's application date to align legacy contracts to the Art.30 minimum content requirements (see our post on Art.28–30 for the complete list of mandatory provisions).

4.2 What "Supplemented" Means in Practice

The transition requirement is not that contracts must be rewritten — they must be supplemented with provisions that ensure compliance with DORA's requirements. In practice this means:

• Contract annexes: Adding a DORA addendum (sometimes called a "DORA rider") that appends the missing provisions (SLA specifications, audit rights, sub-outsourcing controls, data location transparency, exit assistance) without replacing the commercial terms of the original contract.
• Master Agreement updates: For providers with large books of customer contracts, a master services agreement amendment that cascades DORA provisions to all downstream contracts.
• Termination where alignment is impossible: For legacy contracts where the ICT provider refuses DORA-compliant terms (often smaller or non-EU providers), financial entities must consider whether the contract can continue. The competent authority expects evidence that the entity attempted renegotiation.

4.3 Contract Classification and Prioritisation

Not all contracts require the same remediation depth. Priority under Art.58 depends on:

from dataclasses import dataclass, field
from datetime import date
from typing import Optional
from enum import Enum

class ContractPriority(Enum):
    CRITICAL = "P1 — remediate before 17-Jan-2026"
    HIGH = "P2 — remediate before 17-Jul-2026"
    STANDARD = "P3 — remediate before 17-Jan-2027"

@dataclass
class ICTContract:
    provider_name: str
    service_description: str
    is_critical_function: bool
    contract_expiry: Optional[date]
    has_audit_rights: bool
    provider_eu_established: bool

    def dora_priority(self) -> ContractPriority:
        if self.is_critical_function:
            return ContractPriority.CRITICAL
        if not self.provider_eu_established or not self.has_audit_rights:
            return ContractPriority.HIGH
        return ContractPriority.STANDARD

    def transition_deadline(self) -> date:
        hard_deadline = date(2027, 1, 17)
        if self.contract_expiry and self.contract_expiry < hard_deadline:
            return self.contract_expiry  # must align at renewal
        return hard_deadline

    def remediation_gap(self) -> list[str]:
        gaps = []
        if not self.has_audit_rights:
            gaps.append("Art.30(2)(d): audit and inspection rights missing")
        if not self.provider_eu_established:
            gaps.append("Art.30(2)(j): data location/law specification needed")
        gaps.append("Art.30(2)(a): SLA performance targets to specify")
        gaps.append("Art.30(2)(h): exit assistance and transition obligations to add")
        return gaps

# Usage
contracts = [
    ICTContract(
        provider_name="CoreBanking SaaS Provider",
        service_description="Core banking platform",
        is_critical_function=True,
        contract_expiry=date(2026, 6, 30),
        has_audit_rights=True,
        provider_eu_established=True,
    ),
    ICTContract(
        provider_name="US Hyperscaler",
        service_description="Object storage",
        is_critical_function=False,
        contract_expiry=date(2028, 12, 31),
        has_audit_rights=False,
        provider_eu_established=False,
    ),
]

for c in contracts:
    print(f"\n{c.provider_name}")
    print(f"  Priority: {c.dora_priority().value}")
    print(f"  Deadline: {c.transition_deadline()}")
    print(f"  Gaps: {len(c.remediation_gap())} items")
    for g in c.remediation_gap():
        print(f"    - {g}")

4.4 Register of Information Impact

Art.28(3) requires financial entities to maintain a register of information on all contractual arrangements with ICT third-party service providers. The ESAs published an ITS specifying the exact fields for this register. Art.58 means that for legacy contracts, the register must reflect the post-remediation state — and the register itself may be the most important audit trail showing NCAs that you identified, prioritised, and remediated contracts systematically within the transitional window.

5. Art.59–63 — Amendments to Sectoral Financial Legislation

5.1 Why Amendments Were Needed

Before DORA, ICT risk requirements for financial entities were scattered across sectoral legislation:

• CRD IV (Directive 2013/36/EU) had operational risk provisions covering ICT
• MiFID II (Directive 2014/65/EU) required investment firms to have ICT continuity arrangements
• UCITS (Directive 2009/65/EC) had operational resilience requirements for management companies
• AIFMD (Directive 2011/61/EU) similarly had ICT provisions for alternative fund managers
• EMIR (Regulation EU 648/2012) required ICT risk management for CCPs

DORA creates a single, harmonised ICT risk rulebook for all of these entity types. If the sectoral provisions remained in force alongside DORA, there would be duplication, potential conflicts, and uncertainty about which rule prevailed. Articles 59–63 resolve this by deleting or replacing the relevant provisions in the sectoral acts with explicit cross-references or the deletion of superseded text.

5.2 What Changed in Each Sectoral Act

5.3 The Lex Specialis Principle in Practice

The amendments establish DORA as lex specialis for ICT risk. For a credit institution subject to both CRD IV and DORA, the ICT risk chapter is now exclusively governed by DORA — the CRD IV ICT provisions no longer apply independently.

This has a practical compliance implication: your ICT risk management framework (Art.5–16) and your incident reporting procedure (Art.17–23) are now the single source of truth for ICT obligations under EU law. You no longer need to run a parallel CRD IV ICT compliance track alongside DORA. The internal audit function should be updated to reflect this consolidation — one DORA audit captures what previously required separate checks under multiple frameworks.

However, risk management under CRD IV (Pillar II/SREP) and DORA are not the same thing. CRD IV's broader operational risk capital requirements and the SREP assessment continue independently. Only the sectoral ICT-specific provisions were removed or updated by Articles 59–63. The SREP examiner will still assess whether your DORA implementation is reflected in your ICAAP and ILAAP where relevant.

6. Art.64 — Entry Into Force and Application Date

Art.64 closes DORA:

"This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union. It shall apply from 17 January 2025."

Publication date: 27 December 2022 (Official Journal L 333)
Entry into force: 16 January 2023 (20th day after publication)
Application date: 17 January 2025 (24 months after entry into force)

The 24-month gap between entry into force and application was deliberately sized to give financial entities time to build compliance programmes, and to give the ESAs time to draft and the Commission time to adopt the delegated regulations and technical standards that DORA's substantive articles depend on.

import datetime

DORA_OJ_PUBLICATION = datetime.date(2022, 12, 27)
DORA_ENTRY_INTO_FORCE = datetime.date(2023, 1, 16)   # OJ + 20 days
DORA_APPLICATION_DATE = datetime.date(2025, 1, 17)   # EIF + 24 months
DORA_LEGACY_CONTRACT_DEADLINE = datetime.date(2027, 1, 17)  # Art.58 window
DORA_REVIEW_DEADLINE = datetime.date(2028, 1, 17)   # Art.56 Commission review

milestones = {
    "OJ Publication": DORA_OJ_PUBLICATION,
    "Entry Into Force": DORA_ENTRY_INTO_FORCE,
    "Application Date (NOW PAST)": DORA_APPLICATION_DATE,
    "Legacy Contract Deadline (Art.58)": DORA_LEGACY_CONTRACT_DEADLINE,
    "Commission Review Report Due (Art.56)": DORA_REVIEW_DEADLINE,
}

today = datetime.date.today()
print(f"Today: {today}\n")
for name, dt in milestones.items():
    delta = (dt - today).days
    if delta < 0:
        status = f"PASSED ({abs(delta)} days ago)"
    elif delta == 0:
        status = "TODAY"
    else:
        status = f"in {delta} days ({dt})"
    print(f"  {name}: {status}")

7. DORA Complete: 30-Checkpoint Implementation Matrix

Having covered all 64 articles across 510 posts in this series, here is the complete implementation matrix. Each row maps to the relevant DORA chapter, the internal function responsible, and the primary evidence artefact that a competent authority or TLPT assessor would expect to see.

8. The Complete DORA Series: What We Covered

This post is #510 in the sota.io EU Cyber Compliance Series and completes our DORA coverage. Here is the full chapter map:

DORA Series: Complete. All 64 articles covered.

9. What Comes After DORA: The Regulatory Stack

DORA sits within a broader EU digital regulatory stack. Having completed DORA, the natural next layer for engineering and compliance teams to internalise is:

1. NIS2 (Directive EU 2022/2555) — The horizontal cybersecurity directive that applies unless your entity is exclusively subject to DORA as lex specialis. If you are both a financial entity and an essential entity under NIS2, you need to map where DORA and NIS2 obligations overlap vs diverge. Our 100-post NIS2 series (posts #392–#500) covers this in full.

2. GDPR + DORA intersection — DORA's incident reporting obligations run in parallel with GDPR's 72-hour breach notification requirement under Art.33. Both use different criteria for "major": DORA focuses on operational impact on financial services; GDPR focuses on personal data. You may need to report the same incident twice, to different authorities, on different timelines.

3. EU AI Act — From August 2026, AI systems used in financial services (credit scoring, fraud detection, algorithmic trading within certain risk categories) will fall under the AI Act's conformity assessment requirements. Our 100-post AI Act series (posts #200–#350 approx.) covers Art.1–113.

4. CRA (Cyber Resilience Act) — From August 2027 (enforcement), ICT products with digital elements used in DORA-covered systems must carry CE marking under the CRA. DORA's Art.30 due diligence requirements will intersect with CRA supply-chain obligations.

10. Developer Summary: DORA's Non-Negotiables at a Glance

DORA (EU 2022/2554) — all 64 articles, all chapters. Series #510. sota.io runs on EU-only infrastructure in Germany: your DORA compliance workload stays inside a single legal jurisdiction, with no CLOUD Act compellability risk for your operational data.