DORA Register of Information Readiness: Requirements, Templates, and Deadlines

Under DORA, financial entities must maintain and update a register of information covering all contractual arrangements for ICT services provided by ICT third-party service providers. The register must follow the standard template structure set by Commission Implementing Regulation (EU) 2024/2956 and be available for supervisory reporting under Article 28(3).

The difficult part is not creating a vendor spreadsheet. It is connecting contracts, providers, ICT services, functions, subcontractors, locations, identifiers, and criticality in a structure that stays consistent when the same relationship appears across several templates.

There is also no single recurring EU-wide "DORA register deadline" for every financial entity. DORA requires ongoing maintenance, at least annual reporting of specified information, and delivery of the full register or requested sections when the competent authority asks for them. The reporting calendar for the financial entity comes through the relevant competent authority.

DORA register of information at a glance

The register has a narrow legal purpose but a wide data footprint. This summary separates the core requirement from the reporting mechanics.

What is the DORA register of information?

The DORA register of information is the structured record financial entities must keep of their contractual arrangements for ICT services supplied by ICT third-party providers. Article 28(3) makes it part of the ICT third-party risk framework rather than a procurement-only record.

That difference matters. A normal vendor register may tell you the supplier name, contract owner, renewal date, and annual spend. The DORA register needs to connect the arrangement to the ICT service, the financial entity using it, the function it supports, provider identifiers, locations, subcontracting chains, and additional information where critical or important functions are involved.

You can check the legal baseline in Article 28 of Regulation (EU) 2022/2554. It is useful when deciding whether a data point belongs to the DORA register at all or to a separate internal vendor-management record.

The register also has two audiences. Internally, it gives the financial entity a structured view of ICT dependencies. Externally, competent authorities and the European Supervisory Authorities use register data for supervision and for the EU process that identifies critical ICT third-party service providers.

Who must maintain a DORA register of information?

Article 28(3) places the register obligation on financial entities within DORA's scope. This page does not repeat the full DORA scope test, but the practical starting point is simple: if the organization is a DORA financial entity, the register is part of its ICT third-party risk obligations.

Groups have an extra layer. Where applicable, the register must also be maintained at sub-consolidated and consolidated levels, and the Implementing Regulation requires group-level information to remain consistent with the entity-level data underneath it.

That makes ownership important. Procurement may own contracts, IT may know the service, security may understand access and dependencies, finance may know costs, and a group function may own legal-entity data. The register only works when those sources can be joined without inventing values during reporting week.

What must the DORA register of information contain?

Commission Implementing Regulation (EU) 2024/2956 turns the Article 28 requirement into 15 linked template tables. It is easier to understand them as data domains rather than as a wall of B-codes.

The important word is linked. A contract reference used in one table has to reconcile with the provider, service, function, and entity data referenced elsewhere. That is why a flat vendor spreadsheet can look complete and still fail the register requirement operationally.

How do the official DORA register templates work?

The legal template structure comes from Commission Implementing Regulation (EU) 2024/2956. The templates use predefined fields, closed lists, identifiers, and relationships between tables so the same provider, function, contract, or entity can be referenced consistently across the register.

The complete field definitions and fill-in instructions are in the official 2024/2956 Implementing Regulation. Use it when a field name sounds familiar but the exact reporting meaning is unclear.

A few details cause disproportionate trouble in practice:

• Contractual arrangement reference numbers need to stay unique and consistent over time.
• Legal entity identifiers and other provider codes need to match the accepted identification rules.
• The same ICT service can support several functions, which creates repeated rows and cross-template relationships.
• Subcontractors that effectively underpin services supporting critical or important functions need to appear in the supply-chain data.
• Locations, service types, licensed activities, and other closed-list fields have to use the permitted values rather than internal shorthand.

This is where "template" becomes a slightly misleading word. The register is not one worksheet to fill in from top to bottom. It is a connected data model with referential integrity between tables.

If you need to see where Regulation 2024/2956 sits among the other Level 2 rules, our DORA RTS and ITS technical standards list maps the adopted standards to their DORA requirements.

What is the DORA register of information deadline?

There are three different timing questions, and mixing them creates bad advice.

So if someone tells you "the DORA register is due every 30 April," ask which authority and which reporting cycle they mean. The EU regulation does not create that recurring date for every financial entity.

The EBA keeps the current reporting package, validation rules, FAQs, and sample material together on its DORA register reporting preparation page. Check that page when preparing an actual submission because the technical reporting package can change even when the legal obligation does not.

Do you need a specific tool for the DORA register of information?

No specific software product is mandated for maintaining the register. The ESAs have stated that financial entities may choose the internal solution that best fits their ICT and third-party risk management needs.

That could be a GRC platform, a vendor-risk system, a database, or another controlled data source. The important point is whether the system can preserve the required fields, identifiers, relationships, ownership, history, and export/reporting quality.

Reporting is a separate technical problem. The EBA publishes the data model, taxonomy, validation rules, filing rules, sample packages, and other materials used for supervisory reporting. In other words, "we maintain the register in Excel" and "the submission package is an Excel file" are not the same statement.

The EBA reporting FAQ explains this distinction directly: financial entities are free to choose how they keep the register, while the ESA technical specifications apply to reporting through the competent authorities.

Where do DORA register data-quality problems usually appear?

