DORA ICT contract clauses and the register of information

The Digital Operational Resilience Act changed the nature of contract data in financial services. Before it, third-party terms were a legal artifact reviewed at negotiation and consulted during a dispute. Under DORA, a defined set of contract attributes must be maintained as structured data across every ICT contractual arrangement and made available to supervisors in a prescribed register format.

That shift is administratively larger than it appears. A firm with several hundred technology suppliers may hold thousands of contractual arrangements once amendments, order forms and intra-group agreements are counted. Each needs identified contracting entities, a service description, processing and storage locations, service levels, and clarity on whether the arrangement supports a critical or important function. None of that is reliably available from a document repository.

This guide covers the contractual terms DORA requires, how criticality assessment changes the obligation set, where register data actually comes from, and the sequence for getting a portfolio into a state where the register can be produced from systems rather than reconstructed each cycle.

The contractual terms DORA expects

DORA sets a baseline of terms for all ICT contractual arrangements and a heavier set for those supporting a critical or important function. The baseline is where most remediation effort lands, because it applies broadly.

• Service description and locations, a clear and complete description of the functions and services provided, and the countries where services are performed and where data is processed and stored
• Service level provisions, quantitative and qualitative performance targets with defined measurement, so degradation can be identified before it becomes an incident
• Incident reporting and assistance, obligations on the provider to report ICT incidents affecting the service and to assist the financial entity at no additional cost or at a pre-agreed cost
• Access, inspection and audit rights, unrestricted rights of access, inspection and audit for the entity and for competent authorities, with agreed exercise mechanics
• Termination and exit, termination rights covering provider breach and supervisory circumstances, plus transition periods and assistance obligations that make exit executable

Arrangements supporting a critical or important function add requirements, including notice periods for termination, participation in the entity’s security awareness and resilience testing where relevant, and more specific provisions on subcontracting of the function. The practical implication is that criticality assessment is not a risk exercise conducted alongside contracting. It determines which clauses are mandatory, so it has to be resolved before the contract is signed and recorded against the arrangement afterward. Where the classification changes later, because a function grows in importance or a service is extended, the clause set has to be revisited rather than left at the level set at award.

Where register data actually comes from

The register of information draws on several systems, and the failure mode is almost always that they disagree. Reconciling them once, at source, is cheaper than reconciling them every reporting cycle.

• The contract record. Provides parties, dates, service description, locations, service levels and termination terms, which is why these attributes need to be captured as fields rather than left in prose
• The entity and supplier master. Supplies legal entity identifiers for both sides, which is the attribute most commonly missing or inconsistent across group structures
• The function and service catalogue. Links each arrangement to the business function it supports, which is what makes the criticality determination auditable rather than asserted
• The risk and resilience assessment. Carries the criticality classification, concentration analysis and substitutability view that determine which additional clause requirements apply
• The subcontractor inventory. Records the chain beneath the direct provider, which supervisors expect to be visible for arrangements supporting critical or important functions

A five-step remediation sequence

Step 1, Establish the arrangement inventory

Count contractual arrangements, not suppliers. Amendments, order forms, statements of work and intra-group agreements each qualify. Most firms find the arrangement count is several times the supplier count, which reframes the scale of the work immediately.

Step 2, Classify criticality against functions

Map arrangements to business functions and apply the critical or important test consistently. Record the determination, the date and the rationale against the arrangement, because the classification drives clause obligations and will be examined.

Step 3, Run clause gap analysis at portfolio scale

Use clause extraction to test every in-scope arrangement against the required term list and produce a gap register by provider and by clause. Manual review of a full ICT portfolio does not complete inside a normal remediation window.

Step 4, Prioritize remediation by criticality and renewal

Sequence renegotiation by criticality first, then by upcoming renewal dates, so that a large share of gaps close through the normal renewal cycle rather than through standalone amendment negotiations.

Step 5, Automate register production

Wire the register fields to their source systems so the register is generated rather than assembled. The test is whether a supervisory request can be answered in days without a project team, using data that was captured once at contracting time rather than re-derived from documents.

Why exit strategies fail the contractual test

Exit provisions are the requirement most likely to look satisfied on paper and fail in substance. Many technology agreements contain a termination clause and a short transition assistance sentence, which is not the same as an executable exit. DORA expects the arrangement to support an orderly transition without disruption to the business function, which implies defined transition periods, data return in a usable format, continued service during transition, and clarity on who bears the cost. Firms that assess their own exit readiness usually find the constraint is not the clause but the dependency, particularly where data formats are proprietary or where the provider also supplies the alternative. The contract cannot solve a substitutability problem, but it can make the problem visible early. That is why exit terms, concentration analysis and the wider third-party risk workflow need to be connected rather than assessed on separate cycles.

Baseline terms versus critical function terms

The table summarizes how requirements differ between general ICT arrangements and those supporting a critical or important function.

DORA does not ask financial entities to renegotiate everything at once. It asks them to know what they have, classify it consistently, close the clause gaps that matter most, and produce the register from data rather than from documents. Firms that treat this as a contract data project finish once and report continuously. Firms that treat it as a reporting project repeat the abstraction work at every request, and the answer they file is only as current as the last manual pass. The distinction becomes expensive at the second or third cycle, when the portfolio has moved and the previous abstraction no longer describes it.

For related guidance, see The bank’s guide to DORA ICT third-party contract terms, DORA and ICT contracts: what Article 30 requires and Bank fintech partnership agreements, the control questions.

Aavenir Financial Services PracticeICT third-party risk, regulatory contract terms and supervisory reporting