DORA: The Complete Guide to Third-Party Supplier Risk

‍Key Takeaways

The Digital Operational Resilience Act (DORA) is a comprehensive EU regulation designed to strengthen the financial sector's resilience against ICT-related disruptions and threats. It has applied directly across all EU member states since 17 January 2025, with no national transposition and no room for local dilution.
DORA consolidates and upgrades ICT risk requirements across the financial sector, replacing a fragmented, sector-specific approach to operational risk with a single, unified cross-sector framework.
Its core objectives are to strengthen ICT risk management, mandate rigorous testing, increase supervisory awareness of cyber risk, introduce oversight powers over ICT third-party dependency, harmonise incident reporting, and identify and mitigate concentration and systemic risk across the sector.
On 18 November 2025, EU supervisors designated 19 Critical ICT Third-Party Providers (CTPPs) for direct oversight, built from the Register of Information data financial entities were required to submit, confirming just how concentrated the sector's ICT dependencies really are.
The first EU-wide DORA incident report (June 2026) found that 29% of major ICT incidents in 2025 originated from third-party providers, with regulators explicitly naming third-party dependency, including from providers not formally designated as critical, as an ongoing area of supervisory attention.
The Register of Information remains the requirement financial entities find hardest to meet, ahead of incident reporting and resilience testing, largely because ICT contract data sits scattered across procurement systems, business units and subsidiaries.
DORA sits inside a broader global shift toward operational resilience, alongside the UK's operational resilience and critical third-party regimes, the UK's Cyber Security and Resilience Bill, and the EU's NIS2 directive, all of which push firms and regulators toward mapping dependencies rather than assessing suppliers in isolation.

What Is DORA?

The Digital Operational Resilience Act (DORA) is a comprehensive regulation introduced by the European Union to strengthen the financial sector's resilience against ICT-related disruptions and threats. Formally Regulation (EU) 2022/2554, it has applied directly across every EU member state since 17 January 2025, and because it is a Regulation rather than a Directive, it took effect without national transposition, leaving no room for individual member states to soften or delay its requirements.

DORA aims to consolidate and upgrade ICT risk requirements throughout the financial sector, ensuring that all participants in the financial system are subject to a common set of standards to mitigate ICT risks to their operations. It forms part of the European Commission's Digital Finance Package, and represents a significant shift in how financial institutions approach operational resilience and cybersecurity, moving from a fragmented, sector-specific approach to a unified, cross-sector framework.

That shift matters most in one specific area: how financial entities manage their dependency on ICT third parties. DORA was built to enhance ICT risk management, establish thorough testing of ICT systems, increase supervisory awareness of cyber risk, and create a consistent incident reporting mechanism. But it was also built, explicitly, to introduce powers for financial supervisors to oversee risks stemming from financial entities' dependency on ICT third-party service providers, to ensure sound monitoring of ICT third-party risk, and to identify and mitigate concentration and systemic risks to financial entities and the sector as a whole. Since the regulation came into force, that third-party and concentration risk dimension has moved from stated intent to measurable reality: EU supervisors have used financial entities' own contract data to identify the ICT providers whose failure would pose the greatest systemic threat to the sector, and the first sector-wide incident data confirms that third-party dependency is where DORA's risks are actually materialising.
‍

Key Dates and Implementation Timeline

From Publication to Application (2022–2025)

27 December 2022 — DORA published in the Official Journal of the European Union as Regulation (EU) 2022/2554.
16 January 2023 — DORA entered into force.
29 September 2023 — European Supervisory Authorities' first-batch technical standards submitted to the EU Commission.
17 January 2025 — Implementation deadline. DORA applies in full from this date.
‍

What Has Happened Since 17 January 2025

2025 functioned as a transition and readiness year, during which supervisors reviewed firms' frameworks and identified gaps. 2026 marks the shift to active enforcement. Key milestones since the application date include the finalisation of the remaining Regulatory and Implementing Technical Standards, the first Register of Information submissions (reference date 31 March 2025, transmitted to the ESAs by 30 April 2025), the ESAs' July 2025 guide on oversight activities, the designation of the first Critical ICT Third-Party Providers on 18 November 2025, and the publication of the first EU-wide DORA incident report on 3 June 2026. Each of these is covered in detail in the relevant section below.

