Most DORA Register of Information projects look fine in Excel. The register fills up, the templates are completed, and the dataset appears coherent at first glance.
A DORA RoI is a controlled dataset of ICT third-party relationships that only works if identifiers and cross-template links remain consistent as contracts and services change. Excel can collect inputs, but once the workbook circulates, it struggles to maintain a single, defensible state across multiple owners.
The difficulty appears later, when multiple teams begin updating the same register over time. Versions diverge, identifiers drift, and relationships stop aligning.
Workbook circulation breaks control first
The distribution loop that creates parallel truth
Most Excel-led programmes follow the same pattern. A central team distributes templates. Functions populate their sections. Files are returned, merged, adjusted, and redistributed.
Parallel versions appear quickly as each function works on its own copy and applies local updates. There is no single point where all changes are synchronised, and over time the register fragments into several internally consistent but incompatible versions.
Maintain a single RoI dataset
Parallel versions quickly emerge when updates are not controlled centrally. Copla Registry maintains one authoritative dataset with consistent updates across all linked records.
“Current state” becomes a negotiation
Once multiple versions exist, agreeing on what the register actually reflects becomes part of the work. Teams compare files, decide which updates to trust, and merge them into a working version.
The RoI templates are standardised as interlinked reporting structures under Commission Implementing Regulation (EU) 2024/2956, which makes consistency across those versions non-negotiable.
Common Excel failure modes — and the controls that prevent them
This table maps typical Excel failure modes in RoI programmes to the specific controls required to prevent data inconsistency and breakdown.
| Failure mode | What it looks like in Excel | Control that prevents it |
|---|---|---|
| Parallel versions | Same provider or contract appears with different values across files | Single master file with controlled write access |
| Identifier drift | Provider IDs differ across tabs or versions | Locked identifier fields and referential checks |
| Local overrides | Manual fixes applied to “make tabs match” | Controlled update process with validation rules |
| Clause re-interpretation | Same contract produces different field values | Central interpretation layer with evidence reference |
| Supply chain invention | New IDs created to fill missing relationships | Governed identifier model and dependency mapping |
| Late validation rebuild | Errors discovered only at submission stage | Validation embedded during data entry |
Ownership gaps create silent inconsistencies
The next layer of failure sits in how responsibilities are split. Multiple teams contribute to the same dataset, but the boundaries between their inputs are rarely enforced in the workbook itself.
Data domains without boundaries create cross-tab drift
DORA forces multiple functions into the same dataset.
Procurement owns contracts. Legal interprets clauses. Vendor management maintains supplier identifiers. Business units define functions. ICT risk determines criticality. Each team updates its part of the register, and while those updates are correct locally, they conflict across the dataset.
The propagation problem: changes don’t cascade
Changes in one tab do not automatically update dependent records elsewhere.
Illustrative scenario
The local fix that breaks the register
A vendor management team corrects a provider identifier.
The change is applied in the supplier tab.
Contract and supply-chain tabs still reference the old identifier.
Another team manually updates those records.
A third version of the identifier now exists.
Each tab looks correct in isolation.
Across the register, the relationships no longer align.
Clause interpretation creates rework loops
Most institutions underestimate how much of the RoI sits outside structured systems. The pressure comes from translating contract wording into consistent, repeatable data.
In Excel-led processes, those interpretations are captured as static values without a shared layer for reuse. The same clause is reviewed multiple times, often producing slightly different outputs.
Without clear evidence references—such as clause location, contract version, and reviewer—teams cannot rely on prior interpretations. Each inconsistency triggers a new round of analysis.
A typical loop looks like:
- extract the clause
- compare outputs across entries
- re-check the contract
- update the field
- repeat in the next cycle
Without a controlled interpretation layer, teams keep re-deriving the same values, a problem closely tied to mandatory RoI data fields derived from contractual clauses.
RoI supply-chain mapping fails in flat workbooks
The supply-chain requirement introduces a different type of pressure. It forces institutions to represent dependency structures that do not exist in most source systems.
Vendor inventories don’t contain service dependency logic
Most institutions start from vendor inventories.
Those inventories list suppliers but do not describe how services depend on each other.
Teams therefore reconstruct supply chains manually, often applying different assumptions, which leads to inconsistent outputs for the same service.
A common failure appears when different teams map the same service using different dependency assumptions. One version shows a direct provider relationship, another includes subcontractors, and a third applies a different ranking. The template may look complete in each case, but the underlying picture of how the service is delivered no longer matches.
Copla Registry
Model ICT supply chains correctly
ICT supply chains break down when relationships are tracked inconsistently. Copla Registry maps dependencies and subcontractor chains as structured, connected records.
- Map service dependencies across providers and functions
- Track subcontractor chains as linked records
- Maintain a consistent, end-to-end supply chain view
The GDPR processor-mapping trap
DORA requires subcontractors to be recorded based on their role in the ICT service supply chain for ICT services supporting critical or important functions.
Teams that reuse GDPR processor mappings for this field often misidentify providers, because processor lists reflect data-processing roles rather than service dependency structures.
Illustrative scenario
Invented structure to fill gaps
A team identifies a subcontractor used by a cloud provider.There is no structured record of that dependency.
To complete the template, they create a new entry with a locally defined identifier.
The supply chain appears complete in one tab and disconnected in another.
Validation exposes the problem late
By the time validation begins, most of the dataset has already been shaped by multiple edits, versions, and assumptions that were never fully aligned.
Validation does not introduce new issues. It reveals the ones that were already embedded in the register but remained hidden during tab-level work.
Supervisory testing has already shown the pattern: institutions can assemble the register, but many encounter structural consistency issues once validation is applied, as reflected in the supervisory observations from the RoI reporting dry run.
A further practical gap appears at submission. The official reporting format is xBRL-CSV, not Excel, which means the workbook must be transformed into a structured file that passes validation rules before submission. This step often exposes gaps that were not visible while working inside the spreadsheet.
Under challenge, the missing artefact is change history
The pressure increases under review.
Supervisors and internal audit do not just look at values. They focus on how those values were produced and whether the process can be explained consistently.
Without change history, institutions cannot demonstrate how data evolved over time or support the reasoning behind specific entries.
What resilient RoI operating models change
The shift that stabilises RoI programmes is less about tooling and more about how the dataset is governed once it starts evolving.
Controls that stabilise the dataset across owners
Institutions that maintain stable registers tend to introduce a consistent set of controls:
- controlled identifiers reused across all templates
- clear ownership for each data domain
- update triggers linked to contract, supplier, and service changes
- validation embedded during data entry
- traceability of changes and supporting evidence
These reflect a target-state operating model where the register is maintained as a controlled dataset rather than a shared document. For a broader view of how this fits into the overall framework, see how the DORA Register of Information works in practice.
Effective dating: aligning changes over time
Contracts change on one date. Supplier structures change on another. Service mappings evolve separately.
If those timelines are not aligned, the register can reflect a mix of states that never existed at the same time. Maintaining a clear view of when changes take effect helps preserve consistency across related records.
Minimum viable controls when Excel is non-negotiable
Where Excel remains in place, a reduced set of controls can limit the rate of degradation:
- one master file instead of circulated copies
- locked identifier fields
- controlled input ranges
- basic validation rules with an exception log
- defined ownership for each data field
This is a containment approach rather than a full solution.
In practice, the point where many programmes start to struggle is not during initial population, but when the workbook has to be updated, reconciled, and converted into a submission-ready dataset. That pressure is where Excel-based operating models tend to break down.
That becomes clear when comparing manual approaches with more structured ones in the cost dynamics of manual versus automated RoI maintenance.
FAQ
-
Why is using GDPR processor lists for RoI risky?
-
Why is change history important for audit and supervision?
