DORA Register of Information: filling Annex III in practice

The DORA Register of Information is the most underestimated obligation under the Digital Operational Resilience Act. It looks like a spreadsheet exercise. It is, in fact, a structured inventory of every ICT third-party arrangement your firm has — submitted annually to your supervisor, validated against a defined schema, and used by the European Supervisory Authorities to map systemic ICT risk across the bloc. Getting it wrong does not just generate a finding; it forces a re-submission cycle that can run for months.

1. What the Register of Information is

DORA — Regulation (EU) 2022/2554 — applies from 17 January 2025 across the EU financial-services perimeter: banks, EMIs, PIs, investment firms, fund managers, insurers, CASPs and others. Article 28(3) requires every in-scope firm to maintain a register of information on contractual arrangements with ICT third-party service providers. The register’s structure, fields and submission format sit in the implementing technical standards (ITS) developed by the European Supervisory Authorities (EBA, ESMA, EIOPA — collectively the ESAs) and adopted by the European Commission in 2024.

The Register is not just a list of vendors. It is a structured document — fifteen tables in the ITS — capturing every contract, the services it covers, the criticality of those services, the jurisdictions involved, the data flows, the sub-contracting chain, and the exit plan.

2. Who must maintain it

Every “financial entity” defined in Article 2 of DORA. That includes:

• Credit institutions (CRR-banks)
• Electronic-money institutions and payment institutions
• Investment firms under MiFID II
• Crypto-asset service providers (CASPs) authorised under MiCA
• Insurance, reinsurance and pension undertakings
• Trading venues, central counterparties, central securities depositories
• Crowdfunding service providers, account information service providers, and a long list of others

Microenterprises (Article 3(60)) get a proportionality carve-out on certain DORA obligations but the Register of Information itself is mandatory regardless of size.

3. The fifteen tables, in plain English

The ITS structure runs in fifteen related tables. Each table has a defined set of fields. The tables link to each other through cross-reference identifiers — get the IDs wrong and the validation rejects the whole submission. The table groups, in order:

1. Entity-level identification — your firm’s identifiers (LEI, name, country, group structure).
2. Contractual arrangements — every ICT contract, with start date, term, governing law.
3. ICT service providers — provider identifiers and corporate group.
4. ICT services — the services covered by each contract, classified using DORA’s taxonomy.
5. Critical or important functions — which of your business functions the services support.
6. Sub-contracting — the providers’ chain of sub-contractors, by depth.
7. Cross-border data flows — where data is processed and stored.
8. Group-level coverage — when the contract covers multiple entities in your group.

The remaining tables capture the relationship between these (one provider may serve multiple contracts; one contract may cover multiple services; one service may support multiple functions) — which is why the cross-reference identifier discipline matters.

4. The “critical or important function” test

“Critical or important function” is defined in DORA Article 3(22). The test is whether disruption to the function would materially impair the firm’s continued provision of services or its compliance with prudential or conduct rules. Common candidates: payment-processing infrastructure, KYC vendors holding the customer onboarding pipeline, transaction-monitoring vendors, the core banking ledger, the cloud platform itself.

5. Submission cadence and channel

• Frequency: annually, typically by end of Q1 covering the previous year as at 31 December.
• Format: CSV or XBRL per the ESAs’ technical standards. Most national supervisors accept both.
• Channel: via the home supervisor’s reporting portal — same channel each supervisor uses for their other returns. The supervisor forwards to the ESAs for cross-border aggregation.
• Data quality: validations are run at submission. Common rejection reasons are missing LEIs on providers, invalid identifier cross-references, and inconsistent classification of services.

6. Where projects fail

Three operational issues sink first submissions:

• Provider LEI gaps. Every ICT third-party must be identified by its Legal Entity Identifier. Smaller vendors often do not hold one. Procuring an LEI is straightforward (the same LEI register is reused for AnaCredit reporting) and inexpensive but takes a few weeks per vendor — start the inventory exercise early.
• Sub-contracting depth. Article 28(8) and the ITS require disclosure of the sub-contracting chain to a defined depth. Vendors are sometimes reluctant to disclose their own sub-suppliers; the contract must mandate it.
• Cross-reference inconsistency. The fifteen-table structure relies on stable identifiers across rows. Many firms generate the register from a flat spreadsheet that does not enforce referential integrity, then fail validation.

7. The link to Article 30 contractual must-haves

The Register is a manifest. The substance sits in your contracts with each ICT third-party. Article 30 of DORA defines a list of mandatory contract clauses — service-level agreements, audit rights, data-residency, sub-contracting controls, exit assistance, security incident reporting. For services supporting critical or important functions, Article 30(3) adds further specific requirements. Updating contracts to meet Article 30 is parallel work to building the Register; the Register relies on the contract to be accurate.

8. Getting started — practical sequence

• Inventory every ICT third-party arrangement — start from procurement records, IT vendor list, and accounts-payable.
• For each, capture the contract identifier, the provider’s LEI (procure if missing), the services covered, and the supported business functions.
• Tag each as “critical or important” or not, with documented reasoning.
• Map the sub-contracting chain — at least one level deep, more for critical functions.
• Run a validation pass against the ESAs’ template before submitting.
• Set up an internal change-control: every new ICT contract triggers a Register update.

9. FAQ

10. What to do, today

• If the Register is not yet on your project plan, add it. The first submission is annual and you cannot retro-fit.
• Pull the inventory of every ICT contract — including the small ones — from procurement.
• Procure LEIs for any provider that does not hold one.
• Tag the “critical or important” providers and start the Article 30 contract update for those first.
• Run a dry-submission against a validator before the real deadline.

Related: What is CESOP reporting? · What is the IPR report? · How to launch Dutch IBANs