Although the EU Digital Operational Resilience Act (DORA) directly regulates financial entities, its requirements extend throughout their ICT supply chains. Articles 28 to 30 require regulated banks, insurers, and investment firms to incorporate specific contractual, monitoring, risk management, and exit provisions into their relationships with ICT service providers. In addition, the European Supervisory Authorities have designated 19 ICT providers as sufficiently critical to warrant direct regulatory oversight.

Consequently, organizations that provide help desk, cloud, software, managed security, or other ICT services to financial services clients operating in the EU may already be subject to DORA related obligations, even if they are not directly regulated under the legislation.

What Is DORA, and Which Organizations Does It Regulate?

The Digital Operational Resilience Act (DORA) has applied across the European Union since January 2025. It directly covers twenty categories of financial entities, including banks, insurers, investment firms, payment institutions, and crypto asset service providers. Its purpose is to establish a single, harmonized EU framework governing how financial entities manage ICT risk, report significant incidents, test operational resilience, oversee third party providers, and share information about cyber threats. Organizations found to be in serious breach may face substantial financial penalties.

At first glance, DORA may appear to be primarily a compliance concern for financial institutions. In practice, however, its reach extends much further. The regulation recognizes that the operational resilience of modern financial institutions depends heavily on external providers, including cloud platforms, core banking software vendors, payment infrastructure providers, managed detection services, and managed service providers responsible for the day to day operation of IT environments.

DORA’s third party risk management framework is specifically designed to address these dependencies. It extends regulatory expectations to ICT providers primarily through contractual requirements, requiring financial entities to ensure that their providers meet defined standards for security, resilience, monitoring, incident management, cooperation, and service continuity.

The Provisions That Extend DORA to ICT Providers: Articles 28 to 30

Articles 28 to 30 are where DORA moves beyond the internal compliance obligations of financial entities and begins to affect their contractual relationships with ICT providers.

Article 28 requires every financial entity within scope to manage ICT third party risk as an integral part of its overall risk management framework. Financial entities must maintain an up to date register of their ICT contractual arrangements and conduct proportionate due diligence before entering into new agreements. This assessment must consider factors such as the provider’s substitutability, insolvency risk, data protection arrangements, and subcontracting chain.

Article 28 also requires financial entities to establish documented exit strategies for ICT services that support critical or important functions. In practice, this means identifying an alternative provider or an internal fallback arrangement in advance, rather than waiting until a provider fails or a contract must be terminated unexpectedly.

Article 30 translates these principles into specific contractual requirements. Every ICT services agreement must include a clear written description of the services, defined performance standards, the locations where data will be processed and stored, notification requirements for changes to those locations, commitments relating to incident assistance, and clearly defined termination rights.

Where an ICT service supports a critical or important function, additional requirements apply. These include precise performance targets, comprehensive audit and access rights covering the provider’s premises and systems, effective exit assistance arrangements, and appropriate disclosure of subcontractors involved in delivering the service.

A particularly important point for providers is that the financial entity remains fully responsible for DORA compliance when services are outsourced to a third party. Engaging an external provider does not transfer the regulatory obligation. Instead, it requires the financial entity to ensure, through contractual and oversight measures, that the provider supports its compliance responsibilities.

The principle of proportionality may affect the level of documentation, assurance, and testing expected from a smaller provider, but it does not eliminate the underlying obligations. If a client is subject to DORA, its relationship with the ICT provider forms part of its regulatory risk management and compliance framework.

Critical ICT Third Party Providers: Direct Oversight Is Now in Effect

On 18 November 2025, the European Supervisory Authorities published the first official list of critical ICT third party service providers designated under Article 31 of DORA. The list comprises 19 organizations that provide services ranging from core infrastructure and cloud computing to telecommunications, data services, and financial technology.

Designation as a critical provider brings an organization within the EU oversight framework. Designated providers are subject to direct supervisory engagement, information and documentation requests, investigations, inspections, and recommendations intended to address identified ICT risks.

Under Article 31(2), the designation assessment considers four principal criteria. These are the potential systemic impact of a major operational failure, the systemic importance of the financial entities that depend on the provider, the extent to which those entities rely on its services for critical or important functions, and the degree to which the provider can be substituted.

