The Digital Operational Resilience Act, Regulation (EU) 2022/2554, applies to a broad set of EU financial entities and took effect in January 2025. It changed what a supervisor can reasonably ask to see. Contract terms with technology suppliers are no longer a private commercial matter, they are evidence of operational resilience that a competent authority can request and review.
DORA Article 28 sets out the contractual provisions that arrangements with ICT third-party service providers must carry, with a further set where the service supports a critical or important function. That obligation is not satisfied by a policy statement. It is satisfied by language sitting inside executed agreements, and by an ability to retrieve it on demand.
Entities must also maintain a register of information covering all contractual arrangements for the use of ICT services, and report it to competent authorities. The register is a structured data problem. Most teams meet it with a spreadsheet assembled by hand each year, which is exactly where the effort and the reporting risk concentrate.
Why contract language became supervisory evidence
Before DORA, outsourcing governance in most EU financial entities ran on guidelines and internal policy. Terms varied by supplier, by legal entity and by year of signature. DORA narrowed that discretion. It states what arrangements with ICT third-party service providers must contain, and it expects entities to demonstrate it. Clause coverage is now a reportable control rather than a legal preference.
- Service description and data locations, including a clear account of the functions provided and the locations, by country or region, where data is processed and where the service is delivered.
- Availability and service levels, with performance targets described precisely enough for a monitoring team to test them, alongside the reporting the provider owes and the remedies when targets are missed.
- Incident notification and assistance, setting out how quickly the provider must notify ICT-related incidents affecting the service, and the assistance it will give at no additional cost or at a cost fixed in advance.
- Access, inspection and audit rights, covering rights of access, inspection and audit for the entity, for third parties it appoints and for the competent authority, with scope and frequency agreed in advance.
- Subcontracting, exit and termination, including the conditions under which services may be subcontracted, notice of material changes, defined termination rights, and an exit strategy with a usable transition period.
None of that language is exotic. Most of it already exists in a mature legal department, scattered across playbooks, precedent files and the memories of two or three senior counsel. The difficulty is coverage across several hundred supplier agreements, many signed years before the regulation existed and stored in formats nobody can query. Coverage, not drafting, is the binding constraint.
The register of information on ICT contractual arrangements is a reporting deliverable with a defined structure. If it is built by emailing business owners once a year, it will be stale before it is submitted, and every future submission repeats the same manual work. Populate it from contract metadata and the annual exercise becomes an extract.
Turning required provisions into a clause library
A clause library is the mechanism that converts a regulatory list into repeatable practice. Each required provision becomes a named clause with an approved position, one or two fallbacks, and a rule for when the stricter version applies. The library then does two separate jobs. It drafts new agreements consistently, and it gives you a query you can run across everything that is already signed.
- Separate the baseline from the critical tier. Every ICT arrangement carries the general provisions. Arrangements supporting critical or important functions carry more. Encode that split as a flag on the contract record so the right template and review path apply automatically.
- Write clauses to be testable, not merely present. A notification clause that says promptly cannot be monitored. A clause with a defined trigger, a defined recipient and a defined window becomes an obligation you can schedule, assign and evidence.
- Tie each clause to a register attribute. The required provisions and the register overlap heavily. Processing locations, function criticality, subcontracting and termination notice appear in both. Capture them once, at the clause, and let the register read that field.
- Version the library and keep the history. Supervisory expectations and internal risk appetite both move. When a clause position changes you need to know which executed contracts still carry the old wording and which renewal cycle reaches them.
- Give business owners a route that is not a negotiation. Most requests are routine. Guided intake plus a pre-approved template removes legal from the low-risk majority and concentrates senior review on arrangements supporting critical or important functions.
A five-step path from clause list to defensible register
Step 1, Build The Provision Map
Start with the required contractual provisions and write them as a checklist your reviewers agree on. Keep the wording general where you are unsure of a sub-paragraph, and describe the obligation rather than citing a number you cannot verify. This map is the specification for everything downstream, so settle it first.
Step 2, Classify The Portfolio
Identify every arrangement that involves ICT services, then flag which of those support critical or important functions. Criticality is a business judgment, so route it to function owners rather than settling it inside legal. The output is a scoped population, usually smaller than the full supplier list.
Step 3, Extract And Score Executed Contracts
Run the provision map against signed agreements. Clause extraction should return, for each contract, which required provisions are present, which are absent and which are present but weak. Score the gaps by criticality first and renewal date second, so remediation follows a calendar you can influence.
Step 4, Remediate Through The Renewal Cycle
Few teams can reopen an entire portfolio at once, and most should not try. Attach the gap list to each renewal and amendment as a mandatory checklist item, then escalate the critical arrangements that will not reach renewal in time and handle those by targeted amendment.
Step 5, Automate The Register Extract
Once provisions and register attributes live on the contract record, the submission becomes a report rather than a project. Set the extract to run monthly against the same fields, review the exceptions, and you will find data problems in March instead of the week before a filing deadline.
See what a DORA ready contract record holds
Walk through provision mapping, clause extraction and register attributes on a live portfolio, with the gap report a third-party risk team would carry into a supervisory dialogue.
Where legacy contracts fail, and how to triage them
Legacy agreements fail in predictable places. Audit rights are granted to the entity alone and do not extend to a competent authority or an appointed third party. Subcontracting is permitted on notice but with no right to object. Exit language exists but names no transition period, so the practical ability to leave is close to zero. Notification duties are drafted around commercial escalation rather than ICT-related incidents. None of this is visible from a contract list, which is why teams that automate third-party risk contract review get a remediation plan they can size, while teams working from a spreadsheet get a backlog they cannot.
Mapping provisions to fields, cadence and evidence
The table below is the shape of the control. Each required provision needs a home in the system of record, an attribute it feeds in the register, and an artifact you can produce when asked. Teams already running this discipline for financial reporting will recognize the pattern from a SOX and third-party risk exam checklist, and the same structure carries commitments forward into obligation management.
| Required provision | Contract record field | Register attribute | Evidence produced |
|---|---|---|---|
| Service description and locations | Service scope, processing country | Function and location data | Clause extract with source reference |
| Availability and service levels | Target, measurement basis, remedy | Service level indicator | Monitoring report against target |
| Incident notification and assistance | Notification window, named contact | Incident support terms | Notification log and response times |
| Access, inspection and audit rights | Audit scope, beneficiaries, frequency | Audit rights flag | Executed clause and audit calendar |
| Subcontracting, exit and termination | Consent basis, notice, exit period | Subcontracting and exit terms | Amendment history and exit plan |
DORA did not ask third-party risk teams to invent a new discipline. It asked them to make an existing one legible to somebody outside the firm. The entities that handle a supervisory request well will answer three questions from a system rather than a search, which arrangements are in scope, which provisions each one carries, and where the gaps sit. That is a data problem with a known solution, and far cheaper to solve early.
For related guidance, see The DORA guide to ICT contract registers and exits, The bank’s guide to DORA ICT third-party contract terms and OCC and FFIEC expectations for vendor contract files.
