What DORA's Register of Information Actually Requires and How to Build One
If you're subject to DORA, you've probably heard that you need a Register of Information. But knowing it exists and knowing what actually goes into it are two very different things. The regulation demands far more than a simple vendor list; it requires a structured, multi-layered inventory built to precise technical standards. Getting it wrong isn't an option. Here's what you need to know.
What Is the DORA Register of Information?
Under Article 28(3) of Regulation (EU) 2022/2554, the Digital Operational Resilience Act (DORA) requires financial entities to maintain a Register of Information (RoI). This is a structured inventory of all contractual arrangements with ICT third-party service providers, rather than a simple vendor list.
For teams evaluating DORA compliance plattforms, Register of Information capability should be a core consideration, particularly where native xBRL-CSV exports, ICT risk workflows, and subcontractor mapping can reduce manual reporting effort.
The RoI is based on the European Supervisory Authorities’ Implementing Technical Standards (ESA ITS) and uses a relational data model spanning multiple tables. It includes more than 60 mandatory data fields, covering areas such as:
- Entity and provider identifiers
- Key contractual terms and conditions
- Description of services provided
- Classification of services according to their criticality or importance
- Information on data processing and data location
The register must be kept up to date at entity, sub-consolidated, and consolidated levels. Institutions are required to be able to provide the RoI to competent authorities upon request at any time, not only during periodic reporting cycles. This implies the need for robust governance, data quality controls, and clear internal responsibilities for maintaining and reviewing the information recorded in the RoI.
Who Must Build and Maintain a Register of Information?
Under DORA, maintaining a Register of Information is a formal regulatory requirement that can't realistically be handled by a single team. Credit institutions, investment firms, payment institutions, e-money issuers, and insurance or reinsurance undertakings must maintain this register at entity, sub-consolidated, and consolidated levels.
In practice, the register depends on coordinated input from several functions, typically including legal, procurement, information security, business continuity, and compliance. Each of these areas is responsible for specific data fields, such as contractual details, risk classifications, and security or resilience requirements.
To keep the register accurate and up to date, institutions should define clear triggers for updates, for example, when new contracts are signed, existing contracts are renewed or terminated, the criticality of a service changes, or providers update key attributes.
For mandatory identifiers such as Legal Entity Identifiers (LEIs) and information on subcontractor chains, internal data sources are often incomplete. Institutions therefore generally need to engage directly with ICT service providers to obtain or validate missing information and ensure the register meets DORA’s completeness and accuracy expectations.
What Data Fields Your Register of Information Must Include
The DORA Register of Information isn't a simple vendor list but a structured, multi-table data model with more than 60 mandatory fields.
These fields are organised across five main areas: entity-level identifiers, contractual arrangement details, ICT service descriptions, criticality assessments, and service delivery chain data, including subcontractor information.
At the entity level, the register records information such as Legal Entity Identifiers (LEIs) and consolidation scope to clarify which group entities and relationships are covered.
For each contractual arrangement, it captures key legal and commercial terms, including start and end dates, renewal conditions, notice periods, and governing law, enabling consistent oversight of contractual risk and obligations.
ICT service entries must provide controlled, standardised descriptions of services and link them explicitly to the business functions they support.
This facilitates impact analysis and supports proportionate risk management.
Criticality-related fields cover the outcome of materiality and criticality assessments, including assessment dates and the rationale or criteria applied, ensuring that classification decisions can be reviewed and evidenced.
Finally, the register includes detailed information on data storage and processing locations, including backup and failover sites, to support resilience and data sovereignty assessments.
It also requires mapping of the full subcontractor chain for services supporting critical functions, so that dependencies and potential concentration risks across the service delivery chain can be identified and monitored.
Where to Pull ICT Provider and Contract Data From
Building your Register of Information begins with identifying where ICT provider and contract data is currently held across the organisation.
Procurement and accounts payable systems typically provide the initial list of outsourced providers, but this data should be enhanced with information on legal entity structures, Legal Entity Identifiers (LEIs), and ultimate parent organisations.
Contract management repositories are the primary source for contract terms, including start and end dates, renewal and termination provisions, governing law, audit rights, and sub-outsourcing clauses.
Configuration Management Databases (CMDBs) should be used to link active ICT services and applications to specific contracts, ensuring that each service can be traced to its contractual basis.
For missing information, especially data processing locations and subcontractor arrangements, structured questionnaires can be issued to providers, with priority given to those supporting critical or high-risk services.
Build Your Register of Information Using the ITS Template
Once you have identified where your ICT provider and contract data is stored, you can begin mapping it into the Commission/ESA ITS relational template, which is the required format for submitting your Register of Information.
Populate tables B.01 through B.05 in sequence: start with entity identifiers and consolidation levels, then add contractual arrangement details, provider legal entities (including LEIs), service types and criticality classifications, and finally data location information, including backup and failover sites.
Maintain referential integrity between tables so that contract records link correctly to the corresponding provider and service records.
For arrangements supporting critical functions, record any sub-outsourcing chains and capture each arrangement’s criticality rationale, assessment date, and reviewer.
Map Sub-Outsourcing and Fourth-Party Chains in Your Register
Mapping sub-outsourcing chains is a common point of failure in many registers. For critical functions, it isn't sufficient to document only the direct ICT provider; every subcontractor in the chain must be recorded, including their identifiers and country of operation. DORA Article 30(2)(a) requires that institutions have contractual rights to obtain this information, which often means that legacy SaaS and cloud contracts must be reviewed and, where necessary, amended.
A practical approach is to prioritise the most critical arrangements and issue structured questionnaires to relevant providers to collect sub-outsourcing data in a consistent format.
Responses should be validated against public subprocessor or subcontractor lists, as well as internal contract records, to identify discrepancies and missing information.
Registers that document only prime vendors typically don't meet regulatory expectations, leading to validation failures, repeated data collection exercises, and the identification of gaps that supervisory authorities highlighted during 2024–2025 dry-run assessments.
How to Keep Your Register of Information Accurate After Submission
Submitting your Register of Information isn't the endpoint; it marks the beginning of an ongoing maintenance process. Update the register whenever contract terms change, end dates are adjusted, or criticality classifications are revised.
Assign clear ownership of individual data fields across legal, procurement, information security, and operations to reduce the risk of omissions or inconsistencies.
Criticality-related data should be reviewed at least annually and after any material change to the service or relationship, as the classification determines which enhanced fields must remain accurate.
Maintain up-to-date subcontractor information by recording provider notifications and periodically re-running structured questionnaires to confirm current subcontracting arrangements.
Before each export, reapply validation rules to identify common errors, such as missing Legal Entity Identifiers (LEIs), incorrect or inconsistent parent-entity information, and inaccurate governing law entries.
Addressing these issues in advance reduces the likelihood of rejection or the need for resubmission.
Conclusion
Your DORA Register of Information isn't a one-time project; it's a living compliance obligation. You'll need accurate data fields, complete subcontractor chains, and consistent updates across every consolidation level. Start by mapping your contracts against the ITS templates, plug your data gaps, and build a maintenance process before regulators ask for it. Get it right now, and you won't be scrambling when your competent authority comes knocking.