Who Does DORA Apply To?

Financial Entities in Scope

DORA's scope encompasses a wide range of entities across the financial services sector, commonly grouped into seven categories:

Banking sector: credit institutions, payment institutions, electronic money institutions.
Investment sector: investment firms, UCITS management companies, alternative investment fund managers.
Insurance sector: insurance and reinsurance undertakings, insurance intermediaries.
Market infrastructure: central securities depositories, trading venues, trade repositories.
Digital finance: crypto-asset service providers, crowdfunding service providers.
Other financial entities: credit rating agencies, audit firms.
ICT third parties: critical ICT third-party service providers, including cloud, software and data analytics providers.

Estimates put the total number of in-scope entities at over 22,000 across the EU.

The Proportionality Principle

DORA has a proportionality principle: requirements depend on the size of the entity, its nature, and its risk profile. Smaller and less complex organisations face fewer requirements, and a simplified ICT risk management framework is available to microenterprises.

ICT Third-Party Providers and Critical ICT Third-Party Providers

DORA's reach extends beyond financial entities to encompass ICT third-party service providers supporting critical or important functions. This inclusion recognises these providers' critical role in the financial sector's operational resilience and represents a significant expansion of regulatory oversight into the technology providers servicing the financial industry. A subset of these providers, deemed systemically important, are designated Critical ICT Third-Party Providers (CTPPs) and become subject to direct EU oversight, covered in full later in this guide. Intra-group ICT service providers are generally treated as a subcategory of ICT third-party service providers under the technical standards, though certain intra-group and single-member-state providers can be exempt from CTPP designation specifically.

Which Non-EU and UK Organisations Fall Under DORA

DORA's impact extends beyond EU borders. Critical ICT service providers based outside the EU must, in certain circumstances, establish a subsidiary within the EU for oversight purposes, a requirement with significant operational and strategic implications for global organisations. Despite Brexit, UK financial institutions and ICT service providers considered critical and offering services in the EU, directly or indirectly, must comply with DORA for their EU operations.

Organisations without offices in the EU that may fall under DORA's remit include:

A third-country Alternative Investment Fund Manager (AIFM) managing or marketing funds in the EU.
A non-EU investment firm providing investment services or performing investment activities through a branch established in the EU.
A third-country financial entity operating in the EU, even without a physical presence, if it falls under one of the categories covered by DORA.
A non-EU based payment institution or electronic money institution offering services in the EU.
A third-country crypto-asset service provider authorised under MiCA to operate in the EU.
A non-EU based crowdfunding service provider authorised to operate in the EU.
A third-country firm acting as a delegate for an EU-based financial entity subject to DORA, where indirect compliance may be required.
A non-EU parent company of an EU financial services firm providing ICT services to its EU subsidiary.
A third-country ICT service provider designated as critical by the ESAs for its services to in-scope EU financial entities.
A non-EU financial entity belonging to a group where other entities are subject to DORA, potentially requiring group-wide compliance measures.

The exact scope for third-country entities can vary depending on the specific EU sectoral laws for each type of financial entity, and in some cases further regulatory guidance may still be needed.

The Five Pillars of DORA

DORA at a glance

The Five Pillars of DORA at a Glance

Pillar Core requirement

ICT Risk Management and Governance Board-level accountability for a documented, regularly reviewed ICT risk framework, covering legacy systems and third-party dependencies

ICT-Related Incident Reporting Major incidents reported within 4 hours (initial notification), 72 hours (intermediate report), and 1 month (final report)

Digital Operational Resilience Testing Regular resilience testing for all firms; Threat-Led Penetration Testing (TLPT) every 3 years for entities designated as significant

ICT Third-Party Risk Management Register of Information, enhanced contracts for critical functions, concentration risk assessment, and tested exit strategies

Information Sharing Voluntary participation in trusted communities to exchange cyber threat intelligence and best practices

‍

ICT Risk Management and Governance

