DORA Register of Information: Requirements and Preparation

The DORA Register of Information (RoI) is a mandatory database that financial entities must maintain documenting all contractual arrangements with ICT third-party service providers. This register serves multiple purposes: internal risk monitoring, supervisory oversight, and input for designating Critical ICT Third-Party Providers.

Key Takeaways

Point	Summary
Mandatory register	All financial entities must maintain an RoI
All ICT providers	Covers all ICT third-party service providers, not just critical ones
Regulatory submission	Must be submitted to competent authorities
Multiple levels	Required at entity, sub-consolidated, and consolidated levels
Standardized format	ESAs have specified the data fields and format

Quick Answer: The Register of Information is a structured database of all contractual arrangements with ICT third-party service providers that financial entities must maintain and submit to regulators. It must include provider identification, contract details, services provided, criticality classification, data locations, and sub-outsourcing information. The register enables internal risk monitoring, supports supervisory oversight, and provides input for CTPP designation decisions. First submissions are scheduled for 2025/2026.

Purpose of the Register

Internal Use

The RoI serves as an internal risk management tool:

Purpose	Benefit
Visibility	Complete view of ICT third-party landscape
Risk assessment	Input for concentration and dependency analysis
Due diligence	Support for provider reviews
Exit planning	Foundation for transition planning
Incident response	Quick identification of affected providers

Supervisory Use

Competent authorities use submitted registers to:

Purpose	Activity
Oversight	Monitor ICT third-party risk across supervised entities
Concentration analysis	Identify sector-wide concentration risks
CTPP designation	Input for identifying critical providers
Examination planning	Inform supervisory priorities

ESA Use

The European Supervisory Authorities use aggregated data to:

• Identify candidates for Critical ICT Third-Party Provider designation
• Analyze systemic risks from ICT concentration
• Coordinate cross-sector oversight

Required Data Fields

Provider Information

Field	Description
Provider name	Legal name of the ICT service provider
LEI	Legal Entity Identifier (where available)
Headquarters location	Country of provider's registered office
Parent undertaking	Parent company information
Registration details	Company registration numbers
Contact information	Key contact details

Contract Information

Field	Description
Contract identifier	Unique reference for the arrangement
Contract start date	When the arrangement began
Contract end date	Scheduled termination (if applicable)
Contract value	Annual cost of services
Governing law	Jurisdiction governing the contract
Termination provisions	Notice period and termination rights

Service Information

Field	Description
Service description	Nature of ICT services provided
Service type	Classification of service category
Functions supported	Business functions relying on the service
Critical function indicator	Whether service supports critical/important functions
Data types	Categories of data processed
Data locations	Where data is processed and stored

Sub-Outsourcing

Field	Description
Sub-contractor details	Information on material sub-contractors
Sub-contracted services	Services provided by sub-contractors
Sub-contractor locations	Where sub-contractors process data

Risk Assessment

Field	Description
Substitutability assessment	Ease of replacing the provider
Concentration indicator	Contribution to concentration risk
Last assessment date	When provider was last reviewed

Scope of Coverage

Which Providers to Include

The register must include all ICT third-party service providers:

Include	Examples
Cloud services	IaaS, PaaS, SaaS providers
Software vendors	Core banking, trading systems
Data services	Market data, reference data
Infrastructure	Network, telecommunications
Security services	Managed security, SOC services
Support services	IT support, maintenance
Specialized services	Payment processing, custody

Criticality Classification

Distinguish between services supporting:

Classification	Impact
Critical or important functions	Enhanced RoI requirements, additional scrutiny
Other functions	Standard RoI requirements

Critical functions are those whose disruption would materially impair:

• Financial performance
• Soundness or continuity
• Compliance with authorization conditions
• Regulatory obligations

Register Structure

Entity Level

Each legal entity must maintain its own register covering:

• All ICT arrangements directly contracted by that entity
• Services consumed by that entity

Sub-Consolidated Level

For groups, sub-consolidated registers aggregate:

• Registers of entities within sub-consolidation scope
• Cross-entity provider relationships

Consolidated Level

The ultimate parent must maintain a consolidated register:

• Complete group-wide view
• All ICT third-party relationships across the group
• Identification of group-wide concentration risks

Preparation Process

Phase 1: Discovery

Activity	Output
Contract inventory	List of all ICT-related contracts
Provider identification	Deduplicated list of providers
Service mapping	Services provided by each provider
Function mapping	Business functions supported

Phase 2: Data Collection

Activity	Output
Provider data	Complete provider information
Contract data	Contract terms and details
Service data	Service descriptions and classifications
Location data	Data processing and storage locations

Phase 3: Classification

Activity	Output
Criticality assessment	Critical function identification
Concentration analysis	Concentration risk assessment
Substitutability review	Replaceability evaluation

Phase 4: Validation

Activity	Output
Data quality review	Accuracy verification
Completeness check	Coverage confirmation
Format alignment	ESA template compliance

Submission Requirements

Timeline

Event	Date
DORA applicable	January 17, 2025
Submission window	February 16 - March 13, 2026 (approximate)
Authority submission to ESAs	March 31, 2026

Exact dates are announced by competent authorities.

Format

The ESAs have specified:

• Standardized data templates
• Required data fields and formats
• Technical specifications for submission

Frequency

Following initial submission:

• Regular updates (likely annual)
• Notifications of material changes
• Ongoing maintenance requirement

Common Challenges

Provider Cooperation

Challenge: Obtaining complete information from providers

Solutions:

• Engage providers early about data requirements
• Include information requirements in contracts
• Use questionnaires aligned with RoI fields
• Escalate where cooperation is lacking

Group Complexity

Challenge: Aggregating data across multiple entities

Solutions:

• Standardize data collection processes
• Implement central register management
• Coordinate across group entities
• Use automation where possible

Data Quality

Challenge: Ensuring accuracy and completeness

Solutions:

• Validate data against contracts
• Cross-reference with procurement and finance
• Implement data governance
• Regular quality reviews

Classification Consistency

Challenge: Consistent critical function determination

Solutions:

• Develop clear classification criteria
• Document classification rationale
• Review classifications periodically
• Train staff on criteria

Ongoing Maintenance

Updates Required

The register must be updated for:

Event	Action
New arrangements	Add to register
Contract changes	Update relevant fields
Terminations	Update or remove entry
Provider changes	Update provider information
Function changes	Revise criticality classification

Review Cadence

Activity	Frequency
Data accuracy review	Quarterly
Completeness check	Semi-annually
Classification review	Annually
Full register audit	Annually

Common Questions

Do we need to include all ICT providers, even minor ones?

Yes. The register should include all ICT third-party service providers, though the level of detail and scrutiny may vary based on criticality and risk.

What about intragroup ICT services?

ICT services provided within the group should be documented, particularly where they support critical functions. The treatment depends on specific arrangements and regulatory guidance.

How granular should service descriptions be?

Service descriptions should be sufficient to understand what the provider does and which business functions depend on it. For critical functions, more detail is expected.

Can we use existing contract management systems?

Yes, if they can capture required data fields and produce outputs in the required format. Many organizations enhance existing systems or implement dedicated solutions.

What happens if data is incomplete at submission?

Incomplete submissions may attract supervisory attention. Document known gaps and remediation plans. Focus on completeness for critical function providers.

How Bastion Helps

Bastion supports financial entities in preparing and maintaining the Register of Information:

• Gap assessment: Evaluate current third-party documentation against RoI requirements
• Data collection: Support gathering required information from providers
• Classification: Assist with critical function and concentration analysis
• Template population: Prepare submissions in required formats
• Ongoing maintenance: Processes for keeping the register current

Ready to prepare your Register of Information? Talk to our team

---

Sources

• DORA Article 28(3) - Register of Information requirement
• ESA ITS on Register of Information - Technical standards specifying register format and content
• EIOPA DORA Guidance - Supervisory perspectives on register requirements