Module 7: Managing ICT Third‑Party Risk and Critical Providers

Step 1 – Where ICT Third‑Party Risk Fits in DORA

1.1. Why third‑party risk is central in DORA

The Digital Operational Resilience Act (DORA) – Regulation (EU) 2022/2554 – has applied since 17 January 2025. Compared with earlier, fragmented rules (EBA/EIOPA/ESMA outsourcing guidelines, national cloud guidance), DORA:

• Creates a single, cross‑sector framework for ICT risk across EU financial entities (FEs).
• Puts ICT third‑party risk on the same level as internal ICT risk.
• Adds a central oversight regime for critical ICT third‑party providers (CTTPs).

Under DORA, outsourcing ICT services never transfers responsibility: the FE’s management body remains fully responsible for operational resilience, even when services are outsourced or offshored.

1.2. Key legal anchors (for further reading)

• DORA core regulation: Regulation (EU) 2022/2554, especially:
• Arts. 28–30 – ICT third‑party risk management
• Art. 31–33 – Oversight of critical ICT third‑party service providers
• Level 2 & 3 instruments (by 2025) – RTS/ITS and guidelines from ESAs (EBA, ESMA, EIOPA) specifying:
• Minimum contractual clauses and service level requirements
• Structure of registers of ICT third‑party arrangements
• Criteria and process for designation and oversight of CTTPs

1.3. Connection with earlier modules

• From Module 5: Third‑party incidents must feed into your incident classification and reporting (e.g. a cloud outage triggering major incident reporting under DORA and sectoral laws like PSD2 or NIS2).
• From Module 6: Third‑party environments are in scope for digital operational resilience testing and, for some FEs, TLPT (threat‑led penetration testing) – subject to contractual access and cooperation.

In this module, you will:

• Walk through the ICT third‑party risk lifecycle under DORA.
• Understand how critical providers are identified and supervised.
• Practically stress‑test and revise contracts to become DORA‑compliant.

Step 2 – The ICT Third‑Party Risk Lifecycle under DORA

DORA expects a structured lifecycle approach to ICT third‑party arrangements. Think of this as a continuous loop:

1. Strategy & governance

• Define an ICT third‑party risk strategy aligned with the FE’s risk appetite.
• Approve at management body level (board or equivalent).
• Set policies for outsourcing, onboarding, monitoring, and exit.

1. Pre‑contract due diligence

• Assess technical, security, financial, legal, and geopolitical risks of the provider.
• Evaluate concentration risk (e.g. multiple critical services with the same cloud provider).
• Consider data location, cross‑border transfers, and regulatory access.

1. Contracting & onboarding

• Include mandatory DORA clauses (see Step 5).
• Ensure clear SLAs, KPIs, and incident reporting channels.
• Integrate provider into incident management and testing frameworks.

1. Ongoing monitoring & review

• Continuous performance and risk monitoring (technical, cyber, financial).
• Periodic risk re‑assessment and concentration analysis.
• Regular testing, security assessments, and audit rights.

1. Exit & substitution

• Maintain documented exit strategies for important and critical functions.
• Test data portability and reversibility in practice.
• Manage transition risk when switching providers or bringing services back in‑house.

DORA’s message: no ad‑hoc outsourcing. Every ICT third‑party arrangement must fit into this lifecycle and be documented in the FE’s register (Step 3).

Step 3 – Designing the Register of ICT Third‑Party Arrangements

DORA requires each FE to maintain a comprehensive register of all ICT third‑party arrangements (not only outsourcing of critical functions). This register must be standardized enough to feed into supervisory reporting.

3.1. Core data fields (conceptual design)

Imagine you are designing a database schema. For each ICT arrangement, you would at least track:

• Provider identity: legal name, group, country of establishment.
• Service description: nature of ICT service (e.g. IaaS, payment processing engine, anti‑fraud analytics).
• Function criticality:
• Does the service support an important or critical function (as per DORA and sectoral rules)?
• Is it sub‑outsourced further down the chain?
• Data & location:
• Types of data processed (customer, transaction, trade secrets).
• Storage and processing locations (EU/EEA vs third countries, intra‑group vs external).
• Contractual info:
• Start/end dates, renewal terms, notice periods.
• Exit provisions and data reversibility clauses.
• Whether DORA‑mandated clauses are included.
• Risk & oversight:
• Risk assessment results and inherent/residual risk ratings.
• Whether the provider is a designated CTTP under DORA.
• Links to incidents, test results, and remediation plans.

3.2. Thought exercise: spotting weaknesses

Task: You review a mid‑size bank’s ICT register. It has only three columns:

• Provider name
• Service type
• Contract end date

1. List three major DORA compliance gaps in this register.
2. For each gap, explain briefly why it matters for:

• (a) supervisory reporting
• (b) the bank’s own operational resilience

Write your answers in bullet points. Then compare with the model answer in the next step.

Step 4 – Model Answer: Register Gaps and Enhancements

4.1. Example weaknesses in the minimal register

With only provider name, service type, and contract end date, at least these gaps appear:

1. No link to critical/important functions

• You cannot identify which arrangements support critical or important functions.
• Supervisory impact: You cannot easily respond to regulators’ requests for a list of providers supporting critical functions.
• Resilience impact: In a systemic incident, you cannot quickly see which services are mission‑critical.

1. No data on location and data flows

• You do not know where data is processed or stored, or whether processing occurs outside the EU/EEA.
• Supervisory impact: You cannot demonstrate control over cross‑border risk, data protection, and law enforcement access issues.
• Resilience impact: Geopolitical or legal shocks (e.g. sanctions, data transfer restrictions) cannot be assessed or mitigated.

1. No risk assessment or CTTP flag

• You cannot distinguish high‑risk providers from low‑risk ones.
• You cannot see whether a provider is a critical ICT third‑party provider under DORA.
• Supervisory impact: Hard to prove a risk‑based approach or to show enhanced oversight for CTTPs.
• Resilience impact: You may over‑rely on a single hyperscaler or niche provider without recognizing concentration risk.

4.2. Enhancing the register

To move toward DORA compliance, the bank should at least:

• Add a criticality flag linked to the FE’s internal mapping of critical/important functions.
• Record data categories and processing locations.
• Maintain risk ratings, links to incident records, and a CTTP yes/no flag.
• Reference key contractual clauses (e.g. incident reporting, audit rights, exit strategy) and whether they are DORA‑compliant.

In practice, many institutions implement this as a central inventory tool with APIs to procurement, risk, and incident‑management systems.

Step 5 – Mandatory Contractual Clauses and Service Levels

DORA and its Level 2 measures require specific contractual content for ICT services, especially where critical or important functions are involved.

5.1. Core DORA‑aligned clauses

When revising or drafting ICT contracts, ensure they address at least:

1. Scope and service description

• Precisely define the ICT services, systems, and environments in scope.
• Clarify interfaces with the FE’s own systems and with other providers.

1. Performance, SLAs, and KPIs

• Measurable uptime/availability targets (e.g. 99.95% monthly).
• Response and resolution times for incidents by severity.
• Financial and operational remedies for under‑performance (credits, remediation plans, right to terminate).

1. Information security and resilience

• Alignment with industry standards (e.g. ISO 27001, NIST CSF) where appropriate.
• Patch management, vulnerability disclosure, and secure development practices.
• Backup, disaster recovery, and business continuity objectives (RTO/RPO) consistent with the FE’s risk appetite.

1. Incident management and reporting

• Obligations to detect, classify, and report ICT‑related incidents promptly to the FE.
• Timelines aligned with the FE’s own regulatory reporting deadlines (from Module 5).
• Cooperation in root‑cause analysis and remediation.

1. Access, audit, and testing rights

• Right of the FE, its internal and external auditors, and competent authorities to:
• Access relevant data, logs, and systems (subject to proportionality and security).
• Conduct or commission on‑site inspections or pooled audits.
• For entities subject to TLPT: cooperation with threat‑led penetration tests (Module 6), including in shared environments.

