--- title: "EU DORA Register of Information Data Model: templates, fields, and evidence" canonical_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/register-of-information-data-model" source_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/register-of-information-data-model" author: "Sorena AI" description: "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." published_at: "2026-05-09" updated_at: "2026-05-26" keywords: - "EU DORA" - "register of information" - "DORA register templates" - "ICT third-party service providers" - "critical or important functions" - "subcontracting chain" - "LEI" - "EUID" - "ICT third-party risk" - "DORA templates" - "ICT 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) --- # EU DORA Register of Information Data Model: templates, fields, and evidence 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. *Data Model Guide* *EU DORA* ## EU DORA Register of Information Data Model A practical field guide for building the DORA register of information around the Commission's standard templates for ICT third-party contractual arrangements. Use it to check entity, provider, service, function, contract, subcontracting, criticality, date, data-quality, and submission-evidence fields before a supervisory request or register export. The DORA register of information is not a free-form outsourcing inventory. Implementing Regulation (EU) 2024/2956 sets standard templates that financial entities use to maintain and update information about contractual arrangements for ICT services provided by ICT third-party service providers. The data model works only when contract references, entity identifiers, provider identifiers, function identifiers, ICT service types, and subcontractor ranks reconcile across the templates. ## Core template structure for the DORA register of information Build the register as linked tables, not as one flat supplier list. The standard templates separate the entity scope, contractual arrangements, contract signatories, entities using the ICT services, ICT third-party providers, ICT service supply chains, functions, and assessments for ICT services that support critical or important functions. The four practical join keys are the contractual arrangement reference number, the entity and provider identifiers, the function identifier, and the type of ICT services. If those keys are not stable and reused consistently, the register will not reconcile at entity, sub-consolidated, or consolidated level. - Use B_01.01, B_01.02, and B_01.03 to identify the entity maintaining the register, entities in consolidation, and branches. - Use B_02.01 and B_02.02 for contract-level and service/function-level details, including reference numbers, costs, dates, notice periods, governing law, service locations, data locations, data sensitivity, and reliance level. - Use B_03.01, B_03.02, B_03.03, and B_04.01 to show who signed the arrangement and which financial entities or branches make use of the ICT service. - Use B_05.01 and B_05.02 to identify direct ICT third-party providers, intra-group providers, subcontractors, ultimate parents, and the rank chain in each ICT service supply chain. - Use B_06.01 for function identifiers and criticality assessment, and B_07.01 for substitutability, audit, exit, reintegration, discontinuation-impact, and alternative-provider information for critical or important functions. 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) - Sets the standard templates and explains the register join keys used across contract, provider, function, and ICT service records. - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Requires financial entities to maintain a register of information for contractual arrangements on ICT services provided by ICT third-party service providers. ## Entity, provider, service, and function hierarchy The register should distinguish the entity maintaining the register, the financial entity or branch making use of the ICT service, the undertaking that signs the contract, the direct ICT third-party provider, any intra-group ICT provider, and subcontractors in the same ICT service supply chain. Those are different roles and can be different legal entities in a group. Provider records should not rely on informal supplier names. Legal-person ICT third-party providers use a valid and active LEI or EUID where allowed by the ITS, with LEI required for legal persons established outside the Union. Natural persons acting in a business capacity can use the alternative identifier options described in the template instructions. - Give every contractual arrangement a unique reference number and use it consistently across B_02, B_03, B_04, B_05, and B_07. - Record each financial entity making use of the ICT service with its LEI and branch status in B_04.01. - Record each ICT third-party provider in B_05.01 with identification code, type of code, legal name, Latin-alphabet name, type of person, headquarters country, annual expense or estimated cost where required, and ultimate parent identifier. - Assign each function identifier in B_06.01 to a unique combination of LEI, licensed activity or support function, and function name. - Use the Annex III ICT service type identifiers consistently; do not replace them with local procurement categories unless you also map them to the required closed set. 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) - Defines the entity, provider, function, and ICT service identifiers that make the register usable at entity and group level. ## Critical or important function fields The register needs more than a yes/no label for critical or important functions. Template B_06.01 captures whether the function is critical or important, the reason where provided, the date of the last assessment, recovery time objective, recovery point objective, and impact of discontinuing the function. Template B_07.01 then connects the relevant ICT service and provider to substitutability, audit, exit, reintegration, discontinuation-impact, and alternative-provider fields. This is where the register becomes evidence for concentration risk, exit planning, and supervisory review. - Use the closed options for B_06.01 criticality or importance assessment: yes, no, or assessment not performed. - Keep the reason for criticality or importance short enough for the template field and tied to the supported function, not to a generic supplier risk statement. - Report RTO and RPO in hours; where the value is less than one hour, the template instruction uses 1, and where it is not defined, it uses 0. - Use ISO 8601 yyyy-mm-dd for the last criticality assessment date, and use 9999-12-31 where the assessment has not been performed as instructed by the ITS. - For each critical or important function, complete the B_07.01 assessment fields for substitutability, last audit date, exit plan existence, reintegration possibility, discontinuation impact, alternative-provider identification status, and any identified alternative ICT third-party provider. 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) - Provides the B_06.01 and B_07.01 fields for criticality, RTO, RPO, audit, exit, substitutability, and alternative-provider assessment. - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Connects critical or important ICT services to third-party risk management, concentration assessment, exit strategies, and key contractual provisions. ## Contract, data-location, and subcontracting fields Contract records should be granular enough to separate a master arrangement from subsequent or associated arrangements and to avoid double-counting costs. B_02.02 then repeats the contract reference at service/function level, so one contract covering multiple ICT services and functions produces multiple rows. For subcontracting, B_05.02 models the ICT service supply chain with rank. The direct ICT third-party provider is rank 1; subcontractors have ranks higher than 1. For every subcontractor row, the register identifies the provider that receives the subcontracted ICT service at the previous rank. - Capture start date, end date, termination reason where applicable, notice periods, governing-law country, service-provision countries, storage flag, data-at-rest countries, processing countries, data sensitivity, and reliance level in B_02.02 where required. - Use 9999-12-31 for an indefinite contractual arrangement end date where the template instruction requires it. - Report multiple valid countries or values as additional rows where the ITS requires a single value per data element. - Include subcontractors in the supply chain when they effectively underpin ICT services supporting critical or important functions or material parts of those functions. - For intra-group chains, use B_02.03 to reconcile the intra-group contractual arrangement with the external ICT third-party arrangement, and include at least the first extra-group subcontractor where the template instruction calls for it. 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) - Specifies the contract, date, country, data, service, and ICT service supply-chain fields used in B_02 and B_05. - [Commission Delegated Regulation (EU) 2025/532 on subcontracting ICT services](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng?ref=sorena.io) - Supports the subcontracting evidence fields by requiring assessment of subcontractors that support critical or important functions or material parts of them. - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Sets DORA's key contractual provisions for ICT services, including service descriptions, locations, data protection, incident assistance, audit cooperation, termination, and exit. ## Data-quality rules and export evidence The ITS requires the register information to be accurate and consistent, and it lists data-quality principles including validity. Treat validation as part of register maintenance, not as a clean-up step immediately before submission. Useful export evidence shows that the register can be reproduced from source systems and that each exported row traces back to a contract, provider identifier, function owner, service owner, criticality assessment, subcontractor record, and approval or correction history. - Check uniqueness and stability of contractual arrangement reference numbers, function identifiers, LEIs, EUIDs, and provider identifiers across every template. - Reject rows that use supplier display names where a required legal identifier is available and required. - Validate closed-set fields for contractual arrangement type, ICT service type, branch status, criticality status, data sensitivity, reliance, substitutability, reintegration possibility, discontinuation impact, and alternative-provider status. - Validate date fields in ISO 8601 yyyy-mm-dd format and keep the ITS template default values only where the template instruction says to use them. - Keep export evidence: source-system extract date, exported template set, validation report, exception log, correction history, responsible owner, and proof that the same external source URL supports the field design. 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) - Provides the data-quality, single-value, template-completion, identifier, and field-format rules used to validate the register before export. - [Commission Delegated Regulation (EU) 2025/532 on subcontracting ICT services](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng?ref=sorena.io) - Supports evidence for subcontractor due diligence, location risk, concentration risk, access rights, material-change notices, and termination triggers. *Recommended next step* *Placement: before sources* ## Turn the register templates into validation-ready fields Sorena can help map DORA register templates to contract, procurement, risk, and service-owner data so exports preserve identifiers, subcontracting chains, critical-function assessments, and evidence history. - [Open Research Copilot for EU DORA](/solutions/research-copilot.md): Ask source-linked questions about DORA register fields, template joins, identifiers, subcontracting chains, and export evidence using the cited sources on this page. - [Review a DORA register export](/contact.md): Walk through register template coverage, data-quality checks, provider identifiers, and critical-function evidence before a supervisory request. ## Primary sources - [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Primary source for the DORA register of information templates, table structure, mandatory fields, identifiers, closed options, date formats, data-quality rules, and ICT service supply-chain model. - Quote: "standard templates for the register of information" - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary DORA text for the obligation to maintain the register and for the third-party risk, concentration, contractual, and exit-planning context behind the data model. - Quote: "ICT services supporting critical or important functions" - [Commission Delegated Regulation (EU) 2025/532 on subcontracting ICT services](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng?ref=sorena.io) - Supports subcontracting fields and evidence for critical or important functions, including subcontractor identification, location risk, due diligence, monitoring, access rights, material changes, and termination cases. - Quote: "identify all subcontractors" ## 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 Import and Build Workflow](/artifacts/eu/digital-operational-resilience-act/roi-import-and-build-workflow.md): Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks. - [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 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/register-of-information-data-model