DORA Article 30: Key Contractual Provisions Checklist

DORA Article 30 sets out the mandatory clauses every contract with an ICT third-party provider must contain: service scope, data location, security requirements, audit and access rights, and termination terms. Contracts supporting a critical or important function face a second, stricter tier of clauses on top: sub-outsourcing conditions, exit strategies, and continuous monitoring rights. Here is what belongs in each tier, and where entities most often fall short.

What Article 30 covers, and why it exists

Before DORA, ICT outsourcing terms were governed by a patchwork of sector-specific guidelines, EBA outsourcing guidance for banks, EIOPA expectations for insurers, each with slightly different contract checklists. Article 30 replaces that patchwork with one directly applicable standard: a defined list of clauses that must appear in writing in every contractual arrangement for ICT services, regardless of sector.

The logic is straightforward. A financial entity remains fully accountable for an outsourced function even after signing the contract; DORA does not let responsibility travel with the service. Article 30 makes sure the contract itself gives the entity the practical means to meet that responsibility: visibility into what the provider is doing, the right to check it, and a documented way out if the arrangement fails. Weak or missing contract clauses are one of the first things a supervisor checks during a DORA gap assessment, because a missing clause cannot be fixed after an incident, only before one.

The baseline clauses every ICT contract needs

Article 30(2) sets a floor that applies to every ICT services contract, whatever the function's criticality. At minimum, the contract must set out, in writing:

1. A clear, complete description of the service, including whether sub-outsourcing is permitted and under what conditions.
2. Where the data will be processed and stored, and a commitment that the provider will notify the entity of any planned change in location.
3. Full and accessible availability, integrity, security, and protection provisions for personal and other relevant data.
4. Guarantees on the provider's own business continuity, so the entity is not the only party responsible for continuity of the overall service.
5. The provider's obligation to assist the entity with any ICT-related incident connected to the service, at no extra cost or at a cost agreed in advance.
6. Cooperation with the entity's competent authority and resolution authority, including granting them the same access and audit rights the entity itself holds.
7. Termination rights and minimum notice periods, matched to the entity's regulatory and business needs.
8. Support for the entity's own exit, including a transition period during which the provider continues to supply the service under the same terms.

These are baseline requirements. A contract for a low-risk, easily replaceable service (a scheduling tool, a non-critical analytics dashboard) still needs all eight, just documented at proportionate depth.

The additional clauses for critical or important functions

Where an ICT service supports a critical or important function, Article 30(3) adds a second layer of clauses on top of the baseline. These exist because the entity's tolerance for a failure or a slow exit is much lower when the function underpins core operations, payments processing, trading, policy administration. The additional clauses cover:

• Full service level descriptions, with precise, measurable performance targets and consequences for missing them.
• Advance notice periods for planned changes to the ICT service that could affect the entity's ability to operate, long enough for the entity to assess and, if needed, object.
• Requirements for the provider to develop, test, and maintain a business contingency plan, including ICT security measures and tools to restore data with minimal disruption.
• The entity's right to monitor the provider's performance on an ongoing basis, not only at contract signing or renewal.
• Unrestricted rights of access, inspection, and audit by the entity, its competent authority, and third parties it appoints, including the right to take copies of relevant documentation on-site.
• Conditions for sub-outsourcing, spelling out whether it is permitted and, if so, the notice and objection process (this is the clause the subcontracting RTS fills out in far more detail).
• A comprehensive, documented exit strategy, with a defined transition period and continuity of service until migration is complete.

Exit strategy: the clause supervisors check first

Of everything on this list, the exit clause is where reviews find the most gaps. DORA does not just want a contract to be terminable; it wants the entity to be able to leave without an operational cliff edge. The exit strategy itself lives under Article 28(8) as a broader planning obligation, but Article 30 is where it becomes contractually enforceable: the provider has to commit, in the contract itself, to continuing the service on unchanged terms through an agreed transition period, and to returning or securely deleting the entity's data once the arrangement ends.

A contract that lets either party terminate on short notice, with no transition commitment, technically satisfies a termination-rights box but fails the exit-strategy intent entirely. The entity would have the legal right to leave and no practical way to do so without disrupting the underlying business. Reviewers increasingly treat "termination right without a transition commitment" as a finding on its own, not a formality.

Where sub-outsourcing conditions connect to concentration risk

The sub-outsourcing clause required under Article 30(3) is the contract's first line of defence against a problem that often only shows up later: concentration risk hiding inside an apparently diversified vendor list. Two providers with different names and separate contracts can still depend on the same fourth-tier data centre or cloud region if the chain beneath them was never made contractually visible.

Getting the sub-outsourcing clause right at signing is cheaper than discovering the dependency during a register of information refresh, which is exactly the exercise entities are already running under Article 28. Building the contract-review step directly into that register process, rather than treating them as separate workstreams, is the more efficient sequence.

Where entities go wrong in practice

A few patterns recur across gap assessments and internal audits:

• Treating Article 30 as a legal-review checkbox rather than an operational one. Legal counsel confirms the clause exists; nobody checks whether the audit-rights clause is actually usable in practice (can the entity realistically exercise on-site inspection, or is the right theoretical?).
• Applying baseline clauses to critical functions. The clause set is tiered for a reason; a critical payment-processing contract with only Article 30(2)'s eight baseline items is under-specified, even if every item is present.
• Legacy contracts pre-dating DORA that were never re-papered. Article 30 applies to the substance of the arrangement, not the date it was signed; contracts running since before January 2025 still need to meet the standard.
• No process for keeping the ICT third-party provider register in sync with actual contract terms, so the register says one thing and the signed contract, quietly amended, says another.

A practical drafting checklist

• Map every ICT contract against the applicable tier (baseline or critical-function) before renewal, not after a supervisor asks.
• Test the audit-rights clause, not just its wording. Confirm the provider will actually grant the access described, including for the entity's competent authority.
• Write the exit clause with a named transition period, not a vague "reasonable cooperation" commitment.
• Extend visibility clauses down the subcontracting chain, matching what the subcontracting RTS requires for critical or important functions.
• Cross-reference contract terms against the register of information on a fixed schedule so drift between the two gets caught early.

Entities working through a full DORA checklist or preparing for their next audit cycle can use the DORA Readiness Score to see how the third-party risk pillar, contracts included, scores against the other four.

Sources

• Regulation (EU) 2022/2554 (DORA), Article 30, EUR-Lex.
• Regulation (EU) 2022/2554 (DORA), Article 28(8), EUR-Lex.
• ESMA, Digital Operational Resilience Act (DORA).
• Commission Delegated Regulation (EU) 2025/532 of 24 March 2025, EUR-Lex, applicable since 22 July 2025.

Last updated: 24 August 2026.