Regulation (EU) 2022/2554, generally known as DORA, has been applying to in-scope financial entities since January 2025, and the operational reality has settled into a familiar shape. The policy work was finished on time. The register of information turned out to be a data quality exercise that nobody had fully budgeted for, and it recurs.
The reason is structural. The register asks for fields that exist inside executed contracts but were never captured as data, including whether an arrangement supports a critical or important function, the location where data is processed, the notice period for termination by the financial entity, and subcontracting arrangements that support those functions. If those values were never recorded at signature, producing the register means re-reading contracts, and doing it again at the next reporting cycle.
This guide covers how to structure ICT contract data so the register is generated rather than assembled, which Article 30 terms are worth enforcing through a playbook, and what makes an exit strategy credible when a supervisor tests it. It is written for third-party risk, procurement and legal teams in banking, insurance and investment firms.
Why the register is hard the second time
The first submission is usually completed through effort. A working group reads contracts, fills a template and files it. The problem arrives at the next cycle, when the population has changed, the previous readers have moved on and nothing in the contracting process captured the fields as they were signed.
- Fields live in prose, not data, the notice period and the data processing location sit in clauses, so every reporting cycle requires re-reading rather than querying
- Function mapping is disconnected, the critical or important function assessment lives with resilience teams and is not linked to the specific contractual arrangement it applies to
- Subcontracting stops at tier one, the contract names the provider but the chain supporting a critical function is unrecorded, so material subcontractors are invisible
- Group structure is unmodeled, registers must be produced at entity, sub-consolidated and consolidated level, which is painful when contracts are not tagged to legal entities
- Amendments are not reflected, a renegotiated notice period sits in an amendment that was never mapped back to the register fields it changes
None of this is exotic. It is the same failure mode that makes any regulatory report expensive, which is that the data was produced as narrative and is being consumed as structure. The remedy is to move the capture point upstream, so that the fields the register needs are recorded when the contract is signed and updated when it is amended. That is also what makes the register defensible, because each value can be traced to the clause it came from. The same principle underlies third-party risk contract automation more broadly.
Whether an ICT arrangement supports a critical or important function determines the contractual content DORA expects, the depth of exit planning, the monitoring intensity and much of what appears in the register. Make that classification an explicit, recorded, reviewable field on the contract record rather than a judgment held in a resilience workshop. Where classification is ambiguous, record the rationale. Supervisors are generally less interested in the answer than in whether there was a method.
Contract terms worth enforcing through a playbook
DORA sets out contractual provisions for ICT arrangements, with an enhanced set where a critical or important function is supported. Turning these into playbook positions is what stops each negotiation from starting over.
- Service description and locations. A clear description of functions and services, and the countries or regions where services are provided and data is processed and stored, with notice required before material change
- Access, inspection and audit. Unrestricted rights of access, inspection and audit for the financial entity and the competent authority, including on-site access where the function is critical or important
- Subcontracting conditions. Conditions for subcontracting where a critical or important function is supported, with notification of material changes and the ability to object
- Incident and resilience obligations. Assistance during ICT incidents at no additional cost or at a predetermined cost, participation in security awareness and resilience testing where relevant
- Termination and transition. Defined termination rights, a mandatory transition period during which the provider continues to supply the service, and data return in an accessible format
A five-step roadmap to a maintainable register
Step 1, Define the register data model against your contract record
Take the reporting fields and map each one to a field on the contract record, naming the source clause type where the value comes from. Fields with no home in the contract data model are the gap list, and they should be added before the next negotiation cycle rather than after the next submission.
Step 2, Classify arrangements and link the classification
Run the critical or important function assessment and attach the outcome to the specific contractual arrangement, with the rationale and a review date. Classification held only at service level cannot answer questions about a specific provider contract, which is the level the register works at.
Step 3, Backfill through targeted extraction
Extract the register fields from the existing ICT contract population rather than re-reading everything manually. Prioritize arrangements supporting critical or important functions, verify those values through human review, and accept sampled review on the remainder.
Step 4, Wire capture into the contracting workflow
Make the register fields mandatory at execution for ICT arrangements, so new and renewed contracts populate the register automatically. This is the step that turns a recurring project into a byproduct of normal operations.
Step 5, Make exit plans specific and testable
For each critical or important arrangement, record the transition assistance period, the data return format, the identified alternative or in-house route and the last date the plan was reviewed. Then test one, because an untested exit plan is an assertion.
Generate the register from contract data
Aavenir captures ICT contract terms as structured fields at signature and keeps them current through amendments, with clause-level traceability.
What supervisors probe beyond the register
Submitting a complete register is a threshold, not an achievement. Supervisory attention tends to move to whether the underlying management is real. Common lines of questioning include how concentration risk across providers and across subcontractors supporting the same function is measured, whether exit plans have been tested and what the test showed, how the entity monitors provider performance against the contractual terms it negotiated, whether audit rights have ever been exercised, and how quickly the entity could identify every arrangement affected by a specific provider incident. Answering these requires the contract data and the ongoing obligations to sit together, which is the same requirement described in the financial services obligation management datasheet.
Register fields and where the value comes from
A simplified view of the mapping problem. The point is that every field has a source, and unmapped fields are future manual work.
| Register content | Typical source | Failure mode when unmapped |
|---|---|---|
| Function supported and criticality | Resilience assessment linked to the contract record | Classification cannot be traced to a specific arrangement |
| Service description and type | Contract schedule and service definition | Free-text descriptions that cannot be aggregated |
| Data processing and storage locations | Data protection and service location clauses | Locations unknown after provider infrastructure changes |
| Notice periods and termination rights | Termination clause and any amendments | Amended notice periods never reach the register |
| Subcontracting supporting the function | Subcontracting clause and provider disclosures | Chain beyond tier one invisible during an incident |
The register of information is best understood as a test of whether ICT contract data is under management. Entities that capture the fields at signature, link classification to the arrangement rather than the service, record subcontracting for functions that matter and maintain exit plans with tested content will produce each submission as a report. Entities that treat it as an annual reading exercise will pay for it every cycle, and will struggle with the follow-up questions that arrive after the file is accepted. The work is the same either way. The difference is whether it is done once, upstream, or repeatedly, under deadline. For the related examination angle, see the SOX and third-party risk exam checklist.
For related guidance, see DORA Article 28, what your ICT contracts must carry, The bank’s guide to DORA ICT third-party contract terms and Termination assistance clauses, an exit readiness datasheet.
