This comparison separates binding DORA ICT third-party risk obligations from the 2019 EBA outsourcing guidance referenced by DORA and the register ITS.
Focus the gap review on ICT services, critical or important functions, register data, contract clauses, subcontracting chains, exit evidence, incident reporting, and board-level accountability.
DORA and the EBA Guidelines on arrangements answer different scope questions. DORA is directly applicable EU law for ICT risk and ICT third-party services across its listed financial entities. EBA/GL/2019/02 is supervisory guidance for outsourcing by the institutions and payment institutions within its scope. An arrangement can fall under both, under only one, or under neither; the procurement label does not decide the result.
Side-by-side comparison
DORA vs EBA outsourcing guidelines: practical compliance differences
Use these rows to decide what can be reused from an EBA-style programme and what must be upgraded for DORA ICT third-party risk.
A directly applicable EU digital operational resilience regulation for financial entities, with binding ICT risk, ICT third-party risk, register, contract, reporting, testing, and oversight obligations.
Second framework
EBA outsourcing guidelines
Supervisory guidance for governance within its stated institutional scope. DORA and the register ITS reference it, but it does not replace DORA-specific ICT-service obligations.
DORA vs EBA outsourcing guidelines: practical compliance differences
EBA/GL/2019/02 covers arrangements in which a service provider performs a process, service, or activity that the institution or payment institution would otherwise undertake itself. Acquisition of goods, utilities, and services the institution would not otherwise perform are not merely because a third party supplies them.
Review cloud, SaaS, data, security, resilience, and support services under DORA even when they are not . Apply the EBA definition separately rather than relying on procurement labels.
EBA/GL/2019/02 is supervisory guidance addressed to competent authorities and to credit institutions, CRD investment firms, payment institutions, and electronic money institutions within its defined scope. It does not cover every financial entity listed in DORA.
Do not close a DORA gap by pointing only to guideline compliance. Show the DORA article, RTS, ITS, register field, contract clause, or incident-reporting artifact that now applies.
DORA defines a critical or important function by material impairment to financial performance, service continuity, soundness, or ongoing compliance if disrupted or defective.
The EBA Guidelines treat a function as critical or important when a defect or failure would materially impair continuing compliance, financial performance, or the soundness or continuity of banking and payment services. They also identify functions whose requires authorisation or is treated as critical under specified sector rules.
Attach the critical-or-important-function rationale to each contract, register row, subcontracting decision, exit plan, and incident-impact assessment.
DORA requires a register of information for contractual arrangements on ICT services, maintained at entity and where relevant sub-consolidated and consolidated levels.
The EBA Guidelines require institutions and payment institutions to maintain an updated register of all arrangements, with a common information set and extra fields for critical or important functions. The EBA register does not use the DORA ITS templates.
Use the inventory as a starting dataset, then reconcile it to DORA templates, identifiers, ICT-service categories, supported functions, and subcontractor records.
EBA-style evidence remains useful where it proves governance, criticality, due diligence, register discipline, and contract oversight, but it must be labelled against the DORA requirement it supports.
DORA creates a major ICT-related incident reporting process with initial notification, intermediate report, final report, standard templates, secure channels, and voluntary notification of significant cyber threats.
DORA gives competent authorities register access and creates an oversight framework for critical ICT third-party providers, including possible supervisory follow-up where risks are not addressed.
Escalate unresolved DORA gaps through management-body reporting, competent-authority readiness, contract remediation, and provider-risk governance rather than treating them as procurement exceptions.
DORA requires written contracts for ICT services and minimum provisions covering service description, locations, data protection, access and return of data, service levels, incident assistance, cooperation with authorities, termination, and training participation.
DORA requires financial entities to assess risks from subcontracting ICT services supporting critical or important functions, including chain complexity, location, data, concentration, monitoring, access, and termination triggers.
A legacy file may identify subcontracting permission, but DORA requires operational visibility into ICT subcontractors that underpin critical or important functions.
Require advance notice of material subcontracting changes, a right to approve or object, and termination rights where unapproved or impermissible subcontracting occurs.
EBA/GL/2019/02 covers arrangements in which a service provider performs a process, service, or activity that the institution or payment institution would otherwise undertake itself. Acquisition of goods, utilities, and services the institution would not otherwise perform are not merely because a third party supplies them.
Review cloud, SaaS, data, security, resilience, and support services under DORA even when they are not . Apply the EBA definition separately rather than relying on procurement labels.
EBA/GL/2019/02 is supervisory guidance addressed to competent authorities and to credit institutions, CRD investment firms, payment institutions, and electronic money institutions within its defined scope. It does not cover every financial entity listed in DORA.
Do not close a DORA gap by pointing only to guideline compliance. Show the DORA article, RTS, ITS, register field, contract clause, or incident-reporting artifact that now applies.
DORA defines a critical or important function by material impairment to financial performance, service continuity, soundness, or ongoing compliance if disrupted or defective.
The EBA Guidelines treat a function as critical or important when a defect or failure would materially impair continuing compliance, financial performance, or the soundness or continuity of banking and payment services. They also identify functions whose requires authorisation or is treated as critical under specified sector rules.
Attach the critical-or-important-function rationale to each contract, register row, subcontracting decision, exit plan, and incident-impact assessment.
DORA requires a register of information for contractual arrangements on ICT services, maintained at entity and where relevant sub-consolidated and consolidated levels.
The EBA Guidelines require institutions and payment institutions to maintain an updated register of all arrangements, with a common information set and extra fields for critical or important functions. The EBA register does not use the DORA ITS templates.
Use the inventory as a starting dataset, then reconcile it to DORA templates, identifiers, ICT-service categories, supported functions, and subcontractor records.
EBA-style evidence remains useful where it proves governance, criticality, due diligence, register discipline, and contract oversight, but it must be labelled against the DORA requirement it supports.
DORA creates a major ICT-related incident reporting process with initial notification, intermediate report, final report, standard templates, secure channels, and voluntary notification of significant cyber threats.
DORA gives competent authorities register access and creates an oversight framework for critical ICT third-party providers, including possible supervisory follow-up where risks are not addressed.
Escalate unresolved DORA gaps through management-body reporting, competent-authority readiness, contract remediation, and provider-risk governance rather than treating them as procurement exceptions.
DORA requires written contracts for ICT services and minimum provisions covering service description, locations, data protection, access and return of data, service levels, incident assistance, cooperation with authorities, termination, and training participation.
DORA requires financial entities to assess risks from subcontracting ICT services supporting critical or important functions, including chain complexity, location, data, concentration, monitoring, access, and termination triggers.
A legacy file may identify subcontracting permission, but DORA requires operational visibility into ICT subcontractors that underpin critical or important functions.
Require advance notice of material subcontracting changes, a right to approve or object, and termination rights where unapproved or impermissible subcontracting occurs.
Identify every ICT service and determine whether it supports a DORA critical or important function.
Apply the EBA definition separately and record whether the outsourced function is critical or important under EBA/GL/2019/02.
Reconcile the EBA register to the DORA register templates, then remediate DORA Article 30 clauses, subcontracting controls, access and audit rights, incident assistance, and exit strategies.
Keep incident reporting, subcontracting decisions, exit tests, and management-body reviews as DORA evidence even when the same provider is already in an EBA register.
What changed from outsourcing governance to DORA ICT third-party risk
DORA defines ICT third-party risk as ICT risk arising from ICT services provided by third-party providers or their subcontractors, including through arrangements. Its scope therefore includes ICT service arrangements that may not meet the EBA Guidelines' outsourcing definition.
The EBA Guidelines define as an arrangement in which a service provider performs a process, service, or activity that the institution or payment institution would otherwise undertake itself. They apply from 30 September 2019 and use stricter expectations for outsourcing of critical or important functions. DORA notes that this earlier framework did not fully address systemic concentration in critical ICT providers.
The EBA still lists the 2019 final report as applicable. A closed 2025 consultation proposes replacing it with guidance on sound management of non-ICT third-party risk; until the EBA publishes and applies final replacement guidance, treat that proposal as draft guidance rather than as a change to the binding DORA ICT-service rules or the current 2019 guideline baseline.
Run both tests. First decide whether the arrangement is an ICT service under DORA and whether it supports a critical or important function. Separately decide whether it is under EBA/GL/2019/02 and whether the outsourced function is critical or important under that guidance. Reuse evidence only after those conclusions are recorded.
Start with the ICT service and supported function, not the procurement label.
Classify whether the ICT service supports a critical or important function under DORA.
Check whether the existing register can populate the DORA register of information without losing DORA-required ICT-service, function, provider, and subcontractor data.
Remediate contracts where legacy clauses do not cover DORA access, audit, incident assistance, data-location, subcontracting, and exit requirements.
Register of information: reuse the outsourcing inventory carefully
DORA 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, distinguishing arrangements that support critical or important functions from those that do not.
The EBA Guidelines require institutions and payment institutions to maintain an updated register of all arrangements, with additional information for critical or important functions. DORA requires a different register covering all contractual arrangements for ICT services and prescribes standard relational templates. An EBA outsourcing register is therefore a useful input, not a complete DORA register.
Keep legacy identifiers only if they can be reconciled to DORA contract, provider, function, and ICT-service identifiers.
Record direct ICT third-party providers and relevant subcontractors that underpin ICT services supporting critical or important functions.
Use the register to evidence supervision readiness: competent authorities can request the full register or specified sections.
Do not treat a procurement vendor list as sufficient unless it identifies the ICT service, supported function, contract, provider, and criticality status.
Contract and subcontracting remediation priorities
DORA Article 30 sets minimum contractual content for ICT services and adds provisions for services supporting critical or important functions, including service levels, notice and reporting, contingency-plan testing, TLPT cooperation where applicable, access, inspection and audit rights, and exit strategies.
The EBA Guidelines already address sub-, data and system security, access and audit rights, termination, oversight, and exit strategies for outsourcing. DORA's 2025 subcontracting RTS is narrower in subject but more prescriptive for ICT services supporting critical or important functions or material parts of them. Financial entities must assess the subcontracting chain, notification of material changes, access rights, monitoring, objection, and termination conditions.
Map each legacy clause to DORA Article 30 before relying on it.
Add data-location, storage-location, incident-assistance, regulator-cooperation, and termination language where missing.
For critical or important functions, require subcontractor-chain visibility and material-change notice before changes take effect.
Preserve evidence that the financial entity, not the provider, made and approved the risk decision.
A useful comparison file should show which evidence satisfies DORA and which evidence only shows legacy governance. The same contract, risk assessment, or register row can be reused, but only if it contains the DORA-specific fields and approvals.
For reporting, DORA is separate from governance. Major ICT-related incidents are reported to competent authorities using DORA's initial notification, intermediate report, and final report structure; outsourcing a reporting task to a third party does not remove the financial entity's responsibility.
Keep the critical-or-important-function assessment with the contract and register row.
Retain due diligence showing provider suitability, information-security posture, resources, and concentration-risk assessment.
For incidents, keep classification records, reporting-template submissions, third-party reporter identity if used, root-cause analysis, and client-communication evidence where applicable.
This comparison helps test whether existing outsourcing records cover DORA register data, contract clauses, subcontracting controls, exit plans, incident reporting, and management-body accountability.
The EBA lists EBA/GL/2019/02 as applicable and separately identifies the closed consultation on draft third-party-risk guidance focused on non-ICT services.