Ask which critical services depend on the same provider group, in the same countries, through the same subcontractor chain, and many otherwise solid programmes start to wobble.
The RoI is populated, the file is ready, yet the answer still has to be pieced together from separate extracts and competing definitions.
Under Regulation (EU) 2022/2554 (DORA), concentration means clustered operational dependence: which critical or important functions (CIFs) fail together because they share provider groups, service types, locations, or supply-chain nodes. It does not mean “number of vendors.”
That may sound like a small difference, but it matters when a board pack turns supplier counts into resilience reporting and treats them as the same thing.
The question that exposes whether the RoI is usable
For management, the real question is narrower: which critical or important functions depend on the same provider group, the same information and communication technology (ICT) service type, and the same underlying chain?
That is the point at which concentration only matters when tied to critical or important functions.
Clarify the unit of concentration before you build anything
Many weak dashboards fail before the data even arrives. The team never agrees on what “concentration” is supposed to count.
| Unit of concentration | What it is actually measuring | What it misses if used on its own |
|---|---|---|
| Contract concentration | Commercial dependence in signed arrangements | One contract can contain several services and support several functions |
| ICT service concentration | Delivery dependence by service component or service family | It can understate business impact if the function view is missing |
| Function / CIF concentration | Operational dependence at the level management cares about | It needs clean joins back to providers, service types, and chains |
| Provider concentration | Exposure to the direct legal counterparty | It can hide group-level concentration where several providers roll up to one parent |
| Provider-group concentration | Exposure to the ultimate parent or corporate group | It still does not show whether the real weakness sits deeper in the chain |
| Direct-provider concentration | Exposure at rank 1 | It can make diversification look stronger than it is |
| Supply-chain concentration | Exposure to ranked subcontractor nodes underpinning the service | It is only credible if the chain is linked cleanly and deduped properly |
Before any chart goes to a board or risk committee, three questions should already have clear answers:
- What are we counting?
- At what level are we counting it?
- What is the dedupe key?
Without that discipline, the rest of the dashboard is mostly formatting.
Define the RoI before reporting starts
RoI reporting breaks down when structure, definitions, and keys are not stabilised upfront. Copla Registry enforces governed data foundations before reporting logic is applied.
The register was built to be operated, not admired
Here, the structure of the rule matters.
Commission Implementing Regulation (EU) 2024/2956 — the Implementing Technical Standards (ITS) for the register — is unusually clear about why the RoI looks the way it does.
Recital 1 says the information is essential for internal ICT risk management as well as supervision and oversight.
Recital 4 says the templates use open tables with a predefined number of columns and an indefinite number of rows. It also says the templates are linked by specific keys forming a relational structure.
Recitals 8, 11 and 12 go further, spelling out the role of specific keys, consistent identifiers, and a structure shaped by data-management and reporting needs.
For concentration reporting, the practical implication is straightforward. The dashboard depends on the mandated dataset staying joinable.
Once teams start copying RoI content into side spreadsheets and local tracking files, concentration logic usually weakens first. If you want a neutral overview of the underlying model, the RoI’s relational structure is the core data spine.
Why supervisors care about the same data
Internal use is only half the story. In the ESAs Decision on reporting of information for critical ICT third-party service provider (CTPP) designation, the European Supervisory Authorities (ESAs) say they need the RoI data so competent authorities can provide the full registers used for the assessment and designation of critical ICT third-party service providers.
The same dataset used internally to answer concentration questions is also submitted for those assessment and designation purposes, which gives the ESAs a broader supervisory view of dependencies.
The join spine that makes concentration queryable
Only a small part of the model matters for concentration reporting, and it has to stay stable.
The ITS links the register through the contractual arrangement reference number, the identifiers of financial entities and ICT third-party service providers, the function identifier, and the type of ICT services.
It also makes the group point clear: operability across entity, sub-consolidated, and consolidated levels depends on consistent contract references, function identifiers, legal entity identifiers (LEIs), and provider identifiers.
| Minimum field | Why it matters for concentration |
|---|---|
| Contractual arrangement reference number | Holds the record together across templates and stops the same arrangement being interpreted differently by different teams |
| Financial-entity LEI | Distinguishes the entity using the service from the entity signing for it, which is not always the same thing in groups |
| Provider identifier | Anchors the direct provider cleanly enough to join service, contract, and chain records |
| Provider ultimate parent | Lets management see group concentration rather than just legal-counterparty concentration |
| Function identifier | Connects third-party dependency to the operational question that actually matters |
| ICT service type | Stops different service families being collapsed into one supplier label and supports like-for-like concentration views |
| Supply-chain rank | Shows where a node sits in the chain and whether the concentration is direct or downstream |
| Recipient of subcontracted services | Matters when the analysis needs the actual chain path rather than a simple count of ranked nodes |
I would frame it this way: if those fields are unstable, concentration analysis becomes guesswork. Supervisors tend not to enjoy that.
Copla Registry
Turn RoI data into decisions
RoI data often ends up as static reporting rather than usable insight. Copla Registry structures the dataset so dependencies, risks, and concentrations can support real management decisions.
Where diversification starts lying: the supply chain
Prime-vendor diversity can look convincing right up until you look one tier deeper.
The concentration point is simple. Different prime providers can still lead back to the same downstream dependency.
That is why prime-vendor diversification can still hide subcontractor concentration, which is exactly the problem explored in this analysis of sub-processors under DORA.
Three management questions that should turn into queries
This is the operational discipline that separates a useful dashboard from a decorative one.
1. Which critical or important functions share the same provider group, the same ICT service type, and the same underpinning subcontractor at rank 2 or above?
Join logic:
function_id + provider_group + ICT_service_type + rank + provider_id
2. Where does apparent prime-vendor diversification collapse into the same downstream dependency?
Join logic:
compare distinct rank-1 providers against higher-rank provider groups for the same service type and the same function population.
3. Which critical functions depend on services with weak substitutability and no credible exit path?
Join logic:
use the B_07.01 assessment layer to filter CIF-linked services by substitutability, alternatives, reintegration difficulty, and exit-plan status.
The third question is where concentration becomes a resilience action problem. It stops being a charting exercise and becomes a decision about what has to change.
Six concentration views management can actually use
A RoI dashboard can produce a lot of charts. Most of them are forgettable. The useful ones are the views that change a decision.
Firms already have the raw material in the ITS, including the service-type classifications in Annex III and the risk-assessment layer in B_07.01. That is enough to produce a tight set of concentration views without creating a second taxonomy or pretending template completion is the same as analysis.
| Concentration view | What the RoI is showing | Why management should care |
|---|---|---|
| Provider-group concentration | Direct providers rolled up to ultimate parent level | It shows whether apparent supplier diversity is actually dependence on one corporate group |
| CIF exposure concentration | Which critical or important functions share provider groups, service types, or chain nodes | It turns third-party concentration into a business-service question rather than a procurement question |
| ICT service type concentration | Clustering by the mandated ICT service type identifiers | It shows where dependence is concentrated by service family, which is more useful than supplier labels alone |
| Geography and data-footprint concentration | Country of provision, data-at-rest location, processing location, and data sensitivity | It exposes jurisdictional clustering and continuity pressure that are invisible in a supplier-only view |
| Exitability concentration | Substitutability, alternatives, reintegration difficulty, exit-plan status, and discontinuation impact | It shows where concentration has become an action issue rather than a reporting issue |
| Supply-chain concentration | Ranked subcontractor nodes, their position in the chain, and their links to the service path | It shows where the chain itself deserves closer challenge |
Mapping concentration views back to RoI fields
The useful bridge here is narrow and practical.
| Concentration view | RoI fields that matter | Join keys |
|---|---|---|
| Provider-group concentration | provider identifier, ultimate parent undertaking, contractual arrangement reference number | contract_ref + provider_id + provider_group |
| CIF exposure concentration | function identifier, provider group, ICT service type, criticality assessment | function_id + provider_group + ICT_service_type |
| Supply-chain concentration | provider identifier, recipient of subcontracted services, rank, provider group, ICT service type | contract_ref + ICT_service_type + rank + provider_id + recipient_provider_id |
| Geography and data-footprint concentration | country of provision, data-at-rest location, data-processing location, data sensitivity | contract_ref + provider_group + ICT_service_type |
| Exitability concentration | substitutability, alternatives, reintegration difficulty, exit-plan status, discontinuation impact | contract_ref + function_id + provider_group + ICT_service_type |
A fuller inventory of which RoI fields actually power concentration views belongs in the dedicated field breakdown. Here, the point is narrower and more practical.
The dashboard usually goes wrong in three operational places
Weak provider-group roll-up
The ITS requires the identification of the ultimate parent undertaking in B_05.01, and that sounds administrative until you see the effect on management reporting.
Count only direct providers and concentration often looks manageable. Roll them up properly and the picture tightens.
Rank blindness
Article 3 requires firms to include subcontractors that effectively underpin ICT services supporting critical or important functions.
Diversity at the prime layer is not especially comforting if the same ranked node sits underneath multiple services.
Row inflation
Article 4 says each data element must contain a single value, and if more than one value is valid the firm has to add another row.
That is sensible reporting logic. It becomes dangerous when dashboards count rows rather than dependencies.
| Metric being measured | Safer dedupe key | Why it works |
|---|---|---|
| Provider-group exposure count | contract_ref + provider_group + ICT_service_type | Stops multiple location rows from inflating what is really one service exposure to one group |
| Supply-chain concentration by node | contract_ref + provider_group + ICT_service_type + rank + provider_id | Keeps ranked-node concentration tied to the actual chain position rather than to repeated user or location rows |
| CIF exposure concentration | function_id + provider_group + ICT_service_type | Measures the operational dependency instead of counting all technical row expansions around it |
Row structure shapes the concentration view directly. Teams often underestimate this because the export looks tidy. The trouble appears when locations, multi-entity usage, and supply-chain ranks start multiplying one another.
Submission pressure is only relevant because it exposes weak concentration logic
Reporting pressure matters here for one reason: it punishes bad identifiers.
In the ESAs’ RoI reporting FAQ, updated 28 March 2025, the ESAs make clear that reporting runs through competent authorities, that the files are not reported in Excel, and that technical, validation, and business checks can trigger resubmission.
Under supervisory pressure, weak concentration logic stops looking harmless very quickly.
Used properly, the RoI works best as three things at once: a systemic-risk lens for clustered dependencies across provider groups and chains, a board-reporting tool for what the management body can actually ask and act on, and an operational-resilience map of what fails together, where substitutability is weak, and what will be painful to unwind.