DORA mandates that financial entities establish and maintain a robust, comprehensive and well-documented ICT risk management framework, reviewed and updated regularly to adapt to evolving threats, with clear roles and responsibilities defined within the organisation. Boards and senior management are directly accountable for defining, approving and overseeing this framework — board-level accountability is one of the most consequential shifts DORA introduces, since ICT risk management is no longer purely an IT issue but a boardroom one. Entities must also address risks related to legacy ICT systems. For third-party risk specifically, this means extending risk management strategies to all ICT providers and including them in overall risk assessments, with Critical ICT Third-Party Providers subject to additional oversight.

ICT-Related Incident Reporting

Financial entities must establish a process to monitor, log and classify ICT-related incidents against criteria covering client impact, downtime, geographic spread, data loss and economic impact. Major incidents follow a strict three-stage reporting cascade: an initial notification within four hours of classifying an incident as major, and no later than 24 hours from first becoming aware of it; an intermediate report within 72 hours; and a final report within one month. This four-hour trigger is stricter than the reporting deadlines under both NIS2 and GDPR. Entities must also inform affected clients and counterparts. For third-party risk, this means setting up clear incident reporting procedures with providers, being able to quickly assess the impact of third-party incidents on critical services, and maintaining a full, readily accessible register of suppliers and their security controls to give context when an incident occurs.

Digital Operational Resilience Testing

All financial entities must run a comprehensive digital operational resilience testing programme, covering vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, and source code reviews where feasible, alongside penetration tests and operational continuity and disaster recovery tests. For entities designated as significant, DORA introduces Threat-Led Penetration Testing (TLPT), conducted at least once every three years on live production systems, using an independent threat-intelligence provider and red team, and aligned to the EU's TIBER-EU framework. From a third-party perspective, some critical providers must be included in resilience testing programmes, which can require negotiating rights to test third-party systems and coordinating penetration testing with key service providers.

ICT Third-Party Risk Management

DORA places significant emphasis on ICT third-party risk management, requiring a comprehensive strategy integrated with the overall business strategy, a detailed Register of Information covering all ICT contracts, rigorous due diligence and continuous monitoring of providers, and enhanced contractual requirements for arrangements supporting critical or important functions. Because this pillar carries the heaviest practical burden and the most direct relevance to supply chain visibility, it is covered in full in its own dedicated section below.

Information Sharing

DORA encourages financial entities to strengthen collective resilience through collaboration, suggesting participation in trusted communities for the secure exchange of cyber threat intelligence and best practices, provided appropriate protections are in place and participation is reported to competent authorities. Among established information-sharing networks for the sector, FS-ISAC is notable for collaborative threat intelligence. For third-party risk, this must ideally also evolve into establishing protocols for sharing supply chain intelligence with peers.
‍

ICT Third-Party Risk Management Requirements Under DORA

Of DORA's five pillars, ICT third-party risk management is the one most directly concerned with supply chain visibility, and it carries the heaviest compliance burden in practice.

The Register of Information

Every in-scope entity must maintain a structured, continuously updated Register of Information (RoI) covering all contractual arrangements with ICT third-party providers, distinguishing arrangements that support critical or important functions, and submit it annually to its national competent authority, which forwards it to the ESAs. Given the comprehensive nature of the RoI, it typically needs to be compiled from multiple sources: contract lifecycle and supplier management systems, third-party risk management registers, and, in many cases, unstructured data drawn from contracts and open-source information.

The RoI serves three purposes: an internal monitoring tool for the entity itself; a supervisory tool for competent authorities; and, critically, the data source the ESAs use to designate Critical ICT Third-Party Providers. This last point is the clearest statement of regulatory intent in the whole regulation: regulators want a machine-readable, sector-wide map of who depends on whom, and they built exactly that from the RoI data submitted across the sector.

Independent research has consistently found the RoI to be the single hardest DORA requirement to meet in practice, ahead of incident reporting and resilience testing, largely because contract data is scattered across procurement systems, business units and subsidiaries and rarely held in one consistent format.

Mandatory Contractual Arrangements for Critical or Important Functions

All ICT contracts must include baseline provisions: a clear service description, data-processing locations, security requirements, incident-assistance obligations, cooperation with authorities, and termination rights. Financial institutions "may only enter into contractual arrangements with ICT third-party service providers that comply with appropriate information security standards" and must "take due consideration of the use, by ICT third-party service providers, of the most up-to-date and highest quality information security standards."

For contracts supporting critical or important functions specifically, DORA adds a heavier stack of requirements, organised around four areas:

Service definition and performance monitoring: a detailed description of all services, clearly delineated responsibilities, specific and measurable performance metrics, and mechanisms for continuous monitoring, enforcement, and regular performance reviews.
Data governance and security: identification of all data-processing locations, comprehensive data protection measures, and detailed security protocols for confidentiality, integrity and availability, including breach notification procedures.
Audit and regulatory compliance: unrestricted audit rights for the financial entity and access rights for regulatory authorities, an obligation on the provider to maintain detailed logs and assist in regulatory investigations, and provisions for joint audits and penetration testing. Microenterprises may delegate these audit rights to an independent third party.
Exit strategy and operational continuity: defined termination rights, a detailed exit plan ensuring smooth service transition, data portability provisions, rules on subcontracting, and an obligation on the provider to assist with migration.

Due Diligence and Ongoing Monitoring of ICT Providers

Before entering into any contractual agreement, entities must conduct comprehensive risk assessments and due diligence on prospective ICT third-party providers. This is not a one-off exercise: DORA mandates continuous monitoring of ICT third-party providers to ensure ongoing compliance and risk management, particularly for providers supporting critical or important functions. Entities must establish an appropriate oversight framework to continuously monitor and review providers' security controls and wider performance, including evaluating whether a provider can ensure the availability, authenticity, integrity and confidentiality of data, whether personal, sensitive, or non-personal.

Exit Strategies and Contract Termination

DORA requires financial entities to develop comprehensive, documented, and sufficiently tested exit strategies, especially for arrangements supporting critical or important functions. Commission Delegated Regulation (EU) 2024/1773 requires this exit plan to be periodically reviewed and tested for each relevant arrangement, not simply written and filed. The primary purpose is to prepare for potential contract terminations, which may be necessary following significant breaches of laws, regulations or contractual terms by the provider, or where continuous monitoring reveals evidenced weaknesses in the provider's ICT risk management practices.
‍

Critical ICT Third-Party Providers (CTPPs) and Direct EU Oversight

The CTPP Designation Criteria and Lead Overseer Framework

DORA introduces the category of "critical ICT third-party service providers" (CTPPs): providers essential to the financial sector, including cloud platforms, data analytics providers, and other key ICT services crucial to financial entities' operations. The ESAs designate these providers using criteria covering systemic impact, interdependencies, substitutability, technical complexity and integration, cross-border footprint, and the potential systemic impact of failure. Certain providers are exempt from designation, including intra-group providers, providers operating in a single member state, and those already overseen under Article 127 of the Treaty on the Functioning of the EU.

Each designated CTPP is assigned a Lead Overseer, one of the ESAs, with powers to request information, conduct general investigations and on-site inspections, and issue binding recommendations on ICT security, contractual terms and planned subcontracting. Non-compliance with these recommendations can be enforced through periodic penalty payments of up to 1% of the provider's average daily worldwide turnover, per day, for up to six months. Designation does not shift responsibility away from financial entities, who remain fully accountable for their entire ICT supply chain regardless of which providers within it are directly overseen.

The Officially Designated CTPPs

On 18 November 2025, the ESAs designated the first 19 Critical ICT Third-Party Providers, built directly from the Register of Information data submitted across the sector.
‍

Designated 18 November 2025

The 19 Officially Designated CTPPs, by Category

Category Designated providers

Hyperscale Cloud Amazon Web Services EMEA Sàrl, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited, Oracle Nederland B.V.

Data Centre & Colocation Equinix (EMEA) B.V., InterXion HeadQuarters B.V.

IT Services & Integration Accenture plc, Capgemini SE, International Business Machines Corporation, Kyndryl Inc., NTT DATA Inc., Tata Consultancy Services Limited

Telecoms & Network Deutsche Telekom AG, Colt Technology Services, Orange SA

Financial Data & Software Bloomberg L.P., Fidelity National Information Services, Inc., LSEG Data and Risk Limited, SAP SE

‍

The list spans hyperscale cloud providers (AWS, Google Cloud, Microsoft, Oracle), data centre and colocation providers (Equinix, InterXion), IT services and integrators (Accenture, Capgemini, IBM, Kyndryl, NTT DATA, TCS), telecoms and network infrastructure (Deutsche Telekom, Colt, Orange), and financial data and software providers (Bloomberg, FIS, LSEG Data and Risk, SAP). The list is reviewed and updated annually. A note of caution: several vendor blog posts and secondary sources have circulated inaccurate versions of this list since designation; the list above is drawn directly from the official ESA/EIOPA designation document.
‍

Concentration Risk and Nth-Party / Subcontracting Risk

DORA also emphasises reducing concentration risk in financial services supply chains, and requires entities to identify and assess all relevant risks in relation to their contractual arrangements with ICT service providers, including with key subcontractors that support critical functions. Firms are explicitly instructed to ensure that their practices do not contribute to reinforcing ICT concentration risk across the sector.

Non-Substitutable Providers and Multiple Critical Arrangements

Two specific concentration scenarios sit at the centre of DORA's third-party risk requirements: reliance on ICT providers that cannot easily be replaced, and having multiple critical or important functions dependent on the same provider, or on closely connected providers. Before contracting and on an ongoing basis, firms must assess whether an arrangement creates or increases this kind of concentration risk.

The scale of this risk in practice is significant. European Central Bank analysis of significant banks' outsourcing registers found that more than 30% of total outsourcing spend is concentrated in just ten providers, and that for contracts supporting critical functions specifically, half of all spend goes to only 30 external providers. Separate commentary has put the three major hyperscale cloud providers at an estimated 65-70% share of European financial-sector cloud workloads, though this figure should be treated as an estimate rather than an official statistic.

Subcontracting Chains and Fourth-Party Risk

DORA does not stop regulatory interest at a firm's direct, first-tier suppliers. Entities are expected to understand and monitor the subcontracting chain, sometimes described as the subcontracting "tree", that sits behind any ICT service supporting a critical or important function, not just the immediate contract. This reflects DORA's underlying concern with systemic risk and fourth-party risk: current inadequacies in understanding and mitigating risk arising from subcontractors and other parties further down the chain, and the potential for systemic risk to the sector as a whole where many financial entities share the same underlying providers, even at the fourth- or fifth-party level.

An earlier draft of the technical standards on subcontracting would have required financial entities to identify and continuously monitor every individual link in that chain. Industry bodies objected that whole-chain monitoring without a materiality threshold was disproportionate, and the European Commission rejected the draft in January 2025 on exactly those grounds. The final Subcontracting RTS, in force from July 2025, removed the requirement for mechanical link-by-link monitoring. The underlying obligation was not removed, however: firms must still have ongoing knowledge of how the overall subcontracting chain functions in support of a critical or important function, and must reflect meaningful subcontracting relationships in their Register of Information. In practice, this leaves firms owning an outcome, understanding the full dependency chain behind their critical functions, without being told exactly how to achieve it at scale.

Fourth-party and nth-party risk is a large enough topic in its own right that it merits its own dedicated treatment; see our guide to fourth-party vendor risk management for how to identify, assess and monitor dependencies beyond your direct suppliers.
‍

Regulatory Technical Standards Under DORA

Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) translate DORA's principles into specific, actionable requirements, ensuring consistent application across the EU financial sector. The key instruments, now finalised and adopted, are:

