DORA Register of Information Import and Build Workflow

Maintain the register of information as a controlled data product throughout the reporting cycle. Pull from systems that already own the facts: procurement and contract repositories for arrangements, vendor master data for provider identity, service catalogues for ICT service types, enterprise architecture or CMDB records for systems and dependencies, business-service inventories for functions, and third-party risk tools for due diligence, audit, exit, and concentration assessments.

Each imported record should carry a source owner, source-system reference, extraction date, and reconciliation status. A contract record without a signed arrangement, a provider without a reliable identifier, or an ICT service without an accountable business function should remain in a remediation queue instead of being silently exported.

Run an intake scope test before importing. Confirm that the arrangement supplies a digital or data service through ICT systems on an ongoing basis, rather than only non-ICT goods or traditional analogue telephone service. Then identify every entity using the service; a group contract signed centrally does not remove the entity-level, sub-consolidated, and consolidated register relationships.

The build should preserve the relational structure in the ITS. Do not flatten contracts, providers, services, and functions into one undifferentiated row: the same contract can contain multiple ICT services, a service can support multiple functions, and a provider chain can include direct providers, intra-group providers, and subcontractors.

Use the official linking keys as the backbone of the import: contractual arrangement reference number, financial entity and provider identifiers, function identifier, and ICT service type. These keys should be generated or confirmed before enrichment fields are added.

Validation should catch relationship errors before they become supervisory data quality issues. Run validation after every import and again before export. Trace every complete register row from the financial entity to the contract, ICT provider, ICT service, supported function, supply chain, and assessment evidence.

Use blocking errors for missing mandatory identifiers, broken cross-template keys, impossible provider ranks, missing critical-function assessments, and subcontractor chains that cannot be reconciled to a direct provider and service. Validate each data element as a single value; when more than one value is valid, create the additional row required by the ITS instead of placing a list in one cell.

Subcontracting should not be imported only from free-text contract clauses. The register build needs a provider-confirmed subcontracting inventory for ICT services supporting critical or important functions or material parts of those functions, plus governance evidence showing how the financial entity assessed and approved the chain. Also include at least the first extra-group subcontractor after an ICT intra-group provider, even for services that do not support critical or important functions.

For each subcontracted service, reconcile the supplier disclosure to the contract conditions, risk assessment, service location, data location, concentration assessment, access and inspection rights, and exit or transferability analysis.

Before export, route exceptions to accountable owners instead of editing them away. Legal owns contract interpretation, procurement owns arrangement completeness, vendor-risk owns provider and due diligence evidence, business owners own function criticality, ICT risk owns service and resilience assessments, and group reporting owns consolidated consistency.

The export pack should make the register explainable without internal project memory. Keep the exported file, validation report, source-to-template mapping, exception log, owner approvals, provider attestations or disclosures, contract evidence, function-criticality rationale, subcontracting assessment, and change log together.