Artifact GuideEU

EU DORA Scope and Covered Entities

Use this page to classify DORA scope by entity type, ICT service dependency, critical or important function, and group-level evidence.

Grounded in DORA, register-of-information templates, and EU technical standards for ICT third-party providers supporting critical or important functions.

Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
5

Cited legal and guidance references.

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

DORA scope work should start with a classification record, not a generic cyber checklist. The useful question is whether the legal entity is a DORA financial entity, whether an ICT third-party provider is involved, whether the ICT service supports a critical or important function, and whether the evidence must be held at entity, branch, sub-consolidated, or consolidated level.

Section 1

Classify the entity before classifying the control work

DORA Article 2 lists the covered financial entity categories and separately includes ICT third-party service providers. The financial-entity list covers banks, payment and e-money institutions, account information service providers, investment firms, crypto-asset service providers and issuers of asset-referenced tokens, central securities depositories, central counterparties, trading venues, trade repositories, fund managers and management companies, data reporting service providers, insurance and reinsurance undertakings, insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries, IORPs, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, and securitisation repositories.

A scope record should therefore identify the exact authorised entity, its regulated category, its competent-authority perimeter, and any branch or group role. Do not classify a product team, platform, or supplier as in scope until the legal entity using or providing the ICT service has been named.

  • Record the legal name, LEI where available, regulated activity, Member State or branch context, and DORA Article 2 category.
  • Separate financial entities from ICT third-party service providers; DORA uses both categories, but the obligations and evidence flows are different.
  • For multi-licensed groups, classify each financial entity rather than assuming one group answer covers every licence.
  • Where a group service company provides ICT services internally, treat the intragroup provider as part of the ICT third-party risk map rather than ignoring it.
Section 2

Identify exclusions and proportionality without erasing the record

DORA excludes specific categories from Article 2 scope, including AIFMs referred to in Article 3(2) of the AIFMD, insurance and reinsurance undertakings referred to in Article 4 of Solvency II, IORPs operating schemes with no more than 15 members in total, MiFID-exempt natural or legal persons, insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries that are micro, small, or medium-sized enterprises, and post office giro institutions. Member States may also exclude certain CRD Article 2(5) entities located in their territory.

Proportionality is not an exemption from DORA. Article 4 ties implementation to the financial entity's size, overall risk profile, and the nature, scale, and complexity of its services, activities, and operations. The practical output is a narrower or simpler control and evidence set where justified, not a blank scope decision.

  • Write the exclusion basis as a legal-entity fact, with the directive or DORA category that creates the exclusion.
  • For small or simple entities, record the proportionality factors used to scale ICT risk management, incident, testing, and third-party work.
  • Do not rely on a supplier certificate, internal policy label, or customer segment as a DORA exclusion.
  • Reassess scope when the entity gains a new licence, opens a branch, changes group structure, or adds ICT services supporting a critical or important function.
Section 3

Classify ICT services by critical or important function

DORA defines a critical or important function by the consequence of disruption or defective performance: material impairment to the financial entity's performance, soundness, service continuity, authorisation conditions, or other financial-services obligations. Scope analysis should therefore connect each ICT service to the business function it supports and to the consequence of losing that service.

The register-of-information templates make this classification operational. They ask for the function identifier, the financial entity using the ICT service, whether the service supports a critical or important function, data location and sensitivity where relevant, reliance level, substitutability, alternatives, and subcontractors that effectively underpin services supporting critical or important functions.

  • Create one function record per financial entity, licensed activity, and function combination where the register template requires unique identification.
  • Classify reliance as not significant, low, material, or full using the register template logic rather than a free-text label.
  • Document whether an alternative ICT provider exists and how difficult migration or reintegration would be.
  • Treat critical or important function classification as a trigger for contract policy, due diligence, monitoring, audit rights, exit planning, and subcontractor visibility.
Section 4

Map ICT third-party providers, intragroup providers, and subcontractors

DORA defines an ICT third-party service provider as an undertaking providing ICT services and defines ICT services broadly as digital and data services provided through ICT systems on an ongoing basis, excluding traditional analogue telephone services. Intragroup ICT service providers are not outside the analysis; the DORA contract-policy RTS says intragroup providers should be considered ICT third-party service providers for the policy.

For ICT services supporting critical or important functions, the record should show the direct provider, any intragroup links, the ICT service supply chain, and subcontractors that effectively underpin the service. Subcontracting risk does not transfer ultimate responsibility away from the financial entity's management body.

  • For each arrangement, store the contractual reference number, signing entity, entity making use of the ICT service, provider identifier, service type, function identifier, and provider country or data-location facts where required.
  • Use LEI or EUID for legal-person ICT providers where the register instructions require those identifiers; third-country legal-person providers use LEI in the register template logic.
  • Include intragroup links when one group entity signs or provides ICT services for another group entity.
  • For critical or important functions, identify subcontractors whose disruption would impair security or continuity of service provision.
Section 5

Decide when provider criticality is a supervisory designation question

A financial entity's DORA scope decision is separate from the EU process for designating critical ICT third-party service providers. A cloud, software, data-centre, managed-security, or other ICT provider may be important to one financial entity even if it has not been designated critical by the ESAs. Conversely, ESA criticality designation is assessed using systemic criteria across financial entities and categories.

Delegated Regulation 2024/1502 specifies a two-step ESA assessment for critical ICT third-party providers. It uses factors such as the share of financial entities using the same ICT services for critical or important functions, systemic character of the financial entities relying on those services, the critical nature of the ICT service, and substitutability or migration difficulty.

Does DORA apply only to banks?

No. DORA Article 2 covers many financial entity types, including payment, e-money, investment, crypto-asset, market infrastructure, fund, insurance, pension, rating, benchmark, crowdfunding, and securitisation-repository entities, plus ICT third-party service providers.

Is an ICT supplier automatically a critical ICT third-party provider under DORA?

No. A supplier can support a financial entity's critical or important function without being designated critical by the ESAs. Critical-provider designation is a separate supervisory process based on systemic impact, financial-entity reliance, service criticality, and substitutability.

What evidence proves a DORA scope classification?

Keep the legal-entity classification, regulated activity, branch or group role, Article 2 category or exclusion, function map, ICT service and provider identifiers, contractual reference numbers, critical-or-important-function assessment, reliance level, alternatives assessment, and approval history.

  • Do not wait for ESA critical-provider designation before registering and managing an ICT provider that supports a critical or important function.
  • Flag provider concentration where several in-scope entities, licensed activities, or group companies depend on the same provider or same subcontractor.
  • Use substitutability, migration difficulty, and alternative-provider analysis as scope evidence for both internal resilience planning and register quality.
  • Keep the provider-criticality record aligned with register data because ESA assessments rely on registers of information and other available information.
Primary sources

References and citations

eur-lex.europa.eu
Referenced sections
  • Article 3 defines critical or important function; Articles 8, 11, 12, and 28 connect ICT dependencies, continuity, and third-party risk to those functions.
"critical or important function"
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 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
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 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.