Skip to main content
DORA Auditor

guide

DORA Subcontracting Rules: What the RTS Requires

DORA subcontracting rules require ten checks before a critical ICT service is subcontracted, plus notice-and-objection rights. Updated July 2026.

DORA Auditor Editorial Team·Published

When an ICT third-party provider wants to subcontract a service supporting a critical or important function, DORA does not let the financial entity find out after the fact. Commission Delegated Regulation (EU) 2025/532, the Article 30 subcontracting RTS, applicable since 22 July 2025, sets ten conditions an entity must assess before agreeing to a subcontracting arrangement, plus a formal notice-and-objection process for any later change to the chain. Here is what the RTS actually requires, and what changed between the draft and the final version.

Why Article 30 alone was not enough

Article 30 already requires ICT contracts to state whether subcontracting is permitted for services supporting a critical or important function, and under what conditions. That leaves a gap: it does not say how deep an entity has to look before signing off, or what happens when a provider wants to swap a subcontractor six months into the contract. The European Supervisory Authorities were mandated under Article 30(5) to close that gap with binding technical standards, published as Commission Delegated Regulation (EU) 2025/532 of 24 March 2025, entering into force 22 July 2025.

The RTS applies to all DORA in-scope financial entities relying on ICT subcontracting for critical or important functions, directly, with no national transposition needed. It does not touch subcontracting for non-critical services, where the baseline Article 30 contract terms still apply on their own.

The ten conditions to check before signing off

Before contracting with an ICT third-party provider that intends to subcontract part of a critical or important service, the RTS requires the financial entity to assess, among other things:

  1. The subcontractor's operational and financial capacity to deliver the service reliably.
  2. Whether the subcontracting arrangement changes the entity's overall risk profile for the function in question.
  3. Transparency over the full subcontracting chain, not just the first tier below the direct provider.
  4. Whether the entity retains equivalent access, audit, and information rights over subcontractors as it has over the direct provider.
  5. Data location and processing arrangements at every level of the chain, consistent with the entity's own register of information obligations.
  6. Whether adequate business continuity and exit provisions extend down the chain, not just to the direct contractual counterparty.

The assessment is meant to happen before the entity agrees to the arrangement, not as a retrospective check. In practice, this means the due diligence an entity already runs on its direct ICT providers under Article 28 has to extend one or more layers further down, into providers the entity may never deal with directly.

Notification and the right to object

The second half of the RTS covers what happens once a contract is running. The ICT third-party provider must notify the financial entity of any intended material change to its subcontracting arrangements, for example, a new subcontractor taking on part of a critical function, or a change in where subcontracted work is performed. The entity then has a defined notice period to review the change and object before the provider is permitted to implement it.

This is the mechanism that gives Article 30's "conditions for subcontracting" language actual teeth: an entity is not stuck discovering a new, un-vetted subcontractor after the fact. If the entity does not object within the notice period, the change proceeds; if it does object on reasonable grounds, related to risk, capability, or compliance, the provider cannot go ahead without resolving the objection.

What changed between the draft and the final RTS

The version finalised in 2025 is narrower than the draft the ESAs consulted on in 2024. The most notable change: the final RTS does not require the ICT third-party provider to keep the financial entity's register of information automatically up to date as the subcontracting chain evolves. That obligation was dropped from the binding contractual requirement.

This does not remove the entity's own duty to maintain an accurate register. It shifts where that burden sits: financial entities still have to actively monitor their subcontracting supply chain and keep their register current, rather than being able to rely on a contractual guarantee that the provider will do it for them. For an entity already building out its Article 28 register, this means the subcontracting-chain fields need an active review process, not a one-time data pull from the contract.

Where subcontracting overlaps with concentration risk

A long, opaque subcontracting chain is one of the clearest ways concentration risk creeps into a supposedly diversified set of suppliers. Two providers with different brand names can still depend on the same fourth-tier data-centre operator or cloud region. The RTS's transparency requirement, visibility into the chain before signing, and notice of later changes, exists precisely so entities can catch that kind of hidden concentration before it becomes a single point of failure, not just so subcontracting looks orderly on paper.

Entities assessing banks and other systemically important providers under their own third-party risk programmes should treat subcontracting-chain mapping as part of the same exercise as concentration assessment, not a separate checkbox.

A practical approach for your next ICT contract

  • Ask for the subcontracting chain in writing before signing, not after. A provider unwilling to disclose material subcontractors for a critical function is a red flag under the RTS's transparency condition.
  • Build the notice-and-objection clause into the contract explicitly. Do not assume it applies by default; the notice period and objection process should be named terms, with a defined escalation path if the provider disputes an objection.
  • Extend audit and access rights down the chain, at least for subcontractors handling data or processing for the critical function, not only for the entity's direct counterparty.
  • Update the register of information on a schedule, not only when a provider happens to disclose a change. Treat subcontracting-chain review as a recurring control, not a one-off onboarding step.
  • Cross-check against your third-party register with a dedicated tool so subcontracting fields do not silently drift out of date between refresh cycles.

A structured way to test whether your contracts and register already meet these conditions is the DORA Readiness Score, which scores the third-party risk pillar alongside the other four.

Frequently asked questions

What is the DORA subcontracting RTS?
Does the RTS apply to all ICT subcontracting?
Does the ICT provider have to keep my register of information updated automatically?
What happens if I object to a subcontracting change?
How does subcontracting relate to concentration risk under DORA?
Where does subcontracting fit in a DORA gap assessment?

Sources

Last updated: 27 July 2026.

#third-party-risk#subcontracting#article-30#banks

More from the blog