A practical field guide for building the DORA 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.
Since DORA began applying on 17 January 2025, financial entities have had to maintain and update a for contractual arrangements on the use of ICT services. Implementing Regulation (EU) 2024/2956 sets the standard templates. Contract references, entity identifiers, provider identifiers, function identifiers, ICT service types, and subcontractor ranks must reconcile across them.
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. Each data element accepts one value; repeat the row when more than one value is valid instead of storing a list in one cell.
Sources (2)
Sets the standard templates and explains the register join keys used across contract, provider, function, and ICT service records.
standard templates for the register of information
Requires financial entities to maintain a register of information for contractual arrangements on ICT services provided by ICT third-party service providers.
maintain and update at entity level
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 Legal Entity Identifier (LEI) or European Unique Identifier (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.
Sources (1)
Defines the entity, provider, function, and ICT service identifiers that make the register usable at entity and group level.
the function identifier
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.
Sources (2)
Provides the B_06.01 and B_07.01 fields for criticality, RTO, RPO, audit, exit, substitutability, and alternative-provider assessment.
Criticality or importance assessment
Connects critical or important ICT services to third-party risk management, concentration assessment, exit strategies, and key contractual provisions.
ICT services supporting critical or important functions
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.
Sources (3)
Specifies the contract, date, country, data, service, and ICT service supply-chain fields used in B_02 and B_05.
ICT service supply chain
Supports the subcontracting evidence fields by requiring assessment of subcontractors that support critical or important functions or material parts of them.
identify all subcontractors
Sets DORA's key contractual provisions for ICT services, including service descriptions, locations, data protection, incident assistance, audit cooperation, termination, and exit.
Key contractual provisions
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.
At minimum, model the DORA register as linked template tables for entities, branches, contractual arrangements, signatories, entities using ICT services, ICT third-party providers, ICT service supply chains, functions, and critical-function service assessments. The join keys are the contractual arrangement reference number, entity and provider identifiers, function identifier, and ICT service type.
For legal-person ICT third-party providers, the ITS points to LEI and EUID where available and requires LEI for legal persons established outside the Union. Alternative code types are reserved for individuals acting in a business capacity under the template instructions.
The register needs subcontractor rows for ICT services supporting critical or important functions or material parts where those subcontractors effectively underpin the service, including subcontractors whose disruption would impair service security or continuity. The supply-chain template records rank 1 for the direct provider and higher ranks for subcontractors. Where an ICT intra-group provider uses subcontractors, include at least the first extra-group subcontractor even when the ICT service does not support a critical or important function or material part.
Sources (2)
Provides the data-quality, single-value, template-completion, identifier, and field-format rules used to validate the register before export.
accurate and consistent
Supports evidence for subcontractor due diligence, location risk, concentration risk, access rights, material-change notices, and termination triggers.
material changes to subcontracting arrangements
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.
Ask questions tied to cited sources about DORA register fields, template joins, identifiers, subcontracting chains, and export evidence using the cited sources on this page.
Walk through register template coverage, data-quality checks, provider identifiers, and critical-function evidence before a supervisory request.
"standard templates for the register of information"
"the function identifier"
"Criticality or importance assessment"
"ICT service supply chain"
"accurate and consistent"
"ICT services supporting critical or important functions"
"maintain and update at entity level"
"Key contractual provisions"
"identify all subcontractors"
"material changes to subcontracting arrangements"
How DORA critical or important functions affect ICT service mapping, third-party contracts, register-of-information records, incidents, testing, and evidence.
Track DORA dates and recurring evidence: 17 January 2025 application, incident reporting clocks, register updates, annual reporting, TLPT cadence, and critical-provider oversight milestones.
A DORA workflow for remediating ICT third-party contracts covering critical or important functions, subcontracting, audit rights, exits, register updates, and evidence.
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.
Official source guide to DORA ICT incident classification forms: major-incident criteria, significant cyber-threat notifications, report fields, time limits, evidence, and reclassification records.
Official source DORA workflow for starting the major-incident reporting clock, classifying ICT incidents, submitting initial, intermediate, and final reports, and preserving authority evidence.
Official source DORA guide to major ICT-related incident classification, initial notifications, intermediate and final reports, competent authority routing, and significant cyber threat notifications.
Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks.
Map DORA register fields to official templates for ICT contracts, provider chains, critical functions, dates, statuses, reporting, and evidence.
Compare binding DORA ICT third-party risk duties with the EBA outsourcing baseline for registers, critical functions, contracts, subcontracting, exit, incident reporting, and evidence.
Compare DORA's binding ICT operational resilience duties for financial entities with ISO 22301's business continuity management system requirements.
Compare EU DORA and ISO/IEC 27001 across scope, governance, incident reporting, testing, ICT third-party risk, certification, evidence, overlap, and gaps.
Compare DORA and NIS2 for financial entities, ICT providers, incident reporting, management accountability, third-party risk, supervisory routes, and reusable evidence.
Compare DORA major ICT-related incident reporting with PSD2 major operational or security payment incident reporting, including scope, triggers, report stages, recipients, and evidence.
Test DORA applicability against official sources for financial-entity scope, ICT services, critical or important functions, exclusions, proportionality, and evidence.
Check DORA operating evidence against official sources for ICT risk governance, major-incident reporting, resilience testing, TLPT, third-party contracts, and the register of information.
Map DORA obligations to official sources and operating evidence for ICT risk management, incident reporting, testing, third-party risk, registers, governance, and oversight.
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.
An official source DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence.
DORA guide to ICT subcontracting chains for critical or important functions: prior assessment, contract conditions, register fields, monitoring, exit rights, and evidence.
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.
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.
Classify whether DORA applies to a financial entity, ICT third-party provider, group arrangement, branch, or critical ICT service dependency.
Classify DORA covered entities, simplified-framework status, critical or important functions, ICT dependencies, evidence records, and governance approvals.
An official source DORA guide for resilience testing, TLPT eligibility, authority interaction, test evidence, remediation plans, and avoiding unsupported testing cadence.
Check how DORA TLPT authorities identify financial entities for threat-led penetration testing and what evidence supports scope, readiness, providers, and governance.
Build a DORA threat-led penetration testing runbook around authority coordination, scope validation, provider controls, active testing, closure reports, remediation, and attestation.
Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks.
What DORA requires in ICT third-party contracts, including critical or important functions, audit and access rights, termination, exit, subcontracting, register updates, and evidence.
FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs based on EU DORA RTS and ITS texts.
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.
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 proportionality explained from official sources: what can be scaled, simplified-framework eligibility, supporting evidence, and duties that remain mandatory.