DORA Register of Information – A Practical Guide for Financial Entities

ByOfficer

Last updated: March 2026

Your compliance team has a list of ICT providers. Your procurement team has a different list. Your IT department has a third list that includes vendors nobody told compliance about. You now have until 31 March 2026 to reconcile all three into a single, structured, template-compliant DORA Register of Information and submit it to the CSSF. As of 16 March 2026, only 40% of financial entities required to submit had done so.

The DORA Register of Information is not a reporting obligation you can treat like a checkbox exercise. It is the foundation of your ICT third-party risk management under the Digital Operational Resilience Act (Regulation (EU) 2022/2554). Get it wrong and you fail on two fronts: your own risk management is incomplete, and your competent authority has a gap in the data it needs for ICT oversight. Get it right and you have a living inventory that actually helps you manage concentration risk, subcontractor chains, and critical function dependencies.

This guide covers the legal basis, who needs to report, the template structure, the data points that trip people up, and the practical steps to get your register submitted correctly.

Related reading: COREP Reporting Explained | EMIR Reporting Explained

Legal Basis and Purpose

Article 28(3) of Regulation (EU) 2022/2554 (DORA) requires financial entities to maintain and update, at entity level, at sub-consolidated level, and at consolidated level, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers.

The register serves three purposes, and understanding all three matters for how you populate it:

  • ICT risk management: The register is part of your ICT risk management framework under Article 28(1) of DORA. It gives you a structured view of your ICT dependencies, helping you identify concentration risks, single points of failure, and critical function reliance on specific providers.
  • Supervisory oversight: Financial entities must make the register available to their competent authority. The CSSF, ECB, or relevant national authority uses this data to understand the ICT dependency landscape across the entities it supervises.
  • Oversight Framework input: The ESAs use aggregated register data to support the Oversight Framework for critical ICT third-party service providers (CTPPs) under Article 32 of DORA. Your register feeds into the identification and oversight of providers that pose systemic risks to the financial sector.

Article 28(9) mandates the ESAs to develop implementing technical standards (ITS) establishing the standard templates. The ESAs delivered these through their joint Final Report (JC 2023/85), and the resulting Commission Implementing Regulation specifies the exact templates, data fields, and fill-in instructions.

Who Needs to Maintain the Register

DORA applies to a broad range of financial entities. In Luxembourg, Circular CSSF 25/882 on ICT third-party arrangements specifies the scope of entities subject to DORA obligations, including the register of information. The following entity types are in scope (excluding microenterprises as defined in Article 3(60) of DORA):

  • Credit institutions, investment firms, market operators, APAs, and ARMs
  • Payment institutions, account information service providers, and electronic money institutions
  • Crypto-asset service providers and issuers of asset-referenced tokens under MiCAR
  • Central securities depositories
  • Central counterparties
  • UCITS management companies and self-managed investment companies
  • Alternative investment fund managers and internally managed AIFs
  • Institutions for occupational retirement provisions (SEPCAVs and ASSEPs)
  • Administrators of critical benchmarks
  • Crowdfunding service providers

The microenterprise exclusion is narrow. DORA defines microenterprises by reference to the EU SME definition: fewer than 10 staff and annual turnover or balance sheet total not exceeding EUR 2 million. Most regulated financial entities in Luxembourg exceed at least one of these thresholds.

One point I find teams miss: the obligation applies to each financial entity individually, not just at group level. If your group has three licensed entities in Luxembourg, each one maintains its own entity-level register. The group also maintains a consolidated register. These are separate obligations, even though the data overlaps.

Template Structure

The ITS establishes a set of interconnected templates that capture your ICT provider landscape from multiple angles. Understanding the structure saves time because you can plan your data collection around the template relationships rather than filling each one independently.

Entity-Level Templates

B_01.01 (Financial Entity) identifies the financial entity maintaining the register. This is your entity’s LEI, name, type, and the competent authority supervising it. One row per register.

B_02.01 (Contractual Arrangements – General Information) lists every contractual arrangement between your entity and its direct ICT third-party service providers. Each arrangement gets a unique contractual arrangement reference number that must remain consistent over time and across all templates. This is the backbone of the register. Every other template references back to the contract reference number assigned here.

