The first problem with “sub-processors under the Digital Operational Resilience Act (DORA)” is that it sounds simpler than the work really is. Teams hear the phrase and think vendor list. Supervisors see a service chain.
Under DORA Article 28(3) and Commission Implementing Regulation (EU) 2024/2956, the register has to show one information and communication technology (ICT) service, the direct contract behind it, and the downstream providers that sit in that chain.
In this article, “sub-processor” is used in the way most teams search for it; in Register of Information (RoI) terms, we are talking about subcontractors in an ICT service supply chain captured in B_05.02. The European Supervisory Authorities’ (ESAs’) 19 March 2025 RoI reporting FAQ helps because it speaks to the practical side and is clear about its status: useful clarification on a best-efforts basis, not formal legal interpretation.
| Question | GDPR-style sub-processor list | DORA RoI supply-chain view |
|---|---|---|
| What is being tracked? | Processing relationships | ICT service delivery chain |
| What is the anchor? | Processing activity or contract set | Direct contractual arrangement reference number plus the relevant ICT service |
| Which downstream parties matter? | Parties relevant to processing | Subcontractors that effectively underpin the ICT service supporting a critical or important function, plus the first extra-group leg in the intra-group case |
| What has to stay accurate over time? | Legal inventory completeness | Chain logic, identifiers, rank, recipient links, and scope decisions |
Where the subcontractor line actually sits
Most of the debate gets easier once you pin down the service chain. Under the Implementing Technical Standards (ITS) instructions for B_05.02, firms have to record all direct ICT providers, all intra-group ICT providers, and, for ICT services supporting critical or important functions, the subcontractors that effectively underpin those services.
The test is practical: the ITS and the March 2025 FAQ both point to subcontractors whose disruption would impair the security or continuity of service provision.
I would frame the scope test this way:
- Start with one direct contractual arrangement and one ICT service.
- Decide whether that service supports a critical or important function, or a material part of one.
- Check whether the downstream provider actually sits inside the delivery chain for that service.
- Apply the disruption test: would that provider’s failure impair the security or continuity of the service?
- If yes, it belongs in the reported chain. If no, it may still sit in internal third-party risk records, but it stays outside the RoI boundary for that service.
Copla Registry
DORA-ready Register of Information
Maintaining a complete RoI across providers, services, contracts, and subcontractors becomes difficult in spreadsheets. Copla Registry provides a structured environment built for DORA supervision and RoI reporting.
The supported function still matters first, which is why subcontractor scope starts with the function map, not the supplier list.
This decision is easier to defend when it rests on a few concrete pieces of evidence rather than a broad statement that a provider “seems important”. In practice, firms usually rely on a current service dependency view, the service description and contract wording, provider disclosures obtained through the direct provider, and internal continuity mapping showing that failure at that layer would affect the service. That is usually the difference between a scope judgment and a scope explanation.
One point is worth keeping straight because it creates a lot of confusion. The March 2025 FAQ says rank has no theoretical upper limit in the ICT service supply chain and also makes clear that not every downstream provider is reported. Scope still turns on the underpinning test, with one additional rule for intra-group chains.
B_05.02 is where the chain becomes reportable
The direct arrangement stays as the anchor even when the service runs through several providers.
Under the ITS instructions for B_05.02, providers in the same ICT service supply chain share the same contractual arrangement reference number and the same ICT service type; the ITS instructions for B_02.01 do not give external subcontractors separate RoI contract references for that same chain.
For subcontractor traceability, the minimum keys that make chains reportable (IDs, contract refs, function IDs) are what keep each downstream row tied to the service it belongs to.
B_05.02 mechanics: contract reference, rank and recipient logic
Most confusion starts when teams treat the subcontractor leg as if it were a new contract object.
In B_05.02 it is still the same service chain. The direct arrangement stays as the anchor, the direct ICT provider stays at rank 1, subcontractors sit at higher ranks, and several providers can share the same rank when the chain branches, all as set out in the ITS. Each row also has to point to the provider receiving that subcontracted service.
That is why the March 2025 FAQ’s explanation of recipient logic matters: the recipient is the provider at rank n-1 receiving the subcontracted ICT service from the provider at rank n.
One narrow reporting wrinkle is worth knowing because teams do trip over it: the ITS fill-in instruction for B_05.02.0060 says the rank-1 recipient field is left blank, while the March 2025 FAQ and European Banking Authority (EBA) Single Rulebook Q&A 2024_7284 indicate that firms may need to repeat the direct-provider code in reporting practice.
| B_05.02 field logic | Practical reading |
|---|---|
| Rank = 1 | Direct ICT provider in the service chain |
| Rank > 1 | Subcontractor in the same service chain |
| Recipient | Provider at rank n-1 receiving the subcontracted ICT service from the provider at rank n |
Example: a branched supply chain (rank + recipient pointers)
This is where the model becomes more useful than the terminology.
Using the mechanics in B_05.02 and the FAQ’s explanation of rank and recipient, a financial entity may have one direct contractual arrangement for one ICT service, with the direct provider at rank 1, two downstream providers at rank 2 both supporting that same direct provider, and one further provider at rank 3 supporting only one of those rank-2 firms.
The two rank-2 rows both point back to rank 1 as recipient. The rank-3 row points to the relevant rank-2 provider.
The shape is simple enough to draw and surprisingly easy to damage. One wrong recipient, or one provider captured under a brand rather than the legal entity, and the chain stops explaining the dependency it is supposed to show.
Where chain logic breaks first
The weak spots are usually mundane. Article 3(5) and 3(6) of the ITS require valid legal entity identifier (LEI) or European Unique Identifier (EUID) information for ICT providers that are legal persons and, where a service supports a critical or important function, require firms to secure those identifiers for in-scope subcontractors through the direct provider.
In practice, broken identifiers and broken recipient links are what make a subcontractor chain fail first, which is a very specific version of why chain data breaks when keys and relationships drift.
Move beyond spreadsheets for DORA RoI
Spreadsheets struggle with the RoI’s relational structure and validation rules. Copla Registry provides a structured environment for maintaining the register and generating ESA-ready outputs.
Intra-group services often hide the real external dependency
“Intra-group” sounds cleaner than it behaves. The contract may be internal while the technology layer doing the real work is outside the group.
A group service company signs the front contract, while hosting, identity or resilience sits with an external provider underneath.
That is why the RoI ITS requires all intra-group ICT providers in the chain and, where they use subcontractors, at least the first extra-group subcontractor even when the service does not support a critical or important function; the March 2025 FAQ repeats the same point in practical terms.
The group boundary is where chains go to disappear.
That is precisely why the ITS description of B_02.03 links intra-group contractual arrangements to the external contractual arrangements behind them, using contractual arrangement reference numbers, and why the FAQ’s example for B_02.03 explicitly uses that template to reconcile the internal leg with the external one.
“First extra-group subcontractor” is the point where an apparently internal service stops being internal.
Reassessment starts when the service changes
A first subcontractor assessment is rarely the hard part. The harder part is spotting when the service has changed and the old boundary no longer fits.
For ICT services supporting critical or important functions, DORA’s contractual requirements in Article 30 already push firms toward explicit subcontracting conditions and change handling.
Commission Delegated Regulation (EU) 2025/532 on subcontracting adds what practitioners need in real life: planning, due diligence, notice periods, approval or non-objection, risk assessment and ongoing monitoring for new subcontracting arrangements and material changes to existing ones.
Some firms keep the RoI in a relational system rather than in spreadsheet handoffs, a pattern also reflected in how the DORA register of information works in practice.
Change events that force a fresh scope test
| Change event | Why the scope decision may need to change |
|---|---|
| A new subcontractor enters the service chain | A new provider may now sit inside the delivery path for the reported ICT service |
| Hosting, resilience, security or identity moves to a different provider | A provider that was peripheral may now underpin continuity or security |
| The service moves to a new region or data-processing footprint | The chain behind the same service label may no longer be the same chain |
| The direct provider materially changes the service architecture or ICT service type | The original underpinning assessment may no longer fit the service being delivered |
| The supported function becomes critical or important, or the institution’s reliance on the service increases | A provider previously tracked internally may now cross the RoI threshold |
In my view, the cleanest operational rule is simple: reassess subcontractor scope whenever the service chain changes in a way that could change the answer to the underpinning test.
Visibility usually runs through the direct provider and the contract chain rather than through direct contractual privity with every downstream firm, which sits comfortably with the subcontracting regulatory technical standard (RTS) and with the ITS requirement to obtain in-scope subcontractor identifiers through the direct provider.
Why supervisors care about the downstream layer
The downstream layer matters because the RoI is supervisory data. Recital 1 of the RoI ITS says the register information is essential for internal ICT risk management, effective supervision and the annual process used by the ESAs to designate critical ICT third-party service providers.
The systemic angle goes lower into the chain than many firms expect: Commission Delegated Regulation (EU) 2024/1502 on critical ICT third-party provider designation criteria brings dependence on the same subcontractors into the assessment of potential systemic impact.
That is why supervisory questions on subcontractors tend to converge.
Reviewers want to know why provider A is in scope while provider B is out, what evidence supports the view that A effectively underpins the service, which changes send the chain back through review, and how the firm prevents an intra-group wrapper from hiding an external dependency. Once the same downstream provider appears across several direct arrangements, the concentration picture changes as well.
A defensible answer is usually a narrow one. Anchor the chain to one direct contractual arrangement, one ICT service and one supported function. Use the ITS and the March 2025 FAQ to decide which downstream providers effectively underpin delivery.
Then keep that decision under change control, because the service will move long before anyone admits the chain has changed.
