The DORA Register of Information is a Data Problem, Not a Compliance Problem

Have you considered that the Register of Information (RoI) is not primarily a reporting exercise, but a structured data model?

It describes one interconnected system of critical functions, ICT third-party providers, and dependencies between them. The reporting templates are just a way of representing that model.

Those templates serve an important purpose. They are designed to allow financial entities of any size, from the smallest FinTech to large banking groups and insurance undertakings, to describe their ICT supply chains in detail. That flexibility is intentional, but it also means the framework is complex by default.

The problem is not that the templates are complex. The problem is that they do not enforce the rules of the structure they represent.

Relationships, uniqueness constraints, and dependencies are described in documentation rather than built into the format itself. As a result, many issues remain invisible while data is being collected. They only surface later, when the RoI is submitted and validated as a whole.

This is why RoI delivery often feels fragile, unpredictable, and difficult to explain internally. What looks like a reporting challenge is, in reality, a data model problem.

A familiar pattern

For a long time, information systems were built around documented rules rather than enforced ones, which meant that errors were only detected later, during reviews or audits.

Modern systems enforce structure upfront. If a required relationship does not exist, the system blocks the entry. If an identifier must be unique, duplicates are not allowed. The rules are enforced, not merely described.

The RoI follows the older pattern.

While the EBA has clearly defined the underlying structure based on entities, identifiers, relationships, and conditions, the reporting templates do not enforce it. Inconsistent or incomplete data can exist until submission, when validation is applied across the dataset.

From a compliance perspective, the consequences are predictable. Findings appear late, corrections cascade across templates, and the process feels fragile and hard to control. What often looks like supervisory unpredictability is, in practice, the late enforcement of well-documented rules.

What the EBA actually published

When institutions talk about the RoI, they usually talk about templates. That is understandable, because templates are what teams work with day to day.

But the EBA did not publish a collection of independent forms. It published a structured information model, expressed through reporting templates.

That model becomes visible once you step back from individual sheets. Critical functions are defined once and referenced elsewhere. ICT third-party providers are identified centrally and reused across multiple contexts. Relationships exist between providers, functions, and contracts. Certain records are only valid if others already exist.

In other words, the RoI is built around entities and relationships, not isolated tables.

This also explains the scale of the documentation. The hundreds of pages are not primarily there to explain how to complete templates. They describe the rules of the underlying structure: what elements exist, how they relate to each other, and under which conditions data is considered valid.

Where issues surface

When the structure of the RoI is described but not enforced, data quality issues do not disappear; they are simply deferred.

While data is being collected, most problems remain invisible. Each template can look correct in isolation: mandatory fields are filled in, identifiers appear to exist, and the data feels complete at a local level.

The issues only become visible when the RoI is assessed as a whole.

This typically happens for the first time at submission, when validation rules are applied across templates. Cross-references are checked, dependencies are evaluated, and conditions that span multiple sections are enforced. Only then does it become clear whether the data is internally consistent.

The submission process amplifies this effect as validation happens in stages, first at national level and then again at European level, with additional supervisory logic applied. The same dataset is effectively re-evaluated under different checks, even though the underlying rules have not changed.

From the institution’s perspective, this often feels unpredictable. Issues appear late, corrections cascade across templates, and changes in one place trigger errors elsewhere. The problem is not that the rules are unclear, but that they are enforced only after the data has already been assembled.

Treating the RoI as what it is

In practice, this means starting from the core elements the RoI actually describes: critical functions, ICT third-party providers, and the dependencies between them. Each of these elements is defined once, identified consistently, and referenced wherever it is needed.

Dependencies are made explicit rather than inferred through repetition. A contract cannot reference a provider that does not exist. A provider cannot appear twice under different identifiers. Changes in one place are reflected wherever that element is reused.

This shifts validation earlier in the process. Basic consistency checks no longer happen for the first time at submission, but when data is created or updated. Issues are addressed when they arise, not months later during supervisory review.

Ownership changes as well. Responsibility is no longer tied to individual templates, but to parts of the underlying structure. One function owns the definition of critical functions and business context. Another owns provider and dependency information. Oversight becomes a matter of maintaining shared data, not reconciling disconnected reports.

Importantly, this does not require abandoning existing tools or reporting formats. Templates and reporting systems can still be used to produce submissions. What changes is where the data is managed.

The RoI is no longer maintained in the templates themselves. The templates become outputs, generated from a shared, explicitly structured dataset that acts as the system of record.

Conclusion

Much of the difficulty institutions experience with the Register of Information is framed as a documentation burden or a reporting challenge. In reality, it reflects something more fundamental.

The RoI describes a living structure: critical functions, ICT third-party providers, and the dependencies between them. Treating it as a periodic reporting exercise works only until that structure has to be validated, explained, or changed. At that point, the limitations of a form-based approach become visible.

When the RoI is managed as structured, shared information, the dynamic changes. Updates become incremental instead of disruptive. Inconsistencies are addressed earlier. Submissions become confirmation steps rather than discovery exercises, and supervisory questions can be traced back to concrete data relationships rather than worked through template logic.

This matters because the RoI does not exist in isolation. It feeds into multiple aspects of DORA, from ICT third-party oversight to resilience testing and incident analysis. If the underlying information is fragile, every downstream use inherits that fragility.

Institutions that treat the RoI as a data and governance problem, rather than a compliance deliverable, shift where effort is spent. Less time is lost reconciling templates and correcting late-stage errors. More time is spent maintaining a shared, explainable view of operational dependencies.

Over time, that difference compounds. The RoI stops being something that has to be “delivered” and starts functioning as what it was intended to be: a reliable representation of operational reality.