B_02.02 (Contractual Arrangements – Specific Information) provides detail for each arrangement listed in B_02.01: the ICT services in scope, the functions supported by those services, notice periods, governing law, and other contractual specifics. This is where you link ICT services to your business functions.

B_03.01 (Entities Signing Contractual Arrangements) identifies the entities that signed each contract for receiving ICT services. B_03.02 (ICT Third-Party Service Providers Signing Contractual Arrangements) identifies the providers that signed for delivering the services. B_03.03 (Entities Providing ICT Services to Other Entities in the Consolidation) identifies entities within the group that provide ICT services to other group entities, capturing intra-group provider relationships. The signing entity is not always the entity using the service, particularly in group structures where a parent or shared services company signs framework agreements on behalf of multiple subsidiaries.

B_04.01 (Entities Making Use of ICT Services) identifies which entities in the group actually use the ICT services provided under each contractual arrangement. In a group structure, the entity signing the contract (in B_03.01) and the entity consuming the service (in B_04.01) are often different. This template closes the loop between who signed and who depends on the service.

B_05.01 (ICT Third-Party Service Providers) lists and identifies all direct ICT providers and their subcontractors using LEI codes, names, countries of registration, and other identification data.

B_05.02 (ICT Service Supply Chains) maps the subcontracting chains. If your direct provider uses a subcontractor for part of the ICT service, and that subcontractor uses another subcontractor, each link in the chain is captured here. This is where concentration risk becomes visible.

B_06.01 (Functions Identification) lists your entity’s functions, particularly flagging which ones are critical or important. This classification drives additional reporting requirements: contractual arrangements supporting critical or important functions require more granular data.

B_07.01 (Assessment of ICT Services) captures the risk assessment for ICT services provided by ICT third-party service providers that support a critical or important function or material parts thereof. This includes whether a risk assessment has been performed, the date, and the assessment outcomes. This is the deepest template in the register and only applies to services linked to critical or important functions.

The template list above covers the principal templates. The complete ITS also includes a reconciliation template that maps your internal terminology to the standardized taxonomies used in the register. If your entity calls something “application hosting” but the ITS taxonomy calls it “S18: Cloud services: PaaS,” this mapping must be recorded.

Consolidated and Sub-Consolidated Templates

For groups, the register must also be maintained at sub-consolidated and consolidated levels. Article 6 of the ITS requires the ultimate parent undertaking to define the scope of consolidation and sub-consolidation. All financial entities and ICT intra-group service providers within the scope must be included.

The consolidated register uses the same template structure but adds B_01.02 (List of Financial Entities within the Scope of Consolidation) and B_01.03 (Identification of Branches of those financial entities). B_02.03 captures the links between intra-group contractual arrangements and external ICT third-party contracts where part of the ICT service supply chain runs through an intra-group provider.

In practice, the consolidated register is the harder exercise. It requires coordination across multiple entities, consistent reference numbering across the group, and reconciliation of different local practices for classifying ICT services and functions.

The 19 ICT Service Types

The ITS defines a closed list of ICT service types. When populating B_02.02 (Contractual Arrangements – Specific Information), you must map each ICT service to one of these 19 categories using the identifier codes S01 through S19:

  • S01: ICT project management
  • S02: ICT development (business analysis, software design, testing)
  • S03: ICT help desk and first-level support
  • S04: ICT security management services (protection, detection, response, recovery)
  • S05: Provision of data (data provider subscriptions)
  • S06: Data analysis
  • S07: ICT facilities and hosting services (excluding cloud)
  • S08: Computation (excluding cloud)
  • S09: Non-cloud data storage
  • S10: Telecom carrier (excluding traditional analogue telephone per Article 3(21) DORA)
  • S11: Network infrastructure
  • S12: Hardware and physical devices (as a service)
  • S13: Software licensing (excluding SaaS)
  • S14: ICT operation management including maintenance
  • S15: ICT consulting
  • S16: ICT risk management (verification of compliance per Article 6(10) DORA)
  • S17: Cloud services: IaaS
  • S18: Cloud services: PaaS
  • S19: Cloud services: SaaS