Failure to comply with measures imposed by the relevant Lead Overseer may result in periodic penalty payments of up to 1% of the provider’s average daily worldwide turnover in the preceding business year for each day of noncompliance. A designated provider established outside the EU must also establish an EU subsidiary within 12 months of designation if it intends to continue serving regulated financial entities in the EU.

Most managed service providers and smaller ICT vendors are unlikely to be designated as critical providers. However, this does not remove their exposure to DORA related requirements. The 19 designated organizations represent only the highest level of the ICT supply chain. Other providers remain subject to the contractual, assurance, monitoring, and exit requirements that financial entities must implement under Articles 28 to 30.

The potential scope of DORA also remains under review. In January 2026, the European Commission completed its assessment of whether statutory auditors and audit firms should be subject to stronger digital operational resilience requirements. Rather than recommending their immediate inclusion within DORA, the Commission concluded that further analysis was necessary and deferred the issue to the broader review of DORA scheduled for 2028. This confirms that the regulatory framework may continue to evolve as the EU gains practical experience with its implementation.

Why This Is a Human Risk Issue, Not Simply a Documentation Issue

Contracts, registers, and exit strategies describe how a financial entity intends to manage a provider relationship. They do not, however, demonstrate how that relationship will perform under operational pressure or when an attacker deliberately targets the people responsible for administering it.

The 2026 Verizon Data Breach Investigations Report found that third party involvement accounted for 48% of breaches, representing a 60% increase from the previous year. It also found that mobile social engineering attacks involving voice calls and text messages achieved a success rate 40% higher than traditional email phishing. For organizations operating a help desk, this is a particularly significant finding. Verizon 2026 Data Breach Investigations Report summary

These findings closely reflect the methods associated with Scattered Spider, a financially motivated threat group that has targeted technology vendors, managed service providers, and other organizations with privileged access to customer environments. Its approach often relies on a relatively simple technique: impersonating an employee, contacting the help desk, and persuading an agent to reset a password, register a new multifactor authentication device, or approve an account recovery request.

Research published by ReliaQuest found that 81% of more than 600 domains historically linked to Scattered Spider impersonated technology vendors. The group has also demonstrated a particular interest in single sign on platforms, identity providers, virtual private networks, help desk systems, and other services capable of providing access to privileged accounts. ReliaQuest threat research

The strategic rationale is clear. An MSP may hold administrative credentials and operational access across hundreds of customer environments. Compromising a single provider can therefore give an attacker access to multiple downstream organizations, reducing the need to investigate and target each customer separately. The concentration of access that makes the managed services model efficient also creates a significant concentration of human and operational risk.

The continuing effectiveness of these techniques is illustrated by recent enforcement action. In June 2026, two individuals associated with Scattered Spider pleaded guilty on the first day of their UK trial to offences connected with the 2024 cyberattack against Transport for London. One of those individuals, Thalha Jubair, has also been charged separately in the United States in connection with an alleged campaign involving approximately 120 network intrusions, including attacks against 47 US organizations. Those US charges remain allegations unless and until proven in court. UK National Crime Agency, US Department of Justice

The central weakness is not necessarily a technical control. It is often a trusted employee responding to a convincing request under time pressure. Help desk personnel are trained to resolve problems and restore access quickly. Attackers exploit that service oriented mindset by creating urgency, establishing apparent credibility, and persuading staff to bypass or reinterpret established verification procedures.

For this reason, DORA readiness cannot be demonstrated through contractual documentation alone. Providers must also show that their identity verification processes, escalation procedures, workforce training, and help desk controls remain effective when confronted with deliberate and persistent social engineering.

What Your Contracts Are Likely to Require

ICT providers that have not yet encountered DORA specific provisions in client contracts or renewals should expect to see them increasingly incorporated. Supervisory attention is moving beyond whether financial entities have established compliance plans and toward whether they can produce evidence of implementation. This includes a current register of information, a documented methodology for identifying critical or important functions, and confirmation that the contractual provisions required by Article 30 are included in executed agreements.

For ICT providers, the practical implications are likely to include:

• Audit and access rights that apply to the provider’s premises, systems, personnel, and relevant records, rather than relying solely on questionnaires or summary assurance reports.
• A documented and technically viable exit plan that enables the client to transfer services to another provider or return them to an internal operating model without causing material disruption.
• Appropriate disclosure of subcontractors involved in delivering the service, together with information about the functions they perform and the locations from which services are provided.
• Continuing monitoring and assurance obligations that require evidence to be supplied at regular intervals and following material changes, rather than only when the contract is signed.

