DORA makes ICT concentration a pre-contract decision

The concentration decision belongs before signature

The direct answer in DORA is that ICT concentration is not only a portfolio statistic reviewed after contracts accumulate. Article 28 requires a financial entity, before entering an arrangement for ICT services, to determine whether the service supports a critical or important function, assess the applicable supervisory conditions, perform due diligence, identify conflicts, and assess relevant risks. Article 29 then makes concentration one of those pre-contract questions. The decision record should exist while the entity can still change the provider, architecture, scope, terms, or sourcing approach.

That boundary distinguishes this assessment from DORA's register of information. The register preserves contractual relationships and dependencies across the maintained population. The Article 29 decision explains why an envisaged critical-service arrangement was acceptable in the first place. A complete operating model links the two without treating inventory as approval: the proposed service and supported function, criticality basis, provider relationships, known substitutes, existing exposures, subcontracting path, accountable reviewers, decision, conditions, and review trigger should remain traceable.

Substitutability and repeated reliance are separate signals

Article 29 identifies whether the proposed arrangement would involve an ICT third-party service provider that is not easily substitutable. That is more specific than asking whether another vendor exists. An assessment may need to test whether another provider can support the function, data, integration, security, capacity, location, timing, regulatory, and transition needs on credible terms. Assumptions about portability and migration belong in the evidence record, along with their source and review date.

The article separately identifies multiple arrangements for critical or important functions with the same provider or with closely connected providers. A contracting workflow that evaluates only the individual request can miss that pattern. The review therefore needs a current view of related agreements, supported functions, legal entities, provider group relationships, service dependencies, regions, and renewal dates. Neither signal automatically prohibits the arrangement; each creates a decision that must be evaluated in the entity's actual context.

Alternatives are weighed, not presumed

DORA directs financial entities to weigh the benefits and costs of alternative solutions, including the use of different ICT third-party providers, while considering whether those solutions match business needs and the objectives of the digital operational resilience strategy. That language does not create a rigid multi-vendor quota. It does require an intelligible comparison between the proposed dependency and realistic alternatives rather than a conclusory statement that diversification is too expensive or operationally impossible.

A defensible comparison preserves the alternative considered, functional fit, resilience effect, implementation and transition burden, data and integration consequences, timing, cost basis, residual risk, and reason for disposition. Where the entity accepts concentration because the selected option better meets documented needs, conditions such as stronger continuity evidence, tested exit capabilities, architecture changes, contractual protections, monitoring, or a reassessment date can remain attached to the decision instead of disappearing into meeting notes.

Subcontracting extends the analysis beyond the direct provider

For arrangements that permit subcontracting of ICT services supporting a critical or important function, Article 29 requires the entity to weigh benefits and risks arising from that subcontracting, with particular attention to an ICT subcontractor established in a third country. The direct provider name is therefore not a sufficient concentration key. Material service components, downstream providers, locations, changes, and shared dependencies can alter the exposure even when the prime contract remains unchanged.

This is a governance and evidence requirement, not a claim that every subcontractor creates the same risk. The maintained workflow should identify what is known, what disclosure or approval right applies, how a proposed change is assessed, and who can accept, condition, or reject it. Unknown downstream dependencies should remain visible as uncertainty. Article 29 supports a reasoned entity-level assessment; it does not supply a transaction-specific legal conclusion or replace the full DORA text, applicable technical standards, supervisory expectations, or professional advice.

What we will watch next

Third Party Current will watch for later primary-source evidence that changes the maintained company, capability, or standards record. The next useful evidence may include implementation documentation, release details, regulator findings, corrected methods, product packaging, customer-observable workflow, or a subsequent company statement. Until then, the dated source and its stated boundary remain attached to this analysis.