The cloud distinction between S17, S18, and S19 matters because the regulatory treatment differs. DORA and the CSSF’s Circular 25/882 on ICT third-party arrangements impose specific requirements on cloud outsourcing that do not apply to non-cloud ICT services. Getting the classification right in the register ensures your risk assessment framework aligns with the regulatory expectations for each service type.

Critical or Important Functions: The Data Depth Driver

The register is proportionate by design. For ICT services supporting standard (non-critical) functions, you report the basic contractual and provider information. For ICT services supporting critical or important functions, the ITS requires additional data: risk assessments, subcontractor details, substitutability analysis, and supply chain mapping.

This means the classification of your functions in B_06.01 directly drives the volume and depth of data you need to collect. If you classify too many functions as critical, you create unnecessary reporting burden. If you classify too few, you have a gap in your risk management and your register will look implausible to the competent authority.

In my experience, the “critical or important function” classification is where most entities struggle. DORA does not provide a bright-line test. Article 3(22) defines a critical or important function as a function whose disruption would materially impair the financial entity’s financial performance, the soundness of its services, or its ability to comply with regulatory requirements. That leaves room for judgment.

A practical approach: start with the functions that your Business Continuity Plan (BCP) classifies as mission-critical. These are your candidates for “critical or important” under DORA. Then add any function where the ICT service provider cannot be replaced within a reasonable timeframe without material impact. The overlap between BCP priority and substitutability risk gives you a defensible classification.

Contractual Arrangement Reference Numbers

This is the single most important data governance decision in the register. Every contractual arrangement gets a unique reference number in B_02.01. That number must be:

  • Unique within your entity and across the group (at consolidated level)
  • Consistent over time (the same contract keeps the same reference number across reporting periods)
  • Used consistently across all templates (B_02.02, B_03.01, B_03.02, etc. all reference back to the same number)

The reference number is your internal identifier. It does not need to match the contract number your legal team uses, but it must be traceable back to the actual agreement. I recommend creating a mapping table between your contract management system’s identifiers and the register reference numbers. Losing that linkage makes future updates painful.

The reference number covers three types of arrangements:

  • Standalone agreements
  • Overarching or framework arrangements (master agreements, framework contracts)
  • Subsequent or associated arrangements (implementing agreements, order forms, amendments)

Service level agreements subordinated to one of these contract types do not get their own reference number. They are part of the parent arrangement.

Submission Process and CSSF Deadlines

Current Deadline

The CSSF communique of 17 March 2026 confirmed that the Register of Information must be submitted to the CSSF by 31 March 2026. Third-country branches of credit institutions have an extended deadline of 30 June 2026 on a best-effort basis.

As of 16 March, only 40% of required entities had submitted. The CSSF urged remaining entities to submit as soon as possible to allow time to address any issues before the ESA quality checks in April.

The Two-Stage Quality Check

After submission to the CSSF, the register goes through two stages of validation. The CSSF performs an initial check and may request corrections. The CSSF then forwards the registers to the relevant ESA (EBA for credit institutions and investment firms, ESMA for market operators, EIOPA for insurance entities). The ESA performs additional quality control checks throughout April 2026.

If the ESA detects errors and rejects the register, the CSSF will contact the entity with the required corrections. This creates a back-and-forth cycle that eats into the time available. Submitting early is not just good practice. It is a practical necessity to absorb any rejection-resubmission rounds.

Submission Channel

Submission is through the CSSF’s eDesk digital portal. The register must be submitted in the format specified by the ITS (structured data, not PDF). Entities should verify their data against the validation rules in the ITS before submitting to minimize the risk of automatic rejections.

Common Errors and How to Avoid Them

Inconsistent Reference Numbers

The most frequent error is using different reference numbers for the same contractual arrangement across templates. B_02.01 assigns the number. B_02.02, B_03.01, and every other template must use the exact same alphanumeric string. A typo or a formatting inconsistency (leading zeros, dashes vs. no dashes) breaks the cross-referencing and will be flagged by automated validation.

Missing Subcontractor Chains

