The DORA register of information: what the ESAs actually ask for, and where the data has to come from

What the register is (and is not)

Article 28(3) of DORA requires every financial entity to maintain a register of information on all contractual arrangements for the use of ICT services provided by ICT third-party providers, at entity, sub-consolidated and consolidated level. The European Supervisory Authorities prescribe the template through implementing technical standards; competent authorities collect it.

What the regulation does not do is tell you where the data lives. For most entities it lives in three or four systems and a shared drive: procurement holds the contracts, architecture holds the service map, business continuity holds criticality, and the risk team holds — if anyone does — the exit and substitutability assessments.

The register is an output. If the provider, the service it delivers and the function it supports are linked records, the register is a projection of them. If they are not, it is a quarterly project.

The columns, grouped by source record

Grouping the template’s columns by the record that should own them makes the work visible.

Column group	Source record	Typically lives in…
Provider identity, LEI, contract refs	Third party (registry)	Procurement, contract folder
ICT services delivered	IT service linked to the provider	Architecture wiki, nobody’s sheet
Functions supported, criticality	Business solution ↔ IT service links	Business continuity team
Substitutability, exit	Risk register + treatment plan	Risk team, if anywhere

Providers and the services they deliver

Start from what the provider actually runs for you, not from the contract. A cloud provider delivers a handful of ICT services; each of those services underpins one or more of your business functions. Modelling that as records — provider → IT service → business solution — is the single step that turns the register from a document into a query.

Functions supported, criticality, substitutability

Criticality belongs on the function (the business solution), not on the contract: the same provider can support a critical payments flow and an internal wiki. Substitutability and exit are risk statements — capture them as risks with a treatment plan and an owner, and the register’s columns fill themselves.

Producing it without a spreadsheet

When providers, services and solutions are linked records with owners, the register is a projection. The remaining manual work is the contractual detail — which is exactly the part that should be manual, because it is a legal judgement.

Checklist

• Every ICT provider exists as a third-party record with a type and a status
• Every service a provider delivers is an IT service linked to it
• Every IT service in scope rolls up to a business solution with an owner
• Criticality is set on the solution, not guessed per contract
• Exit and substitutability are risks with treatment plans, not paragraphs