Most European financial entities handled the first phase of the Digital Operational Resilience Act as a policy exercise. Frameworks were written, committees were stood up, and third-party risk teams took ownership. The part that has proved hardest is narrower and less strategic: producing a complete, accurate and repeatable register of information from contract data that was never structured for the purpose.
DORA, Regulation (EU) 2022/2554, has applied since January 2025 and treats ICT third-party arrangements as a supervised category rather than a procurement matter. Article 30 prescribes contractual provisions that must be present in every ICT services arrangement, with an enhanced set where the arrangement supports a critical or important function. Article 28 requires a register of information covering all such arrangements, reported to the competent authority.
The practical consequence is that vendor paper became regulated data. A clause that exists but cannot be located, classified and evidenced within a reporting window is a gap in a submission. This guide covers how to structure that data, where the gaps usually sit, and what to track after signature.
What Article 30 actually asks the contract to contain
The baseline provisions apply to every ICT services arrangement, and the enhanced provisions apply where the service supports a critical or important function. Each of these maps to a field that must be reportable, not merely to language that must exist.
- Service description and locations, a clear and complete description of the ICT services, together with the regions or countries where services are provided and where data is processed and stored.
- Data protection and availability, provisions on availability, authenticity, integrity and confidentiality of data, and on access to and recovery of data in the event of insolvency, resolution or discontinuation.
- Access, inspection and audit rights, unrestricted rights of access, inspection and audit for the entity, its appointed third parties and the competent authority, exercisable without hindrance.
- Incident assistance and reporting, the obligation on the provider to assist at no additional cost, or at a pre-determined cost, when an ICT incident affects the service.
- Termination rights and exit strategies, defined termination grounds and notice periods, plus transition arrangements allowing the entity to exit without disruption to business or regulatory compliance.
For arrangements supporting critical or important functions, DORA layers additional requirements including full service level descriptions with precise quantitative and qualitative performance targets, provider participation in the entity security awareness and training programs, and, where relevant, participation in threat-led penetration testing. The classification decision therefore determines the clause set, which is why it has to live on the contract record rather than only in a risk register.
Policy documents can describe intent. A register of information cannot. It is a structured submission covering every ICT arrangement, its provider, its function classification and its subcontracting chain, which means the underlying contract data has to be complete and consistently coded, and has to be reproducible on demand.
Where DORA contract programs run into trouble
The difficulties are consistent, and none of them are about the quality of the legal drafting.
- Incomplete population. The register covers all ICT services arrangements, not only those procured through a formal vendor process. Shadow arrangements, intragroup agreements and services embedded inside broader contracts are the common omissions.
- Classification held outside the contract. When the critical or important function determination lives only in a risk system, nobody can tell from the agreement which clause set applies, and remediation programs prioritize the wrong contracts.
- Subcontracting chains at tier two and beyond. DORA expects visibility into subcontracting that supports critical or important functions. Most registers are accurate at tier one and thin below it, because the data depends on provider disclosure that nobody tracks as an obligation.
- Audit rights that are never exercised. Unrestricted access rights are negotiated and then left dormant. When a supervisor asks how the right has been used, the absence of any exercise record is itself a finding.
- Exit strategies drafted but not tested. An exit plan with no owner, no dependency mapping and no test date is a clause. Supervisors are asking about testing, not about drafting.
A five-step remediation sequence
Step 1, Fix the population before the clauses
Identify every arrangement that delivers ICT services, including those inside non-technology agreements. A clause remediation program run against an incomplete population produces a confident but wrong register.
Step 2, Put the function classification on the contract record
Record whether each arrangement supports a critical or important function, who decided, when, and on what basis. This field drives the applicable clause set, the register content and the remediation priority.
Step 3, Map clauses to reportable fields
Extract the Article 30 provisions as structured attributes rather than as located text, so a register submission is a query rather than a project. This is the same discipline described in the third-party risk contract automation guide.
Step 4, Track disclosure and audit rights as obligations
Subcontractor disclosure, notification of material changes, incident assistance timelines and audit access are commitments with owners and dates. Represent them as tracked obligations so lapses appear on a report.
Step 5, Give every critical exit strategy an owner and a test date
Assign accountability for each exit plan, map the dependencies it assumes, and schedule a test. Record the outcome, because the evidence of testing is what a supervisor will ask for.
See DORA contract data as a queryable register
Aavenir structures ICT third-party terms, function classification and subcontracting chains so register content is produced from live contract data.
Why DORA and existing third-party risk work do not simply overlap
Financial entities that already run mature outsourcing programs under earlier supervisory guidance often assume DORA is a relabeling exercise. The frameworks do overlap substantially, and reusing the existing governance is sensible. The difference is granularity and reproducibility. Earlier regimes largely required entities to have policies, perform due diligence and maintain oversight of material outsourcing. DORA requires a defined clause set in every ICT arrangement, a specific classification decision per arrangement, structured visibility into subcontracting that supports critical or important functions, and a register that is submitted rather than merely maintained. That is a data problem more than a policy problem, and it is why entities with strong frameworks still find their contract repositories underpowered. Entities operating on both sides of the Atlantic face the same structural issue under US interagency third-party risk expectations, which is covered in the SOX and third-party risk exam checklist.
Baseline and enhanced provisions at a glance
The summary below is a planning aid rather than a legal analysis, and the operative text of DORA and its regulatory technical standards should govern any remediation scope.
| Provision area | All ICT arrangements | Critical or important functions | Field to hold on the record |
|---|---|---|---|
| Service description and locations | Required | Required | Service scope, processing locations |
| Service levels | Description | Precise quantitative targets | SLA targets and measurement basis |
| Audit and inspection access | Required | Required, unrestricted | Right type, last exercised date |
| Subcontracting conditions | Required | Enhanced conditions and monitoring | Approved subcontractor chain |
| Exit strategy | Required | Required, with transition period | Plan owner, dependencies, test date |
DORA did not change what a good vendor contract says. It changed how quickly an entity has to prove what its contracts say, across a complete population, in a structured submission. Entities that treat the register as a reporting output of live contract data rather than as an annual data-gathering exercise spend far less effort and produce a defensible answer. The post-signature commitments underneath are covered in obligation management for financial services.
For related guidance, see DORA ICT contract clauses, a register-ready checklist, OCC and FFIEC vendor contract expectations, explained and Vendor contract controls for OCC and FFIEC exam readiness.
