Eighteen months after DORA came into force, a finding is emerging from the first checks carried out by European regulators: the large majority of financial entities in scope have built their ICT register and mapped their critical dependencies. But Article 28, which sets out the contractual requirements for arrangements with third-party ICT providers, remains systematically under-addressed. In practice, existing contracts have been reviewed superficially, without integrating the specific clauses the regulation imposes. This is not a question of bad faith: it is a question of technical and legal complexity that few teams have had the time to absorb. Here is what is missing, and what it means in practice.
Article 28 in the DORA hierarchy: what companies underestimate
DORA structures third-party ICT risk management around two levels. The first, the third-party risk management policy, the information register and the dependency mapping, has received significant attention. The second level, Article 28, is different in nature: it does not concern the assessment of risk, but the contractual framing of each ICT arrangement with an external provider. Its requirements are precise, prescriptive and enforceable.
Article 28 distinguishes two scopes. The clauses of Article 28.3 apply to all ICT contracts. The enhanced requirements of Article 28.4 target contracts covering critical or important functions, those whose failure or interruption would materially affect business continuity. The distinction is critical: a generic cloud email contract and a core banking system contract do not receive the same treatment. But identifying "critical or important" functions within the meaning of DORA is itself an exercise that many entities have not finalised with the required precision.
The ECB published its first observations on DORA compliance at significant institutions under direct supervision at the end of 2025. Among the most frequent gaps identified: the absence of audit and access clauses for ICT third parties, insufficient continuity clauses, and no specifications on subcontracting chains. These three points correspond precisely to the requirements of Article 28.
What your ICT contracts probably do not yet cover
Article 28.3 imposes a minimum baseline in every ICT contract: a precise description of the services and service levels (SLAs), the location of data and processing systems, provisions on portability and reversibility, information security requirements, and mechanisms for reporting ICT incidents. Most of these elements appear in recent contracts, although often not precisely enough to meet DORA standards (best-effort SLAs no longer pass).
Where gaps become systematic is in the Article 28.4 requirements for critical functions. First, audit rights. DORA requires that the financial entity can conduct audits at the ICT provider, directly or through appointed third parties, and access any relevant information. In practice, most cloud providers offer audit rights limited to third-party reports (SOC 2, ISO 27001) or questionnaires. This is not sufficient within the meaning of DORA. The clause must be negotiated and must allow on-site audits, not only documentary ones.
Second, subcontracting clauses. DORA requires the contract to identify the conditions under which the provider may use ICT subcontractors, with a prior information obligation and a right of objection for critical functions. Do your contracts with a hyperscale cloud provider explicitly cover this requirement? For the great majority of standard AWS, Azure and GCP contracts not renegotiated after DORA, the answer is no.
Third, continuity and exit provisions. Article 28.4(f) requires documented business continuity plans and exit strategies, including data portability and reversibility periods. This is not a generic "right to portability" clause: it is a tested operational plan, with defined RTOs and RPOs, and contractual commitments from the provider. Most cloud contracts include references to data portability without a committed timeframe, without technical specification, and without an exit plan.
Critical ICT third-party providers: a separate regime
Beyond the general contractual obligations, DORA introduces a direct oversight regime for Critical ICT Third-Party Providers (CTPPs). The hyperscalers (AWS, Azure, GCP, Oracle) and certain specialised service providers (core banking, payments) were designated as CTPPs in 2025 by the European Supervisory Authorities (EBA, EIOPA, ESMA). This status means they are subject to direct ESA oversight, but also that financial entities using their services have additional documentation and communication obligations.
The practical point often missed: financial entities using CTPPs must ensure their contracts include cooperation clauses with supervisory authorities in the context of CTPP examinations. Standard hyperscaler contracts do not include them, or include them in wording that may be insufficient. This point should be treated as a priority for contracts covering critical functions with designated CTPPs.
How to audit your contractual exposure quickly
A comprehensive Article 28 compliance audit is a project of several weeks. But it is possible to identify the most critical gaps in under a month, with a targeted approach built around three questions.
First question: have you identified your critical or important functions within the meaning of DORA? If this identification is not formalised in your ICT register, you cannot know which contracts are subject to the enhanced Article 28.4 requirements. This is the mandatory starting point.
Second question: do your contracts with ICT providers covering these critical functions include direct audit rights (not only third-party reports)? If the answer is no or uncertain, these are the contracts to review first. The absence of audit rights is the gap most frequently raised by inspectors and the hardest to defend in an inspection.
Third question: do your contracts with designated CTPPs include cooperation clauses with ESA supervisory authorities? If you use AWS, Azure, GCP or Oracle for critical functions, check this point within 30 days.
Presidio includes an ICT third-party contract management module aligned with Article 28 requirements, with clause templates and review workflows. See our analysis of DORA operational resilience. To assess your contractual exposure in 30 minutes: contact us.
Conclusion
DORA Article 28 imposes a precise contractual standard that most ICT contracts in place do not meet, not through negligence, but because the requirements are new, specific, and often in tension with the standard terms of major cloud providers. Three gaps concentrate the real regulatory risk: insufficient audit rights, incomplete framing of subcontracting chains, and the absence of operational exit plans. These three points are where inspectors focus first.
Entities that treat Article 28 as a full contract renegotiation exercise, rather than a superficial documentary review, will build DORA compliance that withstands inspections. Those that stop at updating the ICT register will discover the gap at the wrong moment.