DORA software vendor compliance — contracts as operational resilience.

A regulation, not a guideline.

DORA is an EU regulation, directly applicable in all member states, that replaces and consolidates the prior outsourcing guidelines from EBA, EIOPA and ESMA for ICT services. It establishes a uniform framework for operational resilience across the EU financial services sector and applies to a broad set of in-scope entities: credit institutions, investment firms, payment institutions, insurance and reinsurance undertakings, crypto-asset service providers, central counterparties, trade repositories, and others listed in Article 2.

Two structural choices shape its impact. First, DORA defines ICT services broadly to include all digital and data services provided through ICT systems — SaaS, IaaS, PaaS, managed services, and many software licensing arrangements where the vendor provides ongoing service. Pure perpetual licensing of on-premise software is typically out of scope, but the associated support and maintenance services typically are. Second, DORA introduces direct oversight of critical ICT third-party service providers by the European Supervisory Authorities — Microsoft Azure, AWS, Google Cloud, Oracle and several SaaS vendors are likely designated.

The Register of Information

DORA requires each financial entity to maintain a standardised Register of Information cataloguing all ICT third-party arrangements, with separate categorisation for arrangements supporting critical or important functions. The register is reported to national competent authorities annually and used to identify critical ICT third-party providers. Buyers should treat the register as procurement infrastructure, not a compliance artefact — it forces a single source of truth about ICT dependencies that supports renewal benchmarking, exit planning, and material-change tracking.

The contractual mandatory provisions.

Article 30 specifies mandatory contractual provisions for all ICT services (Article 30(2)) and enhanced provisions for ICT services supporting critical or important functions (Article 30(3)). Most enterprise SaaS contracts signed before 2024 fail at least three of the Article 30(3) provisions, typically:

1. Service descriptions and locations. The contract must specify which services are provided, from which locations, and for which entities and functions. Most SaaS MSAs are silent on location. Vendor-side standard clauses reserve the right to move processing without notice — this is no longer acceptable for in-scope services.
2. Subcontracting chains. The contract must require the vendor to maintain and disclose the chain of subcontractors providing ICT services supporting critical or important functions, with prior notice of changes and customer rights to object on operational resilience grounds.
3. Audit and access rights. The contract must grant the customer and the competent authorities unrestricted rights of access, inspection and audit — including on-site inspection at vendor premises. Standard SaaS audit clauses limited to SOC 2 attestations are insufficient on their own.
4. Exit strategies and assistance. The contract must contain exit strategies, including transition periods during which the vendor continues service and provides reasonable assistance to a successor provider or in-house migration. Most SaaS MSAs cap exit assistance at 30 days; DORA effectively requires longer for critical functions.
5. Termination rights. The contract must grant the customer specific termination rights, including for material vendor breach, regulatory direction, and material change in the vendor's circumstances. Standard "for cause" clauses are too narrow.

A practical renewal-time intervention covers all five at once. Splitting the work across multiple renewals creates exposure during the gap period and signals to the vendor that the buyer's leverage is fragmented.

Critical ICT third-party providers — the concentration problem.

DORA pays explicit attention to ICT concentration risk. Article 29 requires financial entities to assess concentration at the ICT third-party level (e.g., over-dependence on a single hyperscaler) and at the subcontracting level (e.g., multiple vendors backed by the same underlying infrastructure provider). For most EU financial entities, the practical work is a serious exit-feasibility test for the largest two or three ICT dependencies — typically the cloud hyperscaler, the core SaaS platform, and the core banking or insurance vendor.

Exit feasibility is rarely tested honestly. In our experience across 340+ engagements, vendor-supplied exit playbooks typically overstate the practical exit speed by a factor of two to three, and understate the customer-side technical and contractual lift. A defensible Article 28 exit strategy is a documented, costed, time-bound migration path — not a paragraph in the supervisor's questionnaire. The same documentary discipline that satisfies a DORA supervisor also underpins effective software license audit defense when a vendor turns a resilience review into a compliance claim.

Direct oversight of critical ICT third-party providers

The European Supervisory Authorities, acting through a Joint Oversight Forum, can designate ICT third-party providers as "critical" based on systemic importance and impose direct oversight requirements. Designated critical providers face inspection rights, recommendation powers, and potential periodic penalty payments. For the largest hyperscalers and SaaS platforms, this is the most material regulatory development in EU technology contracting in a decade.

When independent advisory pays back