Providers that encounter these requirements for the first time during contract negotiations may face delays, additional scrutiny, and reduced negotiating flexibility. By contrast, providers that have already identified which services support critical or important functions, assessed their subcontracting arrangements, and prepared the necessary evidence can respond more efficiently.

This level of preparation can turn regulatory readiness into a commercial advantage. It enables the provider to demonstrate transparency, operational maturity, and an informed understanding of the client’s compliance obligations.

Readiness: What ICT Providers Should Put in Place Now

Although many of the obligations described above are expressed in legal and contractual terms, an effective readiness program must extend beyond contract documentation. A defensible approach should address governance, operational resilience, third party oversight, incident response, and the effectiveness of the human controls that protect access to systems and data.

Frequently Asked Questions

• Does DORA apply to my company if we are not based in the EU?

Potentially, although the nature of the obligation depends on the provider’s status. ICT providers outside the EU are generally affected through their contractual relationships with financial entities that are subject to DORA. This can include UK providers serving regulated EU clients, group technology functions supporting EU financial entities, and organizations with EU subsidiaries.

A provider designated as a critical ICT third party service provider is subject to direct EU oversight. Other providers are primarily affected through the contractual, assurance, information, and cooperation requirements imposed by their regulated clients.

• What is a critical ICT third party service provider, and is my company one?

A critical ICT third party service provider is an organization that the European Supervisory Authorities have designated as systemically important to the EU financial sector. The first list, published in November 2025, included 19 providers, most of which were large cloud, technology, telecommunications, data, and infrastructure organizations.

Most MSPs and smaller ICT providers are unlikely to receive this designation. However, the absence of a designation does not remove DORA related expectations. For most providers, those expectations arise through client contracts and oversight processes rather than direct supervision by an EU authority.

• We are a small MSP with only a few financial services clients. Do we need to address DORA?

Yes. The principle of proportionality may influence the level of documentation, testing, and assurance expected, but it does not automatically exclude smaller providers from relevant contractual requirements.

If a client is regulated under DORA, it must identify, assess, and document the ICT risks associated with its relationship with the provider. The provider’s size may affect how those requirements are implemented, but it does not remove the client’s obligation to manage the risk.

• Can a help desk error become relevant under DORA?

Yes. A successful social engineering attack against a help desk may result in unauthorized access to a financial entity’s systems, accounts, or data. Depending on its impact and classification, the event could contribute to an ICT related incident that the financial entity must assess and potentially report under DORA.

The client is therefore likely to require timely information from the provider, including how the incident occurred, which systems and data were affected, when it was detected, what containment measures were taken, and how recurrence will be prevented.

• What should we prioritize first?

Begin by identifying which existing services support critical or important functions for regulated financial clients. This classification determines whether enhanced contractual, assurance, audit, continuity, and exit requirements may apply.

This review should be accompanied by a practical assessment of help desk controls, particularly the procedures used to verify identity before resetting passwords, registering authentication devices, or approving account recovery requests. Documentation is necessary, but it must be supported by evidence that these controls operate effectively in practice.

The Gap Bo Contract Can Close

DORA was developed for the financial sector, but its third party risk management framework was designed to extend into the ICT supply chain. Articles 28 to 30 require regulated financial entities to impose defined contractual, monitoring, assurance, cooperation, and exit requirements on the providers that support their operations. In addition, 19 providers are already subject to direct EU oversight following their designation as critical ICT third party service providers.

Most MSPs will never appear on the critical provider list. Nevertheless, those serving regulated financial entities may already be subject to DORA related requirements through their client contracts, due diligence processes, audit requests, and continuing oversight arrangements.

Contractual compliance is important, but documentation alone cannot demonstrate operational resilience. Many serious incidents begin with a routine interaction: a telephone call to a help desk, a credible explanation, and an employee who has not been adequately prepared to recognize or challenge an impersonation attempt.

Addressing this vulnerability is not simply a compliance exercise. It requires tested identity verification procedures, clear escalation routes, effective workforce training, and regular assurance that established controls remain effective under pressure. A signed contract can document that these measures are required, but only operational testing can demonstrate that they work. Book a demo to learn how we can help you turn the gap into evidence, with continuous, realistic testing of the people and processes DORA now expects you to prove.

‍