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.

Article 28 and Implementing Regulation 2024/2956 are binding rules. The data dictionary, source ownership model, exception log, and suggested monthly checks below are practical controls for meeting those rules; DORA does not prescribe those internal tools or that monthly cadence.

Inventory the systems that already hold authoritative data and identify gaps that must be corrected at source. Manually retyping rows from contract owners creates avoidable naming, identifier, and version errors.

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. Mark every field as mandatory, conditional, or optional from the template instructions; do not treat a populated optional field as a substitute for a missing mandatory one.

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. 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.

Identify and correct register validation failures before the data 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.

Keep the yearly reporting duty separate from event-driven notifications. Financial entities must also inform the competent authority in a timely manner about planned contractual arrangements for ICT services supporting critical or important functions and when an existing function has become critical or important; the applicable authority process determines the submission channel and any case-specific timing.