TL;DR. DORA went live on 17 January 2025. The firms that did the bare minimum to be ready are now discovering the DORA regulation didn't end on the deadline, it started. Five pillars, all continuous obligations. The 2024 ICT register is already stale because the SaaS environment changes weekly. The 2026 work isn't getting documented. It's keeping the documentation true, particularly on third party risk management, where most firms are weakest and where the European Supervisory Authorities are most active.
DORA's three areas of real exposure for technology leaders are ICT register currency, incident classification accuracy, and third-party concentration risk, in that order of supervisor priority.
DORA - the Digital Operational Resilience Act, Regulation (EU) 2022/2554, went live on 17 January 2025. A year on, most of the firms that did the bare minimum to be ready are now discovering the regulation didn't end on the deadline. It started. The Article 8 ICT register approved in December is already out of date. The third-party concentration analysis that satisfied the deadline reads thinner against the JC RTS than it did six months ago. The incident classification process designed in haste is producing classification calls that don't quite hold up.
This piece is for the CISO at a 1,200-person Irish or German payments firm, and the IT director and the head of compliance reading alongside them, trying to figure out which 2024 investments are sufficient and where 2026 attention needs to go. It is written by both founders. Namita has spent twelve years inside compliance functions at HSBC, EY, Accenture, and NTT Data; she carries the regulatory framing here. Ankur has spent the last three years building the inventory and register-currency systems that make DORA's continuous obligations operationally tractable; he carries the architecture argument for the register currency and third-party sections.
What DORA Covers and Who It Applies To
DORA is a regulation, not a directive. It applies directly across all member states without national transposition. The 17 January 2025 application date was the date the Regulation became operative; supervisory enforcement powers attached on the same date.
The Act applies to two broad categories.
Financial entities. The Regulation lists about twenty categories of in-scope financial entities, including credit institutions, payment institutions, e-money institutions, investment firms, central counterparties, trade repositories, crypto-asset service providers under MiCA, central securities depositories, and others. The carve-outs are narrow but real, particularly for very small entities under proportionality thresholds the supervisors have set.
Critical ICT third-party service providers. Designated by the European Supervisory Authorities under Article 31, these are the major cloud, infrastructure, and software providers whose failure would have systemic impact across the financial sector. The ESAs have published a roadmap towards critical-TPP designation. The first formal designations are advancing. For most mid-market firms, the practical implication is in the third-party risk pillar: when your provider is designated critical, additional reporting attaches.
Most readers of this piece are in scope as financial entities. The proportionality thresholds matter, a payment institution with under 50 employees and below specific transaction-volume thresholds operates under a lighter version of the regime, but the obligations apply by default unless the proportionality carve-out is documented and defended.
The Five Pillars
The Regulation's substantive obligations split into five pillars. Most teams have built mental models around three or four; for completeness, the five are:
Pillar 1 - ICT risk management. Articles 5 to 16. The governance and risk-management framework that sits over everything else. Article 5 places explicit responsibility on the management body. Article 6 requires a documented ICT risk management framework approved by the management body and reviewed annually.
Pillar 2 - ICT-related incident management, classification, and reporting. Articles 17 to 23. The incident lifecycle from detection through classification, response, and external reporting to the competent authority.
Pillar 3 - Digital operational resilience testing. Articles 24 to 27. The testing programme - vulnerability assessments, scenario-based tests, business continuity tests, and for the largest firms, threat-led penetration testing aligned to TIBER-EU.
Pillar 4 - ICT third-party risk management. Articles 28 to 44. The third-party register, the criticality assessment, the contractual requirements, the concentration analysis, the exit strategies, and the cooperation with critical ICT third-party providers.
Pillar 5 - Information sharing. Article 45. The voluntary information-sharing arrangements between financial entities on cyber threat intelligence.
Most firms invested heavily in Pillar 1 (ICT risk management framework documentation) and Pillar 2 (incident reporting process design) before the 17 January 2025 deadline. Pillar 5 has had limited operational uptake because it is voluntary. Pillars 3 and 4 are where the 2026 work concentrates, and Pillar 4 - third party risk management, is where the gaps are largest, the supervisors are most active, and the work most often gets postponed.
The remainder of this piece focuses on the three areas of weakness we see consistently in audits at mid-market financial entities: the Article 8 register currency problem, the major-incident classification process, and the third-party concentration risk obligation.
Article 8 - The ICT Register, and The Currency Problem
Article 8 requires every financial entity to maintain a register of all contractual arrangements on the use of ICT services provided by ICT third-party service providers. The register has to capture, for each arrangement: the provider, the services, the criticality, the data processed, the location of data and processing, the contract reference and term, exit arrangements, and the relationships to other providers in the firm's ICT supply chain. The standard format for the register is set out in Commission Implementing Regulation (EU) 2024/2956.
Most firms produced a register for the 17 January 2025 deadline. Most of those registers were correct on the day they were signed off. Most are now wrong.
The reason is structural, not procedural. Financial entities adopt new SaaS tools every week; through procurement, through subscription renewals, through embedded AI features turning on inside existing tools, through engineering teams adopting devtools on team budgets, through marketing and finance adopting point-solution tools that go through department-level expense approval. The register, maintained quarterly in a spreadsheet by a small team, cannot keep up with that change rate.
What this looks like in practice. A typical 1,200-person payments firm has 80 to 140 ICT third-party arrangements that should be on the Article 8 register. We have audited firms whose register listed 60. The gap is a mix of: subscriptions paid on personal cards and reimbursed through expenses; team-budget tools that never crossed central procurement; embedded AI features the register simply does not track as separate items; and providers added since the register was last refreshed, all of them DORA compliance gaps that compound with every week the register is not refreshed.
The supervisor's question is not whether the register existed on the deadline. The supervisor's question is whether the register is true today. The implication: the time from request to defensible production is part of what is measured.
The fix is operational, not documentary. The DORA ICT register has to draw from the systems where ICT third-party adoption actually happens; the SSO, the procurement system, the expense management platform, the identity provider, the finance system, and refresh continuously, not quarterly. Firms doing this manually need either a substantial increase in dedicated resource or an automation layer. Firms continuing to refresh manually quarterly will be out of step with the supervisor's expectations within twelve months.
Major ICT Incident Reporting - The 4-hour Clock
Article 19 sets the major-incident reporting timeline under DORA regulation. From classification of an incident as major, the financial entity has four hours to submit the initial notification to the competent authority. A subsequent intermediate report and final report follow on longer timelines. The classification criteria are set out in Commission Delegated Regulation (EU) 2024/1772.
Two things create operational friction here.
The first is classification accuracy. The classification criteria are based on the number of clients affected, financial impact, geographic spread, duration, criticality of services impacted, reputational impact, and data losses. The criteria are quantitative in places, qualitative in others. The classification call has to be made under time pressure, often with incomplete information about the impact scope, by a duty officer who may not have specialist regulatory training.
We see two failure modes. Under-classification - where a firm calls a major incident as a non-major and discovers later that the supervisor disagrees, then has to retroactively reconcile the timeline. Over-classification, where a firm calls a non-major incident as major and produces unnecessary reporting noise that affects the supervisor's view of the firm's incident management capability.
The second source of friction is the upstream visibility problem. The four-hour clock starts at classification, but classification depends on understanding the incident's blast radius, which systems are affected, which ICT third-party providers are involved, which downstream services are impacted. Firms whose DORA ICT register is incomplete (see above) struggle to map the blast radius accurately under pressure, which delays classification, which compresses the window for the four-hour notification.
The fix is preparation, not response. A current ICT register, a documented classification decision matrix, a duty officer with delegated regulatory authority, and tabletop exercises specifically for the four-hour notification, these are the operational practices that make the clock tractable. Firms that prepared for this in the run-up to 17 January 2025 are operating at a different competence level from firms that left it to the post-deadline period.
Third-party Concentration Risk - Pillar 4's Hardest Obligation
This is the area where 2026 enforcement attention will concentrate. The DORA Regulation's third-party risk pillar contains a specific obligation around concentration risk, the requirement to identify, assess, and where appropriate report on situations where dependence on specific ICT third-party providers, or on networks of related providers, creates systemic exposure.
The supervisors care about concentration for the same reason banking supervisors have always cared about concentration: shared infrastructure means shared failure modes. If a critical mass of in-scope financial entities all rely on a single cloud provider, an outage at that provider becomes a financial-stability event. DORA pushes the analysis below the headline level, into the relationships between providers and the dependencies between services.
The standard pattern that catches firms is the apparent-multi-vendor that is actually a concentration. Three examples we have seen:
The cloud-on-cloud pattern. Your production environment runs on AWS. Your backup environment runs on AWS. Your data warehouse - Snowflake - runs on AWS underneath. To your register, that is three vendors. To DORA's concentration logic, that is one provider with three points of failure. A region-level AWS event takes out all three.
The shared-substrate pattern. Your fraud detection runs on a vendor that runs on Azure. Your KYC vendor runs on Azure. Your customer support platform runs on Azure. Three different vendors, one underlying cloud. The supervisor expects you to know.
The fourth-party pattern. Your CRM provider uses an AI sub-processor for its embedded AI features. Your document management provider uses the same AI sub-processor. Your customer support tool uses the same AI sub-processor. Three different SaaS vendors at the contract level, one underlying AI provider. The fourth-party visibility most firms do not yet have is the kind the supervisor is now asking for.
Identifying concentration accurately requires fourth-party visibility, knowing not only your direct vendors, but their critical providers, and the providers of those providers. This is the hardest information asymmetry to close. Few firms have the contractual leverage to demand fourth-party transparency from every vendor; even fewer have the operational means to track it continuously when it does come. But the supervisor's expectation, particularly for ICT services classified as supporting critical or important functions, is moving in this direction. The subcontracting requirements were further specified in Commission Delegated Regulation (EU) 2024/1773, and Commission Delegated Regulation (EU) 2024/1502 sets the criteria for designating ICT third-party service providers as critical.
The first DORA compliance enforcement actions in 2026 will likely include cases where firms identified concentration superficially, at the direct-vendor level, and failed to surface concentrations that emerged at the underlying-infrastructure or sub-processor level. The work to close the gap is partly contractual (renegotiating sub-processor disclosure obligations) and partly operational (building third-party intelligence into the register-currency layer).
The register gap and the concentration gap rarely show up separately. They show up together, during an incident, when it is too late to fix either. The four-hour clock is running. The duty officer pulls up the ICT register to map the blast radius, and the register shows three vendors affected. A notification goes out covering the three vendors. Two weeks later, in the supervisor's review, it becomes clear that all three vendors were running on the same cloud infrastructure. In reality, there was only one provider failure, but the register had three entries, and the notification described three separate impacts. The register was right about the vendors, but it was wrong about the relationship between them. That is the concentration gap, and it only becomes visible at the worst possible moment. The register was built to track contracts, and the supervisor was asking about dependencies. Those are not the same documents. - Ankur Arora, Co-Founder, Montro |
TIBER-EU and Threat-Led Penetration Testing
Article 26 introduces the requirement, for specific in-scope financial entities, to perform threat-led penetration testing at least every three years. The framework aligned to this is TIBER-EU, originally developed by the ECB and adopted by national supervisors.
Most mid-market financial entities are not in TIBER scope. The thresholds prioritise the largest banks, payment institutions, and central counterparties. For firms not in scope, the obligation is the broader Article 24 testing programme - vulnerability assessments, scenario-based tests, business continuity tests, performance tests - without the threat-led penetration testing requirement. Firms in scope should know they are in scope by now; firms unsure should resolve that question explicitly with their competent authority.
ESA Regulatory Technical Standards
The Regulation contains substantive obligations; the Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS), produced by the European Supervisory Authorities, make those obligations operationally specific. The most important RTS now in force or recently published:
Commission Delegated Regulation (EU) 2024/1502 - criteria for designating critical ICT third-party providers.
Commission Delegated Regulation (EU) 2024/1772 - incident classification criteria, materiality thresholds, and major-incident report content.
Commission Delegated Regulation (EU) 2024/1773 - detailed content of the policy regarding contractual arrangements with ICT third-party providers supporting critical or important functions.
Commission Delegated Regulation (EU) 2024/1774 - ICT risk management tools, methods, processes, and policies, and the simplified ICT risk management framework.
Commission Implementing Regulation (EU) 2024/2956 - standard templates for the register of information.
Several additional RTS and ITS, covering incident reporting content, subcontracting elements, threat-led penetration testing, and oversight procedures, were finalised through 2024 and 2025. The compliance team has to track this active landscape, because the RTS is where the supervisor's specific expectations live. The Regulation says "appropriate"; the RTS says how appropriate is measured.
Enforcement Signals - What Supervisors Have Done in Year One and What to Expect in 2026
The first year of DORA was largely about supervisory engagement, not enforcement. ESA Joint Committees published clarifications. National supervisors issued Dear CEO letters and thematic reviews. The major banking supervisors - Central Bank of Ireland, BaFin, ACPR, published expectations on specific elements of the regime. Direct enforcement actions for DORA breaches have been limited.
That changes in 2026. The ESA Joint Committees have signalled supervisory priorities for the year that concentrate on three areas: third-party concentration analysis quality, ICT register completeness, and incident classification accuracy. National supervisors are running thematic reviews on these areas with selected firms; the findings from those reviews will inform broader supervisory expectations and will likely trigger the first formal enforcement actions.
The pattern of enforcement under regulatory regimes like DORA tends to favour early signal cases over breadth. Most firms will not be subject to DORA enforcement in 2026; the firms that are will be selected partly to demonstrate the regime's enforcement capability and to set operational expectations for the broader population. The selection criteria will include the materiality of the apparent breach, the firm's responsiveness to prior supervisory engagement, and the systemic relevance of the firm in question. Mid-market firms that engaged constructively in year one and addressed identified gaps are unlikely to be among the first targets; firms that did the bare minimum in year one and did not engage with supervisory communication are more exposed.
The 2026 Priority List
For a CISO at a mid-market in-scope financial entity allocating 2026 governance budget, five areas warrant priority attention.
- Bring the Article 8 register current and keep it current. This is the most-supervisor-visible gap and the gateway to the rest of the obligations. A register-currency layer that draws from operational sources continuously is the architectural fix.
- Close the third party risk management analysis at the sub-processor level. Direct-vendor concentration analysis is necessary but not sufficient. The fourth-party visibility work is harder; it is also where the supervisor is moving.
- Test the four-hour incident classification process under realistic conditions. Tabletop exercises specifically for the classification call, with deliberately ambiguous scenarios that stress the duty officer's regulatory authority.
- Reconcile the ICT register with the incident response runbook. The blast-radius analysis during an incident depends on the register being current; the register's value during steady-state depends on it being the same artefact the response team uses.
- Track RTS publication actively. The 2026 RTS landscape will continue to add specificity to obligations the firm has already documented against the Regulation's general language. New RTS sets new expectations; the framework needs to track the change rather than be locked to the 2024 baseline.
For financial services firms in particular, and for fintechs operating across multiple member states, the third-party concentration work is the single largest 2026 effort. For CISOs carrying programme accountability, and for the IT directors running the operational layer, the priority is to make the operational layer continuous rather than episodic.
Frequently Asked Questions
We're a payment institution under €30M annual transaction volume - does DORA apply to us?
Probably with proportionality applying. The Regulation contains proportionality provisions for smaller entities, documented in Article 4 and operationalised through ESA RTS on proportionality. The carve-out is not automatic; the firm needs to document its position against the proportionality criteria and be prepared to defend it. For most mid-market payment institutions, the substantive obligations apply with limited proportionality relief.
How does DORA relate to NIS2?
DORA is lex specialis to NIS2 for financial entities. The DORA Regulation explicitly states that for financial entities identified as essential or important entities under NIS2, DORA constitutes a sector-specific Union legal act for the purposes of NIS2 Article 4. A financial entity meeting DORA's incident-reporting obligations does not also have to meet NIS2's general incident-reporting obligations for the same incidents. The reporting timelines differ: DORA's four-hour major incident notification under Article 19 is faster than NIS2's 24-hour early warning. For a financial entity in scope of both, DORA's timing applies for incidents covered by DORA's classification.
We're not a TIBER-scoped firm. Do we still have testing obligations?
Yes - the broader Article 24 testing programme applies to all in-scope financial entities. Threat-led penetration testing under Article 26 is the additional requirement that applies to a smaller subset of larger firms. The Article 24 obligations include vulnerability assessments, network security assessments, scenario-based tests, business continuity tests, and end-to-end testing, running on a documented schedule with results captured, remediated, and reported.
Our cloud provider is being designated critical. What changes for us?
Limited operational change for the financial entity; significant change for the provider. The critical ICT third-party designation places the provider under direct ESA oversight. The financial entity's own obligations under the Regulation continue as before, including the duty to maintain the register entry for the provider, the criticality assessment, the contractual provisions, and the exit strategy. What changes: the provider becomes subject to ESA oversight engagement, and the financial entity may receive supervisor questions specific to the relationship.
Do we need to do a full third-party risk assessment for every SaaS tool, or just the critical ones?
The Regulation distinguishes between ICT services supporting critical or important functions (heavier obligations) and ICT services that do not (lighter obligations). The classification work happens at the service level, not the firm level. Most firms have 15–30 services supporting critical or important functions and a much larger number of services that do not. The full assessment applies to the former; the latter still need to be on the register but with lighter assessment requirements.
Where does AI risk fit in DORA?
AI used as part of ICT services falls under DORA's general obligations rather than a separate AI-specific chapter. Where AI is provided by a third party, the third-party risk pillar applies; where AI is part of an in-house system, the ICT risk management pillar applies. National supervisors, particularly BaFin and ACPR, have signalled that DORA enforcement will incorporate AI risk explicitly through 2026, particularly where AI is used in customer-facing decisioning.
