The DORA Register of Information: Structure, Common Failures, and What Supervisors Check

Most financial entities did not fail their first DORA Register of Information on content. They failed on structure: a flat spreadsheet where the regulation asked for a relational dataset, Legal Entity Identifiers left blank or pointed at the wrong company, and a "critical or important function" column filled in by whoever happened to own each contract. The register read fine to a human and was rejected by a machine.

The Register of Information (RoI) is the one DORA deliverable your competent authority collects on a schedule, feeds into the process that designates critical ICT providers, and validates against referential-integrity rules before an examiner ever reads a field. Treat it as a compliance narrative and it breaks at ingestion. Treat it as a small, well-keyed database and it passes. This is how to build the second kind.

What the register actually is, and three things it is not

The legal basis is narrow and specific. Article 28(3) requires each financial entity to maintain and update a register of information covering all contractual arrangements for the use of ICT services provided by third parties, at entity, sub-consolidated and consolidated level, distinguishing arrangements that support critical or important functions from those that do not. It must be available to competent authorities on request, and the entity reports on it at least annually.

The format is not left to you. Commission Implementing Regulation (EU) 2024/2956 lays down the standard templates. Critically, the ITS defines the register as a set of interlinked templates (the B_xx.xx series) that reference each other by identifier, not a single sheet. Records join: an ICT service points to a provider; a provider carries an LEI; an arrangement links to a function. This relational shape is the single most misunderstood property of the whole exercise.

Three things the register is not, each of which produces a predictable failure:

• Not your EBA outsourcing register. Banks already keep an outsourcing register under EBA/GL/2019/02 and often try to reuse it. But an ICT service (Article 3(21): "digital and data services provided through ICT systems… on an ongoing basis") is far broader than outsourcing. An off-the-shelf SaaS tool nobody would call "outsourcing" is still an ICT service in scope. Reuse the outsourcing register unchanged and you undercount from day one.
• Not a procurement or vendor-spend list. Scope is driven by ICT service and the function it supports, not by supplier or purchase order. A single provider can generate several rows; a large PO can be entirely out of scope.
• Not a one-off submission. It is a living dataset tied to the contract lifecycle. A register that was accurate on the submission date and never touched again is a finding waiting to happen.

The legal spine the register has to carry

The register does not stand alone. Each field it demands is the visible end of an obligation elsewhere in Chapter V. Understanding which is which tells you where an examiner will pull the thread.

Provision	Obligation	What it drives in the register
Art 28(2)	Board-approved strategy on ICT third-party risk	Governance context the register operationalises
Art 28(3)	Maintain the RoI; report at least annually	The register itself, in ITS template form
Art 28(8)	Exit strategies for arrangements supporting critical/important functions	Every C/I arrangement must have a documented, tested exit
Art 29	Preliminary assessment of ICT concentration risk before contracting	Concentration analysis that reads the register's supply-chain data
Art 30(2)	Mandatory contractual provisions for all ICT arrangements	Baseline terms behind every arrangement row
Art 30(3)	Additional mandatory provisions for C/I arrangements	Enhanced terms the C/I flag commits you to
Art 30(5) RTS	Subcontracting of ICT services supporting C/I functions	The ICT service supply-chain templates
Art 3(22)	Definition of a critical or important function	The single flag that everything above pivots on

The template structure: relational, not flat

Think in families of templates joined by keys, not in columns. The ITS groups the register roughly as follows, and each family carries the identifier the next one references.

Template family (B_ series)	Captures	Primary key it is joined by
Entity B_01.xx	The entity maintaining the register, the entities in scope for consolidation, and branches	LEI of the financial entity
Contractual arrangements B_02.xx	Each arrangement: general terms, the per-service specifics, and intragroup arrangements	Contractual arrangement reference number
Provider B_05.xx	Each ICT third-party provider's identity, plus the ICT service supply chain (subcontractors)	LEI / provider identification code
Function B_06.xx	The entity's own functions, each with a function identifier and criticality	Function identifier
Assessment B_07.xx	The assessment of ICT services that support critical or important functions	Joins a service row to a function row

The register is only correct when those keys reconcile in every direction. The diagram below is the mental model to build against.

The identifier backbone, where registers actually break

Four identifiers hold the whole structure together. Each is a distinct source of failure.

Legal Entity Identifier (LEI)

Every ICT third-party provider must be identified by a 20-character LEI (ISO 17442). This was the single biggest data-quality failure in the 2024 dry run, and it fails in a specific way: teams enter the LEI of the brand or the ultimate parent instead of the exact contracting legal entity. For Microsoft cloud services in the EEA, for instance, the contracting party is typically Microsoft Ireland Operations Limited, not "Microsoft Corporation", and you must record that entity's LEI. Look it up in the GLEIF database against the name on the contract; do not guess or infer it.

Providers without an LEI are a project dependency, not a footnote. You cannot mint one for them; the provider has to obtain its own from an accredited issuer, which takes time and vendor goodwill. Start that chase early, because a missing LEI blocks the row, and a blocked row can fail the whole submission.

Contractual arrangement reference number

Your own stable key for each arrangement. Assign a deliberate scheme and never reuse a value that changes, purchase-order numbers being the classic trap. The same reference must appear on every template that references the arrangement, or the join breaks.

Function identifier

This must reconcile to your own business-function taxonomy and your Business Impact Analysis. If your BIA says the payments function is critical but the register's function identifier for it is flagged non-critical, you have handed the examiner two contradictory sources of truth about the same function, and the conversation stops being about the register.

ICT service type

The ITS uses a controlled taxonomy of ICT service types (the S-code list). Pick the code; do not free-text "cloud" or "SaaS". Values outside the taxonomy fail validation, and inconsistent typing makes the ESAs' concentration analysis, and yours, meaningless.

Critical or important functions: the flag everything pivots on

Article 3(22) defines a critical or important function as one whose disruption would materially impair the entity's financial performance, the soundness or continuity of its services, or its continued compliance with its authorisation and regulatory obligations. That single determination propagates outward: the C/I flag triggers the enhanced Article 30(3) contract terms, the Article 28(8) exit strategy, expanded resilience-testing scope, and the lion's share of supervisory attention.

There are two symmetric ways to get it wrong, and both are expensive:

• Over-flagging. Mark everything critical "to be safe" and you now owe Article 30(3) terms, tested exit plans, and concentration assessments for arrangements that never warranted them. You cannot produce them all, so you generate findings across the entire register instead of a few.
• Under-flagging. Mark the core-banking or payments SaaS as non-critical and the supervisor who disagrees does not just correct one row, they lose confidence in your methodology, which reopens every determination you made.

The fix is a documented, repeatable methodology anchored to the BIA, applied centrally, not per-contract judgement by whoever owns the vendor. What "done" looks like: any C/I determination can be traced to the criteria that produced it, and a second competent person running the method reaches the same answer.

ICT service supply chains and hidden concentration

The Article 30(5) RTS on subcontracting requires the register to capture the chain beneath ICT services that support critical or important functions, the subcontractors that effectively underpin the function. You will not extract full nth-tier depth from every provider, and DORA does not ask you to boil the ocean: document to the depth the RTS requires for C/I functions, and record your monitoring approach for the rest.

The payoff for populating this properly is concentration visibility. Three "different" SaaS vendors that all run on the same hyperscaler in the same region are a concentration you can only see once the supply-chain rows exist. That is precisely the systemic exposure Article 29 asks you to assess before contracting, and precisely what the ESAs are building the union-wide picture to detect when they designate critical ICT third-party providers.

Implementation: sourcing the fields and reconciling the registers

No single system holds a clean register. The data is assembled, and the assembly is where quality is won or lost.

Source system	What it supplies	What it misses on its own
Contract repository	Arrangement terms, dates, exit clauses, 30(2)/(3) provisions	Which function the service actually supports
CMDB / service catalogue	The ICT services and the functions they underpin	Contractual and provider-legal detail
Procurement / accounts payable	The full population of paid suppliers (a completeness cross-check)	Free and shadow ICT that never raised a PO
Entra ID enterprise apps / M365 admin	SaaS actually in use via OAuth consent and federation	Contract and criticality context

That fourth row is where the uncomfortable discoveries live. Enumerate the OAuth-consented and federated applications in Entra ID and you will find ICT services in active use that procurement has never heard of, each one an arrangement row you were missing. Reconcile the enterprise-app inventory against the register the same way you reconcile procurement spend: anything in use that is not in the register is either an omission or a shadow-IT problem, and both are yours to close.

