Module 12: Case Studies – Applying DORA in Different Financial Entities

Module 12 Overview – From Theory to Practice

In this module, you apply DORA in concrete organizational settings.

Regulatory context (as of December 2025)

• DORA: Regulation (EU) 2022/2554 on digital operational resilience for the financial sector.
• Entered into force in January 2023 and applies from 17 January 2025.
• Replaces and harmonizes a patchwork of national ICT‑risk rules and earlier EBA/EIOPA/ESMA guidelines.

We focus on how DORA looks in practice for different entities:

• A large universal bank with complex ICT and many critical third‑party dependencies.
• A mid‑size insurer aligning DORA with Solvency II and existing cyber programs.
• A fintech/payment institution with a cloud‑native, cross‑border business model.
• Smaller / less complex entities applying proportionality.

You should already know from previous modules:

• How to build a DORA implementation roadmap (Module 10).
• How to design a steady‑state DORA operating model and controls (Module 11).

Your challenge in this module is to:

1. Translate abstract DORA requirements into entity‑specific actions.
2. Use proportionality rigorously, not as an excuse for under‑compliance.
3. Anticipate typical pitfalls and design mitigations.

We will work through three core case studies plus a proportionality mini‑case, with interactive decision points.

Step 1 – Rapid DORA Lens: What Changes in Practice?

Before diving into cases, apply a systematic DORA lens. For any entity, you can ask:

1. Scope & perimeter

• Which ICT systems, processes, and third‑party services fall under DORA?
• Where are the critical or important functions (CIFs), and who/what supports them?

1. Five DORA pillars in practice
2. ICT risk management – governance, policies, risk assessment, lifecycle controls.
3. ICT‑related incident management & reporting – classification, escalation, reporting to authorities (including major incident reporting).
4. Digital operational resilience testing – from basic testing to threat‑led penetration testing (TLPT) for larger players.
5. ICT third‑party risk management (TPRM) – including critical ICT third‑party providers (CTPPs) and concentration risk.
6. Information sharing – participation in information‑sharing arrangements on cyber threats.

1. Proportionality

• How do size, business model, risk profile, and complexity justify different levels of:
• Documentation detail
• Testing intensity
• Governance layering
• Where is proportionality not a valid excuse (e.g., governance responsibilities, major incident reporting)?

In the next steps, you will apply this lens to each case, explicitly stating:

> “Given this entity’s profile, what does DORA require in practice, and what can be scaled?”

Step 2 – Case Study A: Large Universal Bank (Scenario Setup)

Scenario A – "EuroGlobal Bank" (Large Universal Bank)

Profile

• Headquartered in the EU; operations in 15+ EU/EEA countries.
• Activities: retail, corporate, investment banking, asset management, custody.
• ICT landscape:
• Legacy core banking on mainframe, multiple regional data centers.
• Large middleware layer, hundreds of interfaces.
• Significant use of public cloud for analytics, mobile banking front‑end, CRM.
• Third‑party exposure:
• 2 global cloud providers, 1 major core‑banking vendor, multiple SaaS providers.
• Several providers are likely to be designated Critical ICT Third‑Party Providers (CTPPs) under DORA.

Pre‑DORA status

• Mature ITIL‑based IT service management.
• Strong Basel/CRD‑driven operational risk framework.
• Some alignment with EBA ICT and security risk guidelines, but fragmented by region.

Your task

You are acting as the DORA design lead. For this bank, identify three high‑impact design decisions under DORA:

1. Group‑wide vs. local implementation – how to balance centralization vs. local legal requirements.
2. Critical function mapping – which businesses and systems are deemed CIFs.
3. CTPP strategy – how to manage and govern relationships with key cloud and core‑banking providers.

In the next interactive step, you will choose and justify a design option for each decision.

Step 3 – Design Choices for the Large Bank

Work through the following three decision points. For each, pick an option and write down (mentally or on paper):

• 1–2 key advantages
• 1–2 key risks or drawbacks
• How you would document proportionality in this choice

---

Decision 1 – Group‑wide vs. Local Implementation

Option A – Strongly centralized DORA framework

• One group‑wide ICT risk management framework, policies, and standards.
• Local entities adopt with minimal add‑ons.

Option B – Hybrid model

• Group sets minimum DORA baseline.
• Local entities can tighten or tailor controls significantly.

Option C – Largely decentralized

• Each material entity designs its own DORA framework within high‑level group principles.

> Exercise: Which option is most defensible to a cross‑border college of supervisors, and why?

---

Decision 2 – Critical Function Mapping

You must identify critical or important functions (CIFs) and their supporting assets.

Option A – Narrow definition

• Only functions whose disruption could threaten the bank’s viability or financial stability.

Option B – Moderate definition

• Includes viability‑threatening functions plus those with major customer impact (e.g., national payment systems, mobile banking).

Option C – Broad definition

• Almost all customer‑facing and internal functions are classified as CIFs.

> Exercise: Which option best balances risk sensitivity and operational manageability under DORA? How does this choice impact testing scope and TPRM obligations?

---

Decision 3 – CTPP Strategy for Cloud Providers

DORA expects robust management of critical ICT third‑party providers.

Option A – Concentrated strategy

• Keep 1–2 main cloud providers and deepen resilience arrangements (exit strategy, data portability, robust SLAs, on‑site inspections where possible).

Option B – Diversified multi‑cloud

• Use 3–4 cloud providers to reduce concentration risk.

Option C – Hybrid, with strong on‑prem fallback

• Limit cloud for CIFs; maintain on‑premise or private cloud for the most critical workloads.

> Exercise: For your chosen option, list:

> - One DORA‑specific control you must harden (e.g., exit strategies, testing of failover).

> - One governance mechanism (e.g., CTPP oversight committee, board reporting).

When you’re done, compare your reasoning with the next step’s model answers and pitfalls.

Step 4 – Model Answers & Pitfalls for the Large Bank

Below is a sample high‑quality reasoning an examiner might expect.

Decision 1 – Group‑wide vs. Local

Preferred (often): Option B – Hybrid model

• Why?
• DORA is an EU regulation with direct effect, but national competent authorities (NCAs) and sectors (banking, markets, insurance) may apply slightly different expectations.
• A hybrid model ensures consistency (group baseline) while allowing local tightening to reflect NCA expectations, data localization, or specific payment systems.
• Pitfalls if fully centralized (A):
• Risk of non‑compliance where local laws require stricter controls (e.g., local incident timelines, sectoral rules).
• Pitfalls if decentralized (C):
• Fragmentation, inconsistent incident classification, and duplicated testing.

Decision 2 – Critical Function Mapping

Preferred (often): Option B – Moderate definition

• Why?
• Reflects DORA’s focus on material customer impact and financial stability, not just going‑concern viability.
• Keeps the CIF perimeter manageable for deep testing and strong TPRM.
• Pitfalls of narrow (A):
• Underestimates critical retail and payment services (e.g., mobile banking outages causing systemic reputational damage).
• Pitfalls of broad (C):
• Overloads testing programs, dilutes focus on the truly critical.

Decision 3 – CTPP Strategy

Reasonable choices: A or C, depending on architecture

• Option A – Concentrated
• DORA accepts concentration if risks are actively managed.
• Key DORA controls:
• Documented exit strategy and substitution plans.
• Contractual rights for access, audit, and information.
• Regular resilience testing of failover and data recovery.
• Option C – Hybrid
• Can reduce cloud‑concentration risk for the most critical functions.
• But must ensure on‑prem environments meet equally strong DORA controls.

Common pitfalls observed in early DORA programs (2024–2025):

1. Treating cloud concentration as purely a technical architecture issue, not a board‑level risk appetite decision.
2. Inconsistent incident classification across jurisdictions, leading to under‑ or over‑reporting.
3. Using legacy outsourcing policies without updating them to DORA’s ICT‑specific requirements and the CTPP framework.

> Takeaway: For large banks, DORA is less about inventing new controls and more about harmonizing, deepening, and documenting existing practices across the group.

Step 5 – Case Study B: Mid‑Size Insurer Aligning DORA & Solvency II

Scenario B – "SecureLife Insurance" (Mid‑Size Insurer)

Profile

• Operates in 3 EU countries, life and non‑life products.
• Balance sheet size: mid‑tier in each market; uses standard formula under Solvency II.
• ICT landscape:
• Policy administration system hosted by an external data‑center provider.
• Claims management and pricing tools partly on public cloud.
• Heavy use of outsourced IT support and managed security services.

Pre‑DORA status

• Mature Solvency II risk management (ORSA, risk appetite, control functions).
• Cybersecurity program aligned with ISO/IEC 27001.
• Outsourcing policy aligned with EIOPA Guidelines on Outsourcing to Cloud Service Providers (2019).

Key integration questions

1. How to integrate DORA ICT risk into the Solvency II risk framework?

• Should ICT risk remain a sub‑category of operational risk, or be treated as a stand‑alone category with its own metrics?

1. How to avoid duplication between DORA and existing cyber/ISO controls?

• Where can the insurer reuse evidence and assurance activities?

1. How to apply proportionality?

• As a mid‑size player, the insurer is unlikely to be in scope for TLPT (threat‑led penetration testing) but must still have robust testing.

In the next interactive step, you will map controls and identify overlaps.

Step 6 – Mapping DORA to Solvency II & Cyber Controls

Treat this as a mini‑design workshop.

Task 1 – Control Mapping

For each DORA pillar below, list one existing control SecureLife likely already has under Solvency II or ISO 27001, and one gap that DORA introduces.

1. ICT Risk Management

• Existing control (example): Board‑approved risk appetite including operational risk.
• Possible DORA gap: Lack of explicit ICT risk tolerance statements and ICT risk register.

1. Incident Management & Reporting

• Existing: Cyber incident response plan, aligned with ISO 27001 Annex A.
• Possible DORA gap: No formal classification scheme aligned to DORA’s major incident thresholds and regulatory reporting timelines.

1. Digital Operational Resilience Testing

• Existing: Annual penetration testing and business continuity plan (BCP) exercises.
• Possible DORA gap: No risk‑based testing program explicitly covering all critical functions and third‑party dependencies.

1. ICT Third‑Party Risk Management

• Existing: Solvency II‑driven outsourcing policy, cloud outsourcing assessments.
• Possible DORA gap: Missing ICT‑specific clauses (e.g., data location, security incident notification, access & audit rights) and concentration risk analysis.

> Exercise: For each pillar, decide which existing committee or function (e.g., Risk Committee, ORSA working group, CISO) should own the DORA enhancements to avoid creating a parallel governance universe.

Task 2 – Proportional Testing Program

Design a proportionate testing strategy for SecureLife:

• Which tests are strictly necessary (e.g., vulnerability scans, scenario‑based BCP tests, targeted red‑teaming)?
• How often should each test run, given size and complexity?
• Which tests should explicitly include third‑party providers (e.g., data‑center failover, cloud backup restoration)?

Write down a 1–2 line rationale for why your testing program is proportionate yet robust under DORA.

Step 7 – Quick Check: DORA & Solvency II Alignment

Test your understanding of how DORA integrates with existing Solvency II frameworks.

Step 8 – Case Study C: Cloud‑Native Fintech / Payment Institution

Scenario C – "FlashPay" (Fintech Payment Institution)

Profile

• EU‑licensed payment institution operating cross‑border via passporting.
• Offers instant P2P payments and merchant acquiring via API.
• ICT landscape:
• Fully cloud‑native (microservices on public cloud, serverless functions).
• Heavy use of managed services (databases, messaging, observability tools).
• CI/CD pipelines with multiple daily deployments.

Risks & characteristics

• Lean organizational structure; strong DevOps culture.
• Very high dependency on one hyperscale cloud provider.
• Serves as a critical payment channel for small merchants in several countries.

DORA challenges

1. Fast‑changing environment vs. documentation

• How to maintain up‑to‑date asset inventories, data flows, and risk assessments when architecture changes weekly.

1. Cloud concentration and CTPP management

• How to demonstrate control over a single cloud provider that may be designated as a CTPP.

1. Proportional governance

• How to implement DORA‑level governance with limited headcount while avoiding a "paper‑only" framework.

In the next interactive step, you will design pragmatic controls for FlashPay that still meet DORA expectations.

Step 9 – Operationalizing DORA in a Cloud‑Native Fintech

Task 1 – Living Architecture & Asset Management

FlashPay’s architecture changes frequently. DORA still expects:

• An up‑to‑date ICT asset inventory.
• Clear mapping of critical functions to systems and third parties.

> Exercise: Propose 2–3 practical mechanisms to keep the inventory and mappings current in a DevOps environment. Examples to consider:

> - Integrating asset inventory with CI/CD pipelines (automatic registration of new services).

> - Using infrastructure‑as‑code (IaC) repositories as the source of truth for architecture.

> - Automated tagging of cloud resources linked to business functions.

Write down how each mechanism would reduce manual work while improving accuracy.

---

Task 2 – Cloud Concentration & Exit Strategy

FlashPay relies on a single hyperscale cloud provider.

> Exercise: Design a DORA‑compliant exit and substitution strategy that is realistic for a small fintech. Consider:

> - What data backup and portability measures are essential?

> - What time horizon for exit is plausible (months/years) and how to justify it as proportionate?

> - Which services (e.g., core payment processing vs. analytics) must have stronger portability options?

---

Task 3 – Proportionate Governance

FlashPay has:

• CEO, CTO, CISO (part‑time), Head of Compliance, small engineering team.

> Exercise: Sketch a minimal but robust governance structure that satisfies DORA:

> - Which body (e.g., combined Risk & Compliance Committee) oversees ICT risk?

> - How often should ICT risk and incident reports go to the board?

> - How can you embed secure‑by‑design and change‑risk assessment into DevOps workflows without paralysing deployment speed?

Aim for lean governance that still shows clear accountability and oversight.

Step 10 – Flashcards: Proportionality & Common Pitfalls

Flip these cards to reinforce key ideas about proportionality and implementation pitfalls across the case studies.

Step 11 – Synthesis Quiz: Matching Approaches to Entities

Apply what you’ve learned by matching implementation approaches to the right entity type.

Step 12 – Wrap‑Up: Comparing the Case Studies

Across the three main cases, DORA’s core ideas are constant, but implementation differs:

1. Large Universal Bank

• Focus on group‑wide consistency, cross‑border coordination, and CTPP strategy.
• Key challenges: fragmentation, complex legacy ICT, multiple supervisors.

1. Mid‑Size Insurer

• Focus on integration with Solvency II and existing cyber/outsourcing frameworks.
• Key challenges: avoiding duplication, designing a proportionate testing program.

1. Cloud‑Native Fintech / Payment Institution

• Focus on cloud concentration, DevOps‑friendly governance, and living documentation.
• Key challenges: demonstrating control and resilience with limited staff and rapid change.

1. Proportionality in Smaller / Less Complex Entities (general lesson)

• Use simpler governance structures, fewer committees, and lighter documentation.
• But maintain clear accountability, risk‑based testing, and effective third‑party oversight.

> Reflection prompt: Choose one of the three entities. In 3–4 bullet points, outline:

> - Its top two DORA risks.

> - The most important design decision you would make.

> - One pitfall you would actively avoid.

This ability to contextualize DORA to different organizational profiles is exactly what supervisors and employers expect from advanced practitioners.