DORA: From classic IT security to demonstrable resilience of critical end-to-end services – including ICT supply chain and third-party providers.

Author: NEXORA Unternehmensberatung GmbH Date: January 2026 Reading time: approx. 13 minutes

Introduction & Target Audience

With the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554), the EU has created a uniform framework for the digital operational resilience of financial companies. In addition to classic components such as ICT risk management, incident reporting, testing and information exchange, DORA introduces, for the first time, Europe-wide supervision of critical ICT third-party service providers. This article is aimed at board members, managing directors, CROs, CIOs, CISOs and outsourcing managers in banks, securities firms, payment institutions, e-money institutions, insurance companies, pension funds, crypto service providers and FinTechs with EU connections. It highlights what will really change in practice as a result of DORA and the new supervisory framework for critical ICT third-party service providers (“critical providers”) – including the new EU–UK cooperation.

1. DORA is more than “just another compliance project”

In theory, many institutions know DORA as a package of five modules: ICT risk management, incident reporting, resilience tests, management of ICT third-party risk and information exchange. In practice, however, DORA does not measure whether a framework exists on paper, but whether critical services can actually continue to run under stress – and whether outsourcing is managed in such a way that the failure of a provider does not become a risk to its existence.

The central shift: from “we have IT security and policies” to “we can prove that our critical end-to-end services are resilient” – including people, processes, data, suppliers, BCP/DR and restart in defined RTO/RPO. From a regulatory perspective, ICT risks and outsourcing are therefore no longer treated as a support issue, but as core risks that have a direct impact on the business model, capital planning and governance.

2. Critical ICT third-party service providers: Who is affected – and why even without a direct contract?

DORA establishes an independent European monitoring framework for those ICT third-party service providers that are systemically relevant for many supervised companies. These are typically large cloud, platform and infrastructure providers, but also other central ICT infrastructures on which payment transactions, trading, custody or core banking processes are based.

The classification as a “critical ICT third-party service provider” is carried out by the Joint Committee of the European Supervisory Authorities on the basis of harmonized criteria (including concentration risks, systemic relevance, substitutability, cross-border significance). For each critical provider, the Committee appoints a lead supervisory authority (Lead Overseer – EBA, ESMA or EIOPA), based on the largest customer share by total assets.

Why this really affects financial companies

• Contractual and governance pressure downwards: If a provider (or a sub-service provider in the chain) is classified as critical, requirements for audit rights, information obligations, testing, incident transparency and sub-outsourcing are effectively “close to supervisory” – even if they have to be formally anchored in the B2B contract.

• Architecture and sourcing decisions become relevant for supervision: Single-provider designs, lack of portability, proprietary dependencies and untested exit plans become much more visible in audits and can be addressed directly.

• Indirect reach (“indirect chain”): Even if there is no direct contract with a hyperscaler (e.g. SaaS via integrator), the responsibility remains to understand the risk chain, map control rights and ensure DORA-compliant minimum requirements along the supply chain.

3. How the new supervision of critical providers works

The supervisory framework for critical ICT third-party service providers supplements the classic supervision of financial companies with a “macro view” of central ICT nodes.

Central elements:

• Classification & Lead Overseer: The Joint Committee of the ESAs prepares the classification and appointment of critical providers and appoints a lead supervisory authority (Lead Overseer) for each provider.

• Tasks of the Lead Overseer: Assessment of governance, security and risk structures, request for information and documents, conducting investigations and on-site inspections, issuing recommendations and remedial measures.

• Consequences & costs: If recommendations are not implemented, national supervisory authorities can oblige supervised financial companies to suspend or terminate cooperation with critical service providers; the costs of supervision are borne by the critical providers themselves.

Important for financial companies: Direct supervision of critical providers does not replace their own ICT third-party risk management, but creates additional information flow and supervisory impulses (“top-down”), which must be taken into account in their own management.

4. From policy to “evidence”: What supervision now specifically expects

Many DORA requirements were already known through guidelines from the EBA, ECB or national expectations. What is new is the degree of standardization – for example, via technical standards on outsourcing registers – and the clear expectation that companies can regularly and documentedly demonstrate that controls are effective.

Three areas in which teams really need to sharpen their focus:

4.1 Service map instead of system list

Instead of a pure system inventory list, supervisory authorities expect a service perspective: critical functions/services (e.g. “SEPA Instant Payments”, “Crypto Custody”, “Onboarding/KYC”) with end-to-end flows, RTO/RPO, data classification and a clear owner structure. These service maps must make visible which external ICT third-party service providers are involved at which point – including sub-service provider chains.

