DORA Register: What Goes in It (2026 Guide)

Three weeks before an internal audit committee meeting, your procurement lead sends over “the vendor list.” It is a spreadsheet with duplicates, missing contract owners, and unclear service descriptions. Your CISO points out that several cloud and telecom dependencies never went through formal risk assessment. Now, when it comes to the dora register, this is where many EU financial institutions feel exposed, because the register of information is not a narrative policy. It is structured, evidence-ready data that supervisors can interrogate.

DORA (Regulation EU 2022/2554) requires you to maintain a register of information on ICT third-party arrangements, aligned to the Implementing Technical Standards (ITS) data model and submission format. The register supports ongoing oversight under DORA Article 28 and related provisions, not just a one-off reporting exercise.

This guide explains what information goes into the DORA register, how to think about it field-by-field, and where teams typically fail on data quality. If you need broader context first, start with what is dora.

Table of Contents

What the DORA register is, and why supervisors care

Who must maintain the DORA register, and when it applies

How to read the register field-by-field

ICT service and contract data: what good looks like

Supply chain and sub-outsourcing: what you can and cannot ignore

Assessments and criticality: where many registers break down

Register to supervisory reporting: what your NCA may ask for in practice

Operationalizing the register: governance, workflows, and evidence

Frequently Asked Questions

Key Takeaways

Conclusion

What the DORA register is, and why supervisors care

The DORA register of information is a structured inventory of your ICT third-party arrangements, designed to be comparable across financial entities and usable for supervisory analysis. Under DORA Article 28, you must manage ICT third-party risk as part of your ICT risk management framework. The register is one of the core artifacts that allows you to evidence that oversight.

Think of it this way: a supervisor is not primarily looking for a list of suppliers. They are looking for traceability between critical functions, the ICT services that support them, the contracts governing those services, and the providers and subcontractors delivering them. If your data model cannot support those relationships, you are likely to struggle when asked to explain concentration risk, exit feasibility, or the impact of an ICT disruption.

Many compliance teams overlook that the register is also a management tool. It is meant to support internal decision-making about outsourcing, renewal, resilience testing, and incident readiness. That is why the ITS expects granular fields that feel operational rather than purely legal.

For a deeper definition and how it fits into the supervisory reporting picture, see dora register of information.

Who must maintain the DORA register, and when it applies

What the regulation actually requires is that in-scope financial entities maintain a register of information as part of the ICT third-party risk management obligations under DORA. DORA applies to the financial entity types listed in Article 2 of DORA, which includes (among others) credit institutions, investment firms, insurance and reinsurance undertakings, payment institutions, e-money institutions, central securities depositories, trading venues, certain data reporting service providers, and crypto-asset service providers.

DORA entered into full application on January 17, 2025. From a practical standpoint, that date drives the expectation that your register can be produced in an evidence-ready form when requested by your National Competent Authority. The details of how and when the register is submitted, and whether submission is periodic or ad hoc, may vary by sector and National Competent Authority practices, subject to the joint work of the European Supervisory Authorities (EBA, ESMA, EIOPA) on the implementing standards.

Consider this: if you are a group maintaining a consolidated register, you still need the ability to evidence entity-level accountability, contracting parties, and service consumption at subsidiary level. Supervisors typically care less about how you store the data internally and more about whether you can produce the ITS-aligned dataset with consistent identifiers and traceability across legal entities, branches, and arrangements.

This content is for informational purposes only and does not constitute legal advice. Financial institutions should seek qualified regulatory or legal counsel for institution-specific DORA implementation guidance.

How to read the register field-by-field

The register is usually easiest to understand if you start from the objects you already manage internally, then map them to the ITS structure. In practice, most institutions maintain:

Entities and branches: the regulated legal entities in scope, plus relevant establishments.

Providers: ICT third-party service providers and, where applicable, intragroup providers.

Contracts: the contractual arrangements governing ICT services.

ICT services: the services actually received and consumed, mapped to business functions and users.

Supply chains: subcontractors and supporting ICT providers involved in delivery.

Assessments: criticality, materiality, risk assessments, and oversight outcomes.

Here’s the thing: field-by-field does not mean you should treat every field as equal. Supervisors and internal auditors tend to focus on fields that drive risk decisions, such as service criticality, locations of data processing, subcontracting, and termination and exit conditions.

If you want a practical starting point for the structure many institutions use when building their dataset, see dora roi template. You should still validate alignment to the current ITS and any National Competent Authority submission practices.

Entity and branch identification: make group structure explicit

Your register typically needs to distinguish between the maintainer of the register and the financial entities covered, particularly for groups maintaining a consolidated register. From an operational standpoint, this is where many groups realize they cannot easily reconcile procurement systems across subsidiaries.

