The contractual checklist

The European customer's primary instrument of leverage is not regulation in the abstract — it is the specific clauses in specific contracts. This chapter provides a checklist for IT and cloud contracts. Most items consolidate existing regulatory requirements (DORA, EU Data Act, the Cyber Resilience Act, NIS2) into one operational framework, rather than introducing new layers.

Regulatory context: what is already in force

Five instruments shape the contractual landscape in 2026:

• DORA (Digital Operational Resilience Act) — in force since 17 January 2025 for 22,000 financial institutions. Requires a formal exit strategy, audit rights, and subcontractor monitoring. On 18 November 2025, 19 ICT providers were designated as critical (CTPP) — including AWS, Azure, and Google Cloud.
• EU Data Act — provider switching for cloud services — effective from 12 September 2025. The customer must be able to initiate migration with two months' notice, followed by 30 days of transition and 30 days for data retrieval. Phased prohibition of switching fees from January 2027.
• NIS2 — transposed in most member states in 2024–2025. Expanded scope to ~160,000 entities.
• Cyber Resilience Act (CRA) — full obligations from 11 December 2027. Requires SBOM and vulnerability management across the product lifecycle.
• AI Act — phased into force 2025–2027.

The checklist

#	Area	Requirement	Regulatory basis
1	Data residency	Contractual guarantee of data location in EU/EEA; explicit list of data centres; notification on change	GDPR Art. 44–49, Data Act
2	Encryption keys	BYOK or HYOK; customer holds master key; provider has no plaintext access to keys	DORA, best practice
3	Right of exit	Documented exit strategy; data migration in open format; maximum exit time ≤ 6 months; no penalty fees for departure	Data Act Art. 23–31, DORA
4	SBOM	Provider supplies an up-to-date Software Bill of Materials for all delivered products	CRA
5	Subcontracting	Explicit list of subcontractors; customer right of veto on change of subcontractor	DORA, NIS2
6	Security patches	SLA on critical patches ≤ 72h; customer right to test patches in staging environment before deployment	CRA, best practice
7	Audit rights	Customer or third party (auditor) has right of audit of provider's security controls	DORA Art. 28
8	Business continuity	Provider demonstrates tested BC/DR plan; customer participates in annual BC test	DORA, NIS2
9	Jurisdictional transparency	Explicit identification of jurisdictions in which the parent company, operator, and subcontractors are based; risk analysis of extraterritorial legislation	Best practice
10	Concentration limits	Organisation conducts internal review — no single supplier provides more than two critical systems without management approval	DORA (ICT risk management)

How to use this checklist

The checklist is not a contract template. It is a list of provisions to negotiate. Larger providers will resist some of them; some are non-negotiable in standard terms; some are achievable only at specific contract scales. The realistic application:

1. At every contract renewal, run through the checklist and identify which items are present, which are absent, and which need strengthening.
2. For top-10 critical suppliers, do not wait for renewal — initiate proactive amendments.
3. For new contracts, use the checklist as the starting position in vendor selection. Vendors who reject most items reveal where their commercial interests sit.
4. Document the gap. Where the checklist is not satisfied, document why and what compensating controls are in place. This document is itself an asset in regulatory examinations under DORA.

What this checklist does not solve

The checklist provides leverage; leverage is necessary but not sufficient.

It does not solve the political layer (negotiating with the U.S. on the CLOUD Act, regulatory diplomacy in the WTO).

It does not solve issues that require collective EU action — building new fabs, supporting the RISC-V ecosystem, energy policy for data centres. Those belong to state planners, not individual CIOs.

What it does solve: the organisation's own contractual position with its current and future suppliers. That position is what makes regulation operative rather than aspirational.