The deeper trap is three registers drifting apart: the contract repository, the third-party risk register, and the RoI each describe the same providers with different scope, different names, and different totals. Pick a single master for each field, contract facts from the repository, criticality from the resilience methodology, and reconcile on a fixed cycle. An examiner's first move is to diff the three; make sure you have done it first.

Tie updates to events, not to the calendar. A new, renewed, or terminated arrangement, a change in a function's C/I status, a changed subcontractor beneath a C/I function, or a provider merger should each trigger a register update at the moment it happens. Wire the register into the procurement and contract-lifecycle workflow so it maintains itself, rather than reconstructing it under pressure the week before the annual report. And give it an owner: typically second-line operational resilience owns the dataset, the business owns each C/I determination, and procurement feeds the contract facts. Put that in a RACI so no field is nobody's job.

A worked Microsoft 365 and Azure example

Take a bank running Microsoft 365 (Exchange Online, Teams) and hosting its loan-origination application on Azure IaaS. How that lands in the register:

• Provider row (B_05): Microsoft Ireland Operations Limited, its LEI looked up in GLEIF against the contract, country of the provider's head office, and provider type. Not "Microsoft" and not the US parent.
• Service rows: at least two, typed from the taxonomy, "SaaS, productivity and collaboration" for Exchange/Teams and "cloud, compute/IaaS" for the Azure hosting, each linked to the arrangement's reference number. Model one or two arrangements depending on whether a single Enterprise Agreement or separate contracts govern them; follow the paper, not the convenience.
• Function link and assessment (B_06/B_07): loan origination is critical or important, so the Azure IaaS service is flagged C/I and gets an assessment row. Corporate email may be important too; decide it by the method, not by reflex.
• Supply chain and data location: the Microsoft sub-processors that underpin the C/I hosting, plus the data-processing region and whether data can leave the EEA.
• Contract terms: because the hosting is C/I, the Article 30(3) provisions must exist, exit strategy, audit and access rights, TLPT cooperation, and sub-outsourcing conditions. Map them against Microsoft's DORA-oriented financial-services contractual addendum clause by clause; do not assume the standard product terms already satisfy 30(3).

Common mistakes (the dry-run tells)

1. A flat spreadsheet with broken joins, the register fails ingestion before anyone reads it.
2. Missing LEIs, or parent-company LEIs where the contracting entity's was required.
3. The C/I flag assigned per-contract and inconsistent with the BIA.
4. Free-text ICT service types instead of the controlled taxonomy.
5. The EBA outsourcing register reused wholesale, so non-outsourcing ICT services are absent.
6. Blank supply-chain rows beneath critical or important functions.
7. A register frozen at submission with no event-driven update process.
8. The RoI, the third-party risk register, and the contract repository reporting different totals.

What the supervisor and auditor actually check

The examination runs in a predictable order, from cheapest machine check to deepest judgement.

1. Validation. Does the export pass referential integrity, LEI format, and taxonomy conformance? This is automated and binary.
2. Reconciliation. Do the register's totals agree with the contract repository and the TPRM register? Discrepancies are the first substantive question.
3. C/I methodology. Is the critical/important determination documented, applied consistently, and traceable to the BIA?
4. Per-arrangement depth for C/I. Are the Article 30(3) terms present, is the Article 28(8) exit strategy documented and tested, and has Article 29 concentration risk been assessed?
5. Governance. Does the Article 28(2) board-approved strategy exist, and does the register operationalise it rather than contradict it?
6. Maintenance evidence. Is there a change log, defined update triggers, and a named owner, proof the register is alive?

Dimension	Poor implementation	What good looks like
Structure	One flat sheet; joins done by eye	Relational source; templates exported and validated before submission
Identifiers	LEIs missing or parent-level; free-text service types	Contracting-entity LEIs from GLEIF; taxonomy codes throughout
Criticality	Per-contract guesswork	Central methodology tied to BIA, reproducible by a second assessor
Maintenance	Annual reconstruction from scratch	Event-driven updates wired into procurement, with a change log
Reconciliation	Three registers, three different totals	One master per field; documented reconciliation on a cycle

Evidence and documentation to keep