RTS on the ICT risk management framework: harmonises ICT risk management across financial sectors and specifies the elements of a simplified framework for smaller entities.
RTS on the classification of ICT-related incidents (Commission Delegated Regulation (EU) 2024/1772): defines the criteria and thresholds for determining when an incident is major, and therefore reportable.
ITS establishing the Register of Information templates: sets out the standardised RoI format financial entities must use to report their ICT third-party arrangements to the ESAs, and the procedures for submission and assessment.
RTS on the policy for ICT services supporting critical or important functions: specifies risk assessment, documentation and monitoring requirements, and the criteria for assessing criticality, along with requirements for service level agreements, termination rights and exit strategies.
RTS and ITS on incident and cyber threat reporting (Delegated Regulation (EU) 2025/301 and ITS 2025/302): establishes content, timelines, procedures and standardised templates for reporting major incidents and significant cyber threats, including proportionate provisions for weekend and aggregated reporting.
RTS on the harmonisation of oversight conditions: specifies the information providers must submit when requesting voluntary critical designation, and the content and format of information CTPPs must submit to their Lead Overseer, including a subcontracting-arrangements template.
RTS on the composition of the Joint Examination Team (JET): establishes criteria for balanced ESA and competent-authority participation in oversight teams and their working arrangements.
RTS on Threat-Led Penetration Testing (Commission Delegated Regulation (EU) 2025/1190, applicable from 8 July 2025): specifies criteria for identifying in-scope entities, standards for internal testers and testing methodology, and cross-border supervisory cooperation for TLPT.
RTS on subcontracting (Commission Delegated Regulation (EU) 2025/532, in force 22 July 2025): the final version, adopted after the Commission rejected the ESAs' original full-chain monitoring draft as disproportionate, covered in detail above.
‍

DORA in Practice: Enforcement and Compliance Since 2025

The First EU-Wide DORA Incident Report

The ESAs' first annual DORA incident report (Joint Committee report JC 2026 16, published 3 June 2026) recorded 3,383 major ICT-related incidents across the EU financial sector in 2025, roughly 282 per month. Around two-thirds caused no or only minor disruption to clients, credited to effective detection and containment. Critically, 29% of major incidents originated from ICT third-party providers. A third of major incidents had cross-border impact, and in around 8% of all major incidents, more than ten countries were affected. By cause, system failures accounted for 51% of incidents, external events 27%, and payment-related issues 18%; only around 10% were cybersecurity-related. More than 60% of incidents affected credit institutions.

The ESAs stated explicitly that dependencies on third-party providers, including those not designated as critical, constitute an area of supervisory attention, and that firms must strengthen their third-party risk management frameworks. The report also flagged a "multiplier effect", where a single shared provider's failure generates simultaneous incident reports across many institutions at once, direct evidence of the concentration and systemic risk dynamics DORA was designed to surface.

DORA Compliance Readiness — Where Firms Are Still Behind

Independent readiness surveys paint a consistent picture of where compliance is lagging. One widely cited survey found only around half of firms expected full compliance by the end of 2025, with the remainder targeting 2026; 46% named the Register of Information as the single hardest requirement to meet, ahead of third-party due diligence and risk assessment; and only around 8% of firms reported full compliance with both the resilience testing and third-party risk management pillars specifically, the two most operationally demanding areas of the regulation. Earlier readiness analysis, conducted ahead of the January 2025 deadline, found only around a third of major European financial institutions confident they could meet all requirements in time, with around 70% expecting permanently higher ongoing technology-control costs as a result.

Penalties for Non-Compliance

Board members and senior management are now personally accountable for DORA compliance, a shift that makes ICT risk management a boardroom concern rather than purely an IT one. Non-compliance can result in severe financial penalties for financial entities, for ICT third parties, and for individuals and board members. The exact fines and penalties for financial entities are determined by each individual EU member state, commonly cited at up to 2% of total annual worldwide turnover for firms and up to €1,000,000 for individuals, so the precise figures are jurisdiction-dependent. Critical ICT Third-Party Providers face a harmonised EU-level penalty regime: the Lead Overseer can impose administrative penalty payments of up to 1% of the provider's average daily worldwide turnover in the preceding business year, applied per day of continued non-compliance for up to six months.
‍

DORA and the Broader Shift Toward Operational Resilience

The UK's Operational Resilience Regime and Critical Third Parties

