The DORA Register of Information Templates: What's Actually in Them, and Where Firms Get Stuck

If you've been handed the job of completing your firm's Register of Information, you've probably already found the preparation workbook: a single Excel file made up of fifteen linked templates, most of them referencing each other in ways that aren't obvious until you're three tabs deep. This isn't a light data-entry task. It's a structural exercise in mapping every contractual ICT service arrangement your firm relies on, in a format designed for a regulator's database, not for a spreadsheet.

Here's what's actually in the templates, how they connect, and where firms consistently lose time.

What the register is, and where it comes from

The Register of Information is required under Article 28(3) of DORA. In-scope financial entities must maintain and update a register of contractual arrangements for the use of ICT services provided by ICT third-party providers, and submit the required data to their competent authority under the applicable reporting process. Competent authorities then transmit the collected data to the ESAs (EBA, ESMA, EIOPA) under the ESA/NCA process, who use it to support the designation and oversight of Critical ICT Third-Party Providers and to monitor concentration risk across the sector.

The submission structure isn't a matter of local preference. It's fixed by the Implementing Technical Standard, Commission Implementing Regulation (EU) 2024/2956, supplemented in practice by the ESAs' RoI FAQ and DORA Q&As, which together define the exact templates, fields and machine-readable format every firm has to use. It also sets the identifier rules, and it's worth being precise about them: financial entities themselves must be identified by a valid Legal Entity Identifier (LEI), specifically. ICT third-party providers that are legal persons should be identified by LEI or European Unique Identifier (EUID), by both where available, or by a permitted alternative identifier for relevant third-country providers under ESA/NCA guidance. Identifier quality is a common source of friction in practice. Validate your own LEI and check each provider's identifiers early, rather than at the point of submission. Some identifier issues have been treated as non-blocking warnings in earlier reporting cycles, but NCAs and the EBA are clearly pushing firms toward clean, valid identifiers across the board, so it's not worth treating this as optional.

The fifteen templates, in plain terms

The official templates range from B_01.01 to B_99.01 (you may also see them described as RT.01.01–RT.99.01 in some third-party preparation workbooks, but the regulatory text, validation rules and NCA guidance all use the B_ prefix). They fall into eight groups:

• B_01, entity and scope: who's reporting, which group entities and branches are covered, and how they relate to each other.
• B_02, contractual arrangements: the relational hub of the register. Every ICT arrangement gets a unique reference number here, alongside core metadata: dates, notice periods, annual spend, and intra-group contract links where relevant. That reference number is then reused as the key linking the arrangement across several other templates, including signatories, service users, supply chain and assessment. Get a contract reference wrong or inconsistent here and you'll see orphaned rows and validation failures in templates that otherwise look unrelated.
• B_03, signatory entities: the legal entities that actually signed each contract, whether receiving or providing the ICT service.
• B_04, entities using ICT services: the entities within your firm or group that use the service day to day. This isn't always the same entity that signed the contract, and the register wants both.
• B_05, ICT third-party providers and supply chain: master data on your direct providers, plus the rank-by-rank subcontracting chain sitting behind each one.
• B_06, functions: the business functions your ICT services support, and whether each is classified as critical or important. This classification determines which fields become mandatory elsewhere in the register, so it's worth getting right early rather than reworking it later.
• B_07, assessments: substitutability, exit strategy documentation, and discontinuation impact for services supporting critical or important functions.
• B_99, entity definitions: the internal translation key for your register. This is where your firm maps its own qualitative scales, such as internal risk ratings or criticality criteria, to the regulator's closed-list values elsewhere in the register. It's easy to treat as a throwaway reference tab, but mismatched definitions here create real interpretation problems downstream.

The same template structure applies at individual, sub-consolidated or consolidated level, depending on how your entity or group is required to report.

The submission cycle

Reporting is annual, built around a fixed reference date, typically 31 December of the prior year. National authorities open their submission windows in the following quarter and transmit the collected data to the ESAs shortly after. Exact dates and channels are set by each NCA individually. For example, the Central Bank of Ireland's 2026 cycle uses a 31 December 2025 reporting date, with its portal open from 2 to 31 March 2026.