Many entities report their direct ICT providers but fail to capture the subcontracting chain in B_05.02. If your cloud provider (say, AWS) uses a subcontractor for a specific component of the service, that relationship needs to be recorded. The information may not be easy to obtain from your provider, but DORA places the obligation on the financial entity to maintain this data.

In practice, your provider contracts should include a clause requiring the provider to disclose subcontractor relationships. If existing contracts do not have this clause, you have a contract remediation task on top of the register exercise.

Misclassifying ICT Service Types

The 19 service types are mutually exclusive for each service line. A managed hosting service that includes application support is not one service. It is S07 (hosting, excluding cloud) and S14 (ICT operation management) if it is on-premises, or S17/S18/S19 if it is cloud-based. Splitting bundled services into their correct categories is tedious but necessary. If in doubt, the ITS instructions provide descriptions for each category.

Over-Classifying Critical Functions

Marking every function as “critical or important” triggers the full data requirement for every associated ICT service. This creates a volume of reporting that is difficult to maintain and may not reflect your actual risk profile. Be deliberate about the classification. Your competent authority will compare the number of critical functions you declare against your entity’s size and complexity. An entity with 50 critical functions and 12 staff will raise questions.

Forgetting Intra-Group ICT Services

Groups that have an ICT shared services entity (an “ICT intra-group service provider” in DORA terms) must capture those arrangements in the register. These are not external third-party relationships, but they are in scope. Template B_02.03 at the consolidated level captures intra-group ICT service arrangements separately from external contracts.

Using LEI Codes Incorrectly

Provider identification in B_05.01 requires LEI codes where available. Not all ICT providers have an LEI, particularly smaller local providers. When an LEI is not available, the ITS provides alternative identification options. But when an LEI exists, using a different identifier instead will be flagged. Check the GLEIF database before submitting.

Ongoing Maintenance Obligations

The register is not a one-time submission. Article 28(3) requires financial entities to maintain and update the register on an ongoing basis. Every new ICT service contract, every provider change, every subcontractor modification, and every critical function reclassification triggers an update.

In practice, this means integrating the register into your contract lifecycle management process. When procurement signs a new ICT service agreement, the register update should be part of the onboarding workflow. When a contract is terminated, the register reflects the removal. When a provider notifies you of a subcontractor change, the supply chain template gets updated.

I recommend assigning a register owner at the entity level, typically within the ICT risk management function or the compliance team. Without clear ownership, the register drifts out of date within months. The first submission is the hardest. Keeping it current is where the operational discipline lives.

How the Register Feeds the CTPP Oversight Framework

Beyond your own risk management and supervisory reporting, the register data feeds into the ESA Oversight Framework for Critical ICT Third-Party Service Providers (CTPPs). The ESAs aggregate register data across the financial sector to identify providers on which a significant number of financial entities depend.

Providers designated as CTPPs are subject to direct ESA oversight, including inspections and recommendations. The designation criteria include the systemic importance of the financial entities relying on the provider, the degree of substitutability, and the number of member states in which the provider’s clients operate.

Your register contribution matters because it directly informs these assessments. If your entity depends on a provider that is a CTPP (or a candidate for designation), the quality and completeness of your register data affects the ESA’s ability to oversee that provider effectively.

In January 2026, the ESAs and UK financial regulators signed a Memorandum of Understanding on oversight of CTPPs under DORA, reflecting the cross-border nature of major cloud and ICT providers. This cooperation framework depends on the quality of register data from financial entities across the EU.

EBA ICT Risk Report: Supervisory Context

The EBA published its follow-up report on ICT risk assessment under the SREP in early 2026. The report found that competent authorities have made progress in strengthening ICT risk assessment, driven largely by DORA implementation. The register of information is a key input to the SREP’s ICT risk assessment, providing supervisors with structured data on each entity’s ICT dependencies.

This means the register is not just a compliance exercise. It feeds directly into how your supervisor assesses your ICT risk profile during the annual SREP cycle. A complete and accurate register supports a favourable SREP outcome. An incomplete or inaccurate register raises red flags about your ICT risk management maturity.

Frequently Asked Questions

Does the register cover all ICT services, even small ones?

