EU-wide

DORA Article 30: the mandatory clauses for ICT contracts

Fintech Passport

May 6, 2026 · 7-min read

DORA Article 30: the mandatory clauses for ICT contracts

The Register of Information is the manifest. Article 30 is the substance. DORA’s contractual provisions reach inside every ICT contract a financial entity holds — defining a non-negotiable list of clauses that must be present, with additional requirements where the service supports a critical or important function. Updating contracts to meet Article 30 is the unglamorous half of DORA, and the half supervisors will sample first at any inspection. This piece walks through what must be in the contract, what changes when the function is critical, and the negotiation reality for fintechs.

1. Why Article 30 exists

DORA — Regulation (EU) 2022/2554, applicable from 17 January 2025 — has a simple thesis: ICT third-party risk is a systemic concern, and the supervisor needs visibility through the contract. Article 30 turns that thesis into specific clauses every financial entity must include in every ICT contract. The provisions are mandatory and uniform across the EU; member states have no discretion to dilute them.

The companion to Article 30 is the Register of Information — the manifest at Article 28 — which catalogues every ICT contract and points to the underlying clauses. The two work together: the Register tells the supervisor where the contracts are; Article 30 tells the supervisor what must be in them.

2. Who must include the clauses

Every financial entity defined in Article 2 of DORA — credit institutions, electronic-money institutions, payment institutions, investment firms, fund managers, insurers, CASPs, central counterparties, trading venues, and others. The obligation is on the financial entity, not on the ICT third party. The contract is the artefact; the entity is responsible for ensuring it carries the required clauses.

For services supporting a critical or important function, Article 30(3) layers additional requirements on top of the Article 30(2) baseline. The “critical or important” classification is therefore upstream of the contract drafting — see our Register piece for the test.

3. The Article 30(2) baseline — every ICT contract

Every ICT contract, regardless of the underlying service criticality, must include:

Service description — clear, complete description of the functions and services covered, with whether sub-contracting is permitted
Locations — the locations (regions or countries) where the contracted services are to be provided and data processed and stored
Data confidentiality, availability, integrity and authenticity — provisions on the protection of data, including personal data
Right of access, recovery and return — the entity’s right to access its data and the data return / migration provisions on contract termination
Service-level agreements with measurable performance targets and remedies for breach
Cooperation with competent authorities — the third party’s obligation to cooperate with the entity’s supervisors
Termination rights — the entity’s right to terminate, including for non-compliance, breach, supervisory recommendation, or impossibility of supervision
Description of training and exercises — for staff at the third party who handle the entity’s data or systems

4. Article 30(3) — for critical or important functions

The Article 30(3) additions are:

Detailed service-level agreements including agreed quantitative and qualitative performance targets within the agreed service levels — concrete, measurable, with remedies
Notice periods and reporting obligations by the third party to the financial entity, including notification of any development that may have a material impact on the third party’s ability to provide the services
Training on ICT security awareness and digital operational resilience for the third party’s personnel
Right of the financial entity to monitor the third party’s performance on an ongoing basis, including through unrestricted access to the third party’s premises, audit rights and inspection rights — exercisable directly, by an appointed auditor, or by the supervisor
Cooperation in audits — both for entity-led and supervisor-led audits, with the third party expected to facilitate access to information, premises and personnel
Exit strategy — including an obligation on the third party to support a transition to an alternative provider or in-house solution, with sufficient transition time
Termination rights — extended to include termination for the third party’s failure to comply with applicable laws, the third party’s significant breach of contract, evidenced ineffectiveness in the recovery of services, or the supervisor’s order
Sub-contracting controls — explicit notification and consent rights when the third party intends to use sub-contractors for material functions, plus chain-of-responsibility provisions

5. The sub-contracting question

Sub-contracting is where most enforcement attention has historically landed. Article 30(3) requires that the financial entity has visibility and control over the third party’s sub-contracting decisions for material functions. In practice:

