The Digital Operational Resilience Act gives financial entities a specific and unusually concrete obligation: maintain a register of all contractual arrangements for the use of information and communication technology services, keep it current, and make it available to competent authorities. The register is reported in a standardized format, which removes most of the interpretive latitude that firms are used to in operational resilience reporting.
That standardization is the difficulty. The fields the register requires, service descriptions, function criticality, data processing locations, subcontracting chains, contract dates, termination provisions, are all facts that exist in executed contracts. Most firms hold those contracts across several repositories, in several formats, negotiated by several teams over more than a decade.
This guide describes how to build the register from contract data rather than from a spreadsheet exercise: which provisions the regulation requires, how criticality assessment changes the requirement set, how to handle subcontracting visibility, and how to keep the register current once the first submission is behind you.
The contractual provisions the regulation specifies
DORA sets a baseline of provisions for every ICT contractual arrangement, and an extended set where the arrangement supports a critical or important function. The baseline is where most remediation work sits, because it applies across the whole portfolio rather than to a short list of major providers.
- Service description and locations, a clear and complete description of the services, and the locations where they are provided and where data is processed and stored
- Service levels with quantitative targets, descriptions of service levels including precise quantitative and qualitative performance targets, updated on material change
- Incident notification and assistance, the provider's duty to notify incidents affecting the service, and to assist at no additional cost or at a pre-agreed cost when an incident occurs
- Access, inspection and audit rights, unrestricted rights of access, inspection and audit for the financial entity and for competent authorities
- Exit strategy and transition, termination rights, a defined notice period, and mandatory transition assistance during an exit
Audit and access rights are the provision most often present in outline and inadequate in substance. A clause permitting audit on reasonable notice, subject to the provider's security policies, may not deliver the unrestricted access the regulation expects, particularly where the provider's own subcontractors hold the relevant data. This is worth testing against the existing portfolio before assuming coverage. The same caution applies to service level descriptions, where a reference to a separate service catalogue that the provider maintains unilaterally is weaker than targets stated in the agreement itself.
Whether an ICT service supports a critical or important function determines the additional provisions required, the resilience testing expectations and the supervisory attention the arrangement attracts. The assessment is the firm's to make and defend, and it should be documented against the arrangement rather than held as institutional knowledge in the resilience team.
Where register data usually breaks down
Firms that have attempted the register generally report the same set of data problems, and they are contract data problems rather than reporting problems.
- Entity-level identification. The register requires consistent legal entity identification for providers, which exposes inconsistent counterparty naming accumulated across years of procurement.
- Arrangement granularity. A single master agreement may cover several distinct ICT services with different criticality. Registering the master agreement as one arrangement loses the distinction the regulation cares about.
- Subcontracting visibility. Material subcontractors supporting critical or important functions must be identifiable, and most contracts were not drafted to surface that chain.
- Intragroup arrangements. Services provided by other entities in the same group are in scope, and are frequently documented more informally than external arrangements.
- Currency of the data. The register must be kept current, which makes it a maintained dataset rather than a point-in-time submission exercise.
A five-step roadmap to a maintainable register
Step 1, Define the ICT service inventory first
Start from services rather than contracts. List the ICT services the firm consumes, map each to the business functions it supports, and only then identify the contractual arrangements behind each. Starting from contracts tends to miss services consumed under expense arrangements or embedded in broader business process outsourcing.
Step 2, Assess and document criticality
Determine for each service whether it supports a critical or important function, record the reasoning, and attach the assessment to the arrangement. This assessment is the input to the extended provision set and should be reviewable and re-performable rather than reconstructed each reporting cycle.
Step 3, Extract contract fields at scale
Pull the register fields from executed agreements: parties and identifiers, service description, dates, notice periods, governing law, data locations, audit rights, termination provisions and subcontracting terms. This is the step that determines whether the register is maintainable or rebuilt annually by hand.
Step 4, Run a gap and remediation pass
Compare extracted provisions against the required set, by arrangement and by criticality tier. Sequence remediation by criticality and by renewal date, since amendments at renewal carry far less friction than mid-term amendment requests.
Step 5, Wire the register to change events
Contract amendment, renewal, provider change of control, a new material subcontractor and a change in function criticality should each update the register automatically. Without this the register is accurate on the submission date and decaying from the day after.
Build the register from contract data, not spreadsheets
Aavenir extracts register fields from executed ICT agreements, tracks provision gaps by criticality tier, and keeps the dataset current as contracts are amended and renewed.
Why the register outlives the compliance deadline
Firms that treated the register purely as a submission obligation generally built it once, by hand, and are now facing the maintenance problem. Firms that built it from contract data found the register was substantially the same dataset their third-party risk function already needed for concentration analysis, exit planning and supervisory examination. That overlap is not accidental. The register asks which providers support which functions, where data sits, what the exit route is and who the material subcontractors are, which are the questions any credible operational resilience program is asking anyway. Firms already running structured third-party risk contract automation and examination evidence through one platform tend to find the DORA work extends an existing register rather than creating a parallel one, which matters because parallel registers diverge. The maintenance burden is the deciding factor over a multi-year horizon. A register assembled by hand is accurate for as long as it takes the next amendment to be signed, and firms running several hundred ICT arrangements sign amendments continuously.
Baseline and extended provisions by arrangement type
The requirement set differs between arrangements supporting critical or important functions and the remainder of the portfolio. The distinction below reflects how firms typically structure their remediation.
| Provision area | All ICT arrangements | Critical or important functions |
|---|---|---|
| Service description and data locations | Required | Required, with change notification |
| Service levels | Descriptions required | Precise quantitative targets required |
| Audit and inspection | Access rights required | Unrestricted rights, including for authorities |
| Subcontracting | Conditions stated | Material subcontractor identification and conditions |
| Exit and transition | Termination rights and notice | Transition assistance and tested exit plan |
The register of information is a reporting format sitting on top of a contract data problem. Firms that recognize that early build the extraction and maintenance capability once and report from it. Firms that treat the register as a reporting deliverable build a spreadsheet, submit it, and then rebuild it every time a contract is amended. The regulation's requirement that the register be kept current is what makes the difference between those two approaches compound rather than even out. The practical marker of a working program is that a supervisor's request for the register and its supporting contracts can be answered from a live system rather than reconstructed, and that the firm can show when each field was last verified and against which executed document.
For related guidance, see DORA ICT contract clauses, a register-ready checklist, OCC and FFIEC vendor oversight, the contract controls and Vendor contract controls for OCC and FFIEC exam readiness.
