--- title: "DORA Register of Information Import and Build Workflow" canonical_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/roi-import-and-build-workflow" source_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/roi-import-and-build-workflow" author: "Sorena AI" description: "Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks." published_at: "2026-05-09" updated_at: "2026-05-26" keywords: - "DORA register of information" - "DORA ROI workflow" - "ICT third-party register" - "DORA contractual arrangements" - "ICT service supply chain" - "DORA subcontracting" - "DORA" - "register of information" - "ICT third-party risk" - "contractual arrangements" - "subcontracting" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA Register of Information Import and Build Workflow Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks. *Workflow* *EU DORA* ## DORA Register of Information Import and Build Workflow A practical workflow for turning source-system records into a DORA register of information that preserves the links between entities, contracts, ICT providers, ICT services, functions, subcontractors, and assessment evidence. Use it when procurement, outsourcing, vendor-risk, legal, ICT risk, service ownership, and group reporting teams need one governed build process before competent-authority request or annual reporting. DORA requires financial entities to maintain and update a register of information for contractual arrangements on ICT services provided by ICT third-party service providers. This workflow explains how to import source-system data, map it to the official register templates, validate the relationships, and retain evidence that supports the exported register. ## Start with the source-system intake 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. - Procurement intake: contract reference, arrangement type, signing entity, direct ICT third-party service provider, renewal or termination terms, and whether the arrangement includes ICT services. - Vendor master intake: legal name, LEI or EUID where applicable, country, parent undertaking, intra-group status, and whether the provider is direct, intra-group, subcontractor, or parent. - Service intake: ICT service description, official service type identifier, service owner, supported entity, supported function, data processed or stored, processing and service locations, and SLA or service-level evidence. - Function intake: financial entity LEI, licensed activity, function name, function identifier, critical or important function assessment, and impact of discontinuing the function. - Risk intake: due diligence result, information-security assurance, concentration assessment, audit date, substitutability, exit plan, reintegration possibility, and alternative provider status. Sources for this answer: - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 28 requires the register to cover contractual arrangements for ICT services and distinguishes critical or important functions. - [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - The ITS explains that the register templates use linked open tables and predefined columns for contractual arrangements, entities, providers, services, functions, and assessments. ## Map imported records to the official 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. - Create the maintaining-entity and in-scope entity records before importing arrangements, so every downstream record can link back to the right entity, sub-consolidated, or consolidated scope. - Assign one unique contractual arrangement reference number for each direct ICT third-party arrangement, then reuse that reference across the arrangement, signer, provider, service, supply-chain, and assessment templates. - Split general contract facts from service-specific facts: general arrangement data belongs with the contract, while the ICT services, supported functions, notice periods, data sensitivity, and service-specific details belong with the service layer. - Build provider records once, then reference them wherever they appear as direct providers, intra-group providers, subcontractors, or ultimate parent undertakings. - Generate function identifiers from the financial entity, licensed activity, and function combination, and use the same identifier when mapping ICT services to critical or important functions. - For each critical or important function, create assessment records for the relevant ICT service and provider relationship, including substitutability, last audit, exit plan, reintegration, discontinuity impact, and alternative provider status. Sources for this answer: - [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - The ITS identifies the four linking keys used across templates: contractual arrangement reference number, entity and provider identifiers, function identifier, and ICT service type. - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 28 frames ICT third-party risk management around the nature, scale, complexity, importance, and criticality of ICT dependencies. ## Validate contracts, providers, services, functions, and subcontractors before export 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. - Identifier checks: LEI or EUID is present where the ITS requires it, provider records are active and unique, country codes and service type identifiers use the expected controlled values, and no provider has conflicting legal names across sources. - Contract checks: every service-specific record links to an existing contractual arrangement reference number; each arrangement has a signing entity, direct ICT third-party provider, arrangement type, and written-contract evidence. - Function checks: every ICT service that supports a critical or important function links to a valid function identifier and the corresponding assessment record. - Supply-chain checks: the direct provider is rank 1, subcontractors have ranks greater than 1, providers in the same chain share the contractual arrangement reference and ICT service type, and intra-group-to-external chains are reconciled. - Risk checks: critical or important function services have evidence for substitutability, exit planning, last audit or no-audit marker, reintegration possibility, discontinuity impact, alternative provider assessment, and concentration-risk review. - Change checks: material contract changes, new ICT services, changed supported functions, new subcontractors, changed processing locations, or changed criticality status reopen the build record for approval. Sources for this answer: - [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - The ITS requires direct providers to be rank 1 and subcontractors to have ranks higher than 1 in the ICT service supply chain. - [Delegated Regulation (EU) 2024/1773 on ICT third-party contract policy](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - The RTS requires policies to cover planning, risk assessment, due diligence, approval, monitoring, documentation, record-keeping, exit, and termination for critical or important function arrangements. ## Handle subcontracting data as a separate governed workstream 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. - Capture whether subcontracting is permitted for the ICT service supporting a critical or important function and the conditions that apply. - Record subcontractors that effectively underpin the service, including those whose disruption would impair service security or continuity. - Assess the length and complexity of the subcontractor chain, the nature of data shared, service and data locations, group relationship, supervisory or oversight status, concentration to one or a few subcontractors, transferability impact, and continuity impact. - Require evidence that the ICT third-party service provider can identify subcontractors, notify the financial entity, provide assessment information, and maintain contractual rights that let the financial entity and authorities access and inspect where required. - Keep approval records for new subcontracting arrangements and material subcontracting changes before they are promoted into the export-ready register. Sources for this answer: - [Delegated Regulation (EU) 2025/532 on DORA subcontracting assessments](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng?ref=sorena.io) - The RTS specifies elements to assess when ICT services supporting critical or important functions, or material parts of them, are subcontracted. - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 29 requires financial entities to assess subcontracting chains and their impact on monitoring and supervisory access. ## Govern the build and keep export evidence 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. - Approval gate: no export until blocking validation errors are resolved or explicitly risk-accepted by the responsible governance forum. - Evidence gate: each material field has a traceable source, such as signed contract, addendum, provider disclosure, service catalogue record, function assessment, audit report, exit plan, or risk assessment. - Governance gate: management-body and senior-management reporting receives the unresolved critical or important function gaps, concentration-risk concerns, subcontracting concerns, and exit-plan gaps. - Export gate: the final dataset uses the official template structure, controlled service taxonomy, stable identifiers, and source-system reconciliation status. - Rebuild triggers: new or changed ICT arrangements, provider identity changes, new ICT services, criticality changes, subcontractor changes, audit findings, exit-plan changes, and competent-authority requests. Sources for this answer: - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 28 requires the register to be made available to competent authorities on request and requires planned critical or important function arrangements to be notified in a timely manner. - [Delegated Regulation (EU) 2024/1773 on ICT third-party contract policy](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - The RTS requires governance responsibilities, monitoring, documentation, record-keeping, audit access, and exit planning for ICT services supporting critical or important functions. - [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - The ITS defines the official register template families and the data relationships that an export-ready register must preserve. *Recommended next step* *Placement: before sources* ## Turn source-system records into an export-ready DORA register Sorena can help convert contract, provider, service, function, subcontractor, and risk-assessment records into a governed register build with source mapping, validation checks, and evidence records. - [Open Research Copilot for DORA](/solutions/research-copilot.md): Ask source-linked questions about the register templates, ICT service supply-chain relationships, subcontracting evidence, and export checks cited on this page. - [Talk through implementation](/contact.md): Review your DORA register source systems, template mapping, validation errors, and export evidence approach with Sorena. ## Primary sources - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Core DORA source for Article 28 register duties, ICT third-party risk management, contract assessments, concentration-risk assessment, and key contractual provisions. - Quote: "register of information" - [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Official ITS source for the register template structure, linking keys, provider identifiers, supply-chain ranks, function identifiers, service types, and assessment fields. - Quote: "standard templates for the register of information" - [Delegated Regulation (EU) 2024/1773 on ICT third-party contract policy](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - RTS source for governance, due diligence, contractual clauses, monitoring, documentation, record-keeping, audit access, and exit planning for ICT services supporting critical or important functions. - Quote: "contractual arrangements on the use of ICT services" - [Delegated Regulation (EU) 2025/532 on DORA subcontracting assessments](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng?ref=sorena.io) - RTS source for assessing subcontracting chains that support critical or important functions or material parts of those functions. - Quote: "subcontracting ICT services supporting critical or important functions" ## Related Topic Guides - [DORA Critical or Important Functions: mapping ICT dependencies and evidence](/artifacts/eu/digital-operational-resilience-act/critical-and-important-functions.md): How DORA critical or important functions affect ICT service mapping, third-party contracts, register-of-information records, incidents, testing, and evidence. - [DORA deadlines and compliance calendar for financial entities](/artifacts/eu/digital-operational-resilience-act/deadlines-and-compliance-calendar.md): Calendar the grounded DORA dates and recurring evidence: 17 January 2025 application, incident reporting clocks, register updates, annual reporting, TLPT cadence, and CTPP oversight milestones. - [DORA ICT Third-Party Contract Remediation Workflow](/artifacts/eu/digital-operational-resilience-act/contract-remediation-workflow.md): A DORA workflow for remediating ICT third-party contracts covering critical or important functions, subcontracting, audit rights, exits, register updates, and evidence. - [DORA ICT Third-Party Contracts FAQ](/artifacts/eu/digital-operational-resilience-act/faq/ict-third-party-contracts.md): What DORA requires in ICT third-party contracts, including critical or important functions, audit and access rights, termination, exit, subcontracting, register updates, and evidence. - [DORA ICT third-party risk and contract clauses guide](/artifacts/eu/digital-operational-resilience-act/third-party-risk-and-contract-clauses.md): Source-grounded DORA guide for financial entities in scope, ICT third-party risk, contract clauses, subcontracting controls, register evidence, audit rights, exit planning, and oversight. - [DORA incident classification forms: criteria, fields, and reporting clocks](/artifacts/eu/digital-operational-resilience-act/incident-classification-forms.md): Grounded guide to DORA ICT incident classification forms: major-incident criteria, significant cyber-threat notifications, report fields, time limits, evidence, and reclassification records. - [DORA incident clock workflow: classification, reports, deadlines, and evidence](/artifacts/eu/digital-operational-resilience-act/incident-clock-workflow.md): Grounded DORA workflow for starting the major-incident reporting clock, classifying ICT incidents, submitting initial, intermediate, and final reports, and preserving authority evidence. - [DORA major ICT incident reporting: classification, reports, and timing](/artifacts/eu/digital-operational-resilience-act/major-incident-reporting.md): Source-grounded DORA guide to major ICT-related incident classification, initial notifications, intermediate and final reports, competent authority routing, and significant cyber threat notifications. - [DORA major ICT incident thresholds: what triggers reporting?](/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds.md): FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs grounded in EU DORA RTS and ITS texts. - [DORA Register of Information FAQ: ICT Third-Party Arrangements](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md): FAQ on the DORA register of information: who maintains it, which ICT third-party arrangements it covers, template fields, critical functions, reporting, data quality, and evidence. - [DORA Register of Information Template: ICT Provider Fields and Evidence](/artifacts/eu/digital-operational-resilience-act/dora-register-of-information-template.md): A grounded DORA register of information template for ICT third-party contracts, provider hierarchy, critical functions, dates, statuses, reporting, and evidence. - [DORA TLPT selection: who can be required to test?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md): FAQ on DORA threat-led penetration testing selection: who identifies financial entities, what criteria are used, what the TLPT authority validates, and what evidence to keep. - [DORA vs EBA outsourcing guidelines: ICT third-party risk comparison](/artifacts/eu/digital-operational-resilience-act/dora-vs-eba-outsourcing-guidelines.md): Compare binding DORA ICT third-party risk duties with the EBA/ESA outsourcing baseline for registers, critical functions, contracts, subcontracting, exit, incident reporting, and evidence. - [DORA vs ISO 22301: ICT resilience and business continuity compared](/artifacts/eu/digital-operational-resilience-act/dora-vs-iso-22301.md): Compare DORA's binding ICT operational resilience duties for financial entities with ISO 22301's business continuity management system requirements. - [DORA vs ISO/IEC 27001: legal ICT resilience obligations and ISMS controls](/artifacts/eu/digital-operational-resilience-act/dora-vs-iso-27001.md): Compare EU DORA and ISO/IEC 27001 across scope, governance, incident reporting, testing, ICT third-party risk, certification, evidence, overlap, and gaps. - [DORA vs NIS2: financial-sector obligations, overlap, and evidence](/artifacts/eu/digital-operational-resilience-act/dora-vs-nis2.md): Compare DORA and NIS2 for financial entities, ICT providers, incident reporting, management accountability, third-party risk, supervisory routes, and reusable evidence. - [DORA vs PSD2 incident reporting: major ICT and payment incidents](/artifacts/eu/digital-operational-resilience-act/dora-vs-psd2-incident-reporting.md): Compare DORA major ICT-related incident reporting with PSD2 major operational or security payment incident reporting, including scope, triggers, report stages, recipients, and evidence. - [EU DORA Applicability Test for Financial Entities and ICT Providers](/artifacts/eu/digital-operational-resilience-act/applicability-test.md): A source-grounded DORA applicability test for financial-entity scope, ICT third-party services, critical or important functions, exclusions, proportionality, and evidence. - [EU DORA Compliance Checklist for Financial Entities](/artifacts/eu/digital-operational-resilience-act/checklist.md): A source-grounded DORA checklist covering ICT risk governance, major incident reporting, resilience testing, TLPT, ICT third-party contracts, register-of-information records, and audit evidence. - [EU DORA Compliance Obligations and Evidence Guide](/artifacts/eu/digital-operational-resilience-act/compliance.md): A source-grounded DORA compliance guide covering ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, registers, governance, oversight, and evidence. - [EU DORA FAQ: scope, incidents, ICT contracts, testing, and evidence](/artifacts/eu/digital-operational-resilience-act/faq.md): Concise DORA FAQ covering who is in scope, proportionality, ICT third-party contracts, register-of-information records, major ICT incident thresholds and reporting, TLPT, testing, enforcement, and evidence. - [EU DORA ICT risk management control baseline](/artifacts/eu/digital-operational-resilience-act/ict-risk-management-control-baseline.md): A source-grounded DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence. - [EU DORA ICT subcontracting chain controls for critical functions](/artifacts/eu/digital-operational-resilience-act/subcontracting-chain-controls.md): DORA guide to ICT subcontracting chains for critical or important functions: prior assessment, contract conditions, register fields, monitoring, exit rights, and evidence. - [EU DORA penalties and fines: enforcement powers and limits](/artifacts/eu/digital-operational-resilience-act/penalties-and-fines.md): Grounded guide to DORA enforcement: competent-authority powers, administrative penalties, remedial measures, publication rules, and Lead Overseer penalty payments for critical ICT third-party providers. - [EU DORA Register of Information Data Model: templates, fields, and evidence](/artifacts/eu/digital-operational-resilience-act/register-of-information-data-model.md): Field-level guide to the EU DORA register of information data model: templates B_01 to B_07, provider identifiers, contract links, subcontracting chains, critical-function assessments, dates, and export evidence. - [EU DORA Requirements Overview: ICT risk, incidents, testing, and third-party risk](/artifacts/eu/digital-operational-resilience-act/requirements.md): A grounded overview of the main EU DORA requirements for financial entities: governance, ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, register of information, oversight, proportionality, and evidence. - [EU DORA Scope and Covered Entities: financial entities and ICT providers](/artifacts/eu/digital-operational-resilience-act/scope-and-covered-entities.md): Classify whether DORA applies to a financial entity, ICT third-party provider, group arrangement, branch, or critical ICT service dependency. - [EU DORA Scope and Proportionality Workflow](/artifacts/eu/digital-operational-resilience-act/scope-and-proportionality-workflow.md): Classify DORA covered entities, simplified-framework status, critical or important functions, ICT dependencies, evidence records, and governance approvals. - [EU DORA testing and TLPT readiness guide](/artifacts/eu/digital-operational-resilience-act/testing-and-tlpt-readiness.md): A grounded DORA guide for resilience testing, TLPT eligibility, authority interaction, test evidence, remediation plans, and avoiding unsupported testing cadence. - [EU DORA TLPT eligibility workflow for financial entities](/artifacts/eu/digital-operational-resilience-act/tlpt-eligibility-workflow.md): Check how DORA TLPT authorities identify financial entities for threat-led penetration testing and what evidence supports scope, readiness, providers, and governance. - [EU DORA TLPT Runbook: scope, providers, reports, and remediation](/artifacts/eu/digital-operational-resilience-act/tlpt-runbook.md): Build a DORA threat-led penetration testing runbook around authority coordination, scope validation, provider controls, active testing, closure reports, remediation, and attestation. - [How does proportionality work under EU DORA?](/artifacts/eu/digital-operational-resilience-act/faq/proportionality.md): A grounded FAQ on DORA proportionality: what can be scaled, who may use the simplified ICT risk framework, what evidence supports the decision, and which duties cannot be waived. - [How to build a DORA register of information](/artifacts/eu/digital-operational-resilience-act/register-of-information-how-to-build.md): Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/roi-import-and-build-workflow