FAQEU DORA

DORA Register of Information FAQ

A practical FAQ for building and maintaining DORA's register of information for ICT third-party service arrangements.

Covers the register owner, ICT service arrangements, standard templates, critical or important functions, subcontractors, reporting to competent authorities, data quality, and evidence records.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Questions
6

Structured answer sets in this page tree.

Primary sources
6

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 25, 2026
Overview

DORA has applied since 17 January 2025. Each financial entity must maintain and update a structured register of all contractual arrangements for ICT services provided by ICT third-party service providers. The register connects contracts, providers, ICT services, functions, data locations, relevant subcontracting chains, assessments, and competent-authority reporting; a supplier list alone is not enough.

Search this module

Find a question or answer quickly

6 of 6 questions
Question 1

What is the DORA register of information?

The DORA is the financial entity's maintained and updated record of all contractual arrangements on the use of ICT services provided by ICT third-party service providers. DORA Article 28 requires the register at entity level and, where relevant, at sub-consolidated and consolidated levels.

The register must distinguish arrangements that support critical or important functions from arrangements that do not. That classification determines which additional assessment fields and supply-chain records apply, while DORA Articles 28 to 30 set the related contract, subcontracting, audit, and exit obligations.

  • Include contractual arrangements for ICT services, not only traditional outsourcing contracts.
  • Record all direct ICT third-party providers and the ICT services they provide.
  • Mark whether the service supports a or a material part of one.
  • Make the register available to the competent authority on request, either in full or in requested sections.

Is the DORA the same as a vendor inventory?

No. A vendor inventory can feed the register, but DORA's register is broader and more structured. It links each ICT service arrangement to the financial entity using the service, the direct provider, relevant subcontractors, the supported function, contract reference numbers, data locations, assessment fields, and reporting information.

Citations
Question 2

Who maintains it, and what arrangements must be captured?

The financial entity is responsible for maintaining and updating the register. In a group, the register can be maintained at entity, sub-consolidated, and consolidated levels, but the information still needs to let each financial entity meet its own DORA obligation.

The register covers all contractual arrangements for ICT services from direct ICT third-party service providers. For groups, it must also reflect intra-group ICT service arrangements and reconcile the intra-group contract with contracts between the and external providers in the same service chain. The ITS requires at least the first extra-group subcontractor in that chain even when the ICT service does not support a .

  • Use a unique and stable contractual arrangement reference number across the register templates.
  • Capture standalone contracts, master or framework arrangements, and subsequent or associated arrangements such as order forms.
  • Identify the entity signing the arrangement and the financial entity making use of the ICT service when those are different.
  • For group registers, include the relevant financial entities and ICT intra-group service providers in the scope of consolidation.
Citations
Question 3

Which fields matter most in the standard templates?

Implementing Regulation (EU) 2024/2956 organizes the register into linked templates rather than one flat spreadsheet. The important design choice is to use the same keys consistently: contract reference number, entity and provider identifiers, function identifier, and type of ICT service.

At minimum, teams should make sure their source systems can populate the templates for the maintaining entity, in-scope entities and branches, contractual arrangements, signing entities, ICT third-party providers, ICT service supply chains, functions, assessments, and internal terminology.

  • Provider identity: a valid, active or for legal persons established in the Union, using both where available; only an LEI for legal persons established outside the Union. Alternative codes are available only for individuals acting in a business capacity.
  • Contract details: arrangement type, annual expense or estimated cost, start and end dates, termination reason when relevant, governing law, service country, and notice periods where required.
  • Service and data details: ICT service type, function identifier, storage and processing locations, data sensitivity, and level of reliance for critical or important functions.
  • Assessment details: substitutability, reason for difficult substitution, date of last audit, exit plan, reintegration possibility, discontinuation impact, and identified alternatives.

Can teams complete one row per supplier?

Usually not. The templates use a relational structure. Where one arrangement includes multiple ICT services supporting multiple functions, the specific-information template expects enough rows to combine the relevant ICT services and supported functions at the maximum granularity possible.

Citations
Question 4

How should critical or important functions and subcontractors be handled?

status should be assessed before entering into an ICT service arrangement and revisited when a service, function, provider, data location, or subcontracting chain changes. DORA treats the criticality or importance of the supported function as central to ICT third-party risk.

For subcontractors, the register does not require every remote supplier in every chain. The 2024/2956 templates require subcontractors that effectively underpin ICT services supporting critical or important functions or material parts of them, including subcontractors whose disruption would impair the security or continuity of the service. A separate group rule requires at least the first external subcontractor used by an , even when the service is not critical or important.

  • Document the methodology used to decide whether an ICT service supports a .
  • Map each to the ICT services and providers that support it.
  • For critical or important functions, capture the service supply chain with rank 1 for the direct ICT third-party provider and higher ranks for subcontractors.
  • Keep subcontracting risk assessments separate from supplier assurances; reliance on provider assessments does not remove the financial entity's final responsibility.
Citations
Question 5

How is the register submitted or exported?

DORA requires financial entities to report at least yearly to competent authorities on new ICT-service arrangements, provider categories, contract types, ICT services, and functions being provided. It also requires them to make the full register, or requested sections, available to the competent authority on request.

The implementing regulation is explicit that the register is maintained through standard templates with defined columns, rows, single-value data elements, identifiers, and closed lists. The practical export should therefore preserve the template structure and keys rather than turning the register into a narrative report.

  • Keep a reportable version of each template, not only dashboard views.
  • Use ISO formats and closed-list values where the template requires them.
  • Maintain evidence for the last update date, reporting date when applicable, and the competent authority to which reporting is made.
  • When a competent authority asks for sections, export by template and key so contracts, providers, functions, services, and assessments still reconcile.
Citations
Question 6

What evidence and data-quality checks should support the register?

The register should be backed by evidence that each field can be traced to a contract, provider record, business-function owner, risk assessment, audit record, exit plan, or source system. Implementing Regulation (EU) 2024/2956 requires six data-quality principles: accuracy, completeness, consistency, integrity, uniformity, and validity. Financial entities must regularly review the register and promptly correct errors and discrepancies.

The evidence must support day-to-day maintenance. Contract owners, business-service owners, ICT risk, procurement, legal, and group reporting teams should use the same identifiers and reflect changes in services, functions, providers, subcontractors, data locations, or criticality in the templates.

  • Contract evidence: executed agreement, master agreement, order form, SLA, amendment, termination notice, and notice-period source.
  • Provider evidence: or check, legal name, headquarters country, direct provider status, ultimate parent, and subcontractor list where required.
  • Function evidence: business owner approval, function identifier, assessment, reliance level, and impact of discontinuing the service.
  • Assurance evidence: due diligence, information-security standard review, audit date, substitutability analysis, exit plan, alternative-provider assessment, and data-location validation.
  • Quality evidence: reconciliation reports for duplicate contract references, missing mandatory fields, inconsistent identifiers, stale provider data, and unresolved template errors.

What are the core data-quality principles for the DORA register?

The implementing regulation names accuracy, completeness, consistency, integrity, uniformity, and validity. Those checks should be applied before reporting and after material changes to contracts, providers, services, functions, subcontracting, or data locations.

Citations
Recommended next step

Turn the DORA register of information into a controlled data workflow

Sorena can help map ICT third-party arrangements to DORA register templates, owners, evidence, data-quality checks, and competent-authority export requirements.

Research workflow
Open Research Copilot for EU DORA

Ask questions tied to cited sources about DORA register fields, ICT third-party arrangements, critical functions, subcontractors, and evidence.

Explore next step
Talk to Sorena
Talk through implementation

Review your DORA register structure, source gaps, template mapping, and evidence workflow with Sorena.

Explore next step
Primary sources

References and citations

Regulation (EU) 2022/2554 (DORA)
eur-lex.europa.eu
Referenced sections
  • Primary DORA text for Article 28 register duties, ICT third-party risk, critical or important functions, competent-authority access, and yearly reporting.
"maintain and update at entity level"
Regulation (EU) 2022/2554 (DORA), Articles 28 to 30
eur-lex.europa.eu
Referenced sections
  • Requires pre-contract assessment, concentration-risk assessment, and additional contractual provisions for ICT services supporting critical or important functions.
"supporting critical or important functions"
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
Track DORA dates and recurring evidence: 17 January 2025 application, incident reporting clocks, register updates, annual reporting, TLPT cadence, and critical-provider 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
Official source 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
Official source 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
Official source 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
Official source 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 based on EU DORA RTS and ITS texts.
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 Register of Information Template: ICT Provider Fields and Evidence
An official source 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?
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
An official source 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
An official source 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
An official source 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
An official source 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
Official source 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
An official source 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
An official source 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?
An official source 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.