1. Sub‑outsourcing

• Conditions under which the provider may sub‑outsource critical parts of the service.
• FE’s right to object to certain sub‑contractors or locations.
• Obligation to ensure that sub‑contractors comply with equivalent standards.

1. Data, confidentiality, and location

• Data classification, encryption, and segregation (especially in multi‑tenant clouds).
• Data location requirements, including EU/EEA vs third‑country constraints.
• Reversibility and deletion/return of data at exit.

1. Exit and termination

• Clear exit triggers (e.g. repeated SLA breaches, material incidents, regulatory objections).
• Detailed transition assistance obligations.
• Time‑bound commitments for data migration and support to substitute providers.

5.2. Edge cases

• Standardized cloud contracts: Hyperscalers often resist bespoke clauses. DORA pushes FEs to either:
• Negotiate at least a minimum DORA baseline, or
• Use additional controls (e.g. encryption, architectural changes) to compensate for contractual gaps.
• Intra‑group arrangements: Even within a group, DORA expects formalized contracts or equivalent documents, not informal arrangements.

Step 6 – Contract Surgery: Fixing a Non‑Compliant Clause

You are reviewing a 2019 cloud outsourcing contract for a payments platform that clearly supports a critical function.

The incident clause currently reads:

> “The Provider shall use reasonable efforts to inform the Customer of any service disruption as soon as practicable.”

6.1. Task

1. Identify at least three problems with this clause under DORA.
2. Rewrite the clause in 2–4 bullet points to be more DORA‑aligned, covering:

• Timeliness and severity‑based reporting.
• Cooperation and information‑sharing.
• Alignment with regulatory reporting obligations.

Write your improved version before checking the model answer below.

Step 7 – Model Answer: A DORA‑Aligned Incident Clause

7.1. Problems with the original clause

1. Vague timing – “as soon as practicable” is not aligned with the strict reporting timelines FEs face under DORA and sectoral laws.
2. No severity concept – It does not distinguish between minor glitches and major ICT‑related incidents or threats.
3. No cooperation duty – It lacks commitments to provide root‑cause information, logs, and support during regulatory investigations.
4. No linkage to regulatory reporting – It ignores the FE’s need to meet incident notification obligations to competent authorities and clients.

7.2. Example of a more DORA‑aligned clause

> The Provider shall:

>

> - Notify the Customer without undue delay and in any case within [X] minutes/hours after becoming aware of any ICT‑related incident or serious cyber threat that may affect the Services, indicating at least the nature of the incident, affected services, and preliminary impact assessment.

> - Immediately notify the Customer of any ICT‑related incident that is likely to qualify as a major incident under the Customer’s internal classification framework, and provide regular updates at intervals not exceeding [Y] hours until service restoration and root‑cause analysis are completed.

> - Cooperate fully with the Customer in managing and investigating the incident, including by providing access to relevant logs, technical information, and personnel, and by participating in joint calls with competent authorities if requested by the Customer.

> - Provide, within a mutually agreed timeframe, a written incident report including root cause, remedial actions taken, and measures to prevent recurrence, in a format that enables the Customer to meet its regulatory reporting obligations.

You could further refine this by aligning X and Y with internal playbooks (e.g. 1 hour for critical incidents, 24 hours for full root‑cause reports).

Step 8 – Critical ICT Third‑Party Providers (CTTPs) and Oversight

DORA introduces a new EU‑level oversight regime for critical ICT third‑party providers (CTTPs), such as major cloud, data analytics, or core banking platforms.

8.1. How providers become “critical”

The Joint Oversight Forum (JOF) – composed of the ESAs and national authorities – proposes CTTPs based on criteria including:

• Systemic impact: How many FEs and critical functions depend on the provider.
• Substitutability: Difficulty of switching to another provider (technical, contractual, or economic lock‑in).
• Concentration: Market share and geographic concentration of services.
• Incident history: Past major incidents, vulnerabilities, or systemic outages.

