DORA Register of Information: 15 Official Templates Explained

I want to be honest with you about something upfront: there is no single document from the EBA, ESMA, or EIOPA that tells you everything you need to know about the DORA Register of Information in one place. The requirements are spread across the main DORA regulation text, the Joint Technical Standards, the ITS on registers of information, the xBRL taxonomy documentation, NCA-specific portal guidance, and a series of Q&As that the ESAs have published in response to industry questions - some of which clarify things that the original texts left genuinely ambiguous.

This guide is the document I wish had existed when compliance teams started working on their first submissions. It pulls everything together: what the Register of Information actually is, who has to submit it, what data goes into each of its 15 official templates, how the templates relate to each other, what the submission process looks like from start to finish, and what year-round maintenance looks like once your first submission is behind you.

By the time you finish reading this, you'll have a complete mental model of the RoI - not just enough to fill in a template, but enough to understand why each field exists, what the regulator is trying to see, and where the traps are for teams who are working through this for the first time.

What Is the DORA Register of Information?

The Register of Information (RoI) is one of the central operational requirements of the Digital Operational Resilience Act. It is defined under Article 28(3) of DORA, with detailed technical specifications set out in the Implementing Technical Standards (ITS) on registers of information published jointly by the EBA, ESMA, and EIOPA.

At its core, the RoI is a comprehensive, structured record of every ICT third-party service provider your organisation relies on - and a precise mapping of what those providers do, which contracts govern the relationship, and which of your internal business functions depend on their services. Regulators use this data for two primary purposes: to understand the concentration of risk across the financial system (if one cloud provider fails, which institutions are affected and how severely?), and to assess individual institutions' operational resilience and third-party risk governance.

What it is not is equally important to understand. The RoI is not:

• A vendor risk register - it doesn't capture risk scores, risk ratings, or risk mitigation measures for each provider. That's a separate DORA obligation.
• A contract management system - it captures specific structured data fields about contracts, but it's not a document repository for the contracts themselves.
• A compliance control framework - it doesn't track whether you've implemented the required ICT security controls. That's your ICT risk management framework under Articles 5-15.
• A one-time audit artifact - it's a live register that must be maintained continuously and updated within defined timeframes whenever something material changes.

Who Must Submit - and at What Level?

Article 28(3) of DORA requires all financial entities within scope of the regulation to maintain and submit a Register of Information. The full list of in-scope entities is defined in Article 2(1) and includes:

Micro-enterprises - defined under EU law as entities with fewer than 10 employees and annual turnover under €2 million - benefit from proportionality provisions across DORA. How proportionality applies to the Register of Information depends on your entity type, so check the ESAs' proportionality guidance and your NCA's instructions for your specific case before deciding what you need to submit.

Individual, sub-consolidated, and consolidated submissions

For financial groups, the ITS specifies three possible submission levels. Understanding which applies to your structure is essential before you start building your register - because the answer determines the scope of data you need to collect and how entities within the group relate to each other in the data model.

Groups may need to produce all three levels simultaneously - individual submissions from each entity, sub-consolidated submissions from sub-group parents, and a consolidated submission from the ultimate EU parent. Each submission must be a coherent, self-consistent data package that passes validation independently.

The Data Model: 15 Templates Explained

The RoI data model is the heart of the requirement and the part that most guides and templates explain least well. Understanding it properly - not just what each template contains, but how the templates relate to each other - is what separates teams who build the register correctly the first time from teams who spend months in a resubmission loop.

The backbone of the data model is the set of contractual arrangements you hold with ICT third-party service providers. Each arrangement carries a unique reference number, and that reference number is the key that ties the other templates together. Around that backbone you record who signed each arrangement, which of your entities use the services, the providers behind the services and their supply chains, the functions the services support, and the assessments you have made for services that support critical or important functions.

The register is built from 15 official templates set out in Commission Implementing Regulation (EU) 2024/2956. Their codes run from B_01.01 to B_99.01, and they are organised into groups keyed by the number after B_: 01 (entity and scope), 02 (contractual arrangements), 03 (signatories), 04 (entities using services), 05 (providers and supply chain), 06 (functions), 07 (assessments) and 99 (definitions).

How the templates connect

The reference number on each contractual arrangement (B_02.01) is the primary key that holds the register together. The specific information for that arrangement (B_02.02) hangs off the same reference number, as do the signatory records (B_03.01 for your side, B_03.02 for the provider side, and B_03.03 for intra-group providers) and the record of which entities use the services (B_04.01). Each service is delivered by a provider identified in B_05.01, and the chain of subcontractors behind it is set out in B_05.02. The functions your organisation runs are catalogued in B_06.01, and the assessments for services supporting critical or important functions sit in B_07.01. B_01.01 identifies the entity maintaining the register, B_01.02 and B_01.03 describe the group scope and branches, and B_99.01 holds the definitions you rely on.

Every reference in this chain must resolve. A single broken link - an arrangement in B_02.02 whose reference number has no match in B_02.01, or an assessment in B_07.01 pointing at a provider that is absent from B_05.01 - fails the whole submission at the validation stage.

Key Concepts: Criticality, Sub-Outsourcing, and Functions

Three concepts in the RoI data model deserve extra attention because they're the ones teams get wrong most often - and because getting them wrong affects not just your submission but your underlying compliance posture.

Critical or important functions (CIFs)

The concept of "critical or important functions" under DORA is defined in Article 3(22) and links directly to the EBA's guidelines on outsourcing. A function is critical or important when its disruption would materially impair the financial performance of the entity, or the soundness or continuity of its services or activities.

In practice, this means your organisation must make and document a formal assessment of each business function against these criteria. The RoI records the outcome of those assessments in the functions template (B_06.01). Common mistakes include: applying the criticality label too narrowly (underestimating which functions qualify, thereby understating your ICT dependency), applying it too broadly (over-classifying functions, creating unnecessary reporting scope), or failing to document the assessment methodology behind each classification - which regulators will ask for.

Sub-outsourcing chains

Article 28(2) requires financial entities to identify and document sub-outsourcing arrangements - situations where your direct ICT provider sub-contracts part of the service to another party. The supply-chain template (B_05.02) captures this, recording the subcontracting rank behind each service. In practice, it means you need to know not just who your providers are, but who their providers are, at least for arrangements supporting critical or important functions.

This is one of the most under-populated parts of first RoI submissions, for an obvious reason: gathering sub-outsourcing data requires your direct providers to disclose information about their supply chains that they may be reluctant to share. Your leverage here is contractual: Article 30(2)(a) requires the arrangement to state whether subcontracting of an ICT service supporting a critical or important function is permitted and, if so, the conditions that apply, and Commission Delegated Regulation (EU) 2025/532 sets out what those conditions must cover. Article 30(2)(h), sometimes cited for this, is about termination rights and notice periods, not supply-chain disclosure. Exercising the right still takes time and sometimes produces disputes. Starting this data collection exercise early - ideally 6 months before your first submission - is strongly advisable.

The provider-contract-service-function chain

The most important structural concept in the RoI is that every ICT arrangement must be traceable from provider all the way to internal function. This is not just a data model requirement - it reflects the regulator's actual analytical goal: to understand, for any given business function, exactly which external parties you depend on and through what contractual relationships. If that chain is broken anywhere in your data, the register fails its purpose even if it passes technical validation.

The Submission Process

Format

The RoI must be submitted in xBRL-CSV format - a structured, machine-readable format defined by the XBRL International standard and profiled for DORA by the ESAs. Your submission is a ZIP archive containing one CSV file for each table in the data model. Each CSV must conform to the XBRL taxonomy that the ESAs publish and update. The taxonomy defines field names, data types, controlled value lists, and the relationship constraints between tables.

There is no provision for submitting in Excel format, PDF, or any other format. NCA portals only accept the xBRL-CSV ZIP. This is one of the most impactful practical requirements of DORA - it means that organisations maintaining their register in Excel must go through a conversion and validation process that introduces significant risk of error at the export stage.

Timing and deadlines

The annual submission deadline varies by NCA. Most NCAs have set deadlines in the first quarter of each calendar year, with the reference date being 31 December of the prior year - meaning your register must reflect the state of your ICT arrangements as of 31 December. Check your specific NCA's technical guidance for the exact filing deadline applicable to your entity type and jurisdiction.

The key operational implication: you cannot start building the register in January for a March deadline if your data collection processes aren't already in motion. The sub-outsourcing data alone can take months to gather. Organisations that treat the RoI as a year-end exercise consistently find themselves either submitting incomplete data or requesting extensions.

The NCA portal

Each EU member state's NCA operates its own submission portal. The portal requires registration, and submissions are made by authorised users whose identity is tied to the reporting entity. When you submit, the portal runs its validation sequence - package check, taxonomy conformance, referential integrity, controlled values, and business rules - and returns either a receipt confirmation or a feedback file containing error codes for each failure.

Year-Round Maintenance Obligations

This is the aspect of the RoI that surprises compliance teams most - particularly those who are used to compliance being primarily a point-in-time activity tied to audit cycles. The RoI is not something you build once a year and then archive. It is a living register with continuous maintenance obligations.

Article 28(3) requires financial entities to notify their NCA when material changes occur to ICT arrangements. The ITS specifies timeframes for updating the register following material changes - and "material" is defined more broadly than many compliance teams initially assume. The following events all require register updates:

The practical implication is that the RoI needs to be owned by someone - or some function - that is plugged into the contract lifecycle management and procurement processes of the organisation year-round. A compliance team that only touches the register once a year will consistently find that it no longer reflects reality by the time submission comes around, and that catching up in the weeks before the deadline is frantic, error-prone, and often incomplete.

Common First-Time Mistakes

Teams building their first Register of Information consistently encounter the same set of structural errors. Here are the most consequential ones, and how to avoid them.

Tools and Approaches

There are three broad approaches organisations take to building and maintaining the Register of Information. Each has a different risk profile, and the right choice depends on the size and complexity of your register.

The case for a purpose-built platform becomes compelling quickly once you move beyond a small, simple register. The specific features that matter most for the RoI are: enforced referential integrity between tables, automated GLEIF LEI validation, hard constraints on controlled value fields, xBRL-CSV export that runs the current EBA validation rules before packaging, and audit trail management for updates made throughout the year. These aren't nice-to-haves - they're the capabilities that distinguish a register built for submission from a register that looks complete until the NCA portal tells you otherwise.

Frequently Asked Questions