DORA Vendor Due Diligence for Financial Institutions

DORA's Chapter V (Articles 28–44) establishes a comprehensive framework for managing ICT third-party risk that applies to nearly all EU-regulated financial entities — banks, insurers, investment firms, payment institutions, crypto-asset service providers, and more. Unlike previous guidelines from the EBA or EIOPA that operated on a comply-or-explain basis, DORA is a directly applicable regulation with enforcement powers and penalties.

At its core, DORA requires financial entities to adopt and maintain an ICT third-party risk management strategy that includes a policy on the use of ICT services supporting critical or important functions, the identification and assessment of all ICT third-party dependencies, ongoing monitoring of vendor risk, and documented exit strategies for critical service providers. This isn't a one-time exercise — DORA expects continuous oversight throughout the lifecycle of each vendor relationship.

Article 28 establishes the foundational principle: financial entities remain fully responsible for compliance with all regulatory obligations regardless of what they outsource to ICT third-party providers. Outsourcing an ICT function does not outsource the regulatory accountability. This principle drives every other DORA vendor requirement — you can use external providers, but you must demonstrate that you understand, manage, and can survive disruptions to those relationships.

The regulation also introduces direct oversight of critical ICT third-party service providers by European Supervisory Authorities (ESAs). For the first time, EU regulators can directly examine and issue recommendations to major technology vendors serving the financial sector, rather than regulating them only indirectly through the financial entities they serve. This creates a dual-layer governance model that affects both the financial entity's vendor management and the vendor's own operations.

Article 28(3) requires financial entities to maintain a register of information covering all contractual arrangements with ICT third-party service providers. This register must be comprehensive, up-to-date, and available to supervisory authorities on request. The European Supervisory Authorities have published templates specifying the required data fields, and the level of detail expected goes well beyond what most organizations maintained pre-DORA.

For each ICT vendor relationship, the register must document: the vendor's identity and corporate structure, the nature and scope of ICT services provided, whether the service supports critical or important functions, contract start and end dates, data processing locations (including subcontractors), disaster recovery arrangements, and the results of your most recent risk assessment.

The register must also capture subcontracting chains. If your cloud provider uses subprocessors, and those subprocessors use further subcontractors, DORA expects you to understand and document the chain to a degree that allows you to assess concentration risk and identify single points of failure. For major ICT providers like AWS, Azure, Salesforce, and Snowflake, this means mapping their infrastructure dependencies and key subprocessors.

Maintaining the register is not a static obligation. Financial entities must update it when contracts change, when vendors modify their subcontracting arrangements, when risk assessments are refreshed, and when supervisory authorities request additional information. Many firms have found that the register obligation alone requires dedicated tooling and process investment, as spreadsheet-based approaches struggle with the volume and frequency of updates required.

DORA distinguishes between ICT vendors that support "critical or important functions" and those that don't, creating a two-tier due diligence framework. Vendors supporting critical or important functions face enhanced requirements across every dimension — pre-contract assessment, contractual terms, ongoing monitoring, and exit planning.

Determining whether a vendor supports a critical or important function requires evaluating the impact of that vendor's failure or degradation on the financial entity's ability to maintain operations, meet regulatory obligations, and serve customers. Cloud infrastructure providers, core banking system vendors, cybersecurity platforms, and identity management systems almost always qualify. Collaboration tools, analytics platforms, and developer tools may qualify depending on how they're integrated into critical business processes.

For critical vendors, DORA requires enhanced pre-contract due diligence including assessment of the vendor's operational resilience capabilities, their ability to maintain service during stress scenarios, the adequacy of their security measures, and the risks posed by their own subcontracting arrangements. You must also assess concentration risk — are you (or the broader financial sector) overly dependent on a single ICT provider such that its failure would create systemic risk?

The ESAs maintain a list of designated critical ICT third-party service providers subject to direct oversight. If one of your vendors is on this list, you benefit from additional supervisory attention to that vendor's resilience, but you're also expected to incorporate the ESA's findings into your own risk management. The designation process considers the vendor's systemic importance to the financial sector, the degree of substitutability, and the number of financial entities relying on their services.

Article 30 prescribes mandatory contractual provisions that must be included in agreements with ICT third-party service providers. These aren't optional nice-to-haves — the regulation specifies that contractual arrangements "shall" include these elements, and supervisory authorities will check.

