How to build a DORA register of information

Start with the joins required by the ITS. The register links data across templates using the contractual arrangement reference number, identifiers for financial entities and ICT third-party service providers, the function identifier, and the type of ICT services. Those keys should be designed before teams begin collecting rows.

Create a register data dictionary that names the source system for each field, the accountable owner, the refresh trigger, the evidence location, and the transformation rule used for export. Do not let each business unit create its own provider names, function names, or contract identifiers.

The fastest way to create an unreliable register is to ask contract owners to type rows manually. Instead, inventory the systems that already hold authoritative data and identify the gaps that must be remediated at source.

At minimum, reconcile procurement and contract lifecycle management records, vendor master data, legal entities and branches, business-service or process inventories, ICT asset and service catalogues, outsourcing registers, data-location records, risk assessments, audit plans, incident and continuity records, and exit-plan repositories.

Map the register in passes that follow the ITS structure. First load the entity scope, then contracts, then signing parties and users, then providers and supply-chain links, then functions, and finally the assessment template for ICT services supporting critical or important functions.

Each mapped field should have one accountable source. If two systems disagree, create a remediation ticket against the source system instead of masking the discrepancy in the export layer.

A compliant-looking row can still be useless if it cannot explain what service is provided, which financial entity uses it, which function it supports, and what happens if the service is disrupted. Treat those connections as the core of the build.

For each contract, require the contract owner, ICT service owner, business-function owner, procurement owner, and ICT third-party risk owner to approve the mapping. Legal should validate contract terms; the function owner should validate criticality or importance; ICT risk should validate service, provider, subcontractor, audit, and exit-plan fields.

Intra-group ICT providers still matter for the register. The ITS includes specific templates for intra-group arrangements and for reconciling intra-group contracts with external ICT third-party contracts where the group service provider relies on an external provider.

Subcontractors should not be loaded indiscriminately. The ITS requires subcontractor information for those that effectively underpin ICT services supporting critical or important functions or material parts of them. The subcontracting RTS is useful for designing the intake questions because it focuses on chain length, locations, data, concentration, transferability, continuity impact, monitoring, and approval of new or changed subcontracting.

The register should fail validation before it reaches a regulator or senior management reviewer. Build automated checks for mandatory fields, cross-template joins, identifier validity, controlled values, dates, and logical consistency.

Keep a data-quality exception log with owner, issue, affected template, remediation action, due date, and evidence of closure. That log is useful evidence because it shows active maintenance rather than a one-time spreadsheet exercise.

DORA says competent authorities may request the full register or specified sections, and financial entities must report at least yearly on new arrangements, provider categories, arrangement types, ICT services, and functions being provided. Build export readiness into normal maintenance rather than treating it as an annual clean-up.

Export readiness means the current register can be reproduced from controlled sources, explained field by field, reconciled to contract and provider evidence, and filtered for a competent-authority request without manual reconstruction.