4.2 Incident handling as a real operational process

DORA requires more than defined reporting thresholds. The following are expected:

• functional runbooks with clear roles and escalation paths,

• Triage models that also record third-party incidents in a structured manner,

• Communication cascades (internal, customers, supervisory authority) and

• Consistent post-mortems with lessons learned and demonstrable improvements.

This immediately shows how quickly critical providers deliver technical root cause information, log excerpts and remediation evidence – and whether corresponding rights are contractually secured.

4.3 Resilience tests that are “allowed to hurt”

Resilience tests under DORA should not become a mere formality. Tabletop exercises, technical tests (including failover scenarios across provider boundaries) and realistic incidents – such as the failure of an identity provider during peak times – must be planned, carried out and linked to clear measures. Supervisory authorities are not only interested in the test plan, but also in the chain: findings, decisions, implementation status and repeated tests.

5. Third-party risk: the new minimum components in contracts and management

DORA forces financial companies not only to source ICT third-party service provider relationships, but also to actively manage them – over the entire life cycle.

Typical areas for improvement in practice:

• Clarity about critical/important functions: Which services fall under this, which providers depend on it, how are these mapped in contracts and SLAs.

• Audit and information rights (including sub-service providers): Rights to on-site inspections, access to relevant information, participation in tests and incident simulations, enforceable also against sub-service providers.

• Measurable SLAs/SLOs and incident regulations: Defined time windows for reports, minimum content (impact, causes, measures), access to root cause information at least at the abstraction level.

• Suboutsourcing governance: Transparency about sub-service providers, approval/notification mechanisms, chain controls along the entire ICT supply chain.

• Exit strategy: Data and workload portability, transition assistance, testable exit scenarios (e.g. desktop exercises) and realistic cost assumptions.

For critical providers, these components are increasingly becoming the market standard in the regulated environment; standard conditions without DORA-compatible clauses will be difficult to justify in the supervisory dialogue.

6. Cross-border complexity and the EU–UK MoU “hook”

Many relevant ICT providers, security service providers and group delivery units are located or operate in several jurisdictions (EU, UK, USA, APAC). DORA is EU law – but the value creation and data chains are global.

On January 14, 2026, the European Supervisory Authorities (EBA, EIOPA, ESMA) and the British supervisors (BoE, PRA, FCA) signed a Memorandum of Understanding (MoU) on cooperation in the supervision of critical ICT third-party service providers or Critical Third Parties (CTPs). The MoU creates a framework for information exchange, coordination of supervisory actions and coordination in incident situations (e.g. large-scale cyber attacks or power failures).

What an MoU is good for in practice – and what it is not:

• Good: It reduces friction losses between authorities, facilitates consistent supervision of cross-border structures and can limit duplicate checks.

• Not sufficient: It does not replace contractual control rights, robust exit plans and technically tested portability of data and workloads.

Pragmatic consequence: Cross-border issues must not be treated as a “later legal detail”. They belong in the vendor and architecture design: which data is located where, who can provide which information in the event of an incident, and how quickly is a migration realistically possible in the worst-case scenario.

7. “What do I have to do tomorrow?” – a 30/60/90-day roadmap

A phased approach has proven successful in moving from analysis to implementation.

30 days

• Define critical services (not just systems), name service owners, define target RTO/RPO.

• Map the vendor landscape: direct providers plus essential sub-service providers, including assignment to critical services.

• Quick check of the top 10 contracts: Audit/information, incident regulations, suboutsourcing, exit clauses – where are there obvious gaps.

60 days

• Operationalize incident processes: Runbooks, communication matrix, initial tests/tabletop exercises with the involvement of central providers.

• Create a resilience test plan: Scenarios across provider boundaries, including dependencies on critical and potentially critical service providers.

• Start contract remediation plan: Prioritization according to criticality, negotiating power and time-critical DORA gaps.

90 days

• Concretize the exit strategy for each critical or particularly important provider and test it at least as a desktop exercise.

• Establish KPI/KRI reporting for ICT risk and provider performance, coordinated with risk reporting and IT governance.

• Compile audit-proof evidence packages (policies, service maps, outsourcing registers, test results, incident documentation, remediation evidence).

DORA makes ICT resilience and third-party risk an integral part of the business model – and the new rules for critical ICT third-party service providers ensure that requirements have an impact on architecture decisions, contracts and exit strategies. Anyone who analyzes and manages their ICT supply chain in a structured manner today not only reduces supervisory and reputational risks, but also gains real robustness for the next generation of digital financial services.