While DORA is not currently law in the UK, it will likely apply to UK entities offering services into the EU, and it sits alongside a UK regime that developed on a similar timeline and around similar international principles rather than following from DORA. The UK's own operational resilience regime (PRA SS1/21, FCA PS21/3) was actually finalised earlier, with final rules published in March 2021 and in force from 31 March 2022, with the transition period ending 31 March 2025, roughly two years ahead of DORA's own application date. Both regimes reflect the same broader international shift, most notably the Basel Committee's Principles for Operational Resilience published in March 2021, requiring firms to identify important business services, set impact tolerances for maximum acceptable disruption, map the people, processes, technology and third parties supporting each service, and scenario-test their ability to stay within tolerance under severe but plausible scenarios.

The UK is running a parallel, separate designation regime for systemic third parties: the Critical Third Parties (CTP) regime, created under the Financial Services and Markets Act 2023. Unlike DORA, where the ESAs themselves designate CTPPs, in the UK it is HM Treasury that holds the formal power to designate a provider as critical, typically acting on a joint recommendation from the Bank of England, PRA and FCA, who then jointly oversee the provider's systemic services once designated. The regime only went live with its first designations on 13 July 2026, naming four providers, Amazon Web Services, Google Cloud, Microsoft Ireland Operations, and Oracle, three of which also appear on DORA's own CTPP list. Structurally, the UK's CTP regime sits as a standalone regime bolted onto the broader operational resilience framework, rather than being built into it from the outset the way DORA's oversight powers are woven directly into the same regulation as the third-party risk management pillar.

NIS2 and the UK Cyber Security and Resilience Bill

The EU's NIS2 directive covers a much broader set of essential and important entities across critical sectors, with supply-chain and third-party risk at its core; where a financial entity is also in scope of NIS2, DORA takes precedence as the more specific regulation. In the UK, the Cyber Security and Resilience (Network and Information Systems) Bill, introduced to Parliament on 12 November 2025, is progressing through the House of Lords as of mid-2026 following its passage through the Commons, with Royal Assent expected later in 2026 and phased implementation likely running into 2028. The Bill substantially expands the UK's existing NIS Regulations 2018, bringing managed service providers, data centres and "designated critical suppliers" directly into a statutory regime for the first time, with a two-tier penalty structure and a 24-hour/72-hour incident reporting clock that closely mirrors DORA's own cascade. Alongside the Bill, the UK government replaced its previous Government Cyber Security Strategy with the Government Cyber Action Plan, published 6 January 2026 and backed by £210 million in central investment through a newly formed Government Cyber Unit, reflecting the same shift toward supplier accountability and systemic resilience across public sector digital services.

Mapping the Extended Ecosystem: A Regulatory Trend Beyond Compliance

DORA's five pillars and its third-party requirements are the bedrock obligations individual firms need to meet. But underneath that, a broader and more ambitious regulatory ambition is emerging: mapping the extended sectoral ecosystem of dependencies, not just verifying individual firm compliance. This pattern is visible across DORA, the UK's Operational Resilience and Critical Third Party regimes, NIS2, and the UK's Cyber Security and Resilience Bill and Government Cyber Action Plan alike. In each case, regulators are gathering granular supplier data, including service level agreements and subcontracting information, with the explicit aim of mapping the wider supply chain ecosystem of the sector as a whole, in order to identify single points of failure and concentration risks that no individual firm could ever see by looking only at its own direct suppliers.
‍

Key distinction

Concentration Risk vs. Systemic Risk Under DORA

Risk type Definition

Concentration Risk Multiple of a single firm's critical or important functions rely on the same ICT provider, or on closely connected providers, or when multiple critical third parties of an individual firm all rely on the same 4th party. Visible to the firm itself, if it looks.

Systemic Risk Multiple firms across the sector rely on the same third-, fourth-, or nth-party provider. Invisible to any single firm, since no firm can see its peers' supply chains.

‍

It is worth being precise about two related but distinct concepts here. Concentration risk occurs when multiple of a single firm's critical or important functions all rely on the same downstream provider or when multiple critical third parties of an individual firm all rely on the same 4th party. Systemic risk occurs when multiple firms across the same industry all rely on the same third-, fourth- or nth-party provider, a dependency that is, by definition, invisible to any one firm working in isolation, since a bank has no visibility into its competitors' supply chains and often only limited visibility into its own deeper nth-party dependencies.

This is not a hypothetical concern. A recent industry pilot involving six UK financial institutions overlaid their supply chain data in a shared analysis and mapped nearly 877 additional nth-party dependencies beyond their initial direct-supplier lists, surfacing 47 systemic concentration risks invisible to any single participant. Nine third-party suppliers were found to be connected to at least half of the participating institutions, and three smaller, previously unnoticed suppliers nested deep in the supply chain were found to carry outsized criticality, such that a disruption to any one of them could have triggered a simultaneous, multi-institution crisis.

The implication for individual firms is straightforward: achieving DORA compliance at the level of your own Register of Information and contractual arrangements is necessary, but it is not, on its own, sufficient to see the concentration and systemic risks that regulators are ultimately trying to surface across the sector. Closing that gap requires visibility that extends into the fourth-, fifth- and nth-party layers of the supply chain, and, increasingly, collaboration with peer institutions to see the risks that no single firm's own data can reveal.
‍

How to Strengthen DORA Compliance

Given how consistently readiness data shows firms lagging on the Register of Information and third-party risk management specifically, closing that gap in a durable way means treating third-party risk management as an ongoing visibility exercise, not a point-in-time compliance exercise. In practice, that means:

Maintaining a single, continuously current view of every ICT third-party contract, rather than reconstructing the Register of Information from scratch each reporting cycle.
Identifying which suppliers support critical or important functions, and assessing concentration risk across them on an ongoing basis, not only at the point of contracting.
Building visibility into the subcontracting chain behind critical functions, so that nth-party and shared-supplier dependencies are known before an incident forces them into view.
Testing exit strategies for critical arrangements, rather than only documenting them on paper.
Treating third-party risk data as something that needs to be shared and kept consistent across the organisation, rather than owned by a single team in a spreadsheet.

For a detailed, step-by-step walkthrough of these actions, see our DORA Compliance Checklist.
‍

Frequently Asked Questions

What is the Digital Operational Resilience Act (DORA)?

DORA is EU Regulation (EU) 2022/2554, which sets binding requirements for how financial entities and their ICT providers manage, test, report on and recover from ICT-related disruption. It has applied directly across the EU since 17 January 2025.

Who does DORA apply to?

DORA applies to over 22,000 EU financial entities across roughly 21 categories, including banks, payment institutions, insurers, investment firms and crypto-asset service providers, as well as the ICT third-party providers that serve them.

What are the five pillars of DORA?

ICT risk management and governance, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing.

What is a Critical ICT Third-Party Provider (CTPP) under DORA?

A CTPP is an ICT provider designated by the European Supervisory Authorities as systemically important to the EU financial sector. On 18 November 2025, 19 providers were designated, spanning cloud, data centre, IT services, telecoms and financial data providers, and are now subject to direct EU oversight.

What is the difference between concentration risk and systemic risk under DORA?

Concentration risk occurs when multiple of a single firm's critical or important functions rely on the same ICT provider or closely connected providers. Systemic risk occurs when multiple firms across the sector rely on the same third-, fourth-, or nth-party provider, creating a shared point of failure that no single firm can see on its own.

What are the penalties for non-compliance with DORA?

Financial entities face sanctions set by their national regulator, commonly cited at up to 2% of total annual worldwide turnover for firms and up to €1,000,000 for individuals, varying by member state. Critical ICT Third-Party Providers face a harmonised EU-level penalty of up to 1% of average daily worldwide turnover per day of continued non-compliance, for up to six months.

‍

DORA's five pillars set the compliance floor, but the sector's actual trajectory, visible in the CTPP designations, the first incident report, and the parallel UK and EU regimes covered above, is toward far greater visibility into who depends on whom. Firms that treat their Register of Information and third-party contracts as a one-off compliance exercise will keep re-doing that work every reporting cycle. Firms that build lasting visibility into their supply chain, down to the nth-party dependencies that regulators are now actively mapping, will find each future cycle, and each future regulation built on the same logic, considerably easier to meet.

‍