DORA changed the supplier decision

DORA has applied since 17 January 2025 to the financial entities within its scope.² Its third-party provisions make one point especially clear: buying an ICT service does not transfer the financial entity’s responsibility. That changes what a credible sourcing process must settle before a shortlist becomes a contract.

The supplier decision starts with the supported function

Article 28 requires ICT third-party risk to be managed as part of the entity’s ICT risk-management framework. It also states that financial entities using ICT services shall, at all times, remain fully responsible for their obligations.¹ The exact DORA requirements depend on the entity, service, and whether the ICT service supports a critical or important function.

A request for proposal should therefore identify the business function first. The organisation needs a common view of the service, process, customers, data, jurisdictions, tolerance for disruption, recovery expectations, regulatory reporting, and downstream dependencies. A technology label such as “cloud platform” is not enough to establish criticality or risk.

Classify the function and record the reasoning

Before contracting, establish who owns the function, whether it is critical or important, and how failure could affect continuity, customers, data, or regulatory obligations. Keep the reasoning with the selection record. That creates a traceable basis for due diligence, approval, contract requirements, monitoring, and exit planning.

DORA also requires in-scope entities to maintain a register of contractual arrangements with ICT third-party providers. The EBA explains that the register is used by entities to monitor third-party risk, by authorities for supervision, and by the European Supervisory Authorities in the critical-provider designation process.²

Map the delivery chain, not only the contracting party

Establish where the service is delivered, where data is processed, what intragroup or subcontracted services are material, and how changes in that chain will be notified. The map should show operational dependencies: identity, connectivity, data, support, security, monitoring, incident coordination, and recovery.

This is also where concentration and substitutability become concrete. Several suppliers may still depend on the same infrastructure, software component, region, or specialist support team. A list of legal vendors can conceal one operational dependency.

Turn service levels into evidence

Availability percentages alone rarely describe operational resilience. Evaluation criteria should cover incident detection and notification, severity classification, evidence preservation, recovery objectives, communications, problem management, testing, reporting, and the corrective action expected when a target is missed.

Article 30 lists minimum contractual elements for ICT services, including a clear service description, service and data locations, data protection provisions, access and return of data, service-level descriptions, incident assistance, cooperation with authorities, and termination rights.¹ For services supporting critical or important functions, it adds more detailed requirements, including performance targets, contingency and security measures, audit and access rights, and exit arrangements.

Test access, audit, and cooperation before signature

Contract wording matters, but operability matters more. Confirm how the entity, its appointed third parties, and competent authorities can obtain information, inspect, audit, and follow up remediation. Where a supplier proposes pooled audits, certifications, or independent reports, assess whether the evidence is sufficiently current, scoped, and actionable for the function.

The European Supervisory Authorities’ oversight of providers designated as critical complements rather than replaces each financial entity’s responsibility for its own ICT risk.³ A provider’s designation or certification is therefore not a substitute for entity-level due diligence and monitoring.

Make concentration and substitutability decision criteria

Article 29 requires a preliminary assessment of concentration risk at entity level for ICT services supporting critical or important functions.¹ The sourcing team should examine whether the arrangement creates a dependency that is difficult to substitute, involves multiple critical services with one provider, or limits effective access, supervision, or recovery.

This does not mean every concentrated arrangement is unacceptable. It means the decision record should show the dependency, alternatives, mitigations, residual risk, and approving authority.

Design exit as an operating capability

Exit is not a termination clause at the back of a contract. For a critical or important function, it should identify the data, formats, knowledge, licences, technical interfaces, access, people, transition support, and interim controls required to move to another provider or an internal solution. DORA links exit strategies to an adequate transition period designed to reduce disruption.¹

The plan should be credible under adverse conditions, not only at scheduled contract expiry. Assumptions about supplier cooperation, available alternatives, internal capacity, and transition time need evidence and periodic testing.

A practical pre-contract decision record

Before approval, the accountable body should be able to see, in one place:

• the supported function and criticality assessment;
• the service, data, subcontractor, and location map;
• the due-diligence evidence and unresolved exceptions;
• the measurable service and incident obligations;
• access, audit, testing, and authority-cooperation rights;
• concentration, substitutability, and residual-risk conclusions;
• the exit, transition, data-return, and continuity design; and
• the owners of monitoring, incidents, remediation, and change.

The legal review of the contract remains essential. The wider programme task is to make sure the commercial selection, operating model, risk acceptance, contract, implementation, and ongoing governance describe the same service.