The 2024 ESA dry run is a useful warning because the problems were not theoretical. Of the 947 submissions that passed the initial integration stage and were screened for data quality, only 6.5% passed all 116 data-quality checks.

The ESA dry-run summary is useful for setting expectations: a register can contain a lot of data and still fail because the relationships, identifiers, or permitted values do not reconcile.

For most teams, readiness problems cluster around a few practical areas:

• Missing or inconsistent LEIs, EUIDs, provider identifiers, or other keys.
• Contract references that change between systems or are not unique across the group.
• Internal service names that do not map cleanly to the allowed ICT-service categories.
• Critical or important functions that are defined differently by business, risk, and IT teams.
• Subcontractor information that is incomplete because the contract owner never collected it.
• Data locations, governing-law fields, dates, or closed-list values stored in free text.
• A register that is assembled once for reporting but has no trigger to update when contracts, providers, services, or functions change.

The fix is not more spreadsheet formatting. It is assigning stable data owners and mapping each register field to a source that can be updated without a manual investigation every time the authority asks for the register.

What does a DORA register of information example look like?

A simplified example helps show the relationship between fields without pretending that one row replaces the official templates.

Imagine a financial entity uses a cloud hosting provider for a customer-facing payment application. The same relationship appears in several parts of the register:

The important point is that these are not seven independent notes. They have to reconcile. If the provider identifier changes in one place, the relationship can break elsewhere. If the function identifier is missing, contract and service data cannot be joined cleanly to the business dependency.

How should teams prepare the register before reporting week?

A good readiness process starts before anyone exports a file. The aim is to make the register maintainable, not merely submittable once.

Five operating decisions make the biggest difference:

• Name the owner of each data domain. Contracts, provider identifiers, service classifications, functions, subcontractors, and locations rarely come from one team.
• Map every required field to a source system or controlled record. If the source is "ask someone," that is a readiness gap.
• Define update triggers. New contracts, renewals, provider changes, new subcontractors, service changes, criticality changes, and group restructures should update the register.
• Run referential and closed-list checks before the reporting window. Waiting for the authority's validation feedback is an expensive way to discover broken keys.
• Rehearse the reporting package separately from day-to-day maintenance. The register can be correct internally and still fail technical submission checks.

How does the register connect to DORA ICT third-party risk management?

The register is one piece of the third-party risk framework, not the framework itself. It tells the organization and its supervisor which ICT relationships exist and how they connect to services and functions. It does not decide whether a provider is acceptable, whether concentration risk is tolerable, or whether an exit plan is workable.

You will find those decisions in our DORA ICT Third-Party Risk Management guide, which covers due diligence, contractual requirements, concentration risk, subcontracting, monitoring, and exit planning. The register supports that work by giving the organization a consistent dependency map.

If the same organization is also in the NIS2 scope, our DORA vs. NIS2 guide explains where the two regimes meet and where DORA's sector-specific rules take precedence for equivalent ICT risk-management and incident-reporting requirements.

What should the DORA register tell you before a regulator asks for it?

A technically valid submission is only the minimum. A useful register should also let the organization answer practical questions quickly.

For example, can you identify every ICT provider supporting a critical or important function? Can you see which providers are hard to substitute? Can you trace a provider through subcontractors? Can you identify contracts approaching renewal? Can you explain which legal entity uses the service and where data is processed?

If those questions require separate investigations, the register is probably being treated as a reporting artifact rather than as part of third-party risk management.

The best readiness signal is boring: the data stays current during ordinary operations, so a supervisory request does not start a scavenger hunt across procurement folders, service inventories, and old spreadsheets.

Final thoughts: Keep the register ready between reporting cycles

The DORA register of information is easiest to manage when it behaves like operational data rather than an annual compliance project. Contracts change. Providers restructure. Services move. Functions become critical. Subcontractors appear. The register needs to follow those changes.

If the data is owned, linked, and validated continuously, the reporting step becomes an export and review problem. If the register is rebuilt only when a deadline arrives, every reporting cycle starts with the same detective work.

Frequently asked questions about the DORA register of information

Does DORA require a specific register template?

Yes. Commission Implementing Regulation (EU) 2024/2956 sets the standard template structure. Financial entities can choose how they maintain the data internally, but the required information and reporting structure are standardized.

What is the DORA register of information deadline?

There is no single recurring EU-wide submission date for every financial entity. The register must be maintained and updated, specified information is reported at least yearly, and competent authorities set practical submission dates.

Was 30 April 2025 the DORA register deadline?

Not for every financial entity. The 30 April 2025 date was the ESAs' first collection date for registers transmitted by competent authorities. National or sector supervisors set entity-level submission calendars.

Can the DORA register be maintained in Excel?

DORA does not mandate one maintenance tool. The ESAs allow financial entities to choose their own internal solution. Reporting to authorities follows the ESA technical package and should not be confused with the day-to-day register format.

Does the register include subcontractors?

Yes, where subcontractors effectively underpin ICT services supporting critical or important functions or material parts of those functions, the Implementing Regulation requires relevant supply-chain information.

How many DORA register templates are there?

The standard register structure contains 15 linked template tables covering entities, contracts, providers, service recipients, supply chains, functions, assessments, and terminology.

Is the DORA register the same as a third-party risk register?

No. A third-party risk register records risk decisions and treatments. The DORA register of information is a prescribed record of ICT contractual arrangements and related data used for risk management and supervisory reporting.