The Register of Information (RoI) is one of DORA's most operationally demanding requirements and one of the first things regulators examine. Every financial entity must maintain a comprehensive register of all ICT third-party service arrangements. The European Supervisory Authorities (EBA, ESMA, EIOPA) have published detailed templates specifying exactly what the register must contain.
What the Register of Information Is
The Register of Information is a structured inventory of every arrangement under which a financial entity uses ICT services from third parties. It covers:
- The third-party service provider details
- The services provided
- Criticality assessment
- Data processed
- Contractual terms summary
- Sub-contractor information
It is not a simple vendor list. The EBA/ESMA/EIOPA templates require granular data at the level of individual service arrangements — not just provider names.
The ESA Templates
The European Supervisory Authorities published mandatory reporting templates (ITS on DORA register) specifying the exact fields required. The templates are structured as spreadsheets with multiple sheets:
RT.01 — Contractual Arrangements: One row per contractual arrangement between the financial entity and each ICT third-party provider.
RT.02 — ICT Third-Party Service Providers: One row per third-party provider, with provider details.
RT.03 — ICT Intragroup Arrangements: If the financial entity uses ICT services from entities within the same group.
Register of Information: Key Fields
For each contractual arrangement (RT.01), the register must include:
Entity and Provider Identification
- Financial entity legal name and LEI code
- Third-party provider legal name, LEI code, and country of incorporation
- Whether the provider is a group entity or third-party
Service Details
- Description of the ICT service
- Sub-service category (cloud, data analytics, payment, software, hardware, support, etc.)
- Whether the service supports a critical or important function
- Function identifier (reference to the specific business function supported)
Criticality and Risk
- Assessment of criticality (critical / important / not critical)
- Whether the arrangement covers a service that supports a critical or important function as per DORA Article 3
- Data sensitivity (personal data, payment data, no special data categories)
Contractual Terms
- Contract start date and end date (or if open-ended, note this)
- Notice period for termination
- Data location (country/countries where data is stored and processed)
- Governing law of the contract
Sub-contractors
- Whether the provider uses sub-contractors for the service
- Names and locations of material sub-contractors
Business Continuity
- Whether a business continuity agreement exists for this service
- RTO and RPO for the service
Practical Template Structure
Here is a simplified version of what your working register should contain:
Register of Information — [Financial Entity Name] — [Date]
ROW EXAMPLE:
Provider: Amazon Web Services EMEA SARL
LEI: [LEI code]
Service: Cloud infrastructure (IaaS) — production environment
Critical function: Yes — core payment processing
Data: Customer financial data, transaction records
Contract start: 2021-03-15 | End: 2026-03-14
Data location: EU (Ireland, Frankfurt)
Sub-contractors: AWS, Inc. (US) — underlying infrastructure
BCP: Yes | RTO: 4 hours | RPO: 1 hour
Reporting the Register to Regulators
Financial entities must submit the Register of Information to their competent authority on request and at defined reporting dates. The EBA/ESMA/EIOPA set reporting schedules:
- Annual reporting of the full register
- Ad hoc reporting when requested by the competent authority
The register must be submitted in the format specified by the relevant ESA template. Data quality is assessed — incomplete or inaccurate registers are treated as non-compliance.
Building and Maintaining the Register
Initial build:
- Survey all business units to identify ICT third-party services in use
- Collect provider details (legal name, LEI, country of incorporation)
- Collect contract details (start/end, governing law, data locations)
- Assess criticality for each service
- Identify sub-contractors for each provider
- Populate the ESA template format
Ongoing maintenance:
- Assign ownership to a specific team (typically IT/procurement + legal/compliance)
- Update when new contracts are signed
- Update when existing contracts change
- Update when providers add or change material sub-contractors
- Annual review and confirmation of accuracy
Most financial entities maintain the register in a spreadsheet linked to their contract management system. For larger entities, dedicated third-party risk management (TPRM) tools are used.