Common data quality issues include inconsistent legal names, missing identifiers such as LEI where applicable, and unclear mapping of contracts to the right regulated entity. These issues may appear administrative, but they become material when you need to show which entity bears contractual rights and obligations.

Provider identification: make the provider record usable for oversight

A provider record should be more than a name. You generally need details that allow you to assess jurisdictional exposure, operational dependence, and concentration. In many institutions, procurement holds supplier details, while IT holds technical dependencies. Your register needs a single reconciled view.

When a provider is part of a wider group, you may need both the contracting entity and the broader corporate structure for risk and concentration analysis. This can be sensitive when services are delivered through multiple affiliates.

ICT service and contract data: what good looks like

Most register failures are not caused by missing a field. They are caused by missing clarity about what the institution is buying and consuming. A contract can cover multiple ICT services, and an ICT service can support multiple business functions. You need to represent these relationships cleanly.

Contract-level information: align legal terms to operational risk

At contract level, you should be able to evidence at least:

Which financial entity is party to the contract and which provider entity is contracted.

Contract start, end, renewal, and termination conditions, including notice periods.

Service delivery locations and, where relevant, data storage and processing locations.

Whether the arrangement supports a critical or important function, and the rationale used.

Key resilience-relevant terms, such as audit and access rights and subcontracting conditions, as required under DORA Article 30.

What many compliance teams overlook is that contract terms often exist in annexes, statements of work, or online terms that procurement never imports into structured fields. Your register needs a defensible approach to capturing the effective terms applicable to the ICT service actually used.

Service-level information: define the ICT service precisely

Supervisors typically challenge vague service descriptions like “IT support” or “cloud.” In practice, this means you should capture the service scope, service model, and operational dependencies that affect availability and integrity.

Service fields that tend to matter in supervisory discussions include: the business owner, technical owner, whether the service is customer-facing, the type of access the provider has to your systems and data, and the service’s role in critical or important functions. This is also where you start building the basis for realistic exit planning.

For broader context on the legal framework and how the ITS fits within it, see dora regulation explained.

Supply chain and sub-outsourcing: what you can and cannot ignore

DORA pushes institutions to look beyond the direct contracting party. Your operational resilience exposure often depends on subcontractors, cloud infrastructure layers, managed security providers, and telecom dependencies that sit behind the service you receive.

Now, when it comes to supply chain information in the register, institutions face a practical constraint: you do not always have full transparency. The expectation is not that you know everything, but that you apply risk-based governance, contractual requirements, and monitoring to obtain and maintain sufficient information to manage material risks.

For many institutions, the most difficult part is distinguishing between subcontractors that are merely incidental and those that materially support the ICT service. Your register should capture the relevant chain elements that affect service continuity, data security, and your ability to audit and exit.

If you are building your overall understanding of DORA as a regulatory package, including how third-party oversight connects to other pillars, see digital operational resilience act dora.

Assessments and criticality: where many registers break down

The register is not just who and what. It is also how risky and why. Under DORA, you must identify, classify, and manage ICT risks, including those arising from third parties. If you cannot show consistent assessment logic across your services and contracts, your register becomes a static inventory rather than evidence of governance.

Critical or important function mapping: document the rationale

Institutions typically struggle to keep function criticality, service criticality, and contract materiality consistent. A common friction point arises when business continuity teams classify a function as critical, but procurement treats the supporting ICT service as a standard vendor relationship.

In practice, this means you should record not only the classification outcome but also the rationale and the approval path. That rationale matters when you need to explain why a service did or did not trigger enhanced contractual clauses, monitoring intensity, or exit testing.

Risk assessment outcomes: ensure they are traceable to controls and decisions

Supervisors may ask how your risk assessment outcomes influence contracting and oversight. Your register data should make it possible to trace: identified risks, control expectations, residual risk acceptance, and follow-up actions.

Consider this: if you classify a cloud-based customer onboarding service as critical, but you cannot evidence a review of subcontractor controls, data location, and audit rights, your register may highlight the gap rather than mitigate it.

Register to supervisory reporting: what your NCA may ask for in practice

Many teams build a register and assume the hard part is done. The reality is that supervisory interactions tend to test whether your register can be used to answer specific DORA questions under Chapter IV, not just whether you can produce a file.

In most cases, your National Competent Authority could ask you to extract subsets of the register to support questions such as:

Which ICT services support critical or important functions, and which providers deliver them.

Where data is processed and stored for those services, including the relevant jurisdictions.

Which arrangements involve material subcontracting, and how you approved and monitor that chain.

Which contracts include DORA Article 30-aligned audit, access, and termination provisions, and where compensating controls exist if terms differ due to provider constraints.

Whether you have provider concentration across critical services and whether exit planning is realistic, including for cloud and telecom dependencies.

