The Digital Operational Resilience Act (DORA) came into full effect on 17 January 2025. Among its core obligations is the requirement for financial entities to maintain a structured Register of Information — a comprehensive inventory of all ICT third-party service arrangements, including subcontractors and intra-group services.
This guide explains what the DORA Register of Information is, which organisations are required to maintain one, what data fields are mandated, and how to structure a sustainable operating model. Whether you are a compliance officer preparing your first submission, a risk manager reviewing data quality, or a vendor manager navigating cross-departmental ownership, this guide walks you through every step.
You will learn: what regulators expect, which entities are in scope, what the mandatory data categories are, who should own each field, the seven steps to build your register, the most common mistakes that cause submission failures, and how purpose-built tools can simplify ongoing maintenance.
What is the DORA Register of Information?
The DORA Register of Information (RoI) is a structured dataset that financial entities must compile and maintain under Article 28(3) of Regulation (EU) 2022/2554. It records every ICT third-party service arrangement in place — from cloud infrastructure providers to SaaS platforms, managed security services, payment processors, and intra-group ICT relationships.
The purpose of the register is supervisory. National competent authorities (NCAs) and the European Supervisory Authorities (EBA, EIOPA, ESMA) use the register to assess an entity's ICT dependency landscape, identify concentration risk, and monitor the operational resilience posture of the financial sector as a whole. The ESAs publish an annual aggregate report based on data submitted by firms across the EU.
Regulatory Purpose
DORA moves beyond traditional outsourcing registers. Its Register of Information requirements are defined in the Joint RTS on the register of information under Articles 28(9) and 30(5) DORA (JC 2023 84). The RTS specifies exact data fields, cardinality, and validation rules. It also mandates that the register be kept continuously up to date — not just at submission time.
Supervisory Reporting
Financial entities are required to provide their register to their NCA on an annual basis, and on request at any time. The NCA may forward the data to the relevant ESA. Submissions must conform to the prescribed data templates (typically CSV or XBRL format), and validation will flag missing fields, inconsistent identifiers, and referential integrity errors.
ICT Third-Party Risk Oversight
The register feeds into several other DORA obligations. Criticality assessments, exit strategies, and contractual reviews all reference the same third-party inventory. Getting the register right is therefore not a standalone exercise — it anchors your entire ICT third-party risk management framework.
Operational Resilience
At its core, the DORA Register of Information is an operational resilience instrument. By forcing entities to map and document every ICT dependency — including fourth parties — it creates visibility that management and regulators can use to assess whether a single provider failure could cause systemic disruption. The register is not just compliance paperwork; it is a risk management tool that supports your continuity and exit planning obligations.
Who must maintain a DORA Register?
DORA applies to a broad range of financial entities operating in the European Union. Article 2 of the Regulation defines the scope, which covers most regulated financial institutions.
Credit Institutions
Banks and mortgage lenders authorised under the CRD.
Investment Firms
MiFID II-authorised investment firms providing financial services.
Payment Institutions
PSD2-licensed payment and e-money institutions.
Insurance Undertakings
Solvency II-authorised insurers and reinsurers.
Crypto-Asset Service Providers
MiCA-authorised CASPs as of their supervised onboarding.
CCPs, CSDs & Trade Repositories
Central counterparties, central securities depositories, and data reporting service providers.
The Proportionality Principle
DORA acknowledges that a small payment institution cannot be expected to maintain the same operational resilience infrastructure as a systemically important bank. Article 4 introduces proportionality: micro-enterprises and small entities benefit from a simplified regime that reduces certain documentation and governance requirements while preserving the core register obligation.
Exemptions
Micro-enterprises (fewer than 10 employees and annual turnover or balance sheet below €2 million) qualify for a simplified DORA regime. They are still required to maintain a register, but the requirements for governance, testing, and reporting are lighter. Even micro-enterprises must identify critical ICT services and ensure basic contractual protections are in place.
Entities operating outside the EU but providing services to EU financial entities are not directly subject to DORA — but their clients are, and must ensure DORA-compliant contracts and risk assessments are in place for these arrangements.
What information must be included?
The Joint RTS specifies a detailed data model for the Register of Information. The following table summarises the major data categories and examples of what each requires.
| Category | Examples |
|---|---|
| Provider Information | Legal entity name, LEI, country of incorporation, group membership |
| ICT Services | Hosting, SaaS, MSP, IT support, cloud services, payment processing |
| Criticality Classification | Critical / Non-critical, supporting function or process |
| Contract Details | Start date, end date, renewal terms, termination notice period |
| Subcontractors | Fourth-party ICT providers, subcontractor chains, country of operation |
| Exit Strategy | Exit plan status, alternative providers identified, migration timeline |
| Risk Assessment | Linked risk assessments, risk rating, last assessment date |
Provider information
Every ICT third-party must be identified using a legal entity identifier (LEI) where one is available. The provider's legal name, country, and group structure must be recorded. Using consistent and validated entity identifiers is critical — supervisors use these to aggregate data across firms and identify concentration risk. Informal names, trading names, or abbreviations are not sufficient.
ICT Services
For each arrangement, you must describe the ICT services provided. The RTS uses a controlled vocabulary for service types. Common categories include: cloud computing services, data analytics, data centre colocation, software maintenance and support, managed IT services, cybersecurity services, and payment services. Each service arrangement is registered separately, even if provided by the same vendor.
Criticality Classification
Determining whether an ICT service supports a critical or important function (CIF) is one of the most consequential decisions in the register. Critical services attract heightened oversight, stricter contract requirements, and mandatory exit strategy documentation. The classification must be based on a documented impact assessment — not a blanket judgment — and reviewed at least annually or when material changes occur.
Contract Details
Contract start and end dates, renewal terms, and notice periods must be accurate and matched to your contract management records. Supervisors use this data to assess lock-in risk and concentration. Contracts that have expired or auto-renewed without review are a common quality failure.
Subcontractors
DORA extends the register requirement to subcontractors — often called fourth parties — that support the delivery of a critical or important ICT service. You must identify these subcontractors, their country of operation, and note any material dependencies. This requires active engagement with your primary vendors to obtain disclosure of their supply chains.
Exit Strategy
For every arrangement supporting a critical or important function, the register must record whether a documented exit strategy exists, the status of alternative provider identification, and whether the exit plan has been tested. Many organisations have exit strategies as a concept but lack the service-specific, tested detail DORA requires.
Risk Assessment
The register should link each arrangement to a risk assessment. This includes the overall risk rating, the date of the most recent assessment, and any open remediation actions. The risk record provides auditors and supervisors with evidence that the entity is actively managing — not just documenting — its ICT dependencies.
DORA Register ownership model
One of the most common root causes of poor register quality is the absence of a clear ownership model. The DORA Register of Information is cross-functional by nature: the data it requires spans legal, procurement, risk, information security, and business operations. No single department can maintain it alone.
Legal
Contract ownership, governing law, termination clauses, and contractual rights of access and audit. Legal should validate contract dates, notice periods, and confirm whether DORA-required provisions are present in each arrangement.
Procurement & Vendor Management
Vendor identification, LEI verification, subcontractor disclosure requests, and renewal tracking. Procurement typically holds the master vendor list and is best placed to identify new arrangements before they appear in the register.
Information Security
Risk ratings, security assessments, incident linkage, and subcontractor security posture. Information security teams hold the most recent vendor due-diligence results and are responsible for validating technical risk data.
Business Owners
Service criticality, supporting functions, and operational dependencies. Business owners are best placed to assess whether a service supports a critical or important function — this judgment cannot be made centrally without business input.
Compliance & Regulatory Oversight
Overall register completeness, submission preparation, and liaison with the NCA. Compliance should own the governance framework — the quality rules, review cadences, and escalation paths — even if they do not own individual data fields.
An effective ownership model defines, for each data field, which department provides the data, which department validates it, and at what frequency. This is typically documented in a RACI matrix. Without this clarity, the register will drift: fields go stale, conflicts arise between sources, and no one takes accountability for quality failures.
Common DORA register mistakes
These are the most frequent causes of register quality failures and submission rejections based on implementation experience across financial entities.
1. Missing Subcontractors
Most firms have a clear picture of their direct ICT providers but a poor picture of fourth parties. If your cloud provider outsources data processing to a sub-processor, that relationship must appear in your register for critical services. Failure to capture subcontractors is one of the most frequent validation failures flagged by supervisors.
2. Duplicate Supplier Entries
The same vendor appearing under different names, identifiers, or legal entities is a data quality problem that cascades through the register. Concentration risk calculations become unreliable. Use validated LEI codes and a canonical vendor master to prevent duplicates from proliferating.
3. Incorrect Criticality Classifications
Over-classifying services as non-critical reduces the oversight burden but creates regulatory risk. Under-classifying critical services is a material compliance failure. Classifications must be supported by documented impact assessments — not made informally by whoever is filling in the spreadsheet.
4. Outdated Contract Data
Contract end dates that have passed, renewal terms that no longer reflect the current agreement, and missing termination notice periods all indicate a register that is not being maintained. This is particularly common where the register was built once as a project and not embedded into ongoing contract management processes.
5. No Clear Ownership Model
Without documented data ownership, the register becomes no-one's responsibility. When fields are wrong or missing, there is no clear path to remediation. Organisations that built their register as a compliance project rather than a living operational tool almost always face this problem.
6. Missing Exit Plans
Exit strategy documentation is required for critical services, but many organisations have only a generic exit policy rather than service-specific plans. DORA requires that you can demonstrate a plausible transition path for each critical arrangement — a general statement that you would find an alternative provider is not sufficient.
How to build a DORA Register step-by-step
Building a submission-ready DORA Register of Information is a project with seven distinct phases. Each phase has clear deliverables and dependencies.
Step 1
Define Scope
Identify which legal entities within your group are in scope for DORA and whether consolidated or entity-level reporting is required. Confirm with your NCA which submission format they require. Document the services in scope, including intra-group arrangements, and establish which functions are candidates for criticality classification. Scope definition is the foundation — errors here cascade through every subsequent step.
Step 2
Inventory ICT Providers
Compile a complete list of all ICT third-party service arrangements. Sources include: contract registers, accounts payable systems, IT asset inventories, security vendor lists, and business owner interviews. Validate legal entity names against LEI registries. Identify intra-group providers and confirm whether they are covered by internal service agreements. At this stage, completeness matters more than accuracy — you can correct data; you cannot report what you have not found.
Step 3
Classify Services
For each arrangement, determine whether it supports a critical or important function. Work with business owners to assess the impact of a disruption to the service. Document the rationale. Apply the controlled service-type vocabulary from the RTS. Where multiple services are provided under one contract, register each service separately. Flag arrangements that require subcontractor disclosure and initiate requests to vendors.
Step 4
Assign Ownership
Create a RACI matrix that maps each data field to a responsible owner. Confirm ownership with each department. Establish the review cadence for each field — some fields (like contract dates) only change on renewal; others (like risk ratings) should be reviewed quarterly. Embed register updates into existing processes: contract sign-off, procurement approval, vendor review cycles. Ownership without process integration will not survive the first annual cycle.
Step 5
Validate Data Quality
Run systematic quality checks across all data fields before treating the register as submission-ready. Checks should cover: mandatory field completeness, valid controlled-vocabulary values, date logic (end date must be after start date, no expired contracts without renewal records), referential integrity (every critical service must link to an exit strategy record), duplicate provider detection, and subcontractor completeness for critical services.
Step 6
Establish Governance
Define the ongoing governance model. This includes: a monthly or quarterly quality review with all data owners; an escalation path for unresolved quality issues; a change management process for new, modified, or terminated arrangements; an annual full review of criticality classifications; and a pre-submission validation sprint before each regulatory reporting window. Governance should be documented in a policy or operating procedure that survives staff turnover.
Step 7
Prepare Regulatory Submissions
Export the register in the format required by your NCA (typically CSV aligned to the JTS data templates or XBRL). Run the ESA validation ruleset against your export before submission — errors caught internally are far less costly than errors flagged by your supervisor. Retain the submission artefact and a timestamp. After submission, treat any NCA feedback as a quality improvement trigger and update your governance process accordingly.
DORA Register template example
The following structure shows a representative row from a DORA Register of Information. Each row represents a single ICT service arrangement. A single vendor may appear in multiple rows if they provide several distinct services.
| Field | Example Value |
|---|---|
| Provider | Acme Cloud Services B.V. |
| LEI | 5493001KJTIIGC8Y1R12 |
| Service | Cloud Infrastructure (IaaS) |
| Criticality | Critical |
| Business Owner | Head of IT Operations |
| Contract Start | 2022-01-01 |
| Contract End | 2027-12-31 |
| Subcontractors | DataStore GmbH (DE), NetOps Ltd (IE) |
| Exit Strategy | Documented — alternative identified, plan last tested 2024-11 |
| Risk Rating | High |
| Last Review Date | 2025-03-15 |
DORA Register vs Traditional Outsourcing Registers
Many financial entities already maintain some form of outsourcing or vendor register — often built to meet EBA outsourcing guidelines or internal procurement requirements. The DORA Register of Information is significantly more demanding. The table below highlights the key differences.
| Dimension | Traditional Register | DORA Register |
|---|---|---|
| Primary Purpose | Vendor tracking & spend management | Operational resilience & supervisory reporting |
| Scope | All vendors or outsourced services | All ICT arrangements, including intra-group |
| Data Depth | Contract and cost focus | Risk, dependency, subcontractor & exit data |
| Reporting | Internal only | Mandatory annual supervisory submission |
| Format | Free-form (Word, Excel) | Prescribed templates with validation rules |
| Fourth Parties | Usually not captured | Required for critical services |
| Criticality | Limited or informal | Formally assessed and documented |
| Update Frequency | Annual or project-based | Continuous, event-driven plus periodic review |
If your organisation already maintains an EBA outsourcing register, it provides a useful starting point — but it will typically cover only 60–70% of what DORA requires. The gaps are usually in subcontractor data, exit strategy linkage, criticality formality, and the regulatory submission format. A gap analysis against the RTS data model is the recommended first step.
How RiskNow helps maintain a DORA Register
RiskNow is a GRC platform built by practitioners who have delivered DORA programs in financial entities. The platform provides a dedicated Register of Information module that helps you maintain a complete third-party inventory, trace supply chain dependencies, and prepare submission-ready regulatory outputs.
Register of Third Parties
Maintain a structured register of ICT third parties with legal entity data, LEIs, service mappings, criticality classification, contract lifecycle details, and accountable field owners.
Supply Chain Visibility
Map subcontractors and fourth parties across your ICT supply chain, link dependencies to critical services, and keep an auditable record of where concentration and resilience risks sit.
Data Quality Reporting (100+ Checks)
Run data quality reports with more than 100 automated checks covering completeness, controlled values, duplicate detection, date logic, and referential integrity before submission.
Regulatory Exports (XBRL / CSV)
Export register data to regulatory-ready XBRL and CSV formats aligned to supervisory templates, with pre-export validation to catch issues before filing.
By connecting third parties, supply chain relationships, contracts, risk assessments, and incidents in one model, RiskNow reduces manual reconciliation and helps teams keep the register accurate between annual submission cycles.
Frequently Asked Questions
What is a DORA Register of Information?
The DORA Register of Information is a structured inventory of all ICT third-party service arrangements maintained by a financial entity under Article 28(3) of Regulation (EU) 2022/2554. It covers providers, services, criticality, contracts, subcontractors, and risk assessments.
Is the DORA Register mandatory?
Yes. All in-scope financial entities must maintain a Register of Information and provide it to their national competent authority annually or on request. Non-compliance can result in supervisory measures including public disclosure, fines, and remediation orders.
How often should the DORA register be updated?
The register must be kept continuously up to date. In practice this means event-driven updates for new arrangements, material contract changes, and terminated services — supplemented by a periodic (monthly or quarterly) quality review and an annual full refresh ahead of the supervisory submission window.
What are critical ICT services?
Critical ICT services are those that support a critical or important function (CIF) — one whose failure or degradation would materially impair the entity's regulatory compliance, financial soundness, or service delivery. Criticality must be assessed through a documented impact analysis and reviewed at least annually.
Do subcontractors need to be included in the register?
Yes, for critical and important services. You must identify subcontractors (fourth parties) that are part of the delivery chain for a critical service and include them in the register. This requires proactive engagement with primary vendors to obtain subcontractor disclosure.
How does DORA differ from EBA outsourcing guidelines?
The EBA outsourcing guidelines focus primarily on governance, contract requirements, and notification obligations for material outsourcing. DORA goes further: it covers all ICT arrangements (not just material outsourcing), mandates subcontractor disclosure for critical services, requires formally documented exit strategies, and introduces a standardised supervisory reporting register with prescribed data fields.
Can Excel be used to maintain the DORA register?
Technically yes, but in practice it creates significant operational risk. Excel registers struggle with access control, version management, cross-table referential integrity, and audit trails. For small entities with fewer than 20–30 arrangements a structured spreadsheet may be sufficient short-term. For larger entities, a purpose-built platform is strongly recommended.
What data fields are required by the DORA register?
The Joint RTS specifies mandatory fields including: provider legal entity name and LEI, ICT service type, supported function, criticality classification, contract start and end dates, termination notice period, subcontractor details (for critical services), exit strategy status, and risk assessment linkage. See the "What Information Must Be Included?" section above for a full breakdown.
What happens if the DORA register is incomplete at submission?
An incomplete or inaccurate register can result in: the NCA returning the submission for correction, a formal supervisory dialogue about data governance weaknesses, or — in persistent cases — escalated supervisory measures. Repeated failures are treated as evidence of broader operational resilience deficiencies.