Most financial entities completed their DORA register of information on time. The vendor inventory exists, the critical or important functions are mapped, and the due diligence evidence is filed. What supervisors are now asking is a different question: who are your vendors' vendors, and what happens when the subcontractor — not the contracted provider — is the party that actually goes down?
Article 30(2)(a) of Regulation 2022/2554 requires that contracts with ICT third-party service providers supporting critical or important functions describe the subcontracting chain and the conditions under which subcontracting is permitted. The Commission's Regulatory Technical Standard on subcontracting arrangements, adopted in late 2025, operationalises this requirement. It reframes subcontracting from a disclosure item on a vendor questionnaire into an ongoing oversight discipline.
This post covers what the RTS requires, the practical difficulty of obtaining reliable fourth-party data, and how to build a subcontracting programme that satisfies supervisors without drowning the second line in paperwork that no one reads.
What the Subcontracting RTS Actually Requires
The RTS elaborates Article 30(2)(a) in three directions that most existing TPRM programmes do not cover.
Chain identification, not just disclosure. The requirement is not limited to the subcontractor that the provider discloses on the contract. It covers the entire chain of entities that materially contribute to the delivery of the critical or important function. A cloud provider subcontracts physical facility management, network carriage, hardware maintenance, and software libraries. Each of those parties may itself subcontract further. The RTS expects the financial entity to understand the chain to the point where material service delivery risk sits — not necessarily every downstream supplier, but every entity whose unavailability would meaningfully affect the critical or important function.
Material change notification. Providers must notify the financial entity of planned changes to the subcontracting chain that could affect the provider's ability to deliver the contracted service. The notification must occur before the change takes effect, and the financial entity must have the contractual right to object or terminate if the change is incompatible with its risk profile. This is a structural change from the typical "we will let you know" vendor clause — it requires advance notice with sufficient time for the financial entity to assess and react.
Concentration at the chain level. The RTS clarifies that concentration risk must be assessed across the subcontracting chain, not only at the direct vendor level. A financial entity with twelve direct ICT providers, all of whom depend on the same underlying hyperscale infrastructure or the same handful of undersea cable operators, carries chain-level concentration risk that the direct vendor inventory does not reveal. This is precisely the kind of hidden dependency that caused cascading failures in 2024 and 2025, and supervisors have indicated that chain-level concentration analysis will be a specific area of supervisory focus in 2026.
The Evidence Problem
Building the subcontracting chain map is hard because the data is not sitting in a SaaS tool waiting to be pulled. It comes from three uneven sources.
Provider-supplied subcontracting schedules. Under the RTS, providers must maintain and share a register of subcontractors that support the contracted service. In practice, the quality of these registers varies enormously. Some providers deliver a structured list with entity identifiers, service descriptions, and geographic locations. Others deliver a free-text paragraph describing broad categories ("global content delivery partners") that is nearly useless for supervisory evidence.
Technical discovery. For IaaS and PaaS providers, some of the chain can be discovered technically — the underlying datacentre regions, the transit providers visible in BGP paths, the certificate authorities trusted by the service endpoints. This technical evidence complements but does not replace the provider's declaration. The value is in cross-checking: if the provider's written register is silent on the transit carrier that your BGP telemetry shows is on the critical path, you have a disclosure gap worth raising.
Public regulatory and financial filings. Critical ICT providers that qualify as designated CTPPs publish more extensive subcontracting information as part of their oversight engagement. For non-designated providers, public financial filings, transparency reports, and certification scopes can surface subcontracting relationships that are not in the contracted register.
None of these sources is complete on its own. The practical technique is to build the chain map from all three, flag the discrepancies, and use the discrepancies as the conversation opener with the provider's vendor management team.
Building a Chain Map That Survives Supervisory Review
The artefact a supervisor will ask for is a chain map that answers three questions for each critical or important function:
- Which direct providers support this function, and what service do they deliver?
- For each direct provider, which subcontractors materially contribute to the service, and in what role?
- For each material subcontractor, what is the failure scenario, and how does the recovery plan address it?
Structuring this in a database rather than a spreadsheet matters because the map must support chain-level queries. The typical supervisory question is not "who is your provider for function X" but "what is your exposure to jurisdiction Y across all critical functions" or "which functions would be affected by the unavailability of provider Z, across all chains". A flat vendor list cannot answer these questions. A graph-structured map can.
The minimum attributes to capture per edge in the chain:
- Provider identity — legal entity, LEI where available, ultimate parent
- Service description — what specifically is delivered, linked to the critical or important function it supports
- Geographic exposure — where the service is delivered from and where the supporting data is processed
- Substitutability — is there an identified alternative provider, and what is the switching cost in time and money
- Materiality classification — is this link in the chain critical (failure directly degrades the CIF), important (failure materially degrades the CIF), or auxiliary (failure is a nuisance)
- Last attestation date — when was this chain entry last confirmed with the upstream provider
- Discrepancy flag — does technical discovery contradict the declared chain
The chain map becomes the anchor for three downstream artefacts: the DORA register of information (filtered view of direct providers), the exit strategy documentation (per-function switching analysis), and the concentration report (aggregation by provider, jurisdiction, and chain depth).
The Material Change Clock
The RTS requirement that providers notify material subcontracting changes before they take effect creates an operational tempo that most TPRM teams are not resourced for. A large financial entity may have 200-400 direct ICT providers supporting critical or important functions, each of whom may make several material subcontracting changes per year. That is potentially several thousand change notifications per year, each of which requires an assessment and a documented decision.
The practical design pattern is a tiered triage:
Tier 1 — informational notifications. Changes to non-material subcontractors (auxiliary links in the chain), changes that do not affect the service delivery, or changes that substitute one subcontractor with an equivalent one. These are logged but do not require review. The provider's representation that the change is Tier 1 should be accepted at face value unless it raises an obvious inconsistency.
Tier 2 — reviewable notifications. Changes to material subcontractors that do not change the fundamental risk profile (e.g., substitution of one large cloud region for another in the same jurisdiction). These require a documented review by the second line, but the review is a check against the stated substitutability assessment rather than a full re-assessment.
Tier 3 — escalation. Changes that affect a CTPP-designated subcontractor, introduce a new jurisdiction outside the entity's approved geographic risk appetite, or materially change the service architecture. These require formal risk assessment, potentially management body notification, and the contractual right to object must be actively considered.
Without this triage, the TPRM function drowns in low-value reviews and loses the capacity to focus on the small number of changes that genuinely matter.
Testing Chain-Level Scenarios
The final — and most commonly deferred — part of the subcontracting programme is testing. DORA's ICT business continuity obligations require financial entities to test recovery capability against scenarios that include the failure of ICT third-party service providers. The subcontracting chain map introduces scenarios that go further: what if the shared underlying infrastructure — visible only at chain depth two or three — becomes unavailable?
The tabletop exercises that are worth running are the ones that test the chain-level dependencies the map has revealed. A typical valuable scenario: "the CDN provider used by three different SaaS vendors that each support a different CIF becomes unavailable for eighteen hours". If the chain map shows this is a real dependency, the scenario is concrete and testable. If the chain map has not been built, the scenario is speculative and the test adds nothing.
What to Do in the Next Ninety Days
The RTS compliance clock is running, and supervisory attention on subcontracting will increase through 2026. The ninety-day operational plan for a financial entity that has not yet invested heavily in this area:
- Extract the direct provider list from the DORA register, filtered to critical or important function support. This is the root of every chain.
- Request updated subcontracting schedules from every direct provider supporting a CIF. Set a sixty-day response deadline. Document non-response.
- Cross-check three to five of the largest against technical discovery and public filings to calibrate how much to trust the provider-declared registers.
- Build the chain map in a graph-capable data store. Excel is not sufficient for the queries supervisors will ask.
- Implement the material change triage workflow before the volume of notifications arrives, not after.
- Add one chain-level scenario to the next scheduled resilience test to validate that the chain map is operationally usable, not just documentary.
Subcontracting is where most DORA programmes will be tested in 2026. The entities that built the chain map early, and maintained it as a living artefact rather than a one-time deliverable, will have a materially easier supervisory dialogue than the ones that filed their register and considered the work done.