The DORA Register of Information (RoI) data model looks straightforward when you read the templates. The fields are labelled, the structure is visible, and most of the data already exists somewhere.
The RoI is designed to function as a connected supervisory dataset, which means the value of the register depends on how well records link across tables — a point that becomes clearer when looking at how the RoI is structured and used in practice. Here, the focus is narrower: how the data model creates those links, and why they fail.
In the RoI, “connected” has a very specific meaning. Records are only usable when the same identifiers are reused consistently across templates. If those values drift, the register may still load, but it stops functioning as a joined dataset.
Linking logic: reused identifiers across RoI tables
Most teams build the tables first and only later realise what holds them together. The model works because the same values are reused consistently across tables.
| Data element | Where it appears | What it connects |
|---|---|---|
| Provider identifier | Provider, contracts, services, supply chain | Connects all records to the same provider |
| Contract reference | Contracts, services | Connects services to the correct contract |
| Function identifier | Services, functions | Connects services to business activities |
| ICT service type | Service records | Keeps service classification aligned |
| Entity identifier | Across multiple tables | Connects records to the reporting entity using the service |
If one of these values changes, even slightly, the join breaks. The data is still there, but the structure no longer holds. In supervisory reporting terms, this is a referential integrity failure — the equivalent of a foreign key pointing to a value that no longer exists.
Copla Registry
Keep RoI identifiers consistent
Small inconsistencies in identifiers can break the links across RoI tables. Copla Registry enforces structured identifier management to preserve referential integrity.
- Maintain consistent identifiers across all RoI tables
- Preserve referential integrity between linked records
- Ensure reliable joins for reporting and validation
Where traceability breaks: one contract across the register
A provider is recorded once with a provider identifier. A contract uses that same identifier and adds a contract reference. That contract is then linked to:
- a function
- a type of ICT service
- any subcontractors involved
Each of those sits in a different table.
If the provider identifier in the contract table does not exactly match the provider table, the contract cannot be traced back. If the service type or function identifier differs, the service no longer links to what it supports. If subcontractors use different identifiers, the supply chain cannot be followed.
This becomes especially clear in subcontracting chains, where each provider has to stay aligned across multiple layers.
A join failure here is effectively a foreign key failure: one table references a value that the related table does not recognise.
The patterns that break RoI joins in practice:
- Same provider recorded with different formats (case, spacing, leading zeros)
- Contract reference reused without the field that makes it unique
- Function identifiers created separately in different tables
- Service rows duplicated for multiple entities without repeating all required fields
- Subcontractors keyed differently at each tier
- “Renamed” vendors treated as new providers
These are small inconsistencies. They are also enough to break the dataset.
Composite keys: when a single field doesn’t identify the record
Some records look unique but are not.
A contract reference might appear valid on its own. In practice, it often only becomes unique when combined with another field, such as an entity or a service classification.
The dataset depends on combinations of fields to identify records, not just single values.
A concrete example appears in supply-chain reporting, where rows are effectively organised around combinations such as contractual arrangement reference and type of ICT service, as described in Commission Implementing Regulation (EU) 2024/2956.
If those combinations are duplicated or not applied consistently, the dataset cannot distinguish or reconnect the records correctly.
Handle RoI relationships correctly
The RoI relies on combinations of fields to uniquely identify and link records. Copla Registry supports structured relationships and composite keys across the dataset.
One value per field means more rows
The structure enforces a simple rule: one value per field. Where more than one value applies, additional rows are required.
A single service used by three entities becomes three rows, each repeating the same service details but linking to a different entity.
| Service ID | Entity | Other service details |
|---|---|---|
| Service X | Entity A | (same details repeated) |
| Service X | Entity B | (same details repeated) |
| Service X | Entity C | (same details repeated) |
This is how one-to-many relationships are represented.
This is also where spreadsheet-based approaches start to strain. Each additional row must carry the same identifiers used elsewhere, and small inconsistencies quickly multiply across tables.
Operational control: preventing identifier drift across tables
In practice, most issues come from identifier drift, not missing data. The same provider, contract, or service is entered slightly differently across tables or over time.
Common causes are easy to recognise:
- formatting differences (spaces, case, leading zeros)
- multiple source systems generating their own identifiers
- contract amendments creating new reference patterns
- providers renamed without maintaining the original identifier
- subcontractor tiers re-keying upstream providers
Each of these looks minor in isolation. Together, they break the structure.
Once that happens, the dataset still loads, but it no longer behaves like a connected supervisory record.
