The Digital Operational Resilience Act (Regulation (EU) 2022/2554) became applicable on January 17, 2025. Most financial institutions spent 2023 and 2024 focused on the substance of DORA's requirements — ICT risk management frameworks, incident reporting, third-party ICT provider oversight, and the TLPT (threat-led penetration testing) program. That work was necessary and, for many firms, significant.
What received less attention — and what we are tracking closely in Fynrex — is how DORA itself continues to develop through regulatory technical standards, implementing technical standards, and the ongoing guidance publications of the three European Supervisory Authorities that jointly developed and now oversee it: ESMA, EBA, and EIOPA. DORA's applicability date did not close the regulatory change management book on DORA. It opened a new chapter that looks more like ongoing monitoring than a one-time implementation project.
DORA's Architecture: Why the Base Regulation Is Not the Whole Story
DORA as enacted is a framework regulation — it sets the obligations and outcomes but delegates much of the technical specificity to regulatory technical standards (RTS) and implementing technical standards (ITS) developed by the Joint Committee of the ESAs. This is the standard EU legislative architecture for complex technical domains, but it has important implications for compliance programs: the detailed rules you need to comply with are not all in the regulation itself.
By application date in January 2025, the ESAs had finalized and the Commission had adopted the first batch of RTS and ITS under DORA. These covered ICT risk management requirements (the "simplified" framework for smaller firms), incident classification criteria, the reporting templates and timelines for major ICT incidents, digital operational resilience testing requirements, and third-party ICT provider policy requirements.
The second batch — covering the RTS on subcontracting arrangements for critical or important functions, the register of information on third-party ICT providers (the "contractual register"), and the oversight framework for critical third-party providers (CTPPs) — was still under development or undergoing Commission review as of the application date. These are not minor technical documents: the CTPP oversight framework in particular changes the risk management calculus for firms that rely on cloud and data providers now designated as critical.
The Post-Application Update Cadence You Need to Monitor
From our DORA monitoring work, we are tracking publications from three distinct regulatory channels — each of which has a different publication type and timeline:
ESA Joint Committee. The primary legislative drafting body for DORA RTS and ITS. Publications include consultation papers on draft standards (where comment periods are typically six to twelve weeks), final reports transmitting draft standards to the Commission, and Q&A documents addressing implementation questions. Q&A publications are legally non-binding but operationally significant — they represent the ESAs' formal position on how the regulation should be interpreted in specific scenarios.
Individual ESA publications. ESMA, EBA, and EIOPA each publish sector-specific guidance and supervisory expectations under DORA for their respective supervised populations. A payments firm regulated under EMD2 by national competent authorities under EBA's scope has different supervisory expectations from an investment firm supervised by national competent authorities under ESMA's scope. Following only the Joint Committee publications and missing the sector-specific ESA publications produces an incomplete picture.
National competent authority publications. DORA applies directly in all EU member states, but national competent authorities are responsible for day-to-day supervision. Several NCAs have published or are preparing to publish national supervisory expectations, examination priorities, and sector-specific guidance that goes beyond the minimum set out in the ESA standards. For firms with regulated entities in multiple EU member states, the NCA-level publication cadence matters.
A Scenario: A Payments Firm Expanding Into the EU Under DORA
Consider a growing payments company that has held a UK e-money institution license for several years and obtained an EU electronic money institution license through a new Irish entity in late 2024, in time for DORA's applicability. The firm had mapped its ICT risk management framework against DORA's requirements and implemented the enhanced incident reporting for major ICT incidents under the reporting templates finalized in the first RTS batch.
What the firm's compliance team did not fully account for was the ongoing monitoring requirement. In February 2025, the EBA published updated Q&A responses addressing the definition of "ICT-related incident" versus "major ICT incident" for the classification criteria under Article 18. The Q&As clarified how certain types of third-party provider outages should be classified where the firm's own systems remain available but customer-facing services are impaired via the provider dependency. The firm's incident classification procedure, drafted in late 2024, was based on a reading of the regulation and the RTS that the Q&A now clarified was too narrow.
This is not a failure of DORA implementation — the firm implemented in good faith against the available published materials. It is a regulatory change management failure: the firm did not have a process for tracking post-applicability DORA publications and assessing them against its existing compliance program. By the time the Q&A came to the attention of the compliance team — through an industry newsletter, several weeks after publication — the firm had already classified and reported several incidents under the old framework. Whether any of those classifications would be revisited by the central bank is uncertain; the documentation gap is not.
The CTPP Oversight Framework: What Changes When Your Cloud Provider Gets Designated
The DORA oversight framework for critical third-party providers (CTPPs) is one of the most structurally novel aspects of the regulation. The ESAs, through the Joint Oversight Network, will designate certain ICT providers as critical — primarily the largest cloud providers and data utility vendors — and will conduct direct oversight of those providers.
For financial institutions, CTPP designation of one of your ICT providers creates compliance obligations that were not present before designation: you must incorporate specific provisions into your contractual arrangements with that provider, you may be required to cooperate with ESA oversight activities, and the CTPP's compliance posture under DORA oversight becomes part of your own third-party risk assessment.
The first CTPP designations had not been finalized as of this article's date. When they arrive, firms that rely on designated providers will have a defined timeline to review and update contractual arrangements. That is a discrete compliance task with a deadline — the kind of regulatory event that needs to be in the compliance team's tracking system, not discovered by accident.
We are tracking the designation process through the ESA Joint Committee's publications and will surface CTPP-related updates as a distinct category in Fynrex, because the downstream compliance implications for firms — policy updates, contract reviews, risk reassessments — are specific and time-bound.
What "Ongoing DORA Monitoring" Actually Requires
The practical implication of DORA's architecture is that a compliance team cannot treat DORA as a completed implementation project. The regulatory change management obligations are ongoing and look different from standard rule monitoring in two ways.
First, the publication sources are more diffuse than for a standard national rule. DORA updates come from the Commission (delegated and implementing acts), the Joint Committee of the ESAs, ESMA, EBA, EIOPA independently, national competent authorities across up to 27 member states, and the CTPP oversight process. A monitoring setup that covers only the Commission's Official Journal will miss a significant proportion of operationally material DORA developments.
Second, the publication types require different types of compliance response. An RTS amendment requires a policy review against the new standard. A Q&A clarification requires a check of existing procedures against the clarified interpretation. An EBA supervisory statement on examination priorities requires calibration of your own internal audit program. An NCA supervisory expectation paper may require localized additions to your group DORA policy for entities in that jurisdiction. These are not all the same type of task, and they do not all have the same urgency.
We are not saying that DORA's implementation was straightforward and the ongoing piece is the real challenge — the initial implementation was genuinely complex for any firm with significant ICT dependencies. The point is that DORA compliance is not a state you reach and then maintain on autopilot. It requires the same continuous regulatory monitoring posture as any other actively-developed regulatory framework.
Mapping DORA Updates to Your Existing Controls
One of the most useful things a compliance team can do in the post-applicability phase is build an explicit mapping between their DORA-related policies and controls and the specific regulatory provisions that created each one. This is the foundation of any effective change management process for DORA — when a new publication updates or clarifies a specific article or standard, the mapping tells you exactly which of your policies and controls are implicated.
For example: your incident classification procedure maps to Article 18(1) of DORA and the classification criteria in the RTS on incident reporting. When the EBA publishes a Q&A that clarifies how to apply Article 18(1) in a specific scenario, the mapping tells you to review that specific procedure, not your entire DORA program. Without the mapping, every DORA publication requires a full program review, which quickly becomes impractical and therefore stops happening.
The mapping exercise also forces precision about what your DORA compliance program actually consists of — which controls are genuinely DORA-derived versus pre-existing controls that happen to be relevant, what the overlap is with NIS2 requirements for the same systems, and where your DORA testing program is documented versus where it lives only in email correspondence. That precision becomes the foundation for audit-ready DORA compliance.