Why Reading the Summary Decks Is Not Enough
The Digital Operational Resilience Act (DORA) - Regulation (EU) 2022/2554 - entered full application on January 17, 2025. In the months before that date, financial institutions across the EU received a steady stream of briefing documents summarising its five pillars: ICT risk management, ICT-related incident classification and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing.
What those summaries often omit is the density of specific obligations buried in individual articles. Article 25, for instance, does not merely require that firms manage third-party ICT risk. It specifies the contractual provisions that must be present in every arrangement with an ICT third-party service provider - provisions that many legacy outsourcing agreements do not contain and that require renegotiation before the deadline, not after.
This article works through DORA's key obligations at the clause level, with attention to the provisions that compliance teams have been most likely to underestimate.
Chapter II: ICT Risk Management - Articles 5 to 16
Articles 5 through 16 establish the ICT risk management framework. Article 5 requires the management body to bear ultimate responsibility for ICT risk - this is not a delegation to the CIO or CISO. Board members must have sufficient understanding of ICT risk to challenge management, and firms must document how that understanding is maintained and tested.
Article 8 covers ICT risk identification and introduces the concept of "ICT-supported business functions." Firms must map which business functions depend on which ICT systems, the criticality of each dependency, and the potential impact of ICT disruption on each function. This mapping is not a one-time exercise - Article 8(2) requires it to be updated whenever material changes occur in the ICT environment.
Article 11 addresses business continuity policy and introduces a Recovery Time Objective (RTO) and Recovery Point Objective (RPO) requirement that must be set at the level of individual ICT systems, not the firm as a whole. This is a meaningful shift from previous guidance, which typically set RTOs at the business function level. Testing those objectives - not merely asserting them - is addressed in Chapter IV.
Chapter III: Incident Reporting - The Timeline Obligations
The incident reporting framework in Articles 17 to 23 is where many firms encountered operational difficulty in the months following DORA's application date. The core obligation is tiered reporting to the competent authority: an initial notification within four hours of classification, a detailed intermediate report within 72 hours, and a final report within one month.
The critical challenge is the classification step. Article 18 sets out the classification criteria for "major ICT-related incidents" using thresholds defined in the delegated regulation RTS/ITS published under Articles 18(3) and 20. These thresholds include the number of clients affected, the geographic scope, the data loss, and the economic impact - all of which must be assessed and documented before the four-hour clock starts on the initial notification.
Practically, this means the classification workflow must be automated or at least semi-automated. Manually assessing whether an incident crosses the major classification threshold within four hours, while simultaneously managing the incident itself, is not achievable with the governance structures most mid-tier banks had in place prior to 2025.
Article 19 introduces the concept of "significant cyber threats" - threats that have not yet materialised into incidents but which, if realised, could have a significant impact. Firms must notify the competent authority of significant cyber threats on a voluntary basis. The practical implication is that the intelligence function feeding this assessment must be continuously operational, not reactive.
Chapter IV: Digital Operational Resilience Testing
Articles 24 to 27 govern resilience testing. Article 24 requires all in-scope entities to maintain a digital operational resilience testing program that includes, at minimum, threat-led penetration testing (TLPT). Article 26 specifies that TLPT must be conducted at least every three years, must be performed by qualified testers (either internal with independence controls or external), and must cover production systems in live environments.
The requirement to test production systems - not representative test environments - is one of the most operationally challenging aspects of DORA for banks with complex core banking infrastructure. It requires coordination across technology, risk, legal, and operations at a level of precision that sandbox-only testing programs do not develop.
Article 27 introduces the concept of "pooled testing" for third-party ICT providers, where the provider can commission a single TLPT that multiple financial entities can rely on. The practical conditions for reliance - set out in the implementing technical standards - are restrictive enough that pooled testing will not eliminate the need for firm-specific scoping in most cases.
Chapter V: Third-Party ICT Risk - Articles 28 to 44
Chapter V is the section that will generate the most remediation work for most institutions. Article 28 establishes the general principles of third-party ICT risk management and requires firms to maintain a register of all ICT third-party service providers. Article 28(3) specifies the minimum information that register must contain: the services provided, the ICT systems supported, the jurisdiction of the provider, the date the arrangement commenced, and the most recent due diligence assessment.
Article 30 lists the contractual provisions that must be present in every written arrangement with an ICT third-party service provider. The list is extensive. It includes: a full description of the services and service levels with quantitative performance targets; the locations where data will be processed; notification requirements for incidents that affect the institution; audit rights including the right to inspect; requirements for business continuity plans; and exit provisions including data portability obligations.
For firms that have outsourcing agreements predating DORA, the gap between these requirements and the actual contract language is often significant. Renegotiation at scale - particularly for providers with significant market power - has proven to be a multi-year project, not a pre-application sprint.
Articles 31 to 44 deal with "Critical ICT Third-Party Service Providers" (CTPPs) - a designation that will be assigned by ESA joint committees to providers deemed systemically important. CTPPs are subject to an oversight framework that includes on-site inspections, information requests, and the potential for recommendation of remediation. The list of entities that will be designated as CTPPs was not finalised at the time of writing.
What Automated Regulatory Parsing Adds to DORA Compliance Programs
Managing DORA compliance manually - tracking article-level obligations, monitoring RTS/ITS updates as they are published, maintaining contract register completeness - is a continuous analytical workload. As we explored in our article on why manual gap analysis breaks down at scale, the issue is not the volume of documents but the precision required to match each obligation to a specific internal control or contractual provision.
Paragex processes DORA amendments and implementing technical standards as they are published and maps each obligation to the control inventory. When ESA publishes a revised RTS under Article 20, the system identifies which classification thresholds have changed and flags the incident management procedures that require updating - rather than leaving that discovery to a quarterly compliance review cycle.
Conclusion
DORA's complexity is not in its principles - operational resilience, third-party oversight, and tested continuity are familiar concepts. Its complexity is in the specificity of its obligations at the clause level and the timelines those obligations impose. Firms that built their DORA programs around summary frameworks rather than article-level analysis are finding gaps in their contract registers, their incident classification workflows, and their testing scope that require systematic remediation.
Reading DORA at the clause level, and tracking the implementing technical standards as they develop, is not optional for compliance teams at in-scope institutions. It is the work.
Paragex maps regulatory obligations from DORA and 37 other frameworks to your control inventory. Book a demo to see clause-level extraction in action on a live regulatory document.