DORA: build the ICT third-party register from the real information system

The DORA register of information should not be designed as a regulatory file that is completed once a year. The Regulation requires financial entities to maintain and update a register covering contractual arrangements for the use of ICT services provided by ICT third-party service providers, at entity level and, where relevant, at sub-consolidated and consolidated levels.1 Implementing Regulation 2024/2956 turns that obligation into a set of linked templates covering contracts, entities using the services, providers, ICT services, functions, subcontracting chains and assessments.2

The operational consequence is significant: a reliable register is better treated as a regulatory view over data already governed across the information system than as a standalone spreadsheet. This is Cybercoria’s analysis, not a literal DORA requirement. The Regulation does not prescribe any particular technical means for maintaining this register.

Object	Question to answer	Relevant register area
Function	Which business activity depends on the ICT service?	B_06.01
ICT service	Which service is actually consumed?	B_02.02 / B_05.02
Contract	Which arrangement governs that service?	B_02.01 / B_02.02
Provider	Which legal entity provides the service?	B_05.01
Subcontractor	Who effectively underpins delivery?	B_05.02
Assessment	What risk is attached to a critical or important service?	B_07.01

The DORA register covers more than critical providers

Article 28(3) requires a register relating to all contractual arrangements for the use of ICT services provided by ICT third-party service providers.1 The same paragraph then requires those arrangements to be appropriately documented while distinguishing those that cover ICT services supporting critical or important functions from those that do not.1

This distinction prevents a common scope error: limiting the register to providers labelled “critical”. The EBA reporting FAQ explicitly confirms that a provider which does not support a critical or important function must still be identified where its contractual arrangement is within the scope of Article 28.5

Templates B_02, B_05 and B_06 have to meet

Implementing Regulation 2024/2956 structures the register as a series of predefined templates.2 The most important architectural point is how those templates refer to one another.

B_02.01 assigns a unique reference to each contractual arrangement with a direct ICT third-party service provider. B_02.02 then captures specific information at the maximum level of granularity possible, linking the arrangement to the ICT service and the function it supports.2 Where one arrangement includes several ICT services supporting several functions, the instructions require as many rows as needed to represent the combinations.2

B_05.01 identifies ICT third-party service providers, including direct providers, intra-group providers, subcontractors reported in the service supply chain and relevant ultimate parent undertakings.2 B_06.01 identifies functions and their criticality or importance.2

The data model therefore does not assume “one provider = one contract = one function”. One provider may have several arrangements; one arrangement may cover several services; one service may support several functions; and several entities in a group may use the same service.

Stable join keys matter more than the final spreadsheet

A contract needs a durable reference. A financial entity must be identified according to the model’s rules, including use of its LEI where required. A provider must use the identifier expected by the ITS. A function should keep a stable identifier even if its display name changes. The ICT service type must align with the closed lists defined by the model.2

Cybercoria therefore recommends treating the register as a mapping layer between authoritative sources:

• contract references, dates, costs and governing law come from contract or procurement records;
• the provider’s legal identity comes from the vendor master;
• functions and their criticality come from business or continuity repositories;
• consumed ICT services come from service catalogues or architecture records;
• entities using the service come from the organisation and consolidation perimeter;
• third-party risk assessments come from the risk-management process;
• subcontracting information comes from contracts, annexes, provider notifications and risk reviews.

DORA does not prescribe this source split. Its purpose is to avoid manually maintaining the same fact in several places until the versions diverge.

Read also
Information system mapping: turning ANSSI’s five steps into an operational plan →

B_05.02 changes the question: who actually delivers the service?

Template B_05.02 identifies the ICT service supply chain and ranks the providers participating in it.2 For ICT services supporting a critical or important function, that chain must include subcontractors which effectively underpin delivery, meaning subcontractors whose disruption would impair the security or continuity of the service provision.2

The EBA FAQ confirms that logic and states that there is no theoretical limit to the rank of an ICT third-party service provider in a supply chain.5 That does not mean every supplier of every supplier must be mapped without distinction. The scope depends on the ICT service and, for critical or important functions, on subcontractors that effectively underpin it.

