A DORA register of information is a relational view of all contractual arrangements for ICT services provided by third parties, maintained at entity level and, where applicable, sub-consolidated and consolidated levels. It is not an outsourcing spreadsheet renamed for regulation. The register connects financial entities, branches, functions, ICT services, direct providers, subcontractors, contracts, criticality, locations, dates, costs, and exit information through prescribed templates and identifiers. Those relationships let risk teams see dependencies and let authorities supervise concentration and critical providers.
Commission Implementing Regulation (EU) 2024/2956 establishes the templates and requires accuracy, completeness, consistency, integrity, uniformity, and validity. It also expects all direct ICT services and subcontractors that effectively underpin ICT services supporting critical or important functions or material parts. The EIOPA DORA resource links the operative standards. Build the register as governed master data with source lineage, validation, reconciliation, and change events. A one-off regulatory upload will decay as soon as a contract, function, or provider changes.
Scope entities, levels, arrangements, and ICT services
List every in-scope financial entity, LEI, competent authority, branches, group structure, consolidation level, and register-maintaining entity. Then identify contractual arrangements for ICT services, including intra-group provision and cases in which another entity performs activities on behalf of the financial entity. Do not begin from procurement's outsourcing category; DORA's ICT-service population can be broader. Reconcile accounts payable, contract repositories, architecture inventories, cloud accounts, supplier records, software subscriptions, and service-owner attestations to find omitted arrangements.
Define inclusion and exclusion rules with examples. Professional legal advice delivered by email is not the same dependency as managed cloud hosting; a business process provider may include an ICT service that must be recorded. Capture bundled agreements as arrangements and service rows without losing the signed contract reference. Establish treatment for trials, free services, emergency purchases, resellers, marketplace billing, and expired contracts still supporting data retention or transition. Each exclusion needs an owner and rationale that can survive review.
Design the DORA register of information data model
Implement the official templates as a relational model, not one wide worksheet. Preserve contractual arrangement reference numbers, financial-entity identifiers, provider identifiers, function identifiers, and ICT-service types as keys. Use valid LEIs or EUIDs for legal-person providers according to the Implementing Regulation and maintain evidence of identifier validation. A display name is not a stable key: providers merge, brands differ from contracting entities, and one group can contain many service companies. Separate legal provider, ultimate parent, reseller, and operational service brand.
| Domain | System of authority | Owner | Quality test |
|---|---|---|---|
| Financial entity and branch | Legal-entity registry | Company secretariat or finance | Active LEI and consolidation match |
| Contractual arrangement | Executed contract repository | Procurement and legal | Reference, parties, dates and status agree |
| Business function | Approved function taxonomy | Business owner | Unique identifier and criticality rationale |
| ICT service | Service catalogue and architecture inventory | Technology service owner | Service type, data, location and dependency complete |
| Provider and subcontractor | Third-party master plus verified identifier source | Vendor risk | Legal identity, rank and supply-chain relationship valid |
| Reporting output | Governed register platform | DORA data owner | Template, format and cross-table controls pass |
Map contracts to functions and ICT services
A contract alone does not reveal operational dependency. For each service, name the recipient financial entity, supported function, function owner, critical-or-important assessment, service type, data category, delivery location, storage and processing locations, and the arrangement that authorizes it. A global cloud agreement may support dozens of services and functions with different criticality. Model those many-to-many relationships explicitly. The source-of-truth dashboard guide is useful for definition ownership and freshness; regulatory keys and validations must remain primary.
Criticality must come from the financial entity's approved function assessment, not the provider's marketing tier. Preserve the rationale, approval date, recovery objectives, substitutability, customer impact, and dependencies. Link arrangements signed by another group company to each beneficiary entity. Reconcile service owners against ledger spend and technical discovery quarterly. An unowned API, identity tenant, managed database, or security-monitoring platform can be more operationally material than a large consultancy contract, so value thresholds alone are poor completeness controls.
Trace ICT subcontracting and supply-chain rank
The direct provider has rank one; subcontractors occupy higher ranks in the ICT service supply chain. For services supporting critical or important functions, record subcontractors that effectively underpin the service or material parts, particularly where disruption would impair security or continuity. Obtain structured disclosures through contracts and recurring attestations. Capture which service element the subcontractor supplies, countries, data access, substitutability, notification commitments, and dependency path. Do not create a flat list that cannot show which upstream service relies on which downstream party.
Supplier names require normalization and legal identifiers. Challenge provider claims that no subcontractor is material against architecture and service facts. The supply-chain security guide helps tier dependency risk; DORA adds prescribed register relationships. Track changes as events with effective dates, because a provider may add a hosting subprocessor between reporting cycles. Contract owners need an escalation route when required identifiers, locations, or chain details are missing.
Govern contract intake and change at the source
Add register fields to procurement intake before signature. The requester identifies the service and function; procurement controls arrangement data; legal confirms executed terms; vendor risk identifies providers and subcontractors; the service owner confirms architecture and locations; business continuity validates criticality and exit; finance supplies cost data; the DORA data owner validates the joined record. Prevent production onboarding until mandatory fields have an owner or approved time-bound exception. This is cheaper than reconstructing service facts during submission.
Trigger updates for renewal, amendment, termination, provider merger, new legal entity, service migration, location change, criticality change, and subcontractor notice. Integrate workflow events rather than granting every team direct edit rights. The vendor-access guide can govern provider identities during onboarding and exit. Register closure should verify data return, deletion, access revocation, residual services, and successor arrangement before marking a relationship ended.
Validate, reconcile, and evidence data quality
Run schema, format, referential-integrity, enumeration, cardinality, date, and identifier checks on every build. Then run semantic tests: active service with expired contract, critical function without service, service without recipient entity, third-country provider without LEI, subcontractor rank one, termination before start, and arrangement with no direct provider. Reconcile row counts and totals across entity and consolidated registers. Every correction should preserve old value, new value, source, actor, time, and reason.
| Control | Detects | Owner response | Release condition |
|---|---|---|---|
| Ledger-to-register reconciliation | Paid ICT provider omitted | Classify service or document exclusion | All material differences resolved |
| Contract-to-service cardinality | Executed arrangement with no operational mapping | Assign service and function owner | No unexplained orphan |
| Critical-function chain check | Missing provider or material subcontractor | Obtain and validate chain | Dependency path complete |
| Identifier validation | Inactive, malformed or duplicate LEI/EUID | Correct legal entity mapping | Prescribed identifiers valid |
| Temporal consistency | Impossible or stale dates | Confirm source and effective period | Current reporting date represented |
| Consolidation reconciliation | Entity rows lost or duplicated | Trace keys and consolidation logic | Entity and group totals reconcile |
Prepare supervisory reporting and management use
Build reporting output from the governed model, pin the reporting date, template version, validation rules, source snapshots, and transformation code, and retain acknowledgements or errors. Rehearse the full submission with realistic volume and correct defects at their authoritative source. Limit manual overrides; where unavoidable, record approval and feed the corrected value back. The SaaS audit-log guide provides a model for attributable data changes and export events.
Use the same register for concentration, uncontracted services, critical-function dependencies, renewal risk, missing exit plans, geographic exposure, and provider incidents. This gives owners a reason to improve data between reports. Management dashboards should show freshness, unresolved validation failures, reconciliations, critical chains, and upcoming changes, with drill-down to source. A register that is useful for risk decisions attracts correction; a regulatory-only artifact tends to decay until the next deadline.
Assign a formal issue process for disputed data. Procurement may identify the contracting party, technology may identify a service brand, and vendor risk may identify a different ultimate parent; all can be correct for different fields. The data steward should preserve each source, apply the regulatory definition, record the resolution, and update reusable mapping rules. Set service levels for critical errors discovered during reporting and require root-cause analysis when the same defect recurs across entities. Periodic owner certification should present the relevant service and function records, not ask for a blanket yes. Evidence of challenge, correction, and unresolved uncertainty gives management a more honest view than a register that passes structural validation through guessed values.
Plan for acquisitions and divestments before they occur. New entities bring local contracts, undocumented subscriptions, inherited providers, and different function taxonomies; divested entities can leave shared arrangements and transitional services. Define a cutover date, source inventory, identifier strategy, reconciliation, accountable integration owner, and reporting treatment. Preserve predecessor references so historical incidents and costs remain traceable. Transitional service agreements deserve explicit service, provider, location, criticality, and exit records rather than temporary exclusion. A controlled legal-entity change process prevents group consolidation from silently duplicating providers, dropping beneficiary entities, or breaking the relationship between an old contract and a continuing ICT service.
Key takeaways
- Scope all ICT arrangements from multiple sources rather than an outsourcing label.
- Implement prescribed templates as related data with stable identifiers.
- Map each service to recipient entities, functions, criticality, contracts, and locations.
- Trace material subcontractors through ranked supply-chain relationships.
- Capture and validate data during procurement and service change.
- Reconcile, version, and use the register for both supervision and operational risk decisions.
DORA register of information FAQ
Does the register include only outsourced critical functions?
No. It covers contractual arrangements for ICT services from direct third-party providers, with additional subcontractor detail for services supporting critical or important functions. Do not limit discovery to legacy outsourcing registers.
Can the register be maintained in spreadsheets?
A spreadsheet may support a small implementation, but prescribed relationships, concurrent ownership, lineage, validation, consolidation, and repeated reporting often justify a governed data model. Whatever tool is used must preserve quality and control.
Which provider identifier should be used?
Implementing Regulation 2024/2956 specifies LEI or EUID treatment for legal persons, including LEI requirements for third-country providers. Validate identifiers against current authoritative records and reporting instructions.
Conclusion
The DORA register becomes dependable when contract, service, function, entity, and provider data share stable keys and accountable owners. Continuous intake, change control, reconciliation, and validation turn it from a deadline artifact into a working map of ICT dependency. That same map supports cleaner reporting and better resilience decisions.