DORA does not stop at the provider you signed with. For any ICT service supporting a critical or important function, the Register of Information has to record the chain of subcontractors beneath that provider — the hosting underneath the SaaS, and whoever runs that. The point is concentration risk: several arrangements that look independent on paper can rest on one data centre or one cloud region. Mapping only your direct suppliers is the single most common reason a register is complete on its face and wrong in substance.
Why DORA cares about the chain
Operational resilience isn't about the vendor whose name is on the contract — it's about everything that vendor depends on. A payments provider might run on a single cloud region; if that region fails, so does the service, no matter how resilient the direct provider looks on paper. DORA reflects this by asking for the full ICT subcontracting chain wherever a chain supports a critical or important function.
This is the "Nth-party" problem. Your direct supplier is the first party; their subcontractor is the second; that firm's dependency is the third. Risk doesn't stop at tier one, and neither does DORA's interest in it.
What the register captures
In the Register of Information, the subcontracting chain lives in template B_05.02. Each row ties an arrangement to a subcontractor with a rank in the chain, the subcontractor's LEI and name, and a description of what it provides:
| Column | What it records |
|---|---|
arrangement_ref | The contractual arrangement this subcontractor sits under. |
rank | Where in the chain it sits — first-level subcontractor, second, and so on. |
provider_lei / name | The subcontractor identified by its Legal Entity Identifier. |
service_description | What the subcontractor actually provides to the chain. |
The rank matters: it's what turns a flat list of vendors into an actual chain a supervisor can trace from your critical function down to the firm that could break it.
Where concentration risk hides
Map enough chains and a pattern appears: different providers, resolving to the same underlying dependency. Three "independent" SaaS vendors that all run in one cloud region aren't three points of resilience — they're one. Concentration risk is invisible at the contract level and only shows up once the chain is drawn. That's the entire point of the exercise, and the reason a register that stops at tier one is worse than useless: it looks complete while hiding the real exposure.
The most common gap isn't a missing contract — it's a missing link. A firm records its direct provider diligently and never captures who that provider leans on. For anything supporting a critical function, an undisclosed subcontractor is a hole in the register exactly where it matters most.
Substitutability and exit
Mapping the chain feeds directly into the resilience assessment (B_07.01): how substitutable is this arrangement, could you reintegrate the service, what's the impact if it's discontinued, and is there an exit plan? A hard-to-substitute, sub-outsourced arrangement supporting a critical function is precisely the concentration a supervisor will ask about — so it needs an answer before they do.
How Qgentic maps it
Qgentic DORA assembles the chain from your contract and vendor data, and when a subcontractor supporting a critical function isn't disclosed, it drafts the outreach to your provider, parks the run as input-required, and merges the reply into the supply chain when it arrives — rather than filing a register with a known gap. You can watch it park and resume on an undisclosed subcontractor in the live demo.
Qgentic maps the chain from your contracts and chases an undisclosed subcontractor before the register is filed.
See the DORA platform Try the live demo