Two provider records appear in B_05.01 for what is clearly the same firm. One uses an LEI. The other uses a national identifier pulled from a procurement system. Both are technically valid. Both connect to different contracts, different signatories, and different supply chains.
Everything is populated. The dataset does not reconcile.
Field drift is one part of a wider operating problem across the RoI, as set out in the full DORA RoI framework. This article focuses on how required data fields behave in practice, broken down by the categories institutions actually have to manage.
The four anchors that tend to break first
Contract reference, provider identifier, function identifier, and the signer versus service user split are the most common origins of reconciliation failure.
Stabilise core RoI identifiers
The RoI depends on consistent contract, provider, and function identifiers. Copla Registry enforces alignment across these core fields to keep all linked records intact.
Minimum keys every category depends on
- Contract reference (B_02.01) — anchors all service and obligation records
- Provider identifier (B_05.01) — anchors vendor, supply chain, and signatory linkage
- Function identifier (B_06.01) — anchors service criticality and mapping
- Signer vs service user split (B_03 vs B_04) — anchors accountability vs consumption
If these drift, every category below starts to misalign regardless of how complete the fields look. For a structural view of how these keys connect across the dataset, you’d have to analyse how the linked-table model works.
Category ownership, source systems, and drift triggers across the RoI
| Category | Primary owning teams | Systems you reconcile against | Drift triggers |
|---|---|---|---|
| Entity & service mapping | Legal entity management, outsourcing oversight | Legal entity master, org structure systems | M&A, branch changes, function redesign |
| Provider profile | Procurement, vendor management, data governance | Vendor master, finance systems, LEI/EUID registries | Onboarding, identifier changes, data refresh cycles |
| Contracts & obligations | Procurement, Legal | Contract lifecycle systems, procurement platforms | Renewals, amendments, novations, terminations |
| Risk & controls | Risk, resilience, outsourcing oversight | Risk assessments, BIA, resilience testing outputs | Annual reviews, incidents, material service changes |
| Continuity & exit | Third-party risk, architecture, resilience | Supplier inventories, architecture diagrams | Outsourcing changes, architecture shifts, critical service reviews |
| Oversight & change | Central RoI owner, data governance | All upstream systems | Continuous; reporting cycles, audits |
Entity & service mapping — where alignment starts to slip (B_01, B_03, B_04, B_06)
Entity & service mapping = legal perimeter + accountability (who signs) + consumption footprint (who uses) + function inventory.
This category brings together B_01 (entity perimeter and branches), B_03 (signatories), B_04 (service users), and B_06 (function inventory).
In field terms, this means maintaining:
- entity identifiers, hierarchy, and branch records (B_01)
- signing entities on both receiving and providing sides (B_03)
- actual service-consuming entities (B_04)
- function identifiers, ownership, and criticality classification (B_06)
The first signs of drift usually appear after structural change. A merger updates the legal entity structure, but the RoI perimeter does not move in step. Signatories remain tied to entities no longer in scope. Service-user records reflect an outdated structure. Function ownership no longer matches the organisation.
As the RoI template instructions in Implementing Regulation (EU) 2024/2956 require, these identifiers must remain unique and consistent across templates. That requirement only holds if updates are synchronised.
Provider profile — duplication hides in plain sight (B_05.01)
Provider profile = who the provider is, how it is uniquely identified, and how it links to group structure and cost.
Provider data sits primarily in B_05.01, but it feeds every other template.
At field level, the provider profile includes:
- provider identifier (LEI, EUID, or controlled alternative) and code type
- legal name and name in Latin alphabet
- headquarters country
- ultimate parent undertaking and its identifier
- annual expense or estimated cost where applicable
The provider identification requirements in the ITS expect a consistent identifier strategy across all of these fields.
Illustrative scenario
One provider, two identifiers, three broken links
A provider is recorded twice under different identifiers.
- B_03 links the contract to one version
- B_05.01 holds both as separate providers
- B_05.02 builds separate supply chains
No fields are missing. The provider landscape is duplicated, and downstream dependencies split accordingly.
Contracts & obligations — continuity breaks under normal operations (B_02 spine)
Contracts & obligations = the contractual spine plus the operational facts that define how the service is delivered and terminated.
Contracts are captured across B_02.01 to B_02.03, with B_02.02 adding the service-specific layer.
At field level, this category includes:
- contractual arrangement reference number and arrangement type (B_02.01)
- links to associated and overarching arrangements (B_02.01, B_02.03)
- lifecycle fields: start date, end date, renewal, termination reason (B_02.02)
- governing law and country of provision (B_02.02)
- notice periods and contractual exit conditions (B_02.02)
- service-specific attributes such as data storage and processing locations (B_02.02)
As the B_02.01 instructions make clear, the contractual arrangement reference number has to remain unique and consistent across templates.
Operational reality is less stable. Renewals introduce new identifiers. Framework agreements are split. Procurement systems generate parallel references.
When continuity breaks:
- service records detach from the original contract
- obligations are tied to the wrong reference
- intra-group relationships lose coherence
Copla Registry
Maintain contract continuity
Contract changes often break links across RoI templates. Copla Registry preserves relationships and keeps references consistent across services and entities.
- Maintain consistent contract references across templates
- Preserve links between services, obligations, and entities
- Avoid breaks caused by renewals and amendments
Risk & controls — assessments degrade faster than expected (B_02.02, B_07.01, B_99.01)
Risk & controls = how the service is assessed in terms of reliance, impact, substitutability, and internal classification logic.
Risk and control fields sit mainly in B_02.02, B_07.01, and B_99.01.
At field level, this includes:
- reliance on ICT services and data sensitivity (B_02.02)
- substitutability and difficulty of replacement (B_07.01)
- identification of alternative providers (B_07.01)
- impact of discontinuing the service or function (B_07.01, B_06.01)
- internal definitions for coded values and indicators (B_99.01)
The B_07.01 instructions require these assessment fields to be populated for services supporting critical or important functions, including identifying alternative providers.
Service conditions change. Dependencies deepen. Market options shift. The fields often stay as they were.
B_07.01 only remains credible when the assumptions behind service-level exit planning are revisited after those changes.
Continuity & exit — dependency depth determines what matters (B_05.02, B_07.01)
Continuity & exit = the real dependency chain behind the service and the institution’s ability to replace or exit it.
Continuity and exit considerations sit across B_05.02 and B_07.01.
At field level, this includes:
- identification of subcontractors that underpin the service (B_05.02)
- ranking of providers and subcontractors in the supply chain (B_05.02)
- substitutability and availability of alternatives (B_07.01)
- existence of exit plans and feasibility of transition (B_07.01)
- impact of service discontinuation (B_07.01)
The B_05.02 instructions require institutions to capture subcontractors that effectively underpin ICT services, particularly for critical or important functions.
The operational boundary usually depends on which subcontractors actually support the service path, which is why the distinction in what “effectively underpinning” means matters here.
If that boundary is wrong, continuity planning rests on an incomplete or distorted dependency map.
Oversight & change — where the register is either maintained or abandoned (cross-template)
Oversight & change = the update discipline that keeps all other categories aligned over time.
This category cuts across all templates and determines whether the register stays usable.
At field level, it includes:
- lifecycle date updates and contract renewals (B_02.02)
- perimeter updates after corporate actions (B_01)
- identifier governance for providers and functions (B_05.01, B_06.01)
- maintenance of closed-list definitions (B_99.01)
- periodic reassessment of service-level fields (B_07.01)
The data quality requirements in the ITS require accuracy, completeness, consistency, integrity, and validity. Those conditions depend on continuous updates.
Keep the RoI aligned over time
RoI datasets degrade when updates are applied inconsistently across templates. Copla Registry enforces alignment and control to keep the register accurate as it evolves.
I would frame it this way: this is the category that determines whether the RoI remains a working dataset or becomes a static extract.
This is also why key stability and updates degrade in spreadsheet builds. The structure may be present, but nothing enforces alignment over time.
How field drift originates and propagates across RoI templates
| Drift source | Affected templates | What breaks |
|---|---|---|
| Contract renumbering | B_02.01–B_02.03 | Loss of continuity and cost aggregation |
| Role confusion (signer vs user) | B_03 vs B_04 | Misaligned service ownership and usage |
| Provider duplication | B_05.01, B_05.02 | Fragmented supply chains and signatory mismatch |
| Identifier-type collision (LEI vs national/procurement ID) | B_05.01, B_03, B_02.01, B_05.02 | Parallel provider reality; supply chains fork |
| Function ID reuse | B_06.01, B_02.02, B_07.01 | Broken service-function mapping |
| Closed-list inconsistency | B_99.01, B_07.01 | Loss of comparability across assessments |
What expands when services support a critical or important function
| Condition | Expansion |
|---|---|
| Supports critical/important function | Expanded service details (B_02.02), deeper subcontractor capture (B_05.02), full service-level assessments (B_07.01) |
| Does not support critical/important function | Baseline template population without extended assessment or supply chain depth |
Understanding when that expansion applies depends on what “critical or important function” means operationally and how it is assessed.
Reporting reality: stable fields determine whether submissions hold
The ITS requires accuracy, completeness, consistency, integrity, and validity in the register.
In practice, recurring issues cluster around:
- unstable contract references
- inconsistent provider identifiers
- outdated lifecycle dates
- role mismatches across templates
Even when fields are populated, these inconsistencies create reconciliation failures at submission.
The submission mechanics sit separately, but they depend entirely on the stability of the underlying fields. The practical step of packaging and submitting RoI data without triggering preventable errors comes after that.
FAQ
-
Which RoI categories typically require the most ongoing maintenance?
-
How granular should provider identification be when no LEI is available?