Worth being precise about one thing: the ESAs don't prescribe how you keep your register day to day. You're free to maintain it however suits your ICT and third-party risk management. What they do prescribe is the submission package, and that's an XBRL OIM-CSV reporting package prepared in accordance with EBA DPM 4.0 (often referred to in NCA guidance as plain-CSV), not an ordinary spreadsheet export. The annotated Excel workbook the ESAs and most NCAs publish is a collation and preparation aid, useful for gathering and structuring your data before conversion, but it isn't itself a submission-ready file, and the ESAs have been clear they don't provide an official conversion tool.

It's also worth knowing that passing technical validation isn't necessarily the end of it. For the 2026 cycle, the EBA ran an additional data-quality review in April, after submission windows closed, checking whether the content of submitted registers actually made sense, not just whether the file structure was valid. Examples the Central Bank flagged include invalid placeholder values for a provider's ultimate parent identifier, and generic entries like "not applicable" used in place of an actual provider name. Passing upload validation doesn't guarantee the underlying data holds up.

Always confirm your own NCA's exact reference date, window and submission channel. Don't assume last year's timing, or last year's format, carries over unchanged.

Where firms actually get stuck

Sub-outsourcing chains with real gaps. Because the ESAs use register data to analyse ICT third-party concentration risk, gaps in major provider and subcontractor data are more likely to attract attention over time. That said, the obligation isn't to map an infinite chain of every vendor's vendor. Under the DORA subcontracting RTS (Commission Delegated Regulation (EU) 2025/532), the focus is on subcontractors that effectively underpin services supporting a critical or important function. The failure mode runs both ways: firms that capture nothing behind the direct provider, and firms that burn time mapping non-material subcontractors the register was never asking for.

Criticality classifications applied inconsistently. Whether a function is critical or important (recorded in B_06.01) drives whether the B_07.01 assessment fields even apply. Get this classification wrong early and you'll be reworking multiple templates later.

Contract and provider data going stale between reporting cycles. The register reflects a point-in-time snapshot, but the underlying contracts, renewals, and provider changes happen continuously throughout the year. Most firms rebuild the register from scratch each cycle because nothing tracks these changes as they happen.

Financial and legal fields that live outside compliance's reach. Contract values, renewal dates and legal entity details usually sit with procurement or legal, and chasing that data down is often the slowest part of the process, not the regulatory logic itself.

Why this keeps being an annual scramble

The root problem isn't the templates. It's that most firms have no single place where ICT vendor relationships, contract data, and criticality assessments live together and stay current. The register gets assembled once a year from spreadsheets, contract folders and email threads, which is exactly why sub-outsourcing gaps and stale data show up every cycle.

DORA compliance remains the financial entity's responsibility throughout. Keeping the underlying data current is what makes the annual submission a formality rather than a scramble.

FAQ

Q: How many templates are in the DORA Register of Information?

A: Fifteen, across eight groups: entity and scope (B_01), contractual arrangements (B_02), signatory entities (B_03), entities using ICT services (B_04), providers and supply chain (B_05), functions (B_06), assessments (B_07), and entity definitions (B_99).

Q: What's the legal basis for the Register of Information?

A: DORA Article 28(3) requires the register itself; its structure, fields and identifier rules are set by the Implementing Technical Standard, Commission Implementing Regulation (EU) 2024/2956.

Q: Do I need to report every ICT provider, or only critical ones?

A: Every contractual arrangement for the use of ICT services provided by an ICT third-party provider should be recorded, regardless of criticality. Criticality determines which additional assessment fields apply and how far down the sub-outsourcing chain you need to map, not whether a provider appears in the register at all.

Q: What format does the final submission need to be in?

A: An XBRL OIM-CSV reporting package prepared in accordance with EBA DPM 4.0, submitted as a zip file, regardless of how you maintain the register day to day. The Excel workbooks published by the ESAs and most NCAs are preparation tools for collating your data, not submission-ready files in themselves.

Q: Does the register need to be resubmitted every year?

A: Yes, firms should expect an annual reporting cycle, with the reference date, submission window and channel set by the relevant competent authority.

Note for UK-only readers: DORA is EU law, and the Register of Information obligation applies to EU-regulated financial entities. A UK-only firm isn't automatically in scope unless it has relevant EU-regulated entities or operations. For UK-only firms, the closest equivalents are the operational resilience and outsourcing/third-party governance expectations under the PRA and FCA frameworks, which raise many of the same vendor and subcontracting data challenges without the DORA RoI submission itself.