Delegated Regulation 2025/532 adds a risk-management dimension. When relevant subcontracting is used, the financial entity must consider elements such as the length and complexity of the subcontracting chain, the nature of data shared, the location of subcontractors and the places from which ICT services are provided or data are processed and stored.4 It also makes clear that relying on a provider’s assessment of its subcontractors does not remove the financial entity’s final responsibility for its own obligations.4

For a CIO or CISO, the operational test is straightforward: can the organisation start from an important function and identify the services, contracts, direct providers and subcontracting dependencies capable of interrupting it?

Criticality belongs to the function, not to a vendor label

B_06.01 identifies the financial entity’s functions and whether they are critical or important; B_02.02 links those functions to the relevant ICT services.2 Keeping those objects separate matters.

A “critical vendor” flag in procurement is not enough. Criticality comes from the supported function and the entity’s context. The same provider can deliver one service supporting a critical function and another service that does not have that level of importance.

A more robust data model therefore keeps the chain function → ICT service → contractual arrangement → provider instead of attaching every relevant attribute to the provider record. This is also a useful information-system-mapping principle: dependencies carry more decision value than an asset list alone.

Context
NIS2 Article 21: what information system mapping can actually help demonstrate →

B_07.01 does not prove that third-party risk is controlled

Template B_07.01 covers assessment information for ICT services provided by third parties where those services support a critical or important function or a material part of it.2 It includes risk-related and substitutability information.

The register, however, does not replace the third-party risk-management process.

Delegated Regulation 2024/1773 requires the policy for contractual arrangements supporting critical or important functions to cover the lifecycle of those arrangements, including responsibilities, planning, risk assessment, due diligence, approval, monitoring, audit and exit strategies.3 Completing a field in B_07.01 therefore does not demonstrate that due diligence was adequate, that an exit strategy works, or that audit rights are operational.

The register is a structured reference used to know and connect facts. Evidence remains in contracts, audit reports, risk decisions, continuity tests, due-diligence files and the other systems that actually record those controls.

Changes in the information system should drive register maintenance

DORA uses the language of maintaining and updating the register.1 An annual campaign based on urgent questionnaires may produce a submission, but it weakens data quality between reporting cycles.

A more durable operating model is to define events that trigger a review of the relevant register data:

1. a new ICT contract or amendment;
2. a new service consumed under an existing arrangement;
3. a change of provider legal entity or identifier;
4. a change in the supported function or its criticality;
5. a new relevant subcontractor in a critical service chain;
6. a change in the country of service provision, processing or storage;
7. a new risk assessment, audit or substitutability decision;
8. termination of an arrangement or replacement of a service.

The objective is not to turn every technical change into regulatory administration. It is to define which changes can make a DORA data field wrong.

Referential checks should come before regulatory submission

The relational structure allows useful checks before a register is submitted: does each provider identifier referenced in B_02.02 exist in B_05.01? Does each referenced function exist in B_06.01? Is a B_05.02 chain tied to the correct contractual arrangement and ICT service type? Is B_07.01 populated where the model requires it? Are contractual arrangement references unique and stable?2

The EBA has published reporting FAQs devoted to population and validation questions, which confirms that data quality and model consistency are operational issues in their own right.5

These checks do not prove overall DORA compliance. They only show that the register itself is more coherent.

The decisive test is to trace one function end to end

To determine whether the register is anchored in the real information system, choose one critical or important function and try to answer without rebuilding the chain manually:

Which entity uses the service? Which ICT service supports the function? Which contractual arrangement governs it? Which legal entity provides it? Which subcontractors effectively underpin that service? Where are data processed or stored when that information is required? Which risk and substitutability assessment is associated with it?

If all those answers exist but live in six disconnected repositories, the first task is not “fill in the register”. It is to establish stable identifiers, data owners and synchronisation rules.

That is where the DORA register becomes useful beyond reporting: not because it proves resilience, but because it forces the organisation to make the chain function → service → contract → third party → dependencies explicit. The next action is to test that chain on one critical function, identify the authoritative source for every fact and record every broken join. Those breaks show where the register is most likely to become inaccurate after the next change.