The Register of Information is arguably the most operationally demanding requirement under DORA. It's not conceptually difficult — it's a structured inventory of your ICT third-party arrangements. But with 15 interconnected tables and roughly 200 data fields, the devil is in the details.
Having helped multiple financial entities prepare their submissions, here's a table-by-table walkthrough of what's actually required and where entities consistently get tripped up.
Whether you're preparing your first submission or refining last year's dry run attempt, this guide covers the structure you need to understand, the mistakes you need to avoid, and the practical shortcuts that make the whole process manageable.
What the Register Actually Is
Required under DORA Article 28(3), the Register of Information is a comprehensive, structured inventory of all contractual arrangements that a financial entity maintains with ICT third-party service providers. It's not a risk register, not an asset inventory, and not a vendor list — though it draws on all three.
The register covers all contractual arrangements with ICT third-party providers, not just the critical ones. Every cloud subscription, every SaaS platform, every managed service provider needs to be captured. The scope catches many entities off guard — a typical small financial entity might have 10 to 30 ICT providers, but a mid-sized one can easily reach 50 to 100 when you count everything.
The first submission was the April 2025 dry run, organized by the ESAs to test readiness. Going forward, annual submissions are due between January 1 and March 21 each year. The register must be submitted to your National Competent Authority (NCA), which then forwards the data to the relevant ESAs — the EBA, EIOPA, or ESMA depending on your entity type.
Why do the ESAs want this data? They use it for oversight designation decisions — specifically, to identify critical ICT third-party service providers that pose systemic risk to the financial sector. If a single cloud provider serves 200 financial entities, the ESAs need to know that. Your register is one piece of that aggregate picture.
The 15 Tables — What Goes Where
The EBA template organizes the register into 15 tables, each serving a specific purpose. Understanding the logical grouping makes the whole structure far less intimidating. Here's a walkthrough of each table, what it captures, and the mistakes entities commonly make.
Group A: Entity Information (Tables 1–2)
Table 1: Entity Maintaining the Register
This is your own entity's identification data. It captures the entity responsible for maintaining and submitting the register — your organization's legal name, LEI (Legal Entity Identifier), entity type classification, country of registration, and competent authority. For most standalone financial entities, this is a single row.
Key fields: Entity name, LEI, entity type (using the EBA taxonomy), country code, NCA identifier.
Table 2: Entities Making Use of ICT Services
If you're part of a group, this table lists all entities within your group that use ICT services from third-party providers. If you're a standalone entity, this table simply mirrors Table 1 — it's just you. For groups, this is where you list every subsidiary, branch, or affiliated entity that relies on the ICT arrangements you're reporting.
Key fields: Entity name, LEI, entity type, parent entity relationship, country code.
Common mistake
Using the wrong LEI or an outdated LEI that hasn't been renewed. LEIs expire and must be renewed annually. Also, failing to update entity details after corporate changes such as mergers, name changes, or re-registrations. Always verify your LEI at gleif.org before submission.
Group B: ICT Third-Party Provider Details (Tables 3–4)
Table 3: List of ICT Third-Party Providers
A master list of every ICT third-party service provider your entity has a contractual arrangement with. This includes cloud providers, SaaS vendors, managed service providers, data center operators, telecom providers, and any other external party providing ICT services. Each provider gets one row, regardless of how many contracts you have with them.
Key fields: Provider name, LEI (if available), country of headquarters, nature of provider (cloud, non-cloud), provider type classification.
Table 4: Intragroup ICT Service Providers
If any ICT services come from within your corporate group — for example, a shared services center, a group IT subsidiary, or a parent company providing infrastructure — they need to be listed here separately. This table captures the intragroup dimension of ICT dependencies, which the ESAs track to understand concentration risk within financial groups.
Key fields: Intragroup provider name, LEI, relationship to the entity, country of establishment.
Common mistake
Inconsistent provider naming across tables. "AWS" in one table, "Amazon Web Services" in another, and "AWS EMEA SARL" in a third will cause cross-referencing failures. Pick the exact legal entity name and use it consistently everywhere. The same applies to LEI codes — if you reference a provider by LEI in Table 3, every subsequent reference must use the identical LEI.
Group C: Contractual Arrangements (Tables 5–8)
Table 5: Contractual Arrangements Overview
The master list of all your contracts with ICT third-party providers. Each contract gets a unique identification code that you assign, along with the contract type, start date, end date (or indication of indefinite term), notice period, governing law, and whether the contract supports a critical or important function.
Key fields: Contract reference ID, contract type, start/end dates, governing law (ISO country code), notice period, renewal terms.
Table 6: Specific Contractual Arrangements
This is the linking table that connects contracts to entities and providers. Each row maps a specific contractual arrangement to the entity using the services and the provider delivering them. If one contract covers multiple group entities, you'll have multiple rows here for that single contract.
Key fields: Contract reference (from Table 5), entity identifier (from Table 2), provider identifier (from Table 3).
Table 7: Intragroup Contractual Arrangements
The counterpart of Table 6 for intragroup arrangements. If ICT services are provided by entities within your group (captured in Table 4), the contractual details for those arrangements go here. Even informal shared services agreements need to be captured if they involve ICT services.
Key fields: Contract reference, intragroup provider identifier (from Table 4), entity identifier, service scope.
Table 8: ICT Services
What services are actually provided under each contract? This table itemizes the ICT services — cloud infrastructure, software applications, data hosting, network services, security services, etc. One contract can cover multiple services, and each service gets its own row linked back to the contract reference.
Key fields: Service identifier, contract reference (from Table 5), service type (from EBA taxonomy), description, data processing country.
Common mistake
Missing the link between contracts and services. A contract that doesn't link to at least one service in Table 8 is incomplete. Conversely, a service in Table 8 that doesn't reference a valid contract from Table 5 will fail validation. One contract can and often does cover multiple services — make sure every service is broken out into its own row.
Group D: Functions and Services Mapping (Tables 9–11)
Table 9: Functions Identification
This table lists your business functions that are supported by ICT services from third-party providers. These are your operational functions — payment processing, customer onboarding, lending operations, regulatory reporting, etc. Each function gets a unique identifier and is mapped to the organizational unit responsible for it.
Key fields: Function identifier, function name, responsible business unit, whether the function is critical or important.
Table 10: Functions Assessment
The criticality assessment for each function identified in Table 9. This is where you document why a function is classified as critical or important (or not), the impact of its disruption, the recovery time objectives, and any regulatory requirements that make it critical. This table is the bridge between your business impact analysis and the register.
Key fields: Function identifier (from Table 9), criticality classification, impact assessment, reasons for criticality, date of last assessment.
Table 11: ICT Services Assessment
The criticality assessment for the ICT services themselves (from Table 8), as opposed to the business functions they support. An ICT service can be critical because the function it supports is critical, or because of its own characteristics — for instance, a single-point-of-failure infrastructure service. This table captures substitutability, concentration risk, and the ease of migrating away from the provider.
Key fields: Service identifier (from Table 8), criticality classification, substitutability assessment, data recovery capabilities, exit strategy.
Common mistake
Not distinguishing between the business function and the ICT service supporting it. "Payment processing" is a business function. "Cloud hosting for the payment platform" is the ICT service. They're related but tracked in different tables with different criticality assessments. A critical function can be supported by a non-critical ICT service (if it's easily substitutable), and vice versa.
Group E: Sub-outsourcing and Risk (Tables 12–15)
Table 12: Sub-outsourcing
The full chain of sub-contractors for each ICT service. If your cloud provider uses a data center operator, who in turn uses a network provider, all of that needs to be captured here. DORA requires visibility into the entire supply chain, not just the direct provider relationship. This table tracks each sub-outsourcing level, the sub-contractor identity, the services they provide, and the countries where data is processed.
Key fields: Primary provider reference, sub-contractor name, sub-outsourcing level (tier), services sub-outsourced, data processing locations.
Table 13: Entities Signing the Contractual Arrangement
Identifies which legal entities are signatories to each contractual arrangement. In group structures, the signing entity might be different from the entities actually using the services. For example, the parent company might sign a master agreement while subsidiaries consume services under it. This table captures that distinction.
Key fields: Contract reference, signing entity LEI, signing entity name, role in the arrangement.
Table 14: Data Protection Impact Assessments
Links data protection impact assessments (DPIAs) to the relevant contractual arrangements and ICT services. Where personal data is processed by ICT third-party providers, GDPR requires DPIAs for high-risk processing. This table creates the cross-reference between your DPIA records and the specific arrangements in the register, demonstrating that data protection has been assessed for each relevant service.
Key fields: DPIA reference, linked contract reference, linked service reference, date of assessment, outcome summary.
Table 15: Additional Risk Assessment Information
Captures supplementary risk assessment data for ICT arrangements, particularly those supporting critical or important functions. This includes the date of the last risk assessment, key findings, risk level, mitigation measures in place, and any residual risks identified. It provides the ESAs with a snapshot of your risk posture related to each ICT third-party dependency.
Key fields: Contract/service reference, risk assessment date, risk level, key findings, mitigation measures, next review date.
Common mistake
Not mapping sub-outsourcing chains beyond tier 1. DORA requires the full chain, not just your direct provider. If AWS hosts your SaaS vendor, and that SaaS vendor uses a payment processor that in turn uses another cloud provider, the entire chain needs to be documented. Getting this information from providers often requires explicit contractual clauses and proactive requests — it won't come automatically.
Data Quality — The 5 Rules That Prevent 86% of Errors
Based on the ESA dry run findings, the overwhelming majority of submission failures came down to data quality issues — not conceptual misunderstandings. Here are five rules that, applied consistently, would have prevented the vast majority of errors.
Use LEI Codes Consistently
Validate every LEI at gleif.org before entering it into the register. Check that LEIs are active (not lapsed), and use the exact 20-character format. For providers without an LEI, follow the ITS-prescribed alternative identifier format — don't leave the field blank or invent your own coding scheme.
Use ISO Country Codes, Not Country Names
Every country field requires the ISO 3166-1 alpha-2 code (two-letter format). Use "RO" not "Romania", "DE" not "Germany", "US" not "United States". This seems trivial, but free-text country names were one of the most common validation failures in the dry run.
Ensure Every Contract Links to at Least One Service and One Function
A contract in Table 5 without a corresponding service in Table 8 is an orphan record. Similarly, a service that doesn't link to a function in Table 9 creates an incomplete picture. The tables are designed as a chain: Entity → Contract → Service → Function. Every link must be present.
Cross-Reference Provider Names Exactly Across All Tables
If "Microsoft Ireland Operations Limited" is the name in Table 3, it must be exactly that in every other table that references this provider. Not "Microsoft", not "MSFT", not "Microsoft Corp". Character-for-character consistency is essential for automated validation.
Fill ALL Mandatory Fields
86% of dry run errors were missing mandatory data. Not wrong data, not misclassified data — simply empty fields. Before submission, run a completeness check across every mandatory field in every table. If you genuinely don't have the information, figure out how to get it. A blank mandatory field is an automatic validation failure.
Practical Approach for Small Entities
If you're a smaller financial entity — a credit union, a small payment institution, an insurance intermediary — the register can feel disproportionately burdensome. The template is the same whether you have 10 providers or 500. Here's how to approach it practically.
Start with your vendor list. You probably have 10 to 30 ICT providers, not 200. Pull your accounts payable records, your existing vendor inventory, and your IT asset management data. Cross-reference them to build a complete list. Don't overthink it initially — just get every ICT provider name on a list.
Map contracts to providers first, then services, then functions. Work in the order the tables are structured. For each provider, find the contract. For each contract, list the services. For each service, identify which business function it supports. This sequential approach prevents the disorientation that comes from trying to fill in all 15 tables simultaneously.
Use the criticality assessment to focus effort. Not every provider needs the same depth of analysis. Your core banking system provider requires comprehensive sub-outsourcing mapping, exit strategy documentation, and detailed risk assessment. Your office Wi-Fi provider probably doesn't. Do the criticality assessment early and allocate your effort proportionally.
Pre-populate code lists to avoid free-text errors. Download the EBA's official code lists for service types, entity types, country codes, and criticality classifications. Set these up as dropdown menus in your working template so you're selecting from valid values rather than typing free text.
Run your own quality checks before submission. Before sending your register to the NCA, run through a validation checklist: Are all mandatory fields complete? Do all cross-references resolve? Are LEIs valid? Are country codes in ISO format? This self-validation step catches the majority of errors that trip up submissions.
Preparing for the Next Submission Window
The annual submission window runs from January 1 to March 21. If you're reading this in Q4 or early Q1, you're in the right timeframe to prepare. If you're reading it in Q2 or Q3, you have time to build the right processes so next year isn't a scramble.
Start updating in Q4 of the previous year. Don't wait until January to open the register. Use October through December to review and update your data. New vendors onboarded during the year, contracts renewed or terminated, services added or removed — all of these need to be reflected.
Track contract changes throughout the year. The biggest pain point for the second and subsequent submissions is reconciling a year's worth of changes. Every new vendor, every contract renewal, every service change should trigger an update to your working register. Build this into your vendor management and procurement processes.
The register is a living document. Treat it as such, not as an annual exercise. Entities that maintain their register continuously find the annual submission to be a straightforward export. Entities that treat it as a once-a-year project find themselves in a multi-week data scramble every January.
Consider designating a register owner — someone accountable for keeping the data current. In smaller entities, this often falls to the CISO, the compliance officer, or the risk manager. Whoever it is, they need a process for capturing changes as they happen, not reconstructing them months later.
Getting It Right Matters
The Register of Information isn't the most glamorous part of DORA compliance, but it's one of the most scrutinized. The ESAs use it to identify systemic risks and designate critical ICT providers. Getting it right isn't just about compliance — it's about demonstrating that you understand your ICT dependency landscape.
And for most small entities, that understanding is genuinely valuable beyond the regulatory checkbox. The process of mapping your ICT providers, contracts, services, and functions creates a picture of your operational dependencies that informs better risk decisions, stronger vendor negotiations, and more resilient operations.
The 15 tables are structured. The rules are clear. The challenge is execution — and with the right tools and approach, it's entirely manageable.