IT Contracts, Data & Cybersecurity Lawyer | Withlaw
  • Our firm
  • About us
  • Our areas of expertise
  • What our clients say
  • Insights
  • Contact us
  • FR

DORA & ICT Contracts: What International Providers Need to Know

DORA has changed contract negotiations between EU financial entities and their technology providers.

The reason is unusually concrete: the Regulation itself specifies provisions that must appear in ICT contracts, with additional requirements where the service supports a critical or important function.

For international SaaS, cloud and technology providers, this means that some provisions appearing in a customer’s “DORA addendum” have a genuine regulatory basis. Others may reflect the customer’s own interpretation, policies or preferred risk allocation.

Understanding the difference requires looking at what DORA actually requires from the contract.

First question: does the service support a critical or important function?

This is one of the most important questions in a DORA contract review.

Article 30 establishes a first set of contractual requirements for ICT services generally, and a second, more demanding set for services supporting a critical or important function.

The distinction can materially affect the contract.

Where a critical or important function is involved, additional requirements apply to areas such as service levels, reporting, business continuity and security, audit rights and exit arrangements.

Providers should therefore establish early in the negotiation how the customer has classified the service.

Otherwise, they may spend considerable time negotiating requirements that do not necessarily apply to the service concerned.

Article 30 requires actual contractual provisions

DORA is unusually prescriptive about the content of ICT contracts.

For ICT services generally, Article 30 requires the agreement to address matters including:

  • the services and functions being provided;
  • where services are provided and data is processed and stored, including advance notification of changes;
  • data availability, authenticity, integrity and confidentiality;
  • access to, recovery and return of data;
  • service levels;
  • assistance in connection with ICT incidents;
  • cooperation with competent and resolution authorities; and
  • termination rights.

There are additional requirements where the service supports a critical or important function.

This is why simply stating that the provider “complies with DORA” is unlikely to resolve the issue: the customer needs the relevant mechanisms in the contract itself.

Audit rights deserve careful drafting

For services supporting critical or important functions, DORA requires extensive access, inspection and audit rights.

This can be challenging for international SaaS and cloud providers operating shared environments.

But the Regulation also contains useful elements for the negotiation. Financial entities must determine the frequency and scope of audits using a risk-based approach, and DORA expressly contemplates alternative assurance methods in appropriate circumstances.

The practical discussion can therefore focus on how the audit right will work: notice, scope, confidentiality, security, use of independent auditors and reliance on existing certifications or audit reports where appropriate.

The aim is to preserve the customer’s required access and control while taking account of the operational, security and confidentiality constraints of a shared service.

Subcontracting requires more than a standard subprocessor clause

For many SaaS and cloud providers, subcontracting is one of the more difficult DORA issues.

The provider may rely on cloud infrastructure, hosting, support services and other technology suppliers, and those arrangements may change over time.

Where ICT services support a critical or important function, DORA requires the financial entity to assess the risks associated with subcontracting, including potentially long or complex subcontracting chains.

The contractual discussion therefore goes beyond maintaining a simple list of subprocessors.

Providers may need to address which parts of the service can be subcontracted, how material changes are notified and what happens if the customer considers that a change creates an unacceptable risk.

This needs to be reconciled with the provider’s ability to operate and evolve a standardized service.

Exit provisions need to work with the commercial contract

DORA also places significant emphasis on exit strategies for ICT services supporting critical or important functions.

Financial entities need to be able to exit arrangements without disrupting their business activities or compromising regulatory compliance.

For providers, this can lead to requests for transition periods, continued service, data return and assistance with migration to another provider.

Those provisions should be reviewed together with the term and termination provisions of the main agreement.

A regulatory requirement to prepare for an orderly exit does not, by itself, answer commercial questions such as when the contract may be terminated, what fees remain payable or what transition services are included in the subscription price.

Those issues still need to be addressed expressly.

Incident assistance may have a price

One small but useful detail in Article 30 is sometimes overlooked.

DORA requires ICT contracts to provide for assistance by the provider when an ICT incident related to the service occurs.

But the Regulation expressly allows that assistance to be provided at no additional cost or at a cost determined in advance.

For providers, this matters.

Where incident assistance may require substantial technical resources, the contract can define what is included in the service and establish in advance how additional assistance will be charged.

A regulatory obligation to provide assistance does not necessarily mean unlimited free professional services.

DORA addenda should be reviewed against the actual service

Large financial institutions often use standardized DORA schedules across multiple suppliers.

That is understandable from the customer’s perspective, but the same schedule may be used for very different services and risk profiles.

For the provider, the review should therefore start with the service itself:

What is being provided? Does it support a critical or important function? Where is the data processed? Which subcontractors matter? What audit mechanisms already exist? What would an exit actually require?

Once those points are clear, the DORA schedule can be tested against both the Regulation and the provider’s operating model.

In practice

A DORA addendum should not be treated as an indivisible regulatory document.

Some provisions are expressly required by Article 30. Some depend on whether the service supports a critical or important function. Others concern the practical implementation of those requirements or the customer’s own contractual choices.

For international providers, the classification of the service and the actual wording of Article 30 are therefore two of the most useful starting points for the negotiation.

They make it much easier to identify where the contract genuinely needs to change — and where the discussion remains commercial or operational.

How Withlaw can help

Withlaw assists international SaaS, cloud and technology providers negotiating DORA requirements with French and European financial institutions, including:

  • identifying which Article 30 requirements apply to the service;
  • reviewing and negotiating DORA addenda and ICT contractual provisions;
  • addressing audit and access rights in shared SaaS and cloud environments;
  • structuring subcontracting and change-notification mechanisms;
  • reviewing exit, transition and data-return provisions; and
  • aligning DORA requirements with the provider’s existing global agreement and operating model.

Our objective is to identify what DORA actually requires and translate those requirements into contractual provisions that work with the service being provided.

© Withlaw 2015 – 2026 – All rights reserved

Legal information / Privacy Policy / Credits / Contact us / Share / Follow us on LinkedIn