DORA and outsourcing to third-party ICT service providers

DORA

The Digital Operational Resilience Act (DORA) came into full effect on January 17, 2025. This EU regulation sets the standard for digital operational resilience in the financial sector. Dutch financial institutions, including banks, payment institutions, insurers, investment firms, and stock exchanges, are subject to stricter requirements for outsourcing ICT services, more stringent contract terms, and supervision by the AFM and DNB. The focus is on ICT risk management, incident reporting, testing, and, above all, managing risks associated with “third-party ICT service providers.” In this context, financial institutions must, among other things, maintain an up-to-date register of all ICT service providers and outsourced ICT processes. This register must be available for inspection by the supervisory authority on request and must be updated periodically.

DORA and third-party ICT service providers: who does what?

Most of the DORA questions we see are not about definitions, but about the practical implementation, such as complex outsourcing structures or relationships with a Managed Service Partner (MSP). When does a relationship with a third-party provider qualify as an ICT service relationship under DORA? Who is the ICT service provider when you use an MSP? How should these roles be recorded in the information register and in reports to the supervisory authority? The key is to look at the contractual chain, the actual delivery of ICT services, and the chain of responsibility for operational resilience.

The role of the MSP within DORA

DORA emphasizes on five pillars: ICT risk management, incident reporting, testing digital resilience, managing ICT outsourcing, and exchanging information about threats. The fourth theme in particular—the management of ICT outsourcing—proves challenging in practice. This is especially true for smaller financial institutions, which run their entire ICT environment through a Managed Service Provider (MSP).

An MSP typically provides the entire IT landscape to a financial institution: from workstations and Microsoft 365 to backup, security, and monitoring. This makes the MSP effectively the ICT department of the financial organization. What is less visible is that the MSP itself is also dependent on IT service providers. Think, for example, of Microsoft as a cloud provider, suppliers of antivirus software, remote monitoring & management (RMM) tools, and backups. This IT service chain is exactly what DORA looks at. Because in the event of an incident or disruption, every link in that chain can pose a risk to the continuity of the financial institution. This raises questions such as: What is the role of the MSP, and how does the MSP relate to the actual IT service provider (e.g., Microsoft)? Does the MSP qualify as a third-party ICT service provider or does it fall outside the ICT service chain? Should Microsoft be classified as a subcontractor or, alongside the MSP, as a third-party ICT service provider?

Article 2(1) of the ITS on the information register (JC 2023/85) uses the following definitions to distinguish between a ‘direct third-party ICT service provider‘ and a ‘subcontractor‘:

(a) ‘direct third-party ICT service provider‘ means an external ICT service provider or intra-group ICT service provider that has entered into a contractual agreement with:

1. a financial entity to provide ICT services directly to that financial entity;
2. a financial or non-financial entity to provide ICT services to another financial entity within the same group.

(b) ‘subcontractor’ means a third-party ICT service provider or intra-group ICT service provider that provides ICT services to another third-party ICT service provider within the same ICT service chain.

We often hear that parties believe that the MSP provides ICT services to the financial institution, with the MSP in turn using subcontractors, such as Microsoft. In practice, however, it is important to look at the underlying contracts and to clarify exactly which service(s) the MSP and other ICT service providers provide. Are there only contracts between the financial institution and the MSP? Does the MSP contract in its own name (as a reseller of) or as an agent/representative of the third-party ICT service provider (Microsoft)?

We will explain this in more detail using two examples:

Example 1: The MSP as a Microsoft Cloud Solutions Provider

Many MSPs are affiliated with the Microsoft Cloud Solutions Provider (CSP) program. In that role, the MSP can supply Microsoft products, such as Microsoft 365, Azure, and Teams, on behalf of their customer (i.e., the financial institution). The MSP also invoices the financial institution for the relevant Microsoft product licenses. However, the financial institution must formally agree to the Microsoft Customer Agreement (MCA).

In theory, this process is carefully regulated, but in practice it seems more difficult. Within the CSP program, there are two options for agreeing to the MCA. The financial institution can read the MCA directly and accept it for approval. Alternatively, the MSP can accept the MCA on behalf of the financial institution via a partner statement (“attest“). This process, and the second option in particular, raises questions. How many customers have actually read the MCA? Do these customers realize that, despite the intervention of their MSP, they are in fact contracting directly with Microsoft?

As a result, Microsoft is not a subcontractor with regard to the ICT services it provides, but a ‘direct third-party ICT service provider‘ within the meaning of DORA.

Although Microsoft is generally considered a reliable party, this may not always be the case for the MSP. This is precisely where potential risks can arise. What happens if the MSP collects the Microsoft license fees from you but stops paying Microsoft? What if an MSP employee has unlawful unauthorized access to your Microsoft admin environment? In short, when the MSP manages the license or payment flows, and the financial institution itself is a customer of Microsoft, a potentially vulnerable triangular relationship arises. In the event of an incident, bankruptcy, or conflict at the MSP, the financial institution’s access to the Microsoft environment could suddenly be blocked.

In conclusion, this means that for DORA purposes, Microsoft is a direct third-party ICT provider, and financial institutions must properly understand and document their dependence on their MSP in that relationship. Requesting and retaining the MCA and the accompanying Financial Services Amendment is therefore not a formality, but an essential part of the financial institution’s compliance file.

Example 2: MSP remote monitoring (RMM) tools

Another example concerns the ICT tools that MSPs often use to manage workstations at financial institutions. Think, for example, of remote assistance/remote monitoring & management services. The ICT suppliers of such tools contract directly with the MSP, not with the financial institution. This type of ICT service therefore does not constitute a direct ICT service to the financial institution, but rather an intermediary (subcontractor) in the MSP’s ICT supply chain.

How does this work under DORA? This depends on whether the ICT services provided by the MSP are considered to support an important or critical function. According to Article 3.22 DORA, this is the case for “a function whose disruption would materially impair the financial performance of a financial entity or the soundness or continuity of its services and activities, or whose termination or defective or failed performance would significantly and permanently impair a financial entity’s ongoing compliance with the conditions and obligations under its license or its other obligations under applicable financial services law.”

It is therefore important to make the link with the function(s) supported by the ICT service within the financial institution. The ‘IT support’ function within the financial institution is outsourced to the MSP and is not considered critical by the financial institution, partly because the IT support department mainly deals with Microsoft 365 matters and other departments themselves perform critical transaction reports, which means that these activities do not fall under the IT support function. However, Microsoft Office 365—Excel, for example—is also used by those other departments within the financial institution, including the transaction reports that are considered critical. This means that an incident at the MSP does not, in principle, pose a significant risk, but an incident at Microsoft does.

But suppose the RMM tool is hacked and the MSP can no longer perform management tasks. The MSP’s customers are dissatisfied, fear a hack themselves, and quickly terminate their contract with the MSP with immediate effect. What is the role of the MSP in this case? Is there an incident response scenario in which the financial institution can take over the Microsoft Office 365 environment independently or via a new MSP (quickly)?

Ideally, the financial institution has identified the compliance function as critical and has linked it to Microsoft rather than the MSP as the IT service provider. As part of Business Continuity Planning, consideration has been given to the risks associated with the Microsoft environment. It is not so much the risks that Microsoft itself controls that are relevant (how far do checks on various external audits of security frameworks go?), but rather risk scenarios such as an MSP dropping out.

Tips for outsourcing ICT services under DORA

Most financial institutions are now familiar with DORA. The first risk analyses and policy documents have been drawn up. The AFM and DNB enforce the application of and compliance with the DORA requirements. These supervisory authorities now expect the next step: deeper insight into the ICT chain, including subcontractors of MSPs and hyperscalers such as Microsoft.

Financial institutions must have their registers and documentation ready, report serious ICT incidents in a timely manner, and provide the necessary information upon request. The regulators can conduct investigations into compliance and the management of ICT outsourcing risks. Financial institutions within the SME sector in particular can tackle this step by step:

Tip 1: Understand the IT service chain and ensure you have insight into dependencies. For each IT service, note who the supplier is and whether there are any subcontractors. Pay attention to critical functions and also look at mutual dependencies, for example with an MSP.

Tip 2: Ensure you understand the contractual agreements. Make sure you have a clear overview of your contracts and know which agreements apply. Ask the MSP for access to the MCA and other contractual agreements and ensure that the DORA obligations regarding operational resilience, supervisory rights, audit, exit, concentration risk, incident reporting, and access by supervisory authorities are met. Pay attention to the functions supported by the ICT service and also look at interdependencies.

Tip 3: Test and document. Test access and continuity and document analyses and assessments. Investigate issues such as: “What if Microsoft is hacked?” or “What if the US imposes sanctions on European CSPs?”, but also investigate questions such as “What if my MSP fails or doesn’t pay Microsoft or Google’s bill?” Record how dependencies have been assessed and what control measures apply.

Conclusion

Trust is not control. Microsoft and other hyperscalers enjoy a high level of trust. And rightly so. Their platforms are stable, available worldwide, and meet strict security standards. However, trust sometimes comes at the expense of understanding the contractual reality. In practice, many institutions do not know exactly what they have signed, through whom, and who actually has access to their cloud environment. This is precisely where an important part of DORA’s ” ” lies: knowing what you trust and being able to demonstrate that you understand and control the dependencies. Digital resilience therefore does not start with technology, but with an understanding of relationships, contracts, and responsibilities. DORA’s focus is shifting from awareness to insight and control. Financial institutions must not only be able to demonstrate that they have policies in place, but also that they actually have control over their ICT service chain.