Now, when it comes to the ITS, the point is comparability. The implementing standards drafted by the European Supervisory Authorities (EBA, ESMA, EIOPA) are designed so supervisors can aggregate and analyze the market. That means inconsistencies in identifiers, service naming, and entity mapping create avoidable supervisory friction. Even if your internal systems are fragmented, your output needs controlled vocabularies, stable IDs, and validation rules.

What many compliance teams overlook is that the register can become the bridge between third-party governance and other DORA pillars. For example, incident classification and reporting under DORA Articles 17 to 23 may require you to quickly identify the impacted provider, the impacted ICT services, and the downstream business functions. The same dataset also supports resilience testing planning under Chapter IV by helping you define which externally provided services should be included in test scope.

This content is for informational purposes only and does not constitute legal advice. Submission practices and supervisory expectations may vary by sector and National Competent Authority, and may evolve with European Supervisory Authorities guidance.

Operationalizing the register: governance, workflows, and evidence

The reality is that a register maintained as a spreadsheet rarely survives contact with real change. Contracts renew, services evolve, providers restructure, and security controls degrade or improve. You need a sustainable operating model, with defined ownership and change triggers.

In many EU financial institutions, the register owner sits in Compliance or Operational Risk, while the data sources sit in Procurement, IT, and Vendor Management. You will likely need:

A RACI that assigns accountable owners for provider records, contract records, and service records.

Defined events that trigger register updates, such as renewals, material incidents, significant changes, or new subcontractors.

Validation checks for completeness and internal consistency, so reporting does not become an annual data cleanup project.

Evidence trails for approvals and changes, subject to your internal governance and audit expectations.

From an operational standpoint, teams often underestimate the reporting burden when the ITS requires structured output rather than narrative attachments. One approach some institutions take is to use a dedicated DORA compliance platform to manage the register as a live dataset and then export in the required format. Dorapp, for example, provides DORApp ROI (Register of Information) and DORA report export, with operational guidance available via the DORApp Help Center. You can also review the available modules at DORApp Modules.

Keep your register aligned with incident response, too. When you have an ICT disruption at a provider, you should be able to quickly identify affected services, users, and critical functions. That linkage supports faster classification and reporting decisions under DORA Articles 17 to 23. For incident reporting context, see incident report.

Frequently Asked Questions

Is the DORA register the same as an outsourcing register under EBA guidelines?

They overlap, but they are not identical. Many institutions will reuse outsourcing register concepts, but the DORA register of information is defined by DORA and its ITS, with a specific structured data model intended for supervisory collection and analysis. Depending on your sector and National Competent Authority expectations, you may need to reconcile fields and definitions across frameworks. Treat the DORA register as the authoritative dataset for DORA reporting and third-party ICT oversight, then map to other registers where needed.

What is the difference between a contract record and an ICT service record?

A contract record captures the legal arrangement, parties, duration, and key terms. An ICT service record captures what you actually consume operationally, including scope, ownership, dependencies, and use by business functions. One contract can cover multiple ICT services, and one ICT service can be delivered under multiple contractual documents, for example a master agreement plus statements of work. A register that collapses these concepts usually becomes ambiguous during audits, especially when service criticality and exit planning differ by service.

Do we need to include intragroup ICT arrangements in the register?

In many cases, yes. DORA’s third-party risk management requirements and the register of information are not limited to external providers if intragroup arrangements create ICT dependency that affects operational resilience. The practical requirement is to capture the arrangement in a way that allows governance, monitoring, and exit feasibility to be assessed. Your ability to enforce terms differs in intragroup settings, but supervisors may still expect you to identify dependencies and manage them with appropriate group governance.

How detailed does the subcontractor and supply chain data need to be?

Detail should be risk-based, but defensible. Where subcontractors materially support the ICT service, affect data processing, or create concentration risk, you should typically record them and your governance over them. You may not always have complete transparency, particularly in complex cloud chains, but you should be able to show that your contracts and oversight processes seek sufficient information and that you track known, material chain elements. If information is unavailable, document how you assessed and mitigated the residual risk.

What are the most common data quality failures supervisors flag?

Supervisors and internal auditors often focus on internal consistency and traceability. Common failures include: vague service descriptions, missing mapping to critical or important functions, unclear contracting party versus service delivery entity, incomplete location data, and outdated contract lifecycle dates. Another frequent issue is that the register cannot be reconciled to procurement and IT asset realities. That mismatch can undermine confidence in your third-party risk management controls under DORA Article 28.

How does the DORA register connect to incident reporting?

When an ICT-related disruption occurs at a provider, you need to quickly determine which ICT services are impacted, which business functions depend on them, and whether customer-facing operations are affected. A well-structured register supports that impact analysis and helps you classify events and prepare reports within DORA’s timelines for major ICT-related incidents. Your incident management process and register should reference the same service and provider identifiers, so you can produce consistent evidence across pillars.

Do we have to use a specific DORA register template?

