The first mandatory cycle of DORA Register of Information submissions closed across most EU jurisdictions in March and April 2026, and the early signals from supervisors are blunt. During the 2024 ESA dry run, only around 6.5% of participating firms passed all 116 data quality checks, and roughly 235,000 validation errors were recorded across more than 1,000 institutions. BaFin has confirmed it received over 600 serious ICT incident filings in DORA’s first year of application — a volume that explains why supervisors now treat the Register as the foundation of their third-party risk visibility, not paperwork.
The Register is not an outsourcing log with a new label. It is a relational dataset spanning 15 interconnected templates, around 105 defined data points, and a submission format (xBRL-CSV) that has very little tolerance for spreadsheet improvisation. This guide covers what the Register actually requires under Article 28(3) of DORA and Commission Implementing Regulation (EU) 2024/2956, how to build it without triggering the validation errors that sank most 2024 dry-run submissions, the template structure firms keep getting wrong, and what the 2026 supervisory feedback says about where the bar is moving for the 2027 cycle.
What the Register of Information Actually Is
Article 28(3) of DORA requires every financial entity in scope to maintain a complete register of contractual arrangements with ICT third-party service providers — at entity, sub-consolidated, and consolidated level. The detailed structure, fields, and reporting format come from the Implementing Technical Standards (ITS) finalised in Commission Implementing Regulation (EU) 2024/2956, published in December 2024.
The scope of “ICT third-party service provider” is broader than most procurement teams initially assume. It captures cloud infrastructure, SaaS applications, data centres, telecoms carriers, software vendors, IT consultancies, managed security services, and analytics providers. A web filtering tool, a VPN appliance vendor, a SaaS ticketing system, and a hosted email security gateway are each separate ICT services and each need their own template entries. This is why mid-sized banks routinely discover several hundred contracts during the data-collection phase, even when their procurement system shows fewer than fifty “strategic” vendors.
Three audiences consume the Register data. The financial entity’s management body uses it as an internal third-party risk monitoring tool. The national competent authority (NCA) uses it for entity-level supervision and concentration risk analysis. The European Supervisory Authorities — EBA, EIOPA, and ESMA, acting through the Joint Committee — aggregate the data to designate Critical ICT Third-Party Providers (CTPPs) under Article 31. The first 19 CTPPs were designated in late 2025, and that designation flows directly from Register submissions.
The 15 Templates and How They Connect
The Register’s data model is relational. Identifiers entered in one template act as foreign keys in others. Get the contract reference number wrong in the central template B_02.01 and the error cascades into every dependent template — services, providers, functions, sub-outsourcing chains. This is the single most under-estimated structural feature of the Register and the source of most rejected submissions.
The templates are grouped into eight conceptual blocks: entity identification, contractual arrangements, ICT services, ICT providers, functions, assessments, and supplementary information. The block where firms most consistently struggle is B_05.02 (subcontractor linkages) — the post-March 2026 supervisory feedback flagged it as the most commonly incomplete template across multiple jurisdictions.
B_02.01.0010) is the central foreign key — referenced by B_02.02, B_02.03, B_03.01, B_05.01. Provider LEI in B_05.01 must match B_05.02 subcontractor receiver. Function ID in B_06.01 links every service to a licensed activity.Building the Register From Scratch
The Register cannot be assembled from a single source system in any organisation that didn’t design for it from day one. Procurement holds the contract metadata. Legal holds the executed terms and any data-processing addenda. ICT risk owns the criticality assessment. The business function owners know which licensed activities a system supports. Finance holds the spend data, which is required for several fields. Whichever team is assigned ownership of the Register, the work is overwhelmingly cross-functional.
A workable build sequence runs in five stages. First, define the entity scope — which legal entities in the group are in scope under the parent’s competent authority, and which need a separate filing. The reporting level (.IND for individual or .CON for consolidated) is appended to the LEI in the technical control file and cannot be changed mid-cycle without re-keying. Second, run a discovery sweep across procurement, IT asset management, and accounts payable to surface every contractual arrangement that touches an ICT service. Master service agreements, framework contracts, order forms, statements of work, and subsequent associated arrangements all qualify. The ITS counts these as separate contractual arrangements where the structure makes them distinct. Third, identify each provider with a verified LEI (validated against the Global LEI Foundation database) or an EUID (validated against the Business Register Interconnection System). For providers in third countries without an LEI, populate the field with a relevant alternative identifier — this triggers a data-quality warning but does not cause rejection.
Fourth, map ICT services to the licensed activities of the financial entity in template B_06.01. This is where compliance officers and IT need to sit down together. The compliance team knows which activities are licensed under MiFID II, Solvency II, or the relevant sectoral framework. The IT team knows which production systems support which activity. A wrong code here cascades into the function-criticality assessment. Fifth, run the criticality assessment per arrangement and document the exit strategy state. Both feed into B_07.01 and both are scrutinised closely by NCAs at firms with concentration in a small number of providers — particularly US hyperscalers, which BaFin has explicitly named as a focus area for 2026 supervisory review.
For arrangements supporting critical or important functions, the subcontractor chain in B_05.02 must be documented to a meaningful depth. The current ITS does not prescribe a fixed number of tiers, and after the European Commission rejected the original draft RTS on subcontracting in early 2025, the operative guidance from the ESAs is to capture subcontractors that “effectively underpin” the service — meaning those whose failure would impair the continuity or security of the service. In practice, this means going past the direct cloud provider to the underlying region, the dependent identity provider, and any specialist subprocessors, but stopping short of cataloguing every transitive dependency.
true in lower case.The LEI vs EUID Question
In September 2024 the European Commission rejected the original ESA draft ITS, specifically the requirement that ICT third-party providers be identified by a Legal Entity Identifier in all cases. The Commission required that EU-registered providers be permitted to use either an LEI or a European Unique Identifier — the EUID — which is already attributed free of charge to most EU-registered companies through national business registers and accessible via BRIS (the Business Register Interconnection System on the European e-Justice Portal).
The practical difference matters at scale. An LEI is a 20-character globally unique code maintained through GLEIF, requires annual renewal (typically a paid service through a Local Operating Unit), and includes ownership data useful for systemic risk analysis. The EUID is free, derived from the existing national company registration, and has the form [ISO country code].[national registration number]. The Commission’s view, accepted in the final ITS, is that forcing every small EU software vendor to obtain and maintain a paid LEI imposed an unjustified cost.
The trade-off for financial entities: LEI data is bulk-downloadable from GLEIF for daily reference checks, while EUID lookups are manual on BRIS with no batch API. Firms with hundreds of providers find the LEI route operationally easier even when EUID is permitted. For providers registered outside the EU, only the LEI is usable. If a third-country provider has no LEI, the entity must populate the identifier field with another relevant value — this generates a data quality warning, not a rejection, but is flagged for follow-up.
Submission Format and the Move Off Excel
The technical submission format is xBRL-CSV under the EBA’s Reporting Framework. The submission package is a ZIP file containing CSV files generated against the data point model with eba prefixes on every coded value, plus the JSON metadata files and the META-INF folder. Some NCAs — including DNB in the Netherlands and BaFin in Germany — provided an Excel-to-xBRL conversion path for the first cycle, but they have made clear this is transitional. DNB has stated the expectation for 2026 onwards is direct xBRL-CSV submission, with limited tolerance for Excel-based workarounds.
Firms still working from the EBA Excel template should treat it as a data collection aid only, not a submission format. The structural rules are unforgiving: the order of tabs cannot be changed, hidden columns cannot be deleted, and the TOC tab variables (Period start, Period end, Identifier with the .IND or .CON suffix) drive the conversion. A misplaced row in the template propagates as foreign-key violations across multiple submitted CSV files.
Maintaining the Register Through the Year
Treating the Register as an annual exercise was the second-most-cited cause of submission failure in the 2026 supervisory feedback. The Register is a point-in-time snapshot at the reference date, but the underlying data needs continuous capture: new contracts at signature, criticality reassessments when functions change scope, termination dates recorded immediately, LEI renewals tracked against expiry. Firms that left this to a year-end scramble found themselves chasing legal teams for executed dates, procurement for spend figures, and IT for service descriptions — all in the weeks before the deadline.
The minimum viable maintenance pattern is a single authoritative source of truth for ICT third-party data, with feeds (or at least documented sync points) from procurement, contract management, IT asset management, and risk. Whether that source is a dedicated GRC platform, an extension of an existing third-party risk management tool, or a structured database depends on portfolio size. For an institution with 50 ICT contracts the spreadsheet approach is painful but possible. At 200 contracts with subcontractor chains it is no longer realistic.
A separate operational discipline is monitoring the supervisor feedback loop. Validation feedback from NCAs arrives through portals like AFM Portal in the Netherlands, MyDNB, BaFin’s MVP, the Central Bank of Ireland’s online reporting portal, and CSSF’s e-file in Luxembourg. Feedback files contain triggered business validation rule references and feedbackText entries; the EBA publishes the underlying technical checks and validation rules spreadsheet, which is the document to map errors against before resubmission.
Frequently Asked Questions
Does every contract with an IT vendor need to be in the Register? Yes, if the service falls within DORA’s broad ICT services definition. Cloud, SaaS, telecoms, data centre, hardware, software, IT consulting, and analytics are all in scope. The criticality assessment determines the depth of additional fields (such as subcontractor chains in B_05.02), but every arrangement is registered.
What is the difference between intra-group and external ICT providers in the Register? Both are reported. Intra-group arrangements — for example, a parent providing IT services to a subsidiary — are documented with their own contract references and provider entries. The same template structure applies, and the criticality assessment is performed independently of the corporate relationship.
How deep does the subcontractor chain need to go? Beyond the direct provider, the requirement focuses on subcontractors that effectively underpin the service supporting a critical or important function. The original draft RTS on subcontracting was rejected by the Commission in early 2025; the operative principle until the new RTS lands is materiality, not exhaustiveness. Document subcontractors whose failure would impair continuity or security of the service.
Is the Register the same as the BaFin/CSSF/AFM outsourcing notification? No, and this has been a source of duplicate work. BaFin acknowledged in 2025 that ICT services supporting critical functions also tend to qualify as material outsourcing under existing German MVP outsourcing notification. Until BaFin updates the MVP form to add a DORA-specific checkbox (still pending as of early 2026), firms continue both reporting streams.
What 2026 Has Made Clear
The Register cycle that just closed has shifted supervisor expectations in two directions. First, validation rules are tightening — the ESAs have stated explicitly that 2026 checks are stricter than the 2024 dry run, and a register accepted last year is not guaranteed to pass this year. Second, NCAs are moving from compliance verification to data-driven supervision: BaFin’s stated focus on US hyperscaler concentration, the AFM’s portal-based feedback loop, and the ESAs’ use of aggregated Register data for the 2025 designation of the first 19 CTPPs all point to the same shift.
For institutions building or refining their Register process, the practical implication is that data quality is now a supervisory dimension in its own right. A clean, machine-readable Register that survives validation cleanly says something about the firm’s overall ICT third-party risk maturity — and a Register full of warnings says something else. The firms doing this well in 2026 are the ones who stopped treating the Register as a reporting deliverable and started treating it as a managed dataset with versioning, ownership, and quality controls. The 2027 cycle will reward that approach further.
