DORA Register of Information (ROI)
Under the EU Digital Operational Resilience Act (DORA), financial entities must maintain and submit a Register of Information (ROI), which is a structured record of their ICT third-party providers and the services they support.
The register gives regulators visibility into how financial institutions rely on external technology providers, including the services delivered, contractual arrangements, and supply chain dependencies.
Firms must keep the register accurate and up to date and submit it through their national competent authority, enabling regulators to monitor ICT risk across the financial sector.
Why the ROI exists
Ensures your firm has clear oversight of ICT third party risks
Gives supervisors visibility into your ICT dependencies
Enables effective supervision, esp. of critical ICT providers
The ROI structure & what it contains
The ROI is composed of 15 tables linked by 4 keys – and mapped across your ICT supply chain. It contains:
1 set of templates for all firms- 15 tables
- 100's of pages of EBA guidance
- XBRL-CSV format only
How to complete the ROI
Where to start
1. List all ICT services & functions
- Capture all ICT services from third-party + in-group providers
- List all business + operational functions and talk to them
- This is your initial inventory
2. Internal assessment
- Identify critical/ important functions (Art 3(22) DORA)
- Additional info isneeded for these(risk assessment, supply chain, subcontractors, concentration, exit strategy)
- Identify material sub-contractors (Art 30 (2) DORA)
- Rank providers (Direct = 1, Sub-contractors = 2-3)
3. ICT supply chain
- Map each ICT service to its service type (S01 – S19) Annex III
- Capture your supply chain: direct providers + subcontractors
- Link everything together in the same supply chain
4. Capture the 4 keys
- Record contract ref numbers (internal + external)
- Capture LEI’s for signing entities + direct ICT providers
- Assign ICT service type codes (S01 – S19) from Annex III
- Create consistent function IDs for every function
Scope + document your ICT supply chain
Scope
1. All ICT providers are in-scope (not just those who support critical or important functions)
2. And extra details are required when an ICT provider supports one a critical or important function, including:
- Risk assessments
- Subcontractors
- Concentration risk
- And your exit strategy
What to record:
To clearly document the supply chain, you must:
- Contract ref number: between your firm and the direct ICT TPP.
- Assign ICT service type (Annex III, S01 – S19)
- Rank providers:
- Rank 1 = Direct provider
- Rank 2,3 = Material subcontractors (Upto the last material subcontractor in the chain)
- Links: Show how each provider fits within the same supply chain
Here’s Fiona walking through what an ICT service supply chain looks like in practice.
The 4 keys that link everything together
Contract reference number
- Unique internal ID assigned to each ICT contract
- Must remain consistent across all ROI tables
Legal entity identifier (LEI)
- 20 character code, unique to each entity
- Required for your contracting entity + each direct ICT provider
Function identifier
- Unique function ID created from: LEI + licensed activity + function
- Must remain consistent across all tables.
ICT service type
- One of 19 ICT service types (S01 – S19) from Annex III
- Drives which fields + validations rules apply
How the keys link across templates
This illustration shows how the four keys link across the different ROI templates.
Take the contract ref no. in green for example. It appears in 10 out of 15 tables. So, if a slightly different contract ID is used, the tables stop linking and the whole return breaks.
That’s why these keys need to be absolutely consistent everywhere.
Small technical errors = immediate file rejection.
Don't forget that data quality is everything
Data principles
Accuracy, completeness, consistency, integrity, uniformity, validity
Clear taxonomies
Create clear taxonomies of functions so each ID clearly distinguishes between internal functions
Consistency across the 4 keys
Check for consistency across the 4 keys at entity and group level