Module 13: DORA for ICT and Cloud Service Providers

Step 1 – Why DORA Matters for ICT and Cloud Providers

Digital Operational Resilience Act (DORA) – Regulation (EU) 2022/2554 – has applied since 17 January 2025 (about 11 months ago relative to today).

Until DORA, most EU ICT risk rules targeted financial entities (FEs), not their technology suppliers. DORA changes this by:

• Making FEs directly accountable for ICT risk – including risks from ICT and cloud providers.
• Creating a new oversight framework for critical ICT third‑party service providers (CTPPs).
• Requiring much more granular contractual and technical controls in ICT and cloud services.

From an ICT or cloud provider’s perspective, you need to think in three layers:

1. Baseline obligations when serving EU financial entities (even if you are not designated critical).
2. Additional obligations if you are designated a critical ICT third‑party provider.
3. Global alignment – how to design services and contracts that work across EU and non‑EU regulatory regimes (e.g., UK, US, APAC).

In this module you will:

• Map DORA provisions to your role as an ICT/cloud provider.
• Analyse what changes if you are designated critical.
• Design service features and contract clauses that help FEs comply.

Keep in mind: DORA is directly applicable EU law (a Regulation, not a Directive). It co‑exists with sectoral rules (e.g., EBA/ESMA/EIOPA guidelines) but overrides inconsistent national rules.

Step 2 – Who Is in Scope? Mapping Your Services to DORA

DORA uses the term ICT third‑party service provider broadly. As an ICT/cloud provider, you are in scope if you provide services that support the ICT of an EU financial entity.

2.1. Typical in‑scope providers

You are usually in scope if you offer, for example:

• Cloud computing services: IaaS, PaaS, SaaS, serverless platforms, container orchestration.
• Data centres and hosting: colocation, managed hosting, private cloud.
• Network services: connectivity, VPN, SD‑WAN, DDoS protection.
• Core software: core banking engines, payments platforms, trading systems, risk engines.
• Security services: SOC, SIEM, MDR, identity and access management.
• Support and maintenance: remote administration, managed services.

2.2. Key distinction – ICT provider vs. Critical ICT provider

• ICT third‑party provider (ICT TPP): any external provider offering ICT services to FEs.
• Critical ICT third‑party provider (CTPP): a small subset of ICT TPPs designated as critical at EU level.

Designation as CTPP depends on factors such as:

• Systemic impact: how many FEs rely on you and how important your services are.
• Substitutability: how easily FEs can switch away.
• Concentration risk: geographic and sectoral concentration of your services.

This designation is made by the Joint Committee of the ESAs (EBA, ESMA, EIOPA), with a Lead Overseer appointed for each CTPP.

Your first analytical task as a provider:

• Map all your services used by EU FEs.
• Classify them by criticality for FE operations (e.g., supports payments, trading, settlement vs. internal HR).
• Estimate your market penetration in the EU financial sector.

This mapping helps you anticipate whether you are likely to be designated critical and which services will be scrutinised.

Step 3 – Thought Exercise: Are You Likely to Be Critical?

Imagine you are the Chief Risk Officer of a large cloud provider.

You run three major service lines in the EU:

1. Cloud A – General‑purpose IaaS/PaaS used by ~60% of large EU banks and CCPs.
2. Cloud B – Niche analytics SaaS used by 10–15% of asset managers.
3. Cloud C – Internal HR SaaS used by a few insurers for payroll (non‑core to their financial services).

Task (3–4 minutes):

1. Rank the three service lines by likelihood of being assessed as critical under DORA and justify your ranking.
2. For the service you ranked as most likely to be critical, list three indicators regulators might look at (e.g., substitutability, number of FEs, type of FE).
3. Identify one piece of data you do *not* currently collect that would help you argue against being critical (e.g., evidence of easy substitutability, multi‑cloud usage by clients).

Write down bullet‑point answers as if preparing a regulatory engagement briefing. Focus on evidence and metrics, not intuition.

Step 4 – Baseline Obligations: What FEs Now Expect from ICT Providers

Even if you are not designated as a CTPP, DORA amplifies what financial entities will demand from you. FEs must be able to demonstrate to supervisors that their ICT TPPs support DORA‑level resilience.

Key expectation areas (from the FE’s perspective):

1. Risk‑based service design

• Clear service descriptions, dependencies, and boundaries.
• Documented RTO/RPO capabilities and scalability limits.
• Evidence of threat‑led design (e.g., resilience to DDoS, ransomware, cloud region failure).

1. Robust ICT security

• Strong identity and access management (MFA, least privilege, privileged access monitoring).
• Data protection: encryption in transit and at rest, key management, data integrity controls.
• Secure development lifecycle (SDLC): code reviews, vulnerability management, secure configuration baselines.

1. Operational resilience & continuity

• Tested business continuity and disaster recovery (BC/DR) plans.
• Geographical redundancy and documented failover patterns.
• Capacity management and stress‑testing for peak loads.

1. Incident management & reporting

• 24/7 monitoring and clear incident severity levels.
• Ability to notify FEs quickly with structured incident reports (root cause, impact, remediation).
• Support for FEs’ regulatory reporting timelines (DORA has strict deadlines for major incidents).

1. Transparency & auditability

• Right for FEs (and sometimes their supervisors) to obtain information, audit reports, and assurance.
• Support for independent audits, certifications (e.g., ISO 27001, SOC 2), and penetration tests.

Your challenge as a provider is to industrialise these capabilities so they are:

• Standardised across customers.
• Documented in a way FEs can plug into their DORA compliance evidence.
• Configurable enough to support different FE risk appetites without bespoke engineering for each client.

Step 5 – Example: Designing a DORA‑Aligned Cloud Storage Service

Consider a cloud provider offering object storage used by EU banks for transaction data.

5.1. Service design adaptations

To support DORA, the provider might:

• Define resilience tiers:
• Tier 1: Single region, standard durability – for non‑critical data.
• Tier 2: Multi‑AZ within a region, higher durability.
• Tier 3: Multi‑region replication with automated failover.

• Publish explicit metrics:
• Availability SLAs (e.g., 99.95%, 99.99%).
• Supported RPO options (e.g., near‑real‑time replication vs. hourly snapshots).
• Maximum supported object size, throughput, and latency bands.

• Embed security controls:
• Default encryption at rest with customer‑managed keys as an option.
• Bucket‑level access policies with fine‑grained IAM.
• Built‑in object versioning and immutable storage (WORM) for regulatory records.

5.2. Documentation for FE DORA compliance

The provider prepares a DORA support pack for FEs:

• Service description: architecture diagrams showing regions, AZs, replication.
• Shared responsibility matrix: who handles encryption keys, IAM policy design, data classification.
• Control mapping: table mapping DORA articles (e.g., on ICT risk management, incident handling) to provider controls and customer responsibilities.
• Assurance artefacts: SOC 2 Type II report, ISO 27001 certificate, penetration test summaries.

5.3. Why this matters

Under DORA, the financial entity must show supervisors that:

• The storage design meets its impact tolerance for critical services.
• It understands failure modes and has tested continuity plans.

By pre‑packaging technical and documentary controls, the provider makes it easier for many FEs to meet DORA without each one running its own bespoke due diligence exercise.

Step 6 – Critical ICT Third‑Party Providers and the Lead Overseer

If you are designated a Critical ICT Third‑Party Provider (CTPP), you remain a private company, but you come under direct EU oversight.

6.1. Oversight structure

• Joint Committee of the ESAs: decides which ICT providers are critical.
• Lead Overseer (one of EBA, ESMA, EIOPA):
• Coordinates oversight of the CTPP.
• Develops an oversight plan tailored to the provider.
• Can request information, documentation, and meetings with senior management.

6.2. What the Lead Overseer can do

A Lead Overseer can:

• Conduct general investigations and on‑site inspections (including at data centres and development sites).
• Review ICT risk management, security, and resilience frameworks.
• Request remedial actions and set deadlines.
• In serious cases, recommend to competent authorities that FEs temporarily suspend or terminate contracts with the CTPP (this is an extreme measure, but it exists in the legal toolkit).

6.3. Additional obligations for CTPPs

If you are a CTPP, you must be able to demonstrate:

• Mature ICT risk management: enterprise‑wide risk assessments, risk registers, board‑level risk appetite.
• Advanced resilience engineering: chaos testing, fault‑injection, region‑level failover, capacity models.
• Structured incident governance: central incident command, playbooks, regulator‑compatible reporting formats.
• Third‑party risk management for your own suppliers (fourth‑party risk from the FE’s perspective).
• Board and senior management accountability: clear roles, minutes showing regular oversight of ICT risk.

This is more intrusive than typical certification audits. You must treat the Lead Overseer as a quasi‑regulator with ongoing access, not a one‑off assessor.

Step 7 – Quick Check: CTPP Oversight

Test your understanding of the CTPP oversight framework.

Step 8 – Contracting Strategies and Standard Clauses

DORA requires financial entities to include specific contractual elements in ICT and cloud outsourcing agreements. As a provider, you can pre‑design standard clauses that satisfy these elements, reducing negotiation friction.

Key clause areas you should address:

1. Scope and service description

• Precise definition of services, locations, data flows, and sub‑processors.
• Explicit reference to RTO/RPO, availability targets, and capacity commitments.

1. Security and resilience obligations

• Minimum security controls (encryption, IAM, logging, vulnerability management).
• BC/DR commitments: testing frequency, participation of FEs in tests, reporting of test results.

1. Incident notification and cooperation

• Clear incident severity levels and notification timelines aligned with DORA (e.g., initial notification within X hours of detection for major incidents).
• Obligation to provide FEs with information needed for regulatory incident reports.

1. Audit, access, and information rights

• Rights for FEs (and, where applicable, their supervisors) to access relevant information, including security policies, test summaries, certifications.
• Mechanisms for pooled audits or reliance on third‑party assurance reports to avoid operational overload.

1. Sub‑outsourcing (fourth‑party risk)

• Conditions under which you can use or change sub‑contractors.
• FE rights to be informed or to object to critical sub‑outsourcing.

1. Exit and data portability

• Data export formats, support for migration, and data deletion guarantees.
• Time‑bound assistance for orderly exit and transition to another provider or in‑house solution.

From a strategic perspective, you should develop:

• A DORA‑aligned contract template (or annex) for EU financial sector customers.
• A playbook explaining which terms are non‑negotiable (for regulatory reasons) and which can be flexed.

This anticipates FEs’ due diligence questions and shortens sales and onboarding cycles.

Step 9 – Example Clause Snippets (Pseudocode‑Style)

Below is pseudocode‑style contract language illustrating how a provider might encode DORA‑aligned obligations. This is not legal advice, but a structured way to think about requirements.

Step 10 – Global Service Delivery and Multi‑Regulatory Alignment

Most significant ICT and cloud providers serve global financial institutions. DORA is one major regime among several. Others include, for example:

• UK: PRA/FCA operational resilience and outsourcing rules (e.g., SS2/21, PS7/21, and related guidance).
• US: FFIEC guidance, OCC and Federal Reserve expectations on third‑party risk and cloud.
• APAC: MAS (Singapore) Technology Risk Management Guidelines, HKMA, etc.

To avoid building region‑specific one‑offs, advanced providers:

1. Identify common denominators

• Incident management, BC/DR, access and audit rights, data residency, concentration risk.
• Map DORA requirements to these and design global baseline controls that meet the strictest common standard.

1. Layer regional add‑ons

• Offer regional annexes for EU (DORA), UK, US, etc., to address unique obligations (e.g., UK impact tolerance concepts, EU CTPP oversight mechanics).

1. Centralise evidence production

• Maintain a single global control inventory and assurance library (policies, test reports, certifications).
• Tag each control with the regulatory requirements it supports (DORA articles, UK rules, etc.).

1. Design for data and sovereignty constraints

• Regional clouds or data zones to address data localisation.
• Clear documentation of where data is stored and processed, and how cross‑border transfers are controlled.

Your analytical challenge: design a control and documentation framework that is regulation‑aware but not regulation‑fragmented – i.e., you can prove compliance to different supervisors using one coherent system rather than parallel, conflicting ones.

Step 11 – Key Term Review

Flip the cards to review central concepts for ICT and cloud providers under DORA.

Step 12 – Synthesis Exercise: Designing a DORA‑Ready Offer

You are leading the EU financial services segment of a global cloud provider. You want to launch a “DORA‑Ready Banking Cloud” offering.

In 5–7 bullet points each, outline:

1. Service adaptations you will implement:

• Think about resilience tiers, logging, encryption defaults, incident tooling, BC/DR testing.

1. Contractual package you will propose:

• Which DORA‑aligned clauses will you standardise? How will you handle audit rights and sub‑outsourcing transparency?

1. Regulatory engagement plan if you are, or might become, a CTPP:

• How will you prepare for Lead Overseer interactions? What governance forums, documentation, and metrics will you put in place?

Treat this as if you were preparing a concept note for your executive committee. Aim for precision and feasibility, not marketing language.