The European Commission then designates providers as CTTPs via implementing acts.

8.2. Oversight of CTTPs

Once designated, CTTPs are subject to:

• Lead Overseer: One ESA (EBA, ESMA, or EIOPA) acts as lead overseer.
• Oversight plans: Annual or multi‑year plans focusing on cyber resilience, operational risk, and concentration risk.
• On‑site inspections and requests for information.
• Recommendations and remedial measures: CTTPs must address weaknesses; persistent non‑compliance can trigger warnings and, indirectly, restrictions on FEs using them.

8.3. What this means for FEs

• FEs do not designate CTTPs themselves; they must, however:
• Check whether their key providers have been designated.
• Reflect this in their register and risk assessments.
• Expect increased transparency and possibly standardized reporting from CTTPs.
• Supervisors may instruct FEs to reduce exposure to a CTTP in extreme cases (e.g. if the CTTP fails to remediate critical weaknesses).

A subtle but important point: DORA’s CTTP regime does not replace FEs’ own third‑party risk management. It adds a second oversight layer at EU level, focused on systemic providers.

Step 9 – Concentration Risk, Substitution, and Cross‑Border Issues

9.1. Concentration risk under DORA

DORA explicitly requires FEs to monitor and manage concentration risk, including:

• Single‑provider concentration: Many critical services with one cloud or core banking provider.
• Intra‑group concentration: Heavy reliance on a single group service center in one country.
• Sectoral concentration: Multiple FEs in a market relying on the same CTTP (a systemic risk issue).

Tools to manage this include:

• Architectural diversification (multi‑cloud, hybrid, active‑active setups).
• Splitting critical workloads across different providers.
• Regular scenario analysis (e.g. “What if Provider X suffers a week‑long outage?”).

9.2. Substitution and exit strategies

DORA insists on realistic exit and substitution plans:

• Define target timelines and minimal service levels during transition.
• Maintain data portability (open formats, APIs, documentation).
• Periodically test aspects of the exit plan (e.g. restoring backups to an alternative environment).

Edge case: For highly specialized providers (e.g. niche trading platforms), true substitution may be slow or impossible. DORA then expects compensating controls and explicit risk acceptance by the management body.

9.3. Cross‑border service provision

DORA does not prohibit using non‑EU providers, but it raises the bar:

• FEs must ensure that supervisory access, audit rights, and data protection remain effective.
• Contracts must address conflicts of law (e.g. foreign governmental access to data).
• FEs must assess country risk (political, legal, sanctions) and its impact on service continuity.

Example: A European bank using a US cloud provider with data centers inside the EU still needs to consider US legal requests that might affect data confidentiality and availability, and implement technical/legal safeguards accordingly.

Step 10 – Quick Knowledge Check

Answer this question to test your understanding of DORA’s approach to ICT third‑party risk.

Step 11 – Key Term Flashcards

Flip these cards (mentally or with a study tool) to reinforce core DORA concepts on ICT third‑party risk.

Step 12 – Mini Capstone: Evaluating an ICT Outsourcing Proposal

Imagine you are on the risk committee of an EU investment firm. The CIO proposes to migrate the firm’s trade execution platform (clearly an important/critical function) to a new cloud provider based outside the EU.

The proposal highlights cost savings and scalability but provides only a one‑page risk summary.

12.1. Your task

Draft a structured checklist (5–8 bullet points) of questions or requirements you would raise before approving this arrangement, explicitly linking to DORA themes from this module. For example:

• What additional information do you need about cross‑border risks and data location?
• How will incident reporting from the provider support your regulatory obligations?
• How is concentration risk assessed and mitigated?
• What does the exit strategy look like in practice?

12.2. Suggested structure

Organize your bullets under headings such as:

• Governance & criticality
• Contractual clauses & SLAs
• CTTP & concentration risk
• Cross‑border & legal risk
• Testing, audit, and exit

Use this as a template for your own future reviews of ICT outsourcing proposals under DORA.