The DORA register of information, without the spreadsheet drift

The Digital Operational Resilience Act (DORA) has applied to EU financial entities since 17 January 2025. Of everything it asks for, the register of information is one of the most concrete: a structured record of every contractual arrangement you have with ICT third-party service providers. It sounds like an inventory exercise. In practice it tests whether your procurement, IT, risk and business teams share one view of who supports what.

What the register is

Article 28 of DORA requires financial entities to maintain and keep up to date a register of information on all contractual arrangements for the use of ICT services provided by ICT third-party service providers. The register is kept at entity level and, for groups, at sub-consolidated and consolidated level.

The register serves several audiences. Internally, it is the backbone of ICT third-party risk management: you cannot manage concentration, exit or sub-contracting risk for arrangements you have not listed. Externally, competent authorities can ask for the full register, and entities report on new arrangements regularly. Supervisors also use register data across the sector, including to inform the designation of critical ICT third-party providers at EU level.

The content and format are set out in implementing technical standards as a series of linked templates. The logic is relational rather than a single flat list.

What it contains, at a high level

Think of the register as a set of connected facts:

• The entities within scope, including which group entities use which ICT services.
• The contractual arrangements: each contract with an ICT third-party service provider, its reference, dates, governing law, notice periods and the type of arrangement.
• The providers, identified consistently, with information about where they are established and how they relate to a group.
• The ICT services provided under each arrangement, described by type.
• The functions of the financial entity that those services support, and whether each function is critical or important.
• The supply chain: sub-contractors that effectively underpin ICT services supporting critical or important functions.
• Assessments of those services, such as substitutability, the impact of discontinuing them, and whether an exit is feasible.

The key word is linked. A single contract can cover several services; a single service can support several functions; a function's criticality changes how much information you must hold about the providers behind it.

Where registers go wrong

Most first registers were built under time pressure in a spreadsheet, populated from procurement exports and emails to business owners. The problems appear afterwards.

The spreadsheet drifts from the contracts

Contracts are renewed, amended and terminated throughout the year. If the register is a separate file maintained by a separate team, every change has to be noticed and retyped. Within months, notice periods, end dates and provider details no longer match the signed documents.

Sub-contractors are missing or stale

Supply-chain information sits with the provider. It arrives late, in inconsistent formats, and changes when the provider changes its own suppliers. Registers often list the direct provider in detail and the sub-contractors not at all, which is precisely where concentration risk hides.

Function mapping is vague

Linking ICT services to the functions they support requires input from people who understand the business process, not only the contract. Without a shared list of functions, each contributor describes them differently, and "critical or important" becomes a label applied by instinct rather than by criteria. That undermines tiering, exit planning and testing priorities.

Ownership is unclear

Procurement owns the contract, IT owns the service, the business owns the function and risk owns the assessment. A register that belongs to everyone is maintained by no one. When ownership is not explicit per field, gaps persist.

The register lives apart from everything else

The same facts appear in your business impact analysis, continuity plans and outsourcing policy. When each holds its own copy, they disagree.

A connected model of suppliers, contracts, services and functions

The durable fix is to stop treating the register as a document and start treating it as a view of data you already need to manage. That means modelling the underlying objects once and linking them:

1. Suppliers as records, with identifiers, tiering and screening history.
2. Contracts as records attached to suppliers, with lifecycle dates, clauses, obligations and service levels kept current as part of normal contract management.
3. Services delivered under those contracts, linked to the assets they run on.
4. Functions or processes, each with its impact analysis and recovery objectives, linked to the services and suppliers they depend on.
5. Sub-contractors as suppliers in their own right, linked to the services they underpin.

With that structure, criticality flows from the function to the services and suppliers behind it, instead of being typed into a column. A contract change updates the register because the register reads from the contract. Gaps become visible as missing links rather than blank cells, and ownership can be assigned per record type.

Practical habits that help with any tool:

• Agree the list of functions first. Mapping is only as good as the vocabulary it maps to.
• Write down your criticality criteria and apply them in the impact analysis, not in the register.
• Ask providers for sub-contracting information at onboarding and renewal, and record when you last received it.
• Reconcile against the signed contract, not the procurement system, at least for arrangements supporting critical or important functions.
• Run a quality check before every submission: missing identifiers, expired contracts still listed, functions without a criticality decision.

Where ILSERIS fits

ILSERIS keeps third parties, contracts, assets, business impact analysis and recovery plans as linked records in one data model. Contracts carry their lifecycle, obligations and service levels; suppliers carry tiering, questionnaires and periodic screening; the impact analysis carries recovery objectives and a dependency map. The register of information is then a question you ask of data that is maintained anyway, rather than a spreadsheet maintained beside it.

This article is general information, not legal advice.