DORA Register of Information Import and Build Workflow

Treat the register of information as a controlled data product, not a spreadsheet assembled at the end of a reporting cycle. The intake should 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.

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. A complete register row is not just a populated field set; it must be traceable 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.

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.

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.