DORA Register of Information
How a MiCA-authorized CASP builds and maintains the DORA Register of Information under Article 28: the 15-template data model from Commission Implementing Regulation (EU) 2024/2956, mandatory LEI/EUID identifiers, the criticality classification that drives subcontractor depth and risk assessment, common register-build mistakes and the xBRL-CSV submission pipeline.
13 min read
22 views
Key takeaways: DORA Register of Information 5
What Article 28 actually requires, how the 15-template ITS model fits together and what an engineering team should automate first.
- The register is a standing artifact, not an annual filing Article 28 of DORA requires both a continuously maintained register available to the competent authority on request and a separate at-least-yearly summary report. Treating the whole obligation as one annual filing undercounts the standing half.
- 15 templates in 8 groups, not 8 templates Commission Implementing Regulation (EU) 2024/2956 defines 15 templates, B_01.01 to B_99.01, organized across 8 functional groups. Eight describes the groups, not the template count.
- LEI/EUID and six data quality principles are engineering constraints Article 3 of the ITS makes LEI or EUID identification mandatory for legal-person ICT providers and sets six data quality principles the register must satisfy as referential integrity requirements across all 15 templates, not just field-level formatting.
- Criticality flags in B_06.01 and B_07.01 drive everything downstream The criticality or importance flag on each function determines subcontractor identification depth, required risk assessments and feeds the ESAs' critical ICT third-party provider designation and DORA Threat-Led Penetration Testing scoping.
- Automate the register as one model with 15 generated views Treating the 15 templates as views over one relational model, rather than 15 parallel spreadsheets, lets criticality flags cascade automatically and keeps the xBRL-CSV export aligned with reporting technical package numbering corrections such as EBA Q&A 2025_7313.
A MiCA-authorized Crypto-Asset Service Provider carries two separate regulatory identities at once. As a CASP it answers to Regulation (EU) 2023/1114. As a financial entity operating critical infrastructure, it also falls under Regulation (EU) 2022/2554, the Digital Operational Resilience Act (DORA), the same way a bank or an investment firm does. Article 28 of DORA is where that second identity turns into concrete engineering work: every in-scope financial entity, CASPs included, must maintain a Register of Information (RoI) documenting its contractual arrangements with ICT third-party service providers. The RoI is not a narrative compliance memo a legal team drafts once a year. Commission Implementing Regulation (EU) 2024/2956 defines it as a structured data model of 15 templates, with mandatory identifiers, cross-references and data quality rules that nobody fills in by hand at scale. This article works through the model a CASP's engineering team actually has to build and keep current.
In short: the DORA Register of Information is a standing inventory of ICT third-party contractual arrangements, required under Article 28 of DORA (Regulation (EU) 2022/2554) for every in-scope financial entity, including MiCA-authorized CASPs. Commission Implementing Regulation (EU) 2024/2956 sets 15 mandatory templates, B_01.01 to B_99.01, organized across 8 functional groups covering entities, contracts, signatories, providers, functions and assessments. Every ICT third-party provider that is a legal person needs a valid LEI, or an EUID where a LEI is not available, and the register as a whole must satisfy six data quality principles: accuracy, completeness, consistency, integrity, uniformity and validity. The register itself is maintained continuously and made available to the competent authority on request, a separate obligation from the at-least-yearly summary report Article 28 also requires. The first live collection cycle used a 31 March 2025 reference date, reported by competent authorities to the ESAs by 30 April 2025, submitted as an xBRL-CSV package rather than a free-form spreadsheet.
What the DORA Register of Information is
Article 28 of DORA requires financial entities to maintain and update, at entity level and at sub-consolidated and consolidated levels, a register covering every contractual arrangement for ICT services provided by an ICT third-party service provider. The register has to document those arrangements in a way that distinguishes ICT services supporting critical or important functions from ICT services that do not, and that criticality split is the classification axis the rest of the data model builds around. Beyond the register itself, financial entities report to their competent authority at least yearly a summary covering the number of new arrangements, the categories of ICT providers involved, the type of contractual arrangement and the services and functions each arrangement provides. On top of that summary, the full register or any specified section of it has to be available to the competent authority on request, along with any other information the authority needs for effective supervision. Two obligations sit inside one article: a continuously maintained register, and a periodic summary drawn from it. Treating the whole thing as "an annual filing" undercounts the standing-artifact half of the requirement.
The table below maps the legal sources a register build has to track, since the ITS and EBA Q&A layers carry different binding weight than the DORA article itself.
| Provision | What it requires | Binding |
|---|---|---|
| Art 28(3) para 1 | Maintain and update a register of all ICT third-party contractual arrangements at entity, sub-consolidated and consolidated levels | Yes |
| Art 28(3) para 2 | Document arrangements distinguishing those supporting critical or important functions from those that do not | Yes |
| Art 28(3) para 3 | Report at least yearly the number of new arrangements, provider categories, contract types and services/functions provided | Yes |
| Art 28(3) para 4 | Make the full register, or specified sections, available to the competent authority on request | Yes |
| CIR (EU) 2024/2956, Art 3 | LEI or EUID identification for ICT providers and in-scope subcontractors, plus six data quality principles | Yes |
| EBA Q&A 2025_7313 | Corrects the B_06.01 Official Journal column numbering; use reporting technical package v4.0 numbering instead | No, guidance |
The 15-template data model
Commission Implementing Regulation (EU) 2024/2956 sets the Implementing Technical Standards for the register, and it defines exactly 15 templates, not eight. Eight is the number of functional groups the templates fall into, a distinction worth stating plainly because the two numbers get swapped in secondary summaries. Every template carries a `B_XX.YY` identifier, and the reporting technical package treats them as one relational model rather than 15 independent spreadsheets: a contractual arrangement recorded in B_02.01 has to reference the same entity identifiers used in B_01.01, the same provider identifiers used in B_05.01 and the same function identifiers used in B_06.01.
| Code | Official title | What it captures |
|---|---|---|
| B_01.01 | Entity maintaining the register | The financial entity responsible for maintaining the register |
| B_01.02 | List of entities within the scope of consolidation | All group entities within the register's scope |
| B_01.03 | List of branches | Branches of entities located outside their home country |
| B_02.01 | Contractual arrangements, general information | Master list of all ICT third-party contractual arrangements |
| B_02.02 | Contractual arrangements, specific information | Services, functions and detailed contractual terms |
| B_02.03 | Intra-group contractual arrangements | Links intra-group arrangements to related external provider contracts |
| B_03.01 | Entities signing contractual arrangements | Financial entities that are signatories to ICT contracts |
| B_03.02 | ICT third-party service providers signing contracts | ICT providers that are signatories |
| B_03.03 | Financial entities providing ICT services | Intra-group financial entities acting as ICT providers |
| B_04.01 | Entities making use of the ICT services | Financial entities using the ICT services under each arrangement |
| B_05.01 | ICT third-party service providers | Full identification and detail of ICT providers, including LEI/EUID and HQ country |
| B_05.02 | ICT service supply chains | Subcontracting hierarchy and supply chain mapping |
| B_06.01 | Functions identification | Function taxonomy, criticality assessment, RTO, RPO, impact of discontinuing |
| B_07.01 | Assessments of ICT services supporting critical or important functions | Risk and performance assessment of critical or important ICT services |
| B_99.01 | Entity definitions | Entity-provided terminology and closed-list value definitions |
Read as a pipeline, the 8 groups run entity information (B_01.x) into contractual arrangements (B_02.x), signatories (B_03.x), service usage (B_04.01), the ICT providers themselves (B_05.x), the functions those providers support (B_06.01), the assessments those functions require (B_07.01) and closed-list definitions (B_99.01). A register that gets this right is one relational dataset with 15 views, not 15 unrelated forms.
Identifiers and data quality as engineering constraints
The ITS's Article 3 requires a financial entity to identify every ICT third-party service provider that is a legal person using a valid and active Legal Entity Identifier, or a European Unique Identifier where a LEI is not available, and both where they exist. The only exception is an individual acting in a business capacity. That is a hard mandatory field, not a nice-to-have column: B_05.01 does not validate without it, and a provider record without a working LEI or EUID is the single most common way a register fails a data quality check before it reaches the ESAs.
The identifier requirement extends one layer down the supply chain, but only where it matters for oversight. Subcontractors that effectively underpin ICT services supporting critical or important functions need the same LEI/EUID treatment inside B_05.02. Subcontractors sitting under non-critical services do not need to be enumerated to that depth; the obligation tracks the criticality flag, not the full length of every subcontracting chain a provider happens to run.
Article 3 also sets six data quality principles the register must satisfy as a whole: accuracy, completeness, consistency, integrity, uniformity and validity. In engineering terms these are referential integrity constraints, not abstract compliance language. Uniformity and consistency mean the same entity identifier resolves to the same B_01.01 row everywhere it is referenced across the other 14 templates. Integrity means a contractual arrangement in B_02.01 cannot point to a provider that does not exist in B_05.01, or a function that does not exist in B_06.01. A register built as 15 disconnected spreadsheets structurally cannot hold these properties; a register built as one normalized data model with the 15 templates as generated views can enforce them at write time.
Criticality is the register's central axis
Every other classification in the register hangs off one flag: whether an ICT service supports a critical or important function. B_06.01 carries the function-level assessment fields, including the criticality or importance assessment itself, the reasons behind that assessment, the date of the last review, recovery time objective, recovery point objective and the impact of discontinuing the function. B_07.01 then layers a risk and performance assessment on top of every ICT service that supports a function flagged critical or important in B_06.01.
One numbering detail matters if an engineering team is building B_06.01 field-by-field from the Official Journal text: EBA Q&A 2025_7313 confirmed that the Official Journal version of the template-specific instructions omitted column code B_06.01.0050, which shifted the numbering of every field after it. The safe reference is the reporting technical package v4.0, which uses corrected consecutive numbering, not the OJ column codes as originally published. Field titles such as "Criticality or importance assessment", "Recovery time objective" and "Impact of discontinuing" are stable regardless of which numbering scheme labels them; only the column codes moved.
The criticality flag is not only a register field. It is the input the ESAs use to designate critical ICT third-party service providers for direct oversight, and it carries downstream consequences well outside the register itself. The register's criticality flags and the B_07.01 assessments of ICT services supporting critical or important functions identify which ICT third-party providers underpin a CASP's critical functions, and that inventory is what scopes DORA Threat-Led Penetration Testing (TLPT).
Common register-build mistakes
The most frequent category error is treating the DORA Register of Information as a rebrand of the GDPR Article 30 Record of Processing Activities. The two are different artifacts serving different regulators for different purposes: the RoPA documents personal-data processing, the RoI documents ICT third-party contractual arrangements for operational-resilience supervision. A register that reuses RoPA fields or RoPA ownership as a shortcut will fail on structure before it fails on content.
A second recurring error is citing eight templates instead of 15, because eight is genuinely the number of functional groups the templates sit in. Both numbers are correct for what they describe; only one of them describes the template count the ITS actually defines.
A third error runs the other way on scope: reading the microenterprise proportionality language in DORA as an exemption from the register itself. Microenterprises get reduced obligations elsewhere in DORA, for example they are not required to adopt a dedicated ICT third-party risk strategy under Article 28(2), but nothing in Article 28(3) removes the register requirement for a smaller entity. The obligation is reduced in places, not removed.
A fourth error sits inside B_05.02: assuming every subcontractor in a provider's chain needs full LEI-level identification. The requirement tracks the criticality flag from B_06.01. Subcontractors underpinning critical or important functions need that depth of identification; the rest of the chain does not have to be enumerated to the same standard.
A fifth error is building B_06.01 straight from the Official Journal column codes without checking EBA Q&A 2025_7313 first, which reproduces the missing-column-0050 numbering bug into an internal data model that then has to be remapped before submission.
A sixth error is treating the submission as a spreadsheet export problem late in the build. The register is reported as an xBRL-CSV package following the ESAs' data point model and taxonomy, a table-oriented format with its own validation rules, not a hand-built Excel file with columns matching the template titles. Getting the internal data model right does not automatically produce a valid xBRL-CSV file; the export layer is its own piece of engineering.
None of this is speculation about what specifically goes wrong inside any given register. The ESAs ran a voluntary Dry Run exercise in 2024, ahead of the 2025 live cycle, with close to 1,000 financial entities participating. Registers were checked against 116 data quality checks, and only 6.5% passed every check cleanly; of the registers that did not pass cleanly, half failed fewer than 5 of the 116 checks. Individual feedback went back to entities confidentially through their competent authorities, so no public list of specific field-level errors exists to cite. The verified lesson is quantitative, not anecdotal: most registers were close, not far off, and the gap between "close" and "clean" tends to sit in exactly the areas above: identifier validity, cross-template referential integrity and criticality-flag completeness.
Submission timeline, cadence and format
Keep the 2024 exercise and the 2025 obligation on separate timelines. DORA applies from 17 January 2025, so the first live reporting cycle sits in 2025, not 2024. The 2024 Dry Run was explicitly preparatory and voluntary, run to let the industry test its registers against the 116 data quality checks before anything counted. The first live cycle used 31 March 2025 as the reference date for register content, with competent authorities reporting the collected registers up to the ESAs by 30 April 2025; financial entities themselves submitted to their national competent authority on dates the NCA set individually ahead of that. Confusing the two, or citing 2024 Dry Run participation as satisfying a 2025 live obligation, is a category error a supervisor will not accept.
On format, the submission to authorities is an xBRL-CSV file, a table-oriented reporting format aligned to the ESAs' data point model, not a free-form spreadsheet or PDF export. A CASP can maintain its internal source of truth in any data store it chooses; the report leaving the building has to conform to the taxonomy the ESAs define for that reporting cycle.
Automating the register as a single source of truth
The engineering shape that survives repeated reporting cycles treats the 15 templates as generated views over one internal model, not as 15 things a compliance analyst maintains by hand in parallel. Contracts, providers, functions and assessments live once, with foreign-key relationships enforcing the same referential integrity the six Art 3 data quality principles require. The criticality flag on a function record cascades automatically into which B_05.02 subcontractor rows need LEI/EUID depth and which B_07.01 assessment rows are required, instead of a person deciding case by case which providers "probably count".
Two outputs come off that one model on two different clocks: the standing register, queryable and exportable in full whenever a competent authority asks under Article 28(3), and the periodic xBRL-CSV submission that follows the ESAs' reporting calendar. Automating the export layer against the reporting technical package's field numbering, rather than the Official Journal text directly, avoids rebuilding the B_06.01 mapping every time a numbering correction like Q&A 2025_7313 gets published. A CASP that already runs the MiCA compliance software development discipline for its authorization evidence is building the same kind of structured, auditable data model here, just pointed at ICT third-party arrangements instead of custody or market-conduct records.
How Pharos Production helps
We build the DORA Register of Information as a relational data model with the 15 ITS templates as generated views, not as 15 spreadsheets maintained in parallel: LEI/EUID validation and cross-template referential integrity enforced at write time, criticality flags cascading automatically from B_06.01 into the B_05.02 and B_07.01 rows that depend on them and an xBRL-CSV export pipeline built against the reporting technical package's corrected field numbering rather than the Official Journal text alone. If your platform is a MiCA-authorized CASP that also needs to stand up or harden its DORA register build, we can walk through what that data model looks like for your architecture.
See our MiCA compliance software development services.
Sources: Regulation (EU) 2022/2554 (DORA), Article 28, application date confirmed via Article 64. Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024, Article 3 and the 15-template Annex, alongside EBA Q&A 2025_7313 (single rulebook Q&A, B_06.01 column-numbering correction) and the EBA Dry Run 2024 results press release (116 data quality checks, close to 1,000 participating entities, 6.5% clean pass rate). Reporting-cadence guidance covers the 2025 register collection (31 March 2025 reference date, 30 April 2025 CA-to-ESA reporting deadline).
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 6
No matches
Try a different keyword, change the topic or clear filters
-
Article 28 of DORA (Regulation (EU) 2022/2554) requires every in-scope financial entity, including MiCA-authorized CASPs, to maintain a register documenting all contractual arrangements with ICT third-party service providers, distinguishing arrangements that support critical or important functions from those that do not.
-
15 templates, B_01.01 to B_99.01, set by Commission Implementing Regulation (EU) 2024/2956. They span 8 functional groups covering entity information, contractual arrangements, signatories, service usage, ICT providers, functions and assessments.
-
The register is maintained continuously and made available to the competent authority on request. Separately, at least yearly, the CASP reports a summary to its competent authority.
For the 2025 cycle the reference date was 31 March 2025, with competent authorities reporting collected registers to the ESAs by 30 April 2025, submitted as an xBRL-CSV package.
-
Yes. Microenterprises get reduced obligations elsewhere in DORA, such as not needing a dedicated ICT third-party risk strategy under Article 28(2), but Article 28(3) does not exempt any in-scope financial entity from maintaining the register itself.
-
B_06.01 carries the criticality or importance assessment at function level, along with recovery time objective, recovery point objective and the impact of discontinuing the function. B_07.01 layers a risk and performance assessment on top of every service flagged critical or important.
That flag also feeds the ESAs' designation of critical ICT third-party providers and scopes DORA Threat-Led Penetration Testing.
-
Missing or invalid LEI/EUID identifiers on provider records, broken cross-references between templates such as a contract pointing to a provider or function that does not exist elsewhere in the model and incomplete criticality flags. Building the register as one relational model with the 15 templates as generated views, rather than 15 parallel spreadsheets, enforces the six Article 3 data quality principles (accuracy, completeness, consistency, integrity, uniformity, validity) at write time instead of catching them at submission.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
