TemplateEU DORA

DORA register of information template for ICT third-party arrangements

Use this page to structure the DORA register around the official B_ templates: entity scope, contracts, provider identifiers, ICT services, critical or important functions, supply-chain ranks, risk assessments, dates, and evidence.

The register should be maintained at entity level and, where relevant, sub-consolidated and consolidated levels. It must support internal ICT third-party risk management, competent-authority supervision, and ESA oversight of critical ICT third-party providers.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
May 26, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 26, 2026
Overview

DORA Article 28 requires financial entities to maintain and update a register of information for all contractual arrangements on the use of ICT services provided by ICT third-party service providers. Commission Implementing Regulation (EU) 2024/2956 turns that obligation into linked templates with common keys, provider identifiers, ICT service codes, function records, and assessment fields.

Section 1

Template map and join keys

Build the register as linked tables, not as a flat vendor inventory. The official ITS uses predefined columns with an indefinite number of rows, and the same contract, entity, provider, function, and ICT service identifiers must reconcile across templates.

Use the contractual arrangement reference number as the contract key. Use the financial entity LEI, ICT third-party provider identifier, function identifier, and ICT service type code to connect each contract to the entity using the service, the provider chain, the supported function, and the assessment record.

  • B_01.01: entity maintaining the register, including LEI, name, country, entity type, and competent authority.
  • B_01.02 and B_01.03: entities in consolidation and branches, so group-level registers still trace back to the entity using the ICT service.
  • B_02.01: contract header with unique contractual arrangement reference number, arrangement type, overarching arrangement reference, currency, and annual expense or estimated cost.
  • B_02.02: contract-service-function detail linking the contract reference to the entity LEI, provider identifier, function identifier, ICT service type, dates, locations, data storage or processing, sensitivity, and reliance level.
  • B_03.01, B_03.02, B_03.03, and B_04.01: who signs the arrangement, which provider signs to provide the service, which intra-group entities provide services, and which entities actually use the ICT service.
  • B_05.01 and B_05.02: provider master data and ranked ICT service supply chain.
  • B_06.01 and B_07.01: financial-entity functions and the assessment of ICT services supporting critical or important functions or material parts of them.
  • B_99.01: internal definitions for closed-list options such as sensitivity, impact, substitutability, reintegration, and discontinuation impact.
Sources for this answer
Commission Implementing Regulation (EU) 2024/2956 on DORA register templates
Sets the standard B_ templates, linked keys, data-quality principles, and format requirements for the DORA register of information.
Section 2

ICT provider and service fields

Treat every row as a statement about a specific ICT service under a specific contractual arrangement. If one contract covers several ICT service types, supported functions, countries of data location, or processing locations, add the needed rows rather than compressing multiple values into one cell.

For provider identification, legal-person ICT third-party service providers should use a valid and active LEI or EUID, and where available both. Third-country providers are identified with LEI only. Natural persons acting as ICT service providers may use alternative identification codes under the template rules.

  • Contract fields: contractual arrangement reference number, arrangement type, overarching reference, annual expense or estimated cost, start date, end date or 9999-12-31 for indefinite arrangements, termination reason when ended, and business-as-usual notice periods.
  • Service fields: ICT service type code S01 to S19, such as ICT security management services, hosting excluding cloud, network infrastructure, ICT operation management, cloud IaaS, cloud PaaS, or cloud SaaS.
  • Data fields: whether the ICT service stores data, countries where data is stored at rest, countries where data is processed, and the sensitivity of stored or processed data.
  • Location and law fields: country of governing law and country of ICT service provision when the service supports a critical or important function.
  • Provider master fields: provider identifier, identifier type, provider name, provider hierarchy details, and ultimate parent undertaking where applicable.
  • Supply-chain fields: contractual arrangement reference number, ICT service type, each provider in the chain, and rank, with the direct ICT third-party service provider always ranked 1 and subcontractors ranked higher than 1.
Sources for this answer
Commission Implementing Regulation (EU) 2024/2956 on DORA register templates
Defines provider identifiers, contract dates, ICT service type codes, data-location fields, and supply-chain ranking for the register.
Section 3

Critical or important functions and assessments

The register must distinguish contractual arrangements that support critical or important functions from those that do not. The function record should be specific enough to connect a licensed activity, the function performed for that activity, the entity using the service, continuity targets, and the impact of discontinuing the function.

For ICT services supporting critical or important functions or material parts of them, B_07.01 adds the assessment layer. This is where the register should show substitutability, the reason a provider is not substitutable or is difficult to substitute, last audit date, exit-plan existence, reintegration possibility, discontinuation impact, and whether alternative ICT third-party providers have been identified.

  • Function identifier: use a unique identifier for each combination of financial entity LEI, licensed activity, and function.
  • Criticality flag: record whether the function is critical or important and keep the assessment rationale with the business-impact or resilience record that supports it.
  • Continuity fields: record recovery time objective and recovery point objective for the function, using the template instructions for hours and default values.
  • Reliance field: record the level of reliance on the ICT service supporting the critical or important function, from not significant through full reliance.
  • Audit field: record the date of the last audit of the specific ICT service provided by the ICT third-party provider, or 9999-12-31 where no audit has been performed.
  • Exit and substitution fields: record whether an exit plan exists, reintegration possibility, impact of discontinuing ICT services, identified alternatives, and any alternative provider identifier.
Sources for this answer
Commission Implementing Regulation (EU) 2024/2956 on DORA register templates
Specifies B_06.01 function identification and B_07.01 assessment fields for ICT services supporting critical or important functions.
Regulation (EU) 2022/2554 (DORA)
Requires ICT third-party risk management to consider criticality, impact on continuity and availability, yearly reporting, competent-authority access, and exit strategies.
Section 4

Group, intra-group, and subcontractor hierarchy

For groups, the register can cover entity, sub-consolidated, and consolidated levels, but it still needs enough structure for each financial entity to meet its own register and reporting obligation. The parent undertaking determines which entities are included at sub-consolidated and consolidated level under the relevant sectoral Union financial-services legislation.

Do not stop at the first intra-group service provider when the ICT service supply chain continues outside the group. The ITS requires reconciliation between intra-group contractual arrangements and contracts with external ICT third-party providers when part of the supply chain is intra-group.

  • Record the entity maintaining the register and every entity in scope of consolidation.
  • Record the entity that signs the receiving contract, even when it is not the entity that uses the ICT service.
  • Record intra-group service providers that sign contracts to provide ICT services to other entities in consolidation.
  • Use B_02.03 to link intra-group contract references to external third-party contract references in the same ICT service supply chain.
  • Include all direct ICT third-party providers for ICT services and include subcontractors that effectively underpin ICT services supporting critical or important functions or material parts of them.
  • For subcontractors supporting critical or important functions, keep the provider's LEI or EUID where required and evidence that the direct provider can identify and supply necessary subcontractor information.
Sources for this answer
Commission Implementing Regulation (EU) 2024/2956 on DORA register templates
Explains group-level registers, intra-group reconciliation, direct providers, subcontractors, and ranked ICT service supply chains.
Commission Delegated Regulation (EU) 2025/532 on subcontracting ICT services supporting critical or important functions
Supports the subcontractor evidence requirement for ICT services supporting critical or important functions or material parts of them.
Section 5

Dates, statuses, reporting, and export evidence

The register should be ready both for daily ICT third-party risk management and for supervisory extraction. DORA requires financial entities to report at least yearly on new ICT-service arrangements, provider categories, arrangement types, ICT services, and functions provided. It also requires the full register, or requested sections, to be made available to the competent authority on request.

Avoid invented deadline fields. Use only dates that the contract, audit evidence, function assessment, or authority request supports. Where the ITS gives a specific template default value, use that value exactly and keep the evidence explaining why it was used.

  • Start date: contract entry-into-force date in ISO 8601 yyyy-mm-dd format.
  • End date: contract end date, renewal date, termination date when different, or 9999-12-31 for an indefinite arrangement.
  • Termination status: select the closed-list reason only when the contractual arrangement has been terminated or ended.
  • Audit date: last audit date for the specific ICT service, or 9999-12-31 where no audit has been performed.
  • Correction status: keep a register issue log for detected data errors or inconsistencies and the correction date, because the ITS requires regular review and prompt correction.
  • Reporting export: preserve the contract reference number, entity LEI, provider identifier, function identifier, ICT service type code, closed-list option values, and B_99.01 definitions so competent-authority extracts can be reconciled.
  • Evidence pack: attach or cross-reference the signed contract, master and associated agreement references, provider identifier checks, service catalogue mapping, function criticality assessment, data-location evidence, audit evidence, exit plan, alternative-provider assessment, and source citation used for the field design.
Sources for this answer
Regulation (EU) 2022/2554 (DORA)
Requires yearly reporting to competent authorities, authority access to the register, timely notice of planned critical-function arrangements, and exit strategies.
Commission Implementing Regulation (EU) 2024/2956 on DORA register templates
Provides the date fields, template default values, data quality principles, single-value row rule, and template-specific instructions used for export readiness.
Recommended next step

Map contracts, providers, functions, and evidence against the official DORA templates

Sorena can help convert ICT contract data into a DORA register structure that keeps B_ templates, identifiers, provider chains, critical-function assessments, dates, and evidence aligned.

Research workflow
Open Research Copilot for EU DORA

Ask source-linked questions about DORA register fields, ICT service types, provider hierarchy, critical functions, and evidence requirements using the cited sources on this page.

Explore next step
Talk to Sorena
Talk through implementation

Review your register field map, source gaps, provider hierarchy, and reporting export expectations with Sorena.

Explore next step
Primary sources

References and citations

Regulation (EU) 2022/2554 (DORA)
eur-lex.europa.eu
Referenced sections
  • Requires yearly reporting to competent authorities, authority access to the register, timely notice of planned critical-function arrangements, and exit strategies.
"report at least yearly"
Related guides

Explore more topics

DORA Critical or Important Functions: mapping ICT dependencies and evidence
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
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
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
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
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
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
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
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?
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
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
Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks.
DORA TLPT selection: who can be required to test?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks.