DORA register of information template for ICT third-party arrangements

Build the register as linked tables. The official ITS uses predefined columns with an indefinite number of rows, and the same contract, entity, provider, function, and ICT service identifiers must reconcile across templates.

Use the contractual arrangement reference number as the contract key. Use the financial entity LEI, ICT third-party provider identifier, function identifier, and ICT service type code to connect each contract to the entity using the service, the provider chain, the supported function, and the assessment record. Each data element holds one value; where several values are valid, add a row for each value as the ITS requires.

Scope the register before mapping fields. Include every direct provider arrangement for an ICT service, whether or not procurement calls it outsourcing. Add subcontractors where they effectively underpin an ICT service supporting a critical or important function or a material part of one. Keep non-ICT goods and services outside this register unless the arrangement also contains an ongoing ICT service. Where an ICT intra-group provider uses subcontractors, include at least the first extra-group subcontractor even when the ICT service does not support a critical or important function or material part.

Treat every row as a statement about a specific ICT service under a specific contractual arrangement. If one contract covers several ICT service types, supported functions, countries of data location, or processing locations, add the needed rows rather than compressing multiple values into one cell.

For provider identification, legal-person ICT third-party service providers should use a valid and active LEI or EUID, and where available both. Third-country providers are identified with LEI only. Natural persons acting as ICT service providers may use alternative identification codes under the template rules.

The register must distinguish contractual arrangements that support critical or important functions from those that do not. The function record should be specific enough to connect a licensed activity, the function performed for that activity, the entity using the service, continuity targets, and the impact of discontinuing the function.

For ICT services supporting critical or important functions or material parts of them, B_07.01 adds the assessment layer. This is where the register should show substitutability, the reason a provider is not substitutable or is difficult to substitute, last audit date, exit-plan existence, reintegration possibility, discontinuation impact, and whether alternative ICT third-party providers have been identified.

For groups, the register can cover entity, sub-consolidated, and consolidated levels, but it still needs enough structure for each financial entity to meet its own register and reporting obligation. The parent undertaking determines which entities are included at sub-consolidated and consolidated level under the relevant sectoral Union financial-services legislation.

Do not stop at the first intra-group service provider when the ICT service supply chain continues outside the group. The ITS requires reconciliation between intra-group contractual arrangements and contracts with external ICT third-party providers when part of the supply chain is intra-group.

The register should be ready both for daily ICT third-party risk management and for supervisory extraction. DORA requires financial entities to report at least yearly on new ICT-service arrangements, provider categories, arrangement types, ICT services, and functions provided. It also requires the full register, or requested sections, to be made available to the competent authority on request.

Avoid invented deadline fields. Use only dates that the contract, audit evidence, function assessment, or authority request supports. Where the ITS gives a specific template default value, use that value exactly and keep the evidence explaining why it was used.