The contract lists permitted sub-contractor categories and provides for prior notification of new sub-contractors
The third party warrants that sub-contracts will mirror the relevant Article 30 clauses
The financial entity retains the right to terminate where a proposed sub-contractor is unacceptable
The chain of responsibility flows back to the third party — the financial entity does not have a direct contractual relationship with the sub-contractor but holds the third party accountable for the sub-contractor’s performance

For services supporting critical or important functions, sub-contracting depth (how many tiers down) is a live supervisory question. The Register of Information captures the chain; the contract enforces it.

6. Negotiation reality with large ICT providers

The hardest part of Article 30 implementation is not the drafting — it is the negotiation with large ICT providers whose standard terms predate DORA and do not match the requirements. Three patterns emerge:

Provider has a “DORA addendum” — most major cloud and SaaS providers now ship a DORA-compliant addendum on request. Verify it covers the Article 30(3) layer, not just the baseline.
Provider offers a financial-services rider — broader than DORA but generally sufficient if drafted recently.
Provider negotiates from scratch — smaller providers, often the harder ones to bring into compliance. Article 30 is non-negotiable for the financial entity; the choice becomes accept the provider’s terms (and hold a contractual gap) or change provider.

The financial entity that takes a non-compliant contract for a critical or important function carries regulatory and reputational risk. A documented refusal by the provider to accept Article 30 terms is itself a finding at supervisory inspection.

7. The exit strategy — operationalised

For critical or important functions, the exit strategy is not a paper artefact. The contract must support an actual transition: the entity must be able to migrate the function to an alternative provider or in-house, within a reasonable timeframe, with the third party’s active cooperation. In practice this requires:

Documented data-format and integration specifications
Defined data-return procedures
Transition-assistance commitments (length, scope, cost)
Continuity provisions during the transition
An entity-side exit playbook tested at least annually

The supervisor will ask whether you have actually run the playbook on a sample. “We have an exit clause” is not the same answer as “we tested an exit on Provider X in Q3”.

8. Overlap with other regimes

Article 30 sits alongside several existing contract-rule frameworks:

EBA outsourcing guidelines — pre-DORA, still applicable to outsourcing more broadly. DORA Article 30 is more specific for ICT.
National outsourcing rules — for example CSSF Circular 22/811, MaRisk in Germany. Generally aligned with DORA but with national-specific overlays.
GDPR data-processing agreements — Article 28 GDPR DPA is a separate but adjacent obligation. Modern contracts handle both in a single instrument.

9. FAQ

Does Article 30 apply to small contracts?

The baseline at Article 30(2) applies to every ICT contract, regardless of size. The enhanced regime at Article 30(3) applies where the service supports a critical or important function — that is determined by the entity’s classification, not by contract value.

What if my existing contract is non-compliant?

The entity has an obligation to bring the contract into compliance, typically through a DORA addendum or amendment. Where the third party refuses, the entity must consider alternative providers, particularly for services supporting critical or important functions.

Are intra-group ICT services in scope?

Yes. Intra-group arrangements are captured under Article 30 — the same clauses apply. The Register of Information has specific tables for group-level coverage.

Do I need a separate DORA contract or is a clause set inside the existing contract enough?

An addendum to the existing contract is usually sufficient. The form does not matter; the substance does. Supervisors look at whether the required clauses are legally binding, not whether they sit in a stand-alone document.

How are audit rights actually exercised?

Through the entity directly, an appointed auditor, or the supervisor. For cloud providers, “pooled audits” — where multiple financial entities collectively commission an audit — are increasingly common to manage cost.

What if the provider is outside the EU?

The contractual obligations apply regardless of provider location. Cross-border data-flow rules (under GDPR) sit alongside DORA but are a separate compliance dimension.

10. What to do, today

Pull the inventory from your Register of Information and prioritise contracts supporting critical or important functions.
For each, request the provider’s DORA addendum or initiate a renegotiation.
Build a contract-tracking layer that flags missing Article 30 clauses against the Register of Information.
Test the exit strategy on at least one critical provider per year — document the test, the findings, the remediation.
For services supporting critical or important functions, treat sub-contracting depth as a real supervisory question and coordinate with the provider on chain-of-responsibility documentation.