Yes. Article 28(3) refers to “all contractual arrangements on the use of ICT services provided by ICT third-party service providers.” There is no materiality threshold in the Level 1 text. However, traditional analogue telephone services are explicitly excluded from the definition of ICT services under Article 3(21) of DORA. The proportionality is built into the template design: non-critical ICT services require less granular data than services supporting critical or important functions.

Do microenterprises need to maintain the register?

No. DORA provides a simplified ICT risk management framework for microenterprises under Article 16. The register of information obligation under Article 28(3) applies to financial entities other than microenterprises. However, microenterprises must still maintain basic documentation of their ICT service arrangements as part of their simplified framework.

What if my ICT provider does not have an LEI?

The ITS provides alternative identification mechanisms when an LEI is not available. You may use national registration numbers or other identifiers. However, where an LEI exists, you must use it. Check the GLEIF database (gleif.org) for your providers before defaulting to alternative identifiers.

How often do we need to update the register?

DORA requires ongoing maintenance. There is no fixed reporting frequency like quarterly COREP. You update the register when circumstances change: new contracts, terminated contracts, provider changes, subcontractor modifications, critical function reclassifications. Practically, many entities implement a quarterly review cycle to catch any changes that may have been missed in real time.

Do intra-group ICT services need to be in the register?

Yes, at the consolidated level. Intra-group ICT service arrangements are captured in template B_02.03. At the entity level, the entity receiving the intra-group ICT service reports the arrangement in the standard entity-level templates, treating the intra-group provider as it would any ICT third-party service provider.

What is the penalty for not submitting by the deadline?

DORA does not specify a fixed penalty schedule for late submission. The competent authority has supervisory powers to address non-compliance, which may include supervisory measures, enhanced monitoring, or administrative sanctions depending on the jurisdiction and the entity type. In Luxembourg, the CSSF has a range of enforcement tools. The more practical risk is the data quality issue: late submission means your register misses the ESA quality control cycle in April 2026, which could result in repeated correction requests.

Can we submit a partial register and complete it later?

The CSSF expects a complete register at the time of submission. Submitting a deliberately incomplete register to meet the deadline is not the intended approach. If your register is genuinely incomplete because certain provider or subcontractor data is unavailable, document the gaps and the remediation plan. A register with documented gaps is better than a register with fabricated data.

Practical Implementation Checklist

  • Inventory all ICT service contracts across legal, procurement, and IT departments
  • Assign unique contractual arrangement reference numbers in a mapping table
  • Classify all functions as critical/important or standard using BCP priority and substitutability criteria
  • Map each ICT service to one of the 19 service type categories (S01-S19)
  • Collect provider LEI codes from the GLEIF database
  • Request subcontractor chain information from all providers supporting critical functions
  • Populate entity-level templates (B_01.01 through B_07.01)
  • If part of a group: coordinate with the ultimate parent on consolidated-level templates
  • Validate data against ITS validation rules before submission
  • Submit via CSSF eDesk portal before 31 March 2026
  • Assign a register owner for ongoing maintenance
  • Integrate register updates into the contract lifecycle management process

Related Articles

Key Takeaways

  • The DORA Register of Information under Article 28(3) requires all in-scope financial entities to maintain a structured inventory of every ICT third-party service arrangement at entity, sub-consolidated, and consolidated levels
  • The ITS templates (B_01.01 through B_07.01) are interconnected: the contractual arrangement reference number in B_02.01 is the backbone linking all other templates
  • ICT services supporting critical or important functions require additional data (risk assessments, supply chains, subcontractor details) compared to standard services
  • The CSSF deadline for submission is 31 March 2026, with ESA quality control checks throughout April 2026. Only 40% of entities had submitted as of 16 March
  • The 19 ICT service type categories (S01-S19) are a closed list. Map each service correctly, splitting bundled services into their component types
  • Subcontractor chains must be captured in B_05.02 even if the information is difficult to obtain from providers
  • The register is not a one-time exercise: ongoing maintenance is required as contracts, providers, and function classifications change
  • Register data feeds the ESA CTPP Oversight Framework, meaning your submission quality affects the supervisory response to systemic ICT providers

Sources and References

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts