Module 2: Scope of Application – Who and What Is Covered

Step 1 – Orienting DORA’s Scope (From ‘Who?’ to ‘How Much?’)

In Module 1 you saw what DORA is and why it matters. Now we move to a sharper question:

> Exactly who and what does DORA apply to – and to what extent?

Because DORA (Regulation (EU) 2022/2554) is an EU regulation (not a directive), it has been directly applicable in all EU Member States since 17 January 2025 (almost a year before today).

Understanding scope requires you to track three overlapping dimensions:

1. Personal scope – which entities?

• Financial entities (broadly defined)
• ICT third‑party service providers
• A sub‑set of those: Critical ICT third‑party providers (CTTPs) under direct EU‑level oversight

1. Material scope – which activities and services?

• ICT services supporting critical or important functions (CIFs)
• Cybersecurity, incident management, testing, and ICT third‑party risk management
• Information‑sharing arrangements on cyber threats

1. Territorial scope – where?

• EU‑established financial entities
• Non‑EU ICT providers and financial groups to the extent they serve EU financial entities or EU clients

You should constantly ask:

```text

Entity X + Service Y + Location Z

→ Does DORA apply? To which parts? With what intensity (proportionality)?

```

In the next steps we will:

• Precisely map which financial entities are in scope
• Distinguish ordinary ICT providers from CTTPs
• Examine extra‑territorial reach for non‑EU firms
• Analyse proportionality and overlaps with sectoral rules such as PSD2, MiFID II and Solvency II.

Step 2 – The Core In‑Scope Financial Entities (Article 2 DORA)

DORA’s personal scope is set out mainly in Article 2(1) and Annex I. It is intentionally broad: the idea is that any entity whose failure could impair financial stability or market integrity must be digitally resilient.

2.1 Main categories of financial entities

DORA explicitly includes (non‑exhaustive, simplified grouping):

1. Banking and credit

• Credit institutions (EU‑regulated banks)
• Payment institutions and account information service providers (AISPs) under PSD2
• Electronic money institutions (EMIs)

1. Investment and trading

• Investment firms (MiFID II)
• Crypto‑asset service providers (CASPs) authorised under MiCA when providing services to EU clients
• Central securities depositories (CSDs)
• Central counterparties (CCPs)
• Trading venues (regulated markets, MTFs, OTFs)
• Data reporting service providers (APA, ARM, CTP)

1. Insurance and pensions

• Insurance and reinsurance undertakings (Solvency II)
• Insurance intermediaries and reinsurance intermediaries
• Institutions for occupational retirement provision (IORPs)

1. Asset and fund management

• UCITS management companies
• Alternative investment fund managers (AIFMs)
• Managers of European venture capital funds (EuVECA)
• Managers of European social entrepreneurship funds (EuSEF)
• European long‑term investment fund (ELTIF) managers

1. Market infrastructure and others

• Trade repositories (EMIR)
• Credit rating agencies
• Securitisation repositories
• Benchmark administrators (BMR)
• Crowdfunding service providers (ECSPR)
• Crypto‑asset issuers of asset‑referenced tokens and e‑money tokens (under MiCA, where relevant)

2.2 Why is the list so long?

Historically, ICT risk rules were fragmented across sectoral frameworks:

• Banks: EBA Guidelines on ICT and security risk, EBA outsourcing guidelines
• Markets: ESMA guidelines, MiFID II organisational requirements
• Insurers: EIOPA guidelines, Solvency II

Since January 2025, DORA overlays a single horizontal framework that:

• Harmonises definitions (e.g., ICT‑related incident, critical or important function)
• Aligns minimum requirements for ICT risk management, incident reporting, testing, and third‑party risk
• Introduces centralised oversight of critical ICT providers

Key idea: If an entity is authorised or registered under EU financial services law, assume DORA applies unless explicitly excluded. The burden is on the entity to prove otherwise, not on the supervisor to justify inclusion.

Step 3 – Classify These Entities (Thought Exercise)

For each entity below, decide whether it is in scope of DORA as a financial entity, and briefly justify your reasoning.

1. A Luxembourg‑authorised UCITS fund manager that delegates portfolio management to a UK firm.
2. A BigTech cloud provider with no EU subsidiary, but with contracts directly with several EU banks.
3. A German industrial manufacturer that runs its own captive treasury to manage FX risk for the group.
4. A Lithuanian licensed e‑money institution offering digital wallets to EU consumers.
5. A DeFi protocol with no legal entity, but whose tokens are widely held by EU retail investors.

Your task (5–7 minutes):

• For each case, write down:
• In scope as financial entity? (Yes/No/Unclear)
• In scope as ICT provider? (Yes/No/Unclear)
• One sentence of legal/functional reasoning (e.g., reference to authorisation regime or lack thereof).

Then compare your reasoning with the indicative solution in the next step.

Step 4 – Worked Analysis of the Thought Exercise

Let’s analyse the previous scenarios using DORA’s logic.

1. Luxembourg UCITS fund manager

• Financial entity? Yes. UCITS management companies are explicitly listed.
• ICT provider? No, it is the user of ICT services.
• Key point: Delegation to a UK firm does not remove the UCITS manager from DORA’s scope; it must manage ICT risk of cross‑border outsourcing.

1. Non‑EU BigTech cloud provider contracting with EU banks

• Financial entity? No. It is not authorised under EU financial services law.
• ICT provider in scope? Yes, as an ICT third‑party service provider to EU financial entities.
• Potential CTTP? Yes, if designated by the Joint Oversight Forum (JOF) based on systemic importance, concentration, and substitutability.
• Key point: DORA’s oversight of CTTPs is explicitly extra‑territorial.

1. German industrial manufacturer with captive treasury

• Financial entity? Generally no, if it is not licensed as a bank, investment firm, or other regulated financial entity.
• ICT provider? No, unless it provides ICT services to regulated financial entities (unlikely here).
• Key point: Corporate treasuries of non‑financial groups are usually outside DORA, but their bank counterparties are inside.

1. Lithuanian e‑money institution (EMI)

• Financial entity? Yes. EMIs are explicitly covered (PSD2‑type entities).
• ICT provider? No, they are consumers of ICT services.
• Key point: EMIs must implement full DORA ICT risk management and incident reporting, proportionate to size and risk.

1. DeFi protocol with no legal entity

• Financial entity? Typically no, because DORA attaches to legal persons authorised or registered under EU financial law.
• ICT provider? Also typically no, unless a legal entity operates it as a service provider to a financial entity.
• Key point: This is an edge case where functional regulation collides with entity‑based law. If an EU‑authorised CASP or investment firm integrates the DeFi protocol into its offerings, that regulated firm becomes responsible for DORA compliance for the ICT dependencies.

Use this pattern of reasoning when confronted with ambiguous or novel business models.

Step 5 – ICT Third‑Party Providers vs. Critical ICT Third‑Party Providers

DORA draws a crucial distinction between:

1. ICT third‑party service providers (ICT TPPs)
2. Critical ICT third‑party service providers (CTTPs)

5.1 ICT third‑party service providers (broad notion)

An ICT TPP is any undertaking providing ICT services to one or more financial entities. ICT services include, among others:

• Cloud computing and hosting
• Data centres and infrastructure as a service (IaaS)
• Platform as a service (PaaS) and software as a service (SaaS)
• Managed security services (e.g., SOC, SIEM)
• Payment processing and messaging
• Data analytics and AI models used in critical decision chains

Under DORA, financial entities remain fully responsible for their regulatory obligations even when they outsource or rely on third‑party ICT services. This is a continuity with pre‑existing outsourcing frameworks, but DORA makes it more prescriptive, especially on:

• Contractual clauses
• Exit strategies and portability
• Concentration risk
• Sub‑outsourcing chains

5.2 Critical ICT third‑party providers (CTTPs)

A CTTP is an ICT TPP that has been formally designated as critical by the European Supervisory Authorities (EBA, ESMA, EIOPA) through the Joint Oversight Forum (JOF) mechanism.

Designation criteria (simplified):

• Systemic impact: Number and systemic importance of financial entities relying on the provider
• Concentration: Market share and degree of substitutability
• Nature of services: Support for critical or important functions (CIFs), cross‑border operations, real‑time services
• Incident history: Severity and frequency of past disruptions

Once designated, CTTPs are subject to:

• Direct oversight by an EU Lead Overseer (one of the ESAs)
• Mandatory information requests, inspections, and testing
• Remedial measures (e.g., security upgrades, resilience enhancements)
• Potential fines and periodic penalty payments for non‑compliance (via national implementation of enforcement powers)

Important nuance:

• All CTTPs are ICT TPPs, but only a small subset of ICT TPPs become CTTPs.
• DORA does not force CTTPs to be EU‑established, but it may constrain financial entities’ ability to use providers that refuse to cooperate with EU oversight.

Step 6 – Quick Check: ICT Provider vs. CTTP

Test your understanding of the distinction between ordinary ICT providers and CTTPs.

Step 7 – Territorial Scope and Extra‑Territorial Reach

DORA’s territorial scope is subtle and often misunderstood. It is not limited to entities incorporated in the EU.

7.1 EU‑established financial entities

All financial entities authorised or registered in an EU Member State fall squarely within DORA, regardless of where their ICT infrastructure is located. This includes:

• EU subsidiaries of non‑EU groups (e.g., an EU bank owned by a US parent)
• EU branches of non‑EU banks, to the extent EU law requires them to follow host‑state rules

7.2 Non‑EU ICT providers

Non‑EU ICT providers are drawn into DORA’s orbit indirectly and directly:

1. Indirectly, through contractual requirements imposed by EU financial entities:

• Financial entities must ensure contracts with ICT providers, wherever located, contain DORA‑compliant clauses (e.g., on access, audit, data location, incident reporting).
• If a non‑EU provider refuses, the EU financial entity may need to limit or exit the relationship.

1. Directly, if they are designated as CTTPs:

• A non‑EU cloud or security provider can be designated as a CTTP if it serves many EU financial entities or supports critical functions.
• The provider then faces direct EU oversight, even without an EU legal entity, though enforcement relies on cooperation, market access leverage, and Member State laws.

7.3 Non‑EU financial groups

Non‑EU headquartered groups with EU operations must handle tension between home‑state and EU requirements:

• The EU subsidiary is a full DORA subject and must comply even if the group’s global ICT architecture is centralised outside the EU.
• Group‑wide ICT arrangements (e.g., global cloud contracts, shared SOCs) must be DORA‑compatible for the EU entities (e.g., ensure EU regulators’ access to logs and data, appropriate data localisation if required by other EU law).

Analytical tip: When assessing territorial scope, ask:

```text

1. Is there an EU‑authorised financial entity involved? → DORA applies.
2. Does any ICT provider (EU or non‑EU) support that entity’s critical or important functions?
3. Could that provider be or become a CTTP based on systemic relevance?

```

Step 8 – Proportionality and Differentiated Obligations

DORA is risk‑based. It recognises that a small local broker should not be treated identically to a pan‑European CCP.

8.1 The proportionality principle

DORA repeatedly invokes proportionality: requirements must be applied in light of:

• Size and internal organisation of the financial entity
• Nature, scale, complexity, and risk profile of its services and activities
• Systemic importance and cross‑border footprint

Implications:

• Same articles, different depth. A small payment institution and a global bank both need ICT risk management, but the granularity of documentation, tooling, and testing can differ.
• No entity is exempt from core obligations, but some can use simplified approaches (e.g., less frequent advanced testing, leaner governance structures).

8.2 Examples of proportionality in practice

1. Threat‑led penetration testing (TLPT)

• Large, systemic entities may be required to undergo TLPT every 3 years, covering multiple critical functions and cross‑border operations.
• Smaller, less complex entities may rely on internal and external penetration tests without full TLPT, unless supervisors decide otherwise.

1. ICT risk governance

• A major bank will need a dedicated CISO function, multi‑layered committees, and extensive reporting to the board.
• A small investment firm might centralise ICT risk responsibilities in a single senior manager, with simpler reporting lines.

1. Incident reporting

• All entities must report major ICT‑related incidents, but the volume and complexity of incidents in a large trading venue will be much higher than in a small insurer.
• Supervisors may calibrate expectations on dashboards, automation, and analytics accordingly.

Exam‑style question to self‑check:

> Given two entities with identical balance sheets but very different ICT outsourcing models (one fully cloud‑based, one mostly on‑premise), how would proportionality apply to their DORA obligations?

A strong answer would recognise that ICT dependency and concentration risk, not just size, drive supervisory expectations.

Step 9 – Interaction with PSD2, MiFID II, Solvency II and Other Regimes

DORA does not replace sector‑specific frameworks like PSD2, MiFID II, Solvency II, EMIR, MiCA, etc. Instead, it overlays and harmonises ICT‑related aspects.

9.1 From fragmented guidelines to a single horizontal layer

Before DORA, ICT and outsourcing risk were governed largely by soft law (EBA, ESMA, EIOPA guidelines) and scattered articles in sectoral legislation. This created:

• Divergent national implementations
• Overlaps and gaps (e.g., different definitions of critical functions)
• Regulatory arbitrage opportunities

From January 2025, DORA:

• Centralises core ICT risk requirements (governance, incident reporting, testing, third‑party risk) in one Regulation.
• Leaves prudential, conduct, and product‑specific rules to sectoral frameworks.

9.2 How they fit together (high‑level mapping)

• PSD2 / PSD3 (when applicable)
• Still govern payment services authorisation, conduct, strong customer authentication (SCA), etc.
• DORA governs ICT resilience of payment institutions and AISPs (e.g., incident reporting formats, ICT governance, third‑party cloud risk).

• MiFID II / MiFIR
• Still govern investor protection, best execution, transparency, algorithmic trading rules.
• DORA governs ICT risk of trading systems, algo platforms, and market data infrastructure.

• Solvency II
• Still governs capital, risk management, and governance for insurers.
• DORA provides a detailed ICT layer for cyber resilience, incident reporting, and outsourcing to ICT providers.

• MiCA
• Governs authorisation and conduct of CASPs and issuers.
• DORA governs ICT resilience of those CASPs/issuers when they are within DORA’s list of financial entities.

Conflict rule: Where both DORA and sectoral law regulate ICT‑related aspects, DORA is intended as the lex specialis for operational resilience. But entities must still comply with all other sectoral obligations (e.g., PSD2 SCA, MiFID II algo controls).

For advanced analysis, always ask:

```text

Is this requirement about:

• Operational resilience of ICT? → DORA leads.
• Prudential capital, conduct of business, or product rules? → Sectoral regime leads.
• Both? → Apply both; interpret in a consistent, non‑duplicative way.

```

Step 10 – Scope Application Scenario

Apply what you’ve learned to a realistic multi‑regime scenario.

Step 11 – Flashcard Review of Key Scope Concepts

Use these flashcards to consolidate your understanding of DORA’s scope of application.

Step 12 – Final Analytical Exercise: Is This Organisation in Scope?

Consider the following composite organisation in 2025:

> FinCloudX Group: A US‑headquartered BigTech firm. It has:

> • A Dublin‑based subsidiary providing cloud and AI‑driven risk analytics to EU banks and insurers.

> • A Lithuanian licensed EMI offering digital wallets to EU consumers, fully reliant on the Dublin cloud platform.

> • A Berlin‑based RegTech unit selling compliance software (on‑premise) to EU investment firms; it does not operate the software post‑deployment.

Your tasks:

1. Classify each part of the group:

• Which entities are financial entities under DORA?
• Which are ICT third‑party providers?
• Which could realistically be designated as CTTPs, and why?

1. Assess proportionality:

• Which parts of the group would face the heaviest DORA burden, and on what basis (size, systemic importance, ICT concentration)?

1. Map regime overlaps:

• For the Lithuanian EMI, identify at least two non‑DORA regimes that still apply and explain in one sentence each how they interact with DORA.

Spend 5–7 minutes writing a structured answer. When you’re done, compare against this high‑level solution outline:

<details>

<summary>Show indicative solution outline</summary>

1. Classifications

• Lithuanian EMI → Financial entity under DORA (PSD2/EMI‑type). Full DORA obligations apply, proportionate to its scale.
• Dublin cloud & AI analytics subsidiary → ICT TPP to EU financial entities (including the EMI). Potential CTTP if widely used by EU banks/insurers and supporting CIFs.
• Berlin RegTech unit → Typically an ICT TPP only where it operates or maintains the software as a service; if it merely sells on‑premise software with no ongoing service, DORA impact is limited and mainly indirect.

1. Proportionality

• The EMI faces a significant DORA burden as a regulated financial entity with high ICT dependency (fully cloud‑based).
• The Dublin cloud provider may face the heaviest burden if designated a CTTP (direct EU oversight, inspections, remedial measures).
• The Berlin RegTech likely faces a lighter DORA impact, unless it evolves into a SaaS provider for critical functions.

1. Regime overlaps for the EMI

• PSD2 / e‑money rules → Continue to govern payment services authorisation, safeguarding of funds, and SCA; DORA adds ICT resilience obligations.
• GDPR → Governs personal data processing; DORA’s logging and incident reporting must be implemented in a GDPR‑compliant way (data minimisation, purpose limitation, breach notification alignment).

</details>

Use this as a template for analysing any new business model you encounter in practice or exam scenarios.