All ICT vendor contracts must include: a clear description of all ICT services and functions to be provided, data processing locations and any conditions for changing them, service level descriptions with quantitative and qualitative performance targets, notice periods and reporting obligations for material changes, provisions on the vendor's obligation to provide assistance during ICT incidents, and the financial entity's right to monitor the vendor's performance on an ongoing basis.

For vendors supporting critical or important functions, Article 30 adds further requirements: full audit and access rights allowing the financial entity (or an appointed third party) to inspect the vendor's premises, systems, and controls; guaranteed exit assistance including transition periods and access to data during and after contract termination; incident notification obligations requiring the vendor to report ICT-related incidents that could affect the financial entity; and explicit cooperation commitments with supervisory authorities.

Many existing vendor contracts — particularly with large technology providers like ServiceNow and Datadog — were drafted before DORA and lack these provisions. Financial entities have been working through contract renegotiation programs, and some vendors have developed DORA-specific addenda. However, negotiating audit rights and exit assistance with hyperscale cloud providers remains challenging for smaller financial entities, and the regulation does not exempt any vendor from these requirements based on their market position.

Financial entities that already have mature vendor risk management programs built around SOC 2 reports and ISO 27001 certifications are not starting from zero — but DORA requires meaningful expansion beyond these frameworks. Understanding the overlap and gaps is essential for efficient compliance.

SOC 2 Type II reports provide valuable evidence for several DORA requirements. They demonstrate that a vendor has implemented and operated security controls over a defined period, which supports DORA's ongoing monitoring obligation. The control descriptions and test results in SOC 2 reports can inform your risk assessment of the vendor's security posture. However, SOC 2 doesn't address operational resilience, exit planning, or subcontracting transparency — all areas where DORA has specific expectations.

ISO 27001 certification indicates a vendor has an information security management system (ISMS) with regular internal audits and management reviews. This is relevant to DORA's requirement that ICT vendors maintain adequate security measures. But like SOC 2, ISO 27001 doesn't directly address digital operational resilience concepts like ICT-related incident impact analysis, concentration risk, or recovery time objectives that DORA emphasizes.

The practical approach is to use SOC 2 and ISO 27001 as foundational evidence and layer DORA-specific assessments on top. Request additional information from vendors covering: ICT incident response and notification capabilities, disaster recovery and business continuity testing results, subprocessor registries and change notification processes, and exit/transition planning. Many organizations find that a structured vendor assessment process combining compliance evidence with DORA-specific questionnaires provides the most efficient path. ThirdProof vendor reports consolidate compliance certifications and risk indicators into a single view — see our methodology for how this works.

DORA's application date was January 17, 2025, meaning financial entities have been subject to enforcement for over 14 months. The reality of compliance across the industry is uneven, with large institutions generally further ahead than smaller entities.

What most firms have completed: The ICT vendor register is in place for most regulated entities, though the depth and accuracy of information varies. Pre-DORA contracts with major vendors have been identified, and renegotiation programs are underway. Internal governance frameworks — policies, roles, and reporting lines for ICT third-party risk — have been established or updated. Most firms have classified their vendors into critical/non-critical tiers.

Where firms are still working: Contract renegotiation remains the most labor-intensive workstream. Negotiating DORA-compliant terms with dozens or hundreds of ICT vendors, particularly large technology providers with limited willingness to customize contracts, is a multi-year effort for many institutions. Exit planning for critical vendors is another area of ongoing work — developing realistic transition plans for deeply embedded cloud or core banking providers is complex and requires technical planning beyond legal documentation.

Emerging supervisory focus areas: Regulators have signaled attention to concentration risk — financial entities that have moved critical functions to a single cloud provider without adequate multi-cloud or hybrid contingency plans. They're also examining whether vendor registers truly reflect the complete ICT third-party landscape or whether significant shadow IT relationships remain undocumented. Incident reporting chains (from vendor to financial entity to regulator) are being tested through supervisory exercises.

For financial entities still maturing their DORA compliance programs, a vendor due diligence checklist tailored to DORA requirements can help prioritize remaining gaps. The most impactful investments are in vendor register completeness, critical vendor contract remediation, and concentration risk analysis.