DORA requires alignment to the ITS structure and technical submission requirements, which effectively drives a template even if you implement it in a database rather than a spreadsheet. Many institutions start with an Excel-based approach, but they often struggle with relationships and validation. Use a template that mirrors the ITS tables and enforce validation rules early. For a practical starting point and common structuring choices, see dora roi template, then confirm expectations with your National Competent Authority.

Who should own the DORA register inside the institution?

Ownership varies, but effective models usually assign accountability to a second line function, such as Operational Risk or Compliance, with clear data stewardship in Procurement and IT. The key is to define change triggers and approvals so the register remains current as contracts and services evolve. You should also ensure board and senior management oversight is supported through reporting that highlights material dependencies, critical services, and emerging concentration risks, consistent with DORA governance expectations.

How should we prepare for a supervisory request related to the register?

Prepare for requests that test traceability and decision logic, not just completeness. You should be able to show: how you identified ICT services supporting critical or important functions, how risk assessments drove contractual requirements and monitoring, and how you manage subcontractors. Perform internal sampling before submission, and reconcile to procurement systems and technical inventories. Where data is incomplete, document remediation plans and interim controls. Review foundational context in dora regulation explained if you need to re-anchor on the legal intent.

Is there an official DORA certification for the register or for our institution?

No official DORA certification scheme is established by Regulation (EU) 2022/2554 for financial entities or for a “certified” register. In practice, supervisors and auditors will look for evidence that your ICT third-party risk management controls and register of information meet DORA requirements and the ITS format. You can use recognized assurance reports and certifications from providers as inputs to your oversight, but they do not replace your accountability under DORA.

Does the register need to cover ICT assets, or only third-party arrangements?

The register of information is focused on ICT third-party arrangements and the ICT services you receive from ICT third-party service providers. You do not typically list every internal ICT asset in the register. That said, you often need enough service and dependency detail to link third-party services to business functions, data processing locations, and operational dependencies. Many institutions maintain a separate internal configuration or asset inventory and map it to register service records where that improves traceability.

How should the register reflect DORA Article 30 contract requirements?

The register is not the contract, but it should allow you to evidence that the contract includes key resilience-relevant terms required under DORA Article 30, especially for arrangements supporting critical or important functions. In practice, that means capturing structured indicators or references that show whether audit and access rights, subcontracting conditions, incident cooperation, and termination and exit provisions are present, and where compensating measures exist if standard terms could not be obtained. The exact mapping may vary by institution and contractual model, and should be reviewed with qualified counsel.

How does the register help with concentration risk and exit planning?

Under DORA Article 28, you are expected to manage ICT third-party risk, which typically includes understanding concentration risk and planning for exit where dependencies are material. A well-built register supports this by making it possible to aggregate dependencies by provider group, by service type, by business function, and by geography. The same dataset can support exit planning discussions by clarifying which critical services depend on a provider, what the contractual notice periods are, and which subcontractors or locations could constrain portability.

Key Takeaways

The dora register is structured supervisory evidence, not a generic vendor list. Traceability across entities, services, contracts, and supply chain is the point.

Contract data must connect legal terms to operational risk, especially subcontracting, audit rights, locations, termination, and exit feasibility under DORA Article 30.

Service descriptions need operational precision, including owners, dependencies, and mapping to critical or important functions.

Supply chain fields require a risk-based approach, but you must be able to justify what you capture and how you mitigate unknowns.

A sustainable operating model depends on governance, change triggers, and validation, otherwise reporting becomes repeated remediation work.

Conclusion

Building a defensible DORA register is a data governance project as much as a regulatory one. You are translating real operational dependencies into a structured dataset that can support supervisory reporting and day-to-day third-party oversight. That requires clarity on service definitions, disciplined mapping to critical functions, and consistent treatment of providers and supply chains.

If your institution treats the register as a once-a-year spreadsheet exercise, you will likely spend most of your effort reconciling contradictions rather than improving resilience. A living register, maintained through clear ownership and change triggers, can reduce operational friction and speed up decisions across contracting, monitoring, and incident response.

If you want to see how a DORA-focused platform approaches register maintenance and reporting export, you can explore Dorapp at dorapp.eu and consult the resources in the Help Center. Your goal should be sustainable compliance maturity, where the register becomes an input to resilience decisions rather than an output of remediation.

This article is provided for informational and educational purposes only and does not constitute legal advice. DORA applies to EU-regulated financial entities as defined under Regulation EU 2022/2554. DORA compliance obligations vary depending on the nature, scale, and risk profile of each financial entity. Always consult qualified legal counsel and your relevant National Competent Authority regarding your specific obligations. DORA interpretation and supervisory expectations may evolve as the European Supervisory Authorities (EBA, ESMA, EIOPA) and the Joint Committee publish additional guidance; this content reflects information available at the time of writing and should be verified against current ESA publications.