The DORA Supply Chain Effect on Operational Resilience

DORA’s influence extends beyond Europe and reshapes how U.S. organizations approach technology supply chain and operational resilience.

U.S. technology providers do not need to fall directly under the European Union’s (EU’s) Digital Operational Resilience Act (DORA), but European financial services organizations can extend DORA-driven expectations through their technology supply chains and customer relationships. By mapping critical technology dependencies, identifying concentration and downstream risks, reviewing contractual protections, and testing recovery plans, organizations can better support DORA compliance and strengthen their own operational resilience.

Regulatory obligations extend through the supply chain

DORA took effect on Jan. 17, 2025. It established requirements designed to strengthen digital operational resilience across the EU financial sector, and it centers on five areas: information and communication (ICT) risk management, ICT-related incident management and reporting, digital operational resilience testing, information sharing, and ICT third-party risk management. While these requirements apply primarily to regulated financial entities in the EU, their effects extend into the technology supply chains that support those organizations.

DORA’s reach goes beyond the EU financial entities directly subject to the regulation, meaning that a U.S. technology provider does not need to be a regulated EU financial entity for DORA to affect its customer relationships. European financial services organizations are responsible for managing their ICT third-party risk, including risks associated with technology providers that support critical or important functions. As a result, U.S. providers serving these organizations should expect greater scrutiny of resilience, subcontractors, incident response, auditability, service continuity, and contractual requirements.

Direct applicability represents only one consideration for U.S. organizations. U.S. providers also need to understand what their European customers must demonstrate about the technology supply chains on which they depend. Those customer obligations extend expectations through the technology supply chain and create a DORA supply chain effect.

DORA travels through customer relationships

Consider a U.S.-based software-as-a-service (SaaS) provider that supports an important process for a European bank. The U.S. company might host data and operate primarily in the U.S. while relying on cloud platforms or other subcontractors to deliver its service. Because the bank depends on the SaaS provider for an important process, the bank still needs to understand the resilience of the service and the technology dependencies that support it.

DORA requires financial entities to address specific provisions in contractual arrangements with ICT third-party service providers, including areas related to service descriptions, data locations, incident assistance, business continuity, audit and inspection rights, subcontracting, and termination. Requirements become more detailed when an ICT service supports a critical or important function, and those requirements can eventually reach the U.S. provider through the customer relationship.

U.S. technology providers should prepare for these requirements before customers request evidence of compliance. Providers can review where data is processed, identify subcontractors supporting critical services, document incident notification and recovery processes, and assess whether existing contracts address internal audit and termination rights. Taking these steps in advance can help providers respond efficiently to customer questionnaires and contract reviews rather than identify gaps during a procurement or renewal process. Even when DORA does not directly apply to a U.S. provider, its requirements can affect the provider’s customer relationships and commercial obligations.

Organizations do not need to fall directly within DORA’s primary scope for the regulation to affect how they conduct business. European financial services organizations remain responsible for meeting their DORA obligations when they rely on third-party ICT providers. They cannot transfer those regulatory obligations to a downstream provider. Instead, they must manage the risks associated with those providers and establish contractual requirements that support their own compliance.

For U.S. technology providers serving European financial services organizations, DORA’s third-party requirements can extend beyond the legal or compliance team. Security, technology, procurement, business continuity, and risk teams all have a role in providing the information, controls, and contractual support their customers require.

Third parties might only be the beginning

Third-party risk programs traditionally focus on an organization’s direct vendor relationships. Organizations evaluate vendors, review security controls, collect documentation, assign risk ratings, and monitor higher-risk providers. The challenge is that modern technology rarely stops at one provider.

Consider that same U.S. software company serving a European financial services organization. The software provider runs its application on a cloud platform. The application uses another company for identity services and a separate provider for data processing. One of those providers depends on another infrastructure service. The financial services organization has a relationship with one vendor, but its critical business process might depend on several organizations it never contracted with directly.

DORA places significant emphasis on this problem. EU rules addressing the subcontracting of ICT services that support critical or important functions took effect in 2025 and call for financial entities to consider factors such as the length and complexity of subcontracting chains, the locations where services and data reside, concentration among subcontractors, service transferability, and the potential effects of disruption. The focus on subcontracting also highlights the need for organizations to understand the technology underpinning their critical services and the downstream dependencies that could create operational risk.

Strong controls at the vendor level do not necessarily account for operational risks introduced by downstream providers. A cloud application, for example, might pass a security review but depend on a single region or infrastructure provider. Organizations also might have multiple technology vendors that appear unrelated in a vendor inventory but rely on the same underlying service, which creates dependencies that a traditional third-party assessment might not reveal.

Understanding fourth-party and downstream dependencies does not mean organizations need to investigate every supplier used by every vendor. Such an extensive review would quickly become impractical. Instead, organizations can focus on downstream relationships capable of materially affecting critical business services. A more targeted approach expands the focus beyond vendor security to examine the dependencies supporting critical services and the operational impact if one becomes unavailable.

A secure vendor still carries concentration risk

DORA addresses weaknesses in traditional vendor risk management by looking beyond the risks posed by individual providers to consider collective exposure across an organization’s technology environment. Traditional assessments often evaluate vendors one at a time, examining access controls, vulnerability management, incident response processes, and relevant security certifications. Such assessments are important, but a vendor-by-vendor approach might not reveal when multiple critical services rely on the same underlying technology.

If an organization uses 100 technology vendors, those vendors individually might meet the organization’s security requirements. However, 25 of them could depend on the same cloud provider, and several could rely on the same identity platform. Others might host critical workloads within the same geographic region. Such shared dependencies create concentration risk because a disruption at one provider could affect multiple services simultaneously. The DORA supply chain effect extends across vendor relationships when otherwise separate services depend on the same underlying technology.

DORA incorporates ICT concentration risk into its third-party risk framework and requires financial entities to consider dependencies on individual or interconnected providers that could be difficult to replace or recover from. In November 2025, the European Supervisory Authorities brought those dependencies into sharper focus by publishing the first list of critical ICT third-party providers under DORA. The list included major global technology companies that support services across the European financial sector.

This designation process shows how regulators are assessing technology dependencies across the financial system. The European Supervisory Authorities drew from financial entities’ registers of information, which document contractual arrangements involving ICT services, to identify broader patterns of dependency. U.S. organizations can apply a similar approach internally to identify concentrations and shared dependencies across their own technology environments.

A resilience map reveals vendor dependencies

Most mature organizations already know who their vendors are, but it can be difficult to know how those vendors connect to critical business services. A typical vendor inventory might contain the provider name, business owner, contract information, risk classification, data classification, and assessment status. That information supports governance and third-party risk management, but it does not always explain what happens to the business when a provider fails. A clearer view of those connections can help organizations identify where the DORA supply chain effect creates dependencies across critical services.

A resilience map takes a different approach by starting with the critical business service rather than the vendor. Organizations can identify the technology and external providers that support the service, trace material subcontractors and shared infrastructure, and assess how quickly operations could recover if a provider became unavailable. Mapping those relationships reveals dependencies and risks that a conventional vendor inventory might not capture.

For example, a financial services organization might rely on a third-party identity provider to authenticate employees accessing several critical applications. A vendor inventory identifies the identity provider and each application as separate entries, but it might not show that employees cannot access those applications when the identity service becomes unavailable. Mapping the business service and its supporting technologies reveals the dependency as well as the potential for one disruption to affect multiple critical operations.

Such visibility changes how organizations can test resilience. Rather than testing each application independently, teams can simulate the loss of the identity service and determine which business processes become unavailable, whether alternative access methods work, and how long critical operations can continue.

Mapping those relationships also makes resilience testing more realistic. Instead of testing whether a single application can recover, teams can simulate the loss of an underlying provider and determine which business processes fail with it. The results can help security and risk leaders identify where redundancy is real and where it exists only on paper.

Contracts should become part of the incident response plan

Technology dependencies are only one part of operational resilience, and DORA also highlights the role contracts can play when something goes wrong. During an incident, organizations typically focus on technical controls such as containment, system recovery, backups, access management, monitoring, and communication. However, an organization’s ability to respond can also depend on decisions made months or years earlier during contract negotiations.

Several questions can help organizations assess whether their contracts support an effective response and recovery.

• Can the organization obtain the information it needs from the provider during an incident? Does it have appropriate internal audit rights? Security teams must understand the scope and business impact of a disruption to act quickly. Contracts should establish what information and assistance the provider must supply and what access the organization has when investigating an incident.
• What happens when a provider changes a material subcontractor? Organizations need visibility into changes that could alter the risk profile of a critical service, particularly when a new downstream provider supports an important function or introduces another technology dependency.
• What happens if the organization needs to terminate the service? Can data move to another provider, and how long would that transition take? An exit strategy needs to work under real-world conditions. Contractual provisions around data portability, transition assistance, and termination can determine whether an organization can move a critical service when recovery through the existing provider is no longer practical.

DORA establishes contractual requirements for ICT services that support critical or important functions, including provisions addressing service levels, incident assistance, internal audit and inspection rights, business continuity, subcontracting, and exit strategies. Those requirements illustrate a broader point for U.S. organizations: A contract can function as part of the resilience architecture.

A technically sound recovery plan has limited value if an organization cannot access the information, cooperation, or data needed to execute it. Likewise, strong contractual rights provide little protection if teams have never tested whether they can recover or transition the service. Security, procurement, legal, technology, and business continuity teams can therefore approach critical technology contracts as part of a common resilience strategy rather than as separate exercises.

DORA provides an operational resilience framework for U.S. organizations

U.S. organizations can draw practical lessons from DORA even when the regulation does not apply to them directly. DORA’s focus on operational resilience provides a framework for understanding how technology dependencies can affect critical business services. Viewing those dependencies through a DORA supply chain effect connects customer requirements, downstream providers, concentration risk, and operational resilience.

Organizations can begin by identifying their most critical business services and tracing the technology dependencies that support them. Teams can then identify material downstream providers, assess areas of technology concentration, review whether contracts support incident response and recovery, and test how the loss of an important provider would affect operations.

For U.S. technology providers serving European financial services organizations, understanding these dependencies can also help prepare for changing customer expectations. Providers should be able to explain how critical services operate, which material subcontractors support them, how incidents are managed, and what recovery options exist if a significant dependency fails. The goal is not to map every vendor relationship with the same level of detail. Organizations can prioritize the services whose disruption would have the greatest business impact and then work backward through the technology supply chain. DORA provides a useful model for evaluating operational resilience because it expands the focus beyond cybersecurity controls to consider whether critical business services can withstand disruption.

Operational resilience requires a broader view of vendor risk

Cybersecurity programs have long assessed whether individual vendors meet security requirements. Operational resilience requires a broader view of the technology ecosystem, including the shared providers and downstream dependencies that could disrupt multiple services at once.

For U.S. organizations, DORA offers a framework for strengthening operational resilience across those dependencies. Vendor inventories and security assessments are important, but they provide only part of the picture. Organizations also need to understand how critical services depend on interconnected technologies and whether they can sustain those services when a key part of the ecosystem becomes unavailable.