The Register of Information: DORA's Hardest Operational Deliverable

Of all DORA's deliverables, the register of information generates the most work per unit of regulatory text. The obligation is short. The data model is not.

What the Register Is

Financial entities must maintain a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers, distinguishing those supporting critical or important functions. It is maintained at entity, sub-consolidated and consolidated levels, and reported to competent authorities — annually at minimum, and on request.

The register feeds the European Supervisory Authorities' designation of critical ICT third-party providers. That is why the data model is prescriptive and why submission format errors are treated seriously: the registers are aggregated across the union to identify concentration.

Why It Is Hard

The difficulty is not conceptual. It is that the register requires data that no single system in a typical financial institution holds.

• Contract data sits in legal or procurement, often without ICT classification.

• Function criticality sits in the risk function, in a different taxonomy.

• Technical dependency data sits in IT, keyed to systems rather than contracts.

• Subcontracting chains sit with the provider, and must be requested.

• Entity identifiers — LEIs for providers, standardised identifiers for group entities — frequently do not exist until someone goes and gets them.

Assembling this the first time is a project. Keeping it accurate is an operating model change, because the register decays the moment a contract is signed, renewed, varied or terminated without the register being updated.

The firms that hold accuracy do one thing: they make register update a gating step in contract execution. No signature without the register entry. Everything else — quarterly reconciliations, annual clean-ups — is remediation of a process that leaks.

Contractual Minimums

DORA prescribes what contractual arrangements for ICT services must contain, with an enhanced set where the service supports a critical or important function. Across both tiers, the recurring provisions are:

• A clear and complete description of the services, with locations where services are provided and data is processed.

• Service level descriptions with precise quantitative and qualitative performance targets.

• Provisions on availability, authenticity, integrity and confidentiality of data.

• Assistance obligations at no additional cost, or at a pre-agreed cost, when an ICT incident occurs.

• Full cooperation with competent authorities, including access, inspection and audit rights.

• Termination rights and associated minimum notice periods.

• Exit strategies, including mandatory transition periods.

• Subcontracting conditions, where the subcontracted service supports a critical or important function.

The provisions that cause commercial friction are audit and access rights, unrestricted subcontracting consent, and transition assistance obligations. Large providers resist all three, and smaller financial entities have limited leverage. The realistic strategy is to prioritise: audit rights can often be satisfied by pooled audits or third-party assurance reports; subcontracting can be handled by notification-plus-objection rather than prior consent; transition assistance is the one worth spending negotiating capital on, because it is the provision that has value when it matters.

Exit Plans That Are Not Fiction

For critical or important functions, entities must have exit strategies allowing them to exit contractual arrangements without disruption to business activities, breach of regulatory requirements, or detriment to the continuity and quality of services.

A credible exit plan names the alternative provider or the insourcing route, estimates the transition duration with the basis for the estimate, identifies the data and its extractable format, and quantifies the cost. A plan that says "we would tender for a replacement provider" is not a plan; it is a statement of intent.

The uncomfortable cases are the ones where no realistic alternative exists — a core banking platform, a single dominant cloud region, a market data monopoly. The right response is not a fictional exit plan. It is a documented concentration risk acceptance at board level, with compensating controls and a stated review cycle. Supervisors respond considerably better to an honest acceptance than to an exit plan everyone knows is undeliverable.

Concentration and the Fourth Party

The register exists partly to surface concentration: many contracts, one underlying provider. Firms consistently underestimate this because contracts are held with intermediaries whose own infrastructure sits with a small number of hyperscalers.

Map to the substrate. If eleven critical suppliers all run in the same cloud region, the firm has one dependency, not eleven, and its scenario testing should say so. The oversight regime for critical providers is the union-level response to the same problem.

Key Takeaways

• Register accuracy is an operating model question: make the entry a gating step in contract execution.

• Required data is spread across legal, risk, IT and the provider — no single system holds it.

• Prioritise transition assistance in negotiation; audit rights and subcontracting consent have workable alternatives.

• Where no realistic exit exists, document a board-level concentration acceptance rather than write a fictional plan.

• Map dependencies to the underlying substrate to reveal true concentration.

Frequently Asked Questions

Do intra-group ICT arrangements go in the register? Yes. Intra-group providers are ICT third-party service providers for these purposes, and intra-group arrangements are frequently the least documented, because they were never treated as outsourcing.

How often must the register be submitted? At least annually, in the prescribed format, and at any time upon request from the competent authority. The on-request limb is the one that punishes firms which rebuild the register annually rather than maintaining it.

Does DORA replace the EBA and EIOPA outsourcing guidelines? It substantially overlaps them for ICT services and the sectoral guidelines have been aligned, but non-ICT outsourcing remains governed by the existing guidelines. Running one register that covers both, with a flag for ICT scope, avoids maintaining two decaying datasets.

About the author

Jonas Mohamed Osman Abdelghafour is a risk and compliance expert advising banks, insurers, payment institutions and asset managers on operational resilience, ICT and third-party risk, financial crime and enterprise governance across EU and UK regimes. He works at the point where digital operational resilience obligations meet the evidence a board and a supervisor actually ask for. See qualifications and services, or get in touch to discuss an engagement.

*This article discusses regulatory frameworks in general terms and is not legal advice. Jurisdictional interpretation should be confirmed with qualified counsel.*