The DORA Contract Clauses Most Vendor Paper Doesn’t Have

Most DORA third-party programmes focus on the register and miss the clause. The register tells a supervisor what you rely on. Article 30 is what actually protects you when reliance goes wrong — and generic vendor paper almost never meets it.

I have written elsewhere about the Register of Information as a live supervisory instrument and about the data-quality failures that plagued the first submission cycles. This piece is about the layer underneath the register: the contractual terms DORA requires you to have actually negotiated into every arrangement supporting a critical or important function, under Article 30 — and the gap between what most vendor contracts say and what the regulation requires them to say.

Why a standard vendor contract usually fails

Most ICT vendor contracts are drafted by the vendor, for the vendor, and negotiated by procurement teams optimising for price and service levels. That produces contracts that are commercially reasonable and, in a meaningful number of cases I have reviewed, silent or vague on exactly the clauses DORA makes mandatory for arrangements supporting critical or important functions: audit and access rights that let you or your supervisor actually inspect the provider, not just request a report; termination rights triggered by specific, named events rather than only for material breach; cooperation obligations during your own incident response, not the vendor’s; and a tested, documented exit plan — not an exit clause, an exit plan, with a credible alternative already identified.

The subcontracting layer is where this gets harder still. Delegated Regulation (EU) 2025/532 tightened what you must determine and assess when a critical function is supported by a chain of subcontractors, not just your direct provider — chain visibility, change-notification rights, and termination rights if a subcontractor introduces risk beyond your tolerance. A cloud provider’s own sub-processors are routinely invisible in the primary contract, which means the entity actually carrying your critical function may be several layers removed from anyone you have a direct legal relationship with.

Where this connects back to the register

The register and the contract have to agree, and supervisors are now checking. If your Register of Information states a function is critical, supported by a named provider, with an exit strategy — and the underlying contract has no exit-plan clause, no audit-rights clause, and no visibility into subcontracting — you have filed a register that your own contract cannot support. That inconsistency is precisely the kind of gap automated supervisory cross-referencing is built to surface, and it is a harder conversation to have with a supervisor than either problem would be alone, because it suggests the register was completed as a filing exercise rather than a true reflection of your actual arrangements.

The practical fix

Retrofitting Article 30 clauses into live contracts is not fast, and it is worth being honest about that going in. Renewal cycles, not blanket renegotiation, are usually the realistic path — which means the priority sequencing matters: contracts supporting your most critical functions, with providers who show any concentration risk, come first. For designated Critical Third-Party Providers specifically, the leverage dynamic shifts, because ESA oversight of the CTPP itself creates pressure the CTPP cannot simply absorb the way an unregulated vendor can shrug off a single client’s demands.

This is, underneath the legal language, the same evidence discipline I write about across every regulation on this site: a register is only as good as the contract that backs it, and a contract clause is only as good as the record that proves it was actually exercised — the audit that actually happened, the exit test that actually ran. Both live in the same evidence chain.

A concrete version of the gap

Take a Cyprus-licensed investment firm running its core trading infrastructure on a single cloud provider. The Register of Information correctly names the provider as critical and states an exit strategy exists. The underlying master services agreement, signed three years before DORA applied, gives the firm a right to request data export on termination — standard commercial boilerplate — but no tested exit runbook, no named alternative provider, and no contractual audit-access right beyond the provider’s own annual third-party attestation report, which the firm has never actually reviewed against its own risk register. On paper, compliant. Under a supervisor’s specific questions — when did you last test the exit, who is the alternative provider, can you show me the audit you conducted — the register’s “exit strategy exists” collapses into “we believe one would be possible.” That collapse is the actual finding, and it was invisible until someone asked the specific question rather than the general one.

If your Register of Information and your actual vendor contracts have not been checked against each other line by line, that reconciliation is worth doing before a supervisor does it for you. A technology control assessment covers exactly this gap; see the wider argument on proving DORA compliance to a supervisor.