Mapping Your ICT Subcontracting Chain Under the DORA Subcontracting RTS

The DORA subcontracting RTS is written as a contracting obligation, but it lands on your desk as a data problem. You cannot assess a chain you have not modelled, and the chain does not sit still long enough for a spreadsheet to describe it.

Commission Delegated Regulation (EU) 2025/532 supplements DORA under the mandate in Article 30(5). It was adopted on 24 March 2025, published in the Official Journal on 2 July 2025, and applies from 22 July 2025. It is short — seven articles — and most commentary reads it as a checklist of clauses to insert into your ICT contracts. That reading misses the harder half. The RTS asks you to determine and assess the subcontractors that support your critical or important functions, and to keep assessing them as the arrangement changes. The moment a direct provider is more than one layer deep, or reserves the right to swap its own suppliers, that requirement stops being a document you sign and becomes a dataset you maintain.

What the RTS actually asks you to model

Strip the RTS to its load-bearing parts and it does five things. Article 1 requires the assessment to reflect your overall risk profile and the complexity of the arrangement. Article 3 requires due diligence and a risk assessment of the use of subcontractors before you enter, renew or materially change an arrangement — proportionate, and revisited when things move. Article 4 sets the conditions under which ICT services supporting a critical or important function, or a material part of one, may be subcontracted at all. Article 5 governs material changes to the subcontracting arrangements. Article 6 deals with termination rights when the chain becomes unmanageable.

Read those together and the object of the exercise is not the contract. It is the chain. You are being asked to hold a current, defensible view of who ultimately runs the systems behind a critical function — the provider you signed, the provider they leaned on, and the provider behind that. Chain length, layering, geography and concentration are all explicit factors in the assessment. None of them survives contact with a static register, because every one of them is a property of a graph you do not fully control.

Why the register on its own does not carry it

Most firms already keep a register of information for DORA, and the register template does reach subcontractors that support critical or important functions. That is necessary and it is not sufficient. A register is a list of rows recorded at a point in time. The question the RTS actually forces — does any single fourth-party provider sit underneath three of my critical functions through different direct suppliers who do not know about each other — is not answerable by reading rows. It is a traversal. You have to walk the edges between providers, not scan a column, and a flat table makes that walk expensive and error-prone.

This is the same shape of problem I described in turning the incident classification RTS into a decision engine: a regulation written in prose that only becomes operable once you model it as data and query it. Here the data model is a directed graph. Nodes are your firm, your functions and the providers at every tier. Edges are the supports and subcontracts-to relationships between them. Once it is a graph, concentration, hidden common dependencies and chain depth become queries you can run on a schedule rather than judgements you reconstruct by hand each audit.

The graph, made concrete

Below is the minimum viable version in Cypher. The point is not the tool — a recursive SQL common table expression does the same job — but the shape: functions depend on providers, providers subcontract to providers, and a variable-length traversal surfaces the full nth-tier chain and the shared dependencies underneath it.

// Nodes: critical/important functions and ICT providers at every tier.
MERGE (f:Function {id:'settlement', critical:true})
MERGE (p1:Provider {id:'core-saas', tier:1, country:'IE'})
MERGE (p2:Provider {id:'cloud-hyperscaler', tier:2, country:'DE'})
MERGE (p3:Provider {id:'cdn-edge', tier:3, country:'US'})

// Edges: what supports the function, and who subcontracts to whom.
MERGE (f)-[:SUPPORTED_BY]->(p1)
MERGE (p1)-[:SUBCONTRACTS_TO]->(p2)
MERGE (p2)-[:SUBCONTRACTS_TO]->(p3)

// Walk the whole chain behind every critical function (nth tier).
MATCH path = (f:Function {critical:true})
      -[:SUPPORTED_BY|SUBCONTRACTS_TO*1..8]->(p:Provider)
RETURN f.id AS function, length(path) AS depth, p.id AS provider, p.country
ORDER BY function, depth;

// Concentration: one provider sitting under several critical functions
// through different direct suppliers -- the fourth-party you would miss.
MATCH (f:Function {critical:true})-[:SUPPORTED_BY|SUBCONTRACTS_TO*1..8]->(p:Provider)
WITH p, collect(DISTINCT f.id) AS functions
WHERE size(functions) > 1
RETURN p.id AS shared_dependency, p.country, functions
ORDER BY size(functions) DESC;

The second query is the one that earns its keep. It finds the provider that no single contract owner would flag, because each of them only sees their own direct supplier. That is precisely the concentration the RTS asks you to assess and that a per-contract review structurally cannot see.

Keeping it live, not just built

A graph populated once is a register with better plumbing. The RTS obligation is continuing: Article 5 turns on material changes, and the material changes that matter most are the ones your direct provider makes to its suppliers, often without asking you. So the contract terms and the data model have to interlock. The contract must require prior notification of subcontractor changes and give you rights to object and to terminate; the model has to have somewhere to put that notification the day it arrives, and a job that re-runs the concentration and depth queries when it does. Notification you cannot act on within your reporting windows is a clause, not a control.

This is where the exercise connects back to the rest of the resilience framework rather than sitting beside it. The chain you map is the same chain that determines whether you can stay inside the impact tolerances you have set for those functions, and third-party dependency is explicitly in scope of the ICT risk management framework itself — a point I laboured in the reading of Article 6. A subcontracting model that does not feed those two things is doing compliance theatre with a database attached.

Where firms will get this wrong

The predictable failure is to treat 2025/532 as a legal workstream and close it when the contracts are re-papered. The clauses will be correct and the picture will still be blind, because the blindness was never in the contract language. It was in the assumption that a chain of independent commercial relationships can be understood one relationship at a time. It cannot. The RTS has quietly made your supplier estate a monitoring system, and monitoring systems that run on documents fail silently — you find out they were wrong when the fourth party you never modelled goes dark and takes a critical function with it.