• The validated register export itself, with the validation result.
• The critical/important function determination methodology and the BIA it derives from.
• The register maintenance procedure, its update triggers, owner, and cadence, plus the change log.
• Reconciliation working papers: RoI versus contract repository versus TPRM register.
• For each C/I arrangement: the contract with 30(3) clauses mapped, the exit plan and its last test date, and the concentration assessment.

How the register maps to what you already run

If you already operate a supplier-risk programme under another framework, the register is not net-new work so much as a prescriptive, machine-validated version of a control you have. Mappings are approximate and directional; DORA is the harder-edged obligation for financial entities.

Framework	Nearest control	Relationship to the RoI
DORA	Art 28(3) + ITS (EU) 2024/2956	The mandate, with a prescribed, validated template format
NIS2	Art 21(2)(d) supply-chain security; Art 4 sectoral acts	DORA is lex specialis for financial entities; its ICT rules take precedence, and the RoI is the prescriptive version of NIS2's supply-chain expectation
ISO/IEC 27001:2022	A.5.19–A.5.23 (supplier relationships, ICT supply chain, cloud)	Same supplier-register concept; no prescribed format or LEI
NIST CSF 2.0	GV.SC (supply-chain risk mgmt) + ID.AM (inventory)	Governance and inventory of the same third parties, framed as outcomes
CIS Controls v8.1	Control 15 (15.1 inventory of service providers)	The RoI is a regulated, supercharged Control 15.1
EBA/GL/2019/02	Outsourcing register	A subset; ICT services are broader than outsourcing

Key takeaways

• Build the register as a small relational dataset with enforced joins, then export to the ITS templates. Referential integrity is checked before content.
• Chase the LEI of the exact contracting legal entity from GLEIF, never the brand or parent, and start early for providers that lack one.
• Make the critical/important determination once, centrally, from a documented method tied to your BIA, not per-contract. Everything downstream pivots on it.
• Populate the supply chain under C/I functions; it is the only way to see the hyperscaler concentration Article 29 asks about.
• Reconcile the RoI, the TPRM register, and the contract repository yourself, because the examiner will diff them first.
• Wire updates to contract-lifecycle events and give the dataset a named owner; a static register is a finding.

References and further reading

• Regulation (EU) 2022/2554 (DORA), in particular Articles 28–30 and 3(21)–(22).
• Commission Implementing Regulation (EU) 2024/2956, the ITS establishing the register-of-information templates.
• The ESAs (EBA, EIOPA, ESMA), materials from the 2024 voluntary dry-run collection and the subsequent live collection, including the data-quality feedback and validation rules, validate every field against the current versions, which continue to be updated.
• GLEIF, the global LEI lookup, for confirming the LEI of the exact contracting entity.

Frequently Asked Questions

Is the Register of Information the same as our outsourcing register?

No. The RoI covers all ICT services (Article 3(21): digital and data services provided on an ongoing basis), which is far broader than outsourcing, and it must follow the prescribed ITS template format. An outsourcing register kept under EBA/GL/2019/02 is a starting subset, not a substitute; reused unchanged it undercounts the non-outsourcing ICT services in scope.

Do we need an LEI for every ICT provider?

Yes. Each ICT third-party provider is identified in the register by a 20-character LEI (ISO 17442), and it must be the LEI of the exact contracting legal entity, not the brand or ultimate parent. Providers without an LEI must obtain their own from an accredited issuer; you cannot create it for them, so start that request early because a missing LEI can block the submission.

What counts as a critical or important function?

Under Article 3(22), a function whose disruption would materially impair the entity's financial performance, the soundness or continuity of its services, or its continued regulatory compliance. Determine it with a documented, repeatable methodology anchored to your Business Impact Analysis rather than contract by contract, because the flag drives the Article 30(3) contract terms, the exit strategy, and the scope of supervisory scrutiny.

How often do we submit the register?

Maintain it continuously and make it available to the competent authority on request, with reporting at least annually under Article 28(3). In practice the ESAs run an annual collection through national competent authorities, and the register is validated against referential-integrity and format rules at ingestion, so it needs to be submission-ready, not reconstructed each year.

Does DORA replace NIS2 for a financial entity?

For ICT risk management, ICT third-party risk, and incident matters, DORA is lex specialis and takes precedence for financial entities in its scope. You apply DORA's specific requirements, including the Register of Information, rather than the equivalent NIS2 provisions for the same subject; you do not satisfy both separately for the same requirement.

---