Artifact GuideEU

EU DORA ICT subcontracting chain controls

Use this guide to 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.

Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 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 9, 2026
Overview

DORA 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 useful control is not a generic supplier list. It is a documented chain view that shows 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.

Section 1

When the subcontracting chain control is in scope

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.

  • Identify the supported function and record whether the function is critical or important.
  • Map the direct provider, every relevant ICT service, and the subcontractors that underpin the service or a material part of it.
  • Capture country or region of service delivery, data processing, and storage when the contract or register requires location visibility.
  • Treat long, complex, third-country, intra-group, concentrated, or hard-to-transfer chains as higher-risk review items.
Section 2

Prior assessment before permitting subcontracting

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.

  • Check that the provider can select and assess subcontractors' operational, financial, human, technical, information-security, governance, risk-management, and internal-control capabilities.
  • Require the provider to identify all subcontractors supporting the critical or important function and to provide information needed for the financial entity's assessment.
  • Assess whether the provider's subcontractor contracts enable the financial entity to meet DORA, Union, and national legal obligations.
  • Confirm that access, inspection, and audit rights are not blocked at subcontractor level.
  • Assess concentration risk, location risk, data-processing and storage locations, transferability, and the impact of subcontractor failure on digital operational resilience and financial soundness.
Section 3

Contract clauses that make the chain controllable

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.

  • State which ICT services or material parts may be subcontracted and which may not.
  • Make the direct ICT third-party provider responsible for subcontracted services and for monitoring subcontractors against the financial entity's contract.
  • Require subcontractor monitoring and reporting obligations, including agreed reporting to the provider and, where agreed, to the financial entity.
  • Require continuity across the subcontracting chain if a subcontractor fails to meet contractual obligations.
  • Flow down business contingency plans, service levels, ICT security standards, and any additional security requirements.
  • Include notice periods, approval or objection mechanics for material subcontracting changes, and termination rights when permitted subcontracting conditions are breached.
Section 4

Register-of-information impact

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.

  • Use contract reference numbers, provider identifiers, function identifiers, and ICT service types consistently across templates.
  • Populate supply-chain ranks: the direct ICT third-party provider is rank 1, and subcontractors have ranks higher than 1.
  • Record the recipient of subcontracted ICT services for each subcontractor beyond rank 1 so the chain can be reconstructed.
  • Keep B_06.01 criticality, impact, RTO, and RPO fields aligned with the function supported by the ICT service.
  • Keep B_07.01 assessment fields current for critical or important functions, including substitutability, last audit date, existence of an exit plan, reintegration complexity, discontinuation impact, and identified alternatives.
Section 5

Monitoring, material changes, exit, and evidence

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. It also requires the provider to inform the financial entity about intended material changes well in time for assessment.

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.

Does DORA allow ICT subcontracting for critical or important functions?

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.

Which subcontractors belong in the DORA register of information?

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.

When should a financial entity object to a subcontracting change?

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.

  • Maintain a current chain map, provider notices, subcontractor approvals or objections, risk assessments, and change decisions.
  • Keep monitoring evidence for service levels, incidents, security controls, continuity tests, audit activity, access-right exercise, and provider reporting.
  • Document periodic reassessments and event-driven reassessments when business functions, threats, concentration, locations, data handling, or geopolitical risks change.
  • Preserve exit-plan evidence: alternative providers or in-house options, transition steps, data return and transfer method, continuity controls, transition period, and tested recovery assumptions.
  • Retain termination evidence for unapproved subcontracting, implementation before the notice period ends, ignored objections, significant legal or contractual breaches, provider ICT risk weaknesses, or loss of effective supervisory access.
Recommended next step

Build a source-linked subcontracting review workflow

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.

Primary sources

References and citations

eur-lex.europa.eu
Referenced sections
  • Sets periodic reassessment duties, material-change notice and objection mechanics, and termination cases for subcontracting arrangements supporting critical or important functions.
"right to terminate"
eur-lex.europa.eu
Referenced sections
  • Requires exit strategies for ICT services supporting critical or important functions and lists risks to consider when planning exit.
"put in place exit strategies"
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 Register of Information Template: ICT Provider Fields and Evidence
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?
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 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.