This guide helps decide when an ICT provider may subcontract services that support a critical or important function, what conditions must be in the contract, and what evidence must be kept.
Built for financial-entity ICT risk, procurement, legal, outsourcing, resilience, register-of-information, and service-owner teams reviewing provider chains under DORA.
DORA has applied since 17 January 2025. Its subcontracting controls matter when an ICT third-party service provider uses, or may use, further ICT providers for services that support a financial entity's critical or important functions. The required is a documented chain view showing which subcontractors effectively underpin the service, what risks were assessed before approval, what the main contract allows, how material changes are handled, and how the service can be exited without disrupting regulated activity.
Start with the function, not the vendor. DORA defines a critical or important function by the impact its disruption, defective performance, or failure would have on financial performance, service continuity, authorisation conditions, or other financial-services obligations. If an ICT service supports that function, subcontracting of the service or a material part of it needs explicit treatment.
The chain review should cover direct ICT third-party providers and the subcontractors that effectively underpin ICT services supporting critical or important functions or material parts of them. Intra-group ICT subcontractors are not automatically outside the review: Delegated Regulation 2025/532 treats ICT intra-group subcontractors providing those services as ICT subcontractors.
DORA, Implementing Regulation 2024/2956, and Delegated Regulation 2025/532 are binding EU rules. The chain map, approval log, and suggested evidence file below are practical ways to prove the required assessment and control; the regulations do not prescribe a particular diagram or internal workflow.
Sources (2)
Defines critical or important functions and requires ICT third-party risk management, register maintenance, pre-contract assessment, subcontracting assessment, contractual clauses, and exit strategies.
critical or important function
Specifies the elements financial entities must determine and assess when subcontracting ICT services supporting critical or important functions.
overall chain of subcontractors
Before entering into a contract with an ICT third-party provider, the financial entity must decide whether that provider may subcontract ICT services supporting critical or important functions or material parts of them. The assessment should be completed before approval, not reconstructed after the subcontractor is already in the chain.
The assessment should test both the provider's control of its subcontractors and the financial entity's own ability to monitor the resulting risk. Delegated Regulation 2025/532 lists conditions covering subcontractor identification, provider due diligence, contractual flow-down, access and inspection rights, provider and financial-entity monitoring resources, operational resilience impact, location risk, concentration risk, and obstacles to audit or supervisory access.
Sources (2)
Lists the due diligence and risk-assessment conditions that must be assessed before permitting subcontracting of ICT services supporting critical or important functions.
before entering into a contractual arrangement
Requires pre-contract assessment of whether an ICT arrangement supports a critical or important function, relevant risks, due diligence, conflicts of interest, and concentration risk.
Before entering into a contractual arrangement
For ICT services supporting critical or important functions, the main contract should say whether subcontracting is permitted and, if permitted, under what conditions. A simple consent sentence is too thin; the contract needs operational conditions that let the financial entity monitor the chain and object when material changes exceed risk tolerance.
The clauses should also flow through core DORA controls to the subcontracting chain: service levels, continuity, security requirements, contingency plans, incident assistance, access and audit, cooperation with competent and resolution authorities, notification of material changes, and termination rights.
Sources (2)
Article 30 sets written-contract requirements, including descriptions of services, subcontracting conditions, locations, security, incident assistance, audit rights, and exit strategies.
conditions applying to such subcontracting
Specifies contract conditions for subcontracted ICT services supporting critical or important functions, including monitoring, reporting, continuity, flow-down, material change, and termination provisions.
material changes to subcontracting arrangements
The register of information should make the subcontracting chain visible enough for internal ICT risk management and supervision. DORA requires a register for contractual arrangements on ICT services, distinguishing arrangements that support critical or important functions from those that do not. The ITS then adds structured templates for provider identity, ICT service supply chains, functions, and assessment fields.
For subcontracting, the important register question is not whether every remote supplier appears somewhere in procurement data. The register must include information on subcontractors that effectively underpin ICT services supporting critical or important functions or material parts of them, including those whose disruption would impair security or continuity of the service provision. For an intra-group provider chain, the ITS also requires at least the first extra-group subcontractor even when the service is not critical or important.
Sources (2)
Sets the standard register templates, including ICT service supply-chain ranking and assessment fields for ICT services supporting critical or important functions.
ICT service supply chain
Requires financial entities to maintain and update the register of information and make it available to competent authorities on request.
maintain and update
Once subcontracting is permitted, the control becomes continuous. Delegated Regulation 2025/532 requires periodic reassessment against changes in supported business functions, ICT threats, concentration risks, geopolitical risks, and the wider business environment. The provider must give notice of an intended material change early enough for assessment, and the contract must set a reasonable period for approval or objection. The provider may implement the change only after approval or after that period ends without an objection.
Exit and termination evidence should be practical. The financial entity should be able to show when it can object to a material subcontracting change, when the provider may not implement a change, when the contract may be terminated, and how the service and data can move to another provider or back in-house without disrupting business activities, regulatory compliance, or client service continuity.
Yes, but only where the financial entity permits it in the ICT contract and has assessed the required conditions. The contract should identify which ICT services or material parts may be subcontracted and the conditions that apply.
The register should include subcontractors that effectively underpin ICT services supporting critical or important functions or material parts of them, including subcontractors whose disruption would impair security or continuity of the service provision. For an intra-group provider chain, the ITS also requires at least the first extra-group subcontractor even when the service is not critical or important.
The entity should object before the notice period ends when its assessment shows that the intended material change exceeds its risk tolerance, and it should request modifications before implementation.
Sources (3)
Sets periodic reassessment duties, material-change notice and objection mechanics, and termination cases for subcontracting arrangements supporting critical or important functions.
right to terminate
Requires exit strategies for ICT services supporting critical or important functions and lists risks to consider when planning exit.
put in place exit strategies
Requires register assessment fields that support exit and monitoring evidence, including substitutability, exit-plan existence, reintegration, discontinuation impact, and alternatives.
Existence of an exit plan
Sorena can convert the checks on this page into provider questionnaires, contract review points, register fields, reassessment triggers, and evidence requests for DORA ICT third-party risk work.
Ask questions tied to cited sources about ICT subcontracting, critical or important functions, register fields, contract clauses, and exit evidence.
Review your DORA subcontracting chain controls, source gaps, and implementation evidence with Sorena.
"ICT third-party risk"
"critical or important function"
"Before entering into a contractual arrangement"
"conditions applying to such subcontracting"
"maintain and update"
"put in place exit strategies"
"elements that a financial entity has to determine and assess"
"overall chain of subcontractors"
"before entering into a contractual arrangement"
"material changes to subcontracting arrangements"
"right to terminate"
"standard templates for the register of information"
"ICT service supply chain"
"Existence of an exit plan"
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.
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.
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.
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.