DORA compliance monitoring: why you need more than a checklist
DORA has been in full application since January 2025. A static checklist got you through initial implementation. Continuous monitoring of implementing acts, supervisory guidance, and third-party risk developments is what keeps you there. This article explains the difference and what tools actually serve each need.
This article is for informational purposes only and does not constitute legal advice. Consult a qualified legal professional for advice specific to your situation.
DORA is in application. The regulatory layer beneath it is still developing.
The Digital Operational Resilience Act (Regulation (EU) 2022/2554, CELEX: 32022R2554) became fully applicable on 17 January 2025. The headline framework is in force: ICT risk management obligations, incident reporting timelines, resilience testing requirements, and third-party risk management rules apply now to banks, investment firms, payment institutions, insurance undertakings, crypto-asset service providers, and a range of other financial entities.
What many compliance teams have not fully registered is the volume of Level 2 material that continues to develop beneath the framework regulation. The regulatory technical standards and implementing technical standards specifying the operational detail of DORA obligations were published in stages through 2024 and into 2025. Supervisory guidance from national competent authorities is at different stages of development across EU member states. ESMA, EBA, and EIOPA are actively engaged in the oversight of critical ICT third-party providers, a process that generates new designations and supervisory expectations on an ongoing basis.
A firm that implemented DORA against the framework regulation and the major RTS published by early 2025, then stopped monitoring, is already working with an incomplete picture. That is not a hypothetical risk. It is the current state for a significant number of firms that treated DORA as a project with a January 2025 go-live date rather than as an ongoing compliance obligation.
This article explains the difference between the checklist work that served initial implementation and the continuous monitoring that ongoing DORA compliance requires. It then maps what different tool categories actually provide for each type of need.
What a checklist covers and where it stops
A DORA compliance checklist, including the five-pillar checklist for financial entities, is the right starting point for understanding the scope of initial implementation. It tells you what the regulation requires across ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing. It tells you what demonstrable compliance looks like for each obligation. It gives you a structured way to assess your current position and identify gaps.
A checklist has a fixed reference point. It reflects the state of the regulatory text and the published technical standards at the time it was written. It does not update when a new supervisory Q&A is published. It does not flag when an EBA opinion changes the expected approach to a DORA provision. It does not tell you when the ESA list of critical ICT third-party providers is updated with a new designation that affects your provider register.
For initial implementation, a checklist is the right tool. For ongoing compliance, it is a starting point that needs to be supported by continuous monitoring.
The distinction matters because DORA is not a regulation whose requirements were fully specified at the point of application. It is a framework regulation whose operational requirements continue to be filled in by the ESAs and interpreted by national competent authorities. The compliance obligation you are managing is a moving target, not a fixed set of requirements.
The regulatory layer that continues to develop
Understanding what to monitor requires understanding the structure of the DORA regulatory package. The framework regulation sets out the headline obligations. The Level 2 technical standards specify the operational detail. NCA guidance and ESA supervisory output interpret both in the context of specific firm types and fact patterns.
The Level 2 layer covers a large amount of operationally significant ground.
The incident reporting RTS specifies the classification criteria for major ICT incidents, the content of the initial notification, intermediate report, and final report, and the format for submission to national competent authorities. This RTS was finalised in 2024 and its interaction with existing NCA reporting infrastructure has generated practical questions that supervisory guidance is still addressing.
The TLPT technical standards specify the accreditation criteria for external testers, the scope definition methodology, the red team exercise structure, and the reporting requirements following a TLPT exercise. For firms that have been designated by their NCA for TLPT, these standards determine what a compliant exercise looks like in practice.
The third-party risk RTS specifies the content of the ICT third-party provider register, the minimum contractual clauses required under Article 30, and the criteria for classifying arrangements as covering critical or important functions. Firms that built their DORA TPRM frameworks against the consultation paper version of this RTS before the final text was published may have gaps they have not yet identified.
The critical third-party provider oversight framework generates ongoing output in the form of ESA designations. The list of ICT third-party providers designated as critical for the EU financial sector is maintained and updated by the ESAs. A firm whose provider register does not reflect current designations is not managing its DORA third-party risk obligations accurately.
Beyond the formal Level 2 layer, national competent authorities across the EU are issuing supervisory guidance on DORA expectations, supervisory priorities for the first assessment cycle, and practical requirements for incident reporting submissions. This NCA-level material is not published on EUR-Lex and is not systematically indexed by most monitoring approaches. For firms managing DORA obligations across multiple EU jurisdictions, it is operationally significant.
The three compliance monitoring problems DORA creates
Thinking about DORA monitoring as a single problem understates what is actually required. There are three distinct monitoring problems, and they are best served by different approaches.
The first is regulatory currency: knowing what the current DORA obligations are, including the Level 2 technical standards and any subsequent amendments, and being able to answer specific compliance questions against the current text. This is the foundation. A firm that cannot accurately describe what Article 30 requires for contracts covering critical or important functions, or what the incident classification criteria in the RTS specify, is not in a position to manage its DORA obligations effectively.
The second is change detection: knowing when the regulatory position changes, whether through a new technical standard, an amendment to an existing one, a new ESA guideline, or a significant supervisory statement that affects how an existing requirement is interpreted. This is the monitoring function that needs to be continuous rather than periodic.
The third is third-party risk tracking: knowing whether the ICT third-party providers your firm relies on are designated as critical under the DORA oversight framework, what the ESAs’ supervisory activities regarding those providers are generating in terms of recommendations and findings, and whether your contractual position and exit strategies remain adequate as the provider landscape evolves.
These three problems overlap but are not the same. A tool that addresses the first does not necessarily address the second. A tool that addresses the second does not address the third. The right monitoring infrastructure for DORA uses different tools for different parts of the problem.
What tool categories actually provide
Source-anchored regulatory intelligence
A source-anchored regulatory intelligence platform built on EUR-Lex continuous ingestion and ESA source monitoring provides the most reliable coverage of the first two monitoring problems: regulatory currency and change detection. For DORA specifically, this means continuous monitoring of the framework regulation, all published technical standards and implementing acts, and supervisory guidance from EBA, ESMA and EIOPA, with personalised alerts when new instruments affecting DORA are published and the ability to query specific DORA provisions and receive answers sourced from the current official text with CELEX citations.
The practical value for a DORA compliance team is the ability to answer questions like: what does the incident reporting RTS require for the content of an intermediate report, and is the version of the RTS we implemented against still the current text? Or: has the third-party risk RTS been amended since we built our provider register against it? These are the questions that ongoing compliance management requires answers to, and they require answers sourced from the current text rather than from memory of what was published at a point in the past.
Enterprise regulatory monitoring platforms
Enterprise platforms such as Wolters Kluwer FRR and Corlytics cover DORA within their broader EU financial regulation monitoring. Their coverage of the framework regulation and the major Level 2 instruments is generally strong. The limitations are those that apply to these platforms for all EU financial regulation: analyst curation introduces latency between publication and platform delivery, multi-jurisdiction breadth dilutes DORA-specific depth, and the absence of a source-anchored query interface means users cannot interrogate specific DORA provisions directly against the current text.
Corlytics is comparatively stronger on pre-legislative content, including ESA consultation papers and draft technical standards. For DORA, where most of the major technical standards are now finalised, this pre-legislative advantage is less differentiating than it was during the implementation phase. The ongoing value for DORA monitoring is the enforcement analytics layer and the NCA guidance coverage, which goes beyond the EUR-Lex layer.
For mid-market firms and smaller compliance teams, the cost structure of enterprise platforms is a significant constraint. The value proposition of multi-jurisdiction breadth is also weaker for a firm whose primary regulatory exposure is EU-specific. A firm managing DORA, MiFID II, and SFDR without material UK or US obligations is paying for substantial out-of-scope coverage with an enterprise platform.
TPRM platforms with DORA modules
Third-party risk management platforms are the right tool for the third monitoring problem: ongoing oversight of ICT third-party providers. Prevalent and ProcessUnity have both developed DORA-specific modules that address the Article 28 to 30 obligations: maintaining the provider register in the format specified by the RTS, tracking contractual clause coverage, managing due diligence workflows, and monitoring sub-outsourcing chains.
What TPRM platforms do not provide is regulatory currency monitoring. A TPRM platform configured against the DORA third-party risk RTS does not tell you when the RTS is amended, when the ESA critical provider list is updated, or when a supervisory statement changes the expected approach to a DORA third-party obligation. The register is only as good as the regulatory knowledge used to configure it.
This creates a specific integration point between regulatory intelligence monitoring and TPRM workflow. The monitoring function tells you what the current requirements are and when they change. The TPRM platform manages the process of meeting those requirements. Neither substitutes for the other.
For a full discussion of TPRM platform options for DORA, including the distinction between TPRM-specific tools and broader operational resilience platforms, see EU financial regulation software: what firms actually need.
Generic AI tools
The failure modes of generic AI tools for DORA monitoring are the same structural failures that apply to EU financial regulation research generally, and they are more consequential for DORA than for most other frameworks because of the pace at which the Level 2 layer developed.
A language model trained at any point before the final versions of the DORA technical standards were published will describe DORA requirements based on consultation draft versions that may differ from the adopted text. Specifically:
A tool asked about the incident reporting deadlines and classification criteria may describe requirements based on the consultation paper for the incident reporting RTS rather than the final adopted text. The changes between consultation and final adoption in the RTS are operational, not cosmetic.
A tool asked about the contractual requirements for ICT third-party providers may describe the minimum provisions in terms that reflect the framework regulation without incorporating the more specific requirements set out in the adopted technical standards.
A tool asked about the TLPT requirements may describe the exercise scope and tester accreditation requirements in terms drawn from pre-finalisation material, or from general descriptions of TIBER-EU that predate the DORA-specific TLPT standards.
In each case the answer is not fabricated. It reflects the regulatory position at the training cutoff, which for DORA is often the pre-final-adoption position on the most operationally significant details. The three tests described in why generic AI tools are unreliable for regulatory compliance research apply directly: source transparency, currency, and scope discipline. Generic AI tools fail all three for DORA.
The monitoring approach that fits ongoing DORA compliance
For most financial entities managing DORA on an ongoing basis, the practical monitoring approach combines source-anchored regulatory intelligence across the full regulatory lifecycle with direct monitoring of relevant NCA publication feeds, supported by TPRM workflow tooling that manages the operational process of meeting the requirements the monitoring function identifies.
The sequence matters. Regulatory currency comes first: knowing what the current DORA obligations actually are is the foundation for everything else. TPRM process management comes second: once you know what the requirements are, the workflow tools help you meet them. Change detection runs continuously alongside both: when the requirements change, the workflow needs to update.
A static checklist, completed at implementation and not revisited, addresses none of these ongoing needs. It is a point-in-time snapshot of what DORA required at the time it was written, and the distance between that snapshot and the current regulatory position grows every time a new supervisory statement, ESA guideline, or technical standard amendment is published.
The firms that will face the most significant DORA supervisory risk in the next two years are not necessarily the ones that failed to implement. They are the ones that implemented carefully in late 2024 and early 2025 and then stopped paying attention. The regulatory position they implemented against is no longer the complete picture of what DORA requires.
What to monitor in 2026 and beyond
The areas where ongoing DORA monitoring is most likely to surface operationally significant developments in 2026:
Critical third-party provider designations. The ESA oversight programme for critical ICT third-party providers is active. New designations are published on an ongoing basis. Firms should be monitoring the ESA designation list and cross-referencing it against their provider register systematically, not as a one-off exercise.
Incident reporting in practice. The first full year of DORA incident reporting is generating NCA feedback on submission quality, classification decisions, and reporting content. Some NCAs have published guidance on what they expect in incident reports and where submissions have been inadequate. This NCA-level guidance is operationally significant for firms refining their incident management processes.
Third-party risk supervisory focus. Third-party risk is the area attracting the most sustained supervisory attention in the first DORA assessment cycle. The interaction between DORA’s Article 28 to 30 obligations and pre-existing EBA and EIOPA outsourcing guidelines is a source of practical complexity, and supervisory interpretations of how these frameworks interact continue to develop.
TLPT coordination across borders. For significant firms operating across multiple EU jurisdictions, the TLPT coordination arrangements between NCAs are developing in ways that affect the practical management of the three-year TLPT cycle. The cross-border recognition of TLPT results and the role of joint TLPT exercises are areas where supervisory practice is still being established.
For a broader view of the EU financial regulatory landscape and how DORA fits within it, see EU financial regulation in 2026: what it covers, who it affects, and why horizon scanning matters.
For the full five-pillar implementation checklist covering what DORA requires and what compliance looks like in practice, see DORA compliance checklist for financial entities.
Forseti monitors DORA continuously across all five streams: adopted legislation, Commission proposals, supervisory guidance from EBA and ESMA, consultations and draft standards, and case law. Personalised alerts and source-anchored answers cited to specific CELEX identifiers and article numbers. Start for free.
This article is part of a series on the EU regulatory intelligence platform landscape. See also: EU financial regulation software: what firms actually need.
Having the right evidence is necessary but not sufficient. This guide covers how to organise sustainability compliance documentation so that an auditor, regulator, or EU buyer can follow the chain of reasoning without your assistance.