The register lists the ICT provider and three subcontractors. It looks like a chain. It does not show which service each sub-provider touches, which function depends on that service or what changes if one link moves.
Names are not dependencies. The dependency sits in the operating path between service and function.
Fact: the issue in 30 seconds
Direct answer. Regulation (EU) 2022/2554 establishes digital operational resilience requirements for financial entities and addresses ICT third-party risk. A DORA-related subcontracting map should begin with scope, then connect the contracted service to the supported function, sub-provider, change route and exit dependency. It should not assume every vendor, service or function is governed identically.
The hidden variable is the operational function affected when subcontracting changes.
Why the vendor list feels like a chain map
Vendor registers are familiar. Legal names, contracts, owners and renewal dates fit a consistent format. Adding subcontractor names appears to extend the register one level deeper.
A provider may offer several services. A sub-provider may support only one region, data path or technical layer. The same named vendor may be material to one function and incidental to another. Without the service-function link, the list cannot explain consequence.
PARAVEILUX inference. The useful unit is not the company name alone. It is the dependency between a defined service and a defined function.
What the source record supports
DORA is Regulation (EU) 2022/2554. Articles 28 to 30 provide the bounded EU financial-sector context for ICT third-party risk, subcontracting considerations and written allocation of rights and obligations.
Those provisions do not classify a particular organization as a financial entity, a function as critical or important, or an arrangement as subject to a specific requirement. Those questions can depend on the entity, service, function, contract and current technical standards.
Action: scope before topology
Start with entity, jurisdiction and regulatory role. Record the official source and unresolved applicability question. Then identify the business function and contracted ICT service supporting it.
Only after those fields are stable should the map add sub-providers. For each one, describe the service component, data or operation involved, relevant geography where authenticated, and known change-notice mechanism. Do not infer unseen subcontractors or data locations.
This creates a factual topology without turning the map into a legal conclusion.
A service-function-sub-provider record
For a material dependency, record the entity and role assumption under review; business function and owner; ICT service and contract; primary provider and sub-provider; service component or operation that moves; authenticated region where relevant; actual contractual notice or approval route; transition or exit dependency; source and date; unknowns, conflicts and review trigger.
Contract rights should be summarized only after the exact agreement and hierarchy are reviewed. A framework cannot establish a negotiated term.
Signal: signals and counter-signals
Investigate when a list cannot show which function a sub-provider supports; materiality is inferred from vendor spend; a data location is guessed; contract rights are copied from a template; or a provider change has no business owner.
Counter-signals include a scoped entity and service, function owner, authenticated topology, contract-specific change route, exit dependency and event-based review. These improve visibility. They do not prove DORA applicability, resilience or contractual rights.
The hidden variable
The hidden variable is functional movement. A legal entity may remain the same while processing, support, hosting or another service component moves. A new sub-provider name may also appear without changing the function that matters to the owner.
The owner’s question is what moved and which decision it reopens—not simply whether a name changed.
Limitations: what this does not prove
A vendor label does not prove DORA applicability, criticality or contractual treatment. A subcontractor list does not prove completeness. A service map does not establish resilience, compliance or a right to object, terminate or switch.
Regulated status, criticality, contractual rights, sub-provider completeness, technical standards and liability remain Not assessed.
Owner Q&A
Must every sub-provider be mapped?
No universal depth is recommended. Define the relevant service and function first, then obtain regulatory and technical review.
What if the provider will not disclose the full chain?
Record the request, response, contractual position and uncertainty. Inaccessible information is not proof that no further subcontracting exists.
What is the first exit question?
Ask which data, configuration, identity, integration or operating knowledge is needed to move the defined service path. Test the answer proportionately.
Next verification
Identify the entity, service and supported function, then ask what changes when a sub-provider moves. Check the current EU rules, technical standards and contract before treating the map as proof of scope, criticality or a right to object, terminate or switch.
Sources and limitations
- Regulation (EU) 2022/2554 — official EU source; entity, function and service applicability are Not assessed.
This is general risk education, not professional or certified advice. The source describes a bounded EU financial-sector context; whether it applies or a comparable dependency can arise for you depends on current rules, entity, service, function, contract and evidence.