Skip to main content

DORA ICT Third-Party Risk: What Financial Services CISOs Must Have in Place Before the First Supervisory Reviews

7 min read
CISO Daily
DORA ICT Third-Party Risk: What Financial Services CISOs Must Have in Place Before the First Supervisory Reviews

DORA — the EU Digital Operational Resilience Act — has applied to in-scope financial entities since January 2025. The first wave of substantive supervisory engagement is now underway, and the European Supervisory Authorities (ESAs: EBA, EIOPA, and ESMA) are working through the register of critical ICT third-party providers (CTPPs) that will be subject to direct EU-level oversight. Financial services CISOs who treated the DORA deadline as a documentation exercise are finding that supervisors are asking for evidence of actual programme implementation, not just policy frameworks.

The ICT third-party risk chapter is the area generating the most compliance concerns across the industry. This is the component that requires re-papering existing vendor contracts, creating a comprehensive register of ICT dependencies, classifying providers by criticality, and demonstrating live oversight. Here is where the programme needs to be.

What DORA Actually Requires on Third-Party ICT Risk

DORA’s ICT third-party risk requirements (Articles 28–44) cover four main obligations:

1. ICT third-party register. Financial entities must maintain a documented register of all ICT third-party service providers (not just cloud providers — this includes any software vendor, data processor, or managed service provider materially involved in the delivery of ICT services). The register must include: type of service, data processed, whether the provider is classified as critical, and subcontractors used by that provider.

2. Contractual requirements for ICT service agreements. All ICT service contracts must contain specific provisions under DORA Article 30. These include: exit strategy and transition assistance obligations, audit rights, incident notification timelines (aligned to DORA’s own reporting obligations), data portability and service continuity requirements, and security standards the provider must maintain. Contracts that predate DORA and lack these provisions require amendment or replacement.

3. Concentration risk management. Financial entities must assess and manage their dependency on single providers, particularly for cloud services and software infrastructure. Where a firm relies heavily on one provider (for example, a single cloud hyperscaler for production workloads), DORA requires documented concentration risk analysis and mitigation plans.

4. Critical ICT third-party provider (CTPP) oversight. Providers designated as CTPPs by the ESAs become subject to EU-level supervisory oversight directly. In-scope financial entities using a CTPP must ensure the contractual provisions are in place, cooperate with the supervisory process, and — if the CTPP cannot demonstrate compliance — have documented exit and substitution plans.

The Contractual Gap

The most common finding in DORA readiness assessments is the contractual gap: firms have identified their ICT providers and classified some as critical, but legacy contracts from before DORA’s application date do not contain the required provisions. Renegotiating contracts at scale with major software vendors and cloud providers is a slow process, and some providers have been resistant to accepting audit rights language in the form DORA requires.

The practical approach that supervisors have signalled they will accept for existing contracts: a documented remediation roadmap that prioritises contracts with critical providers, with a realistic timeline for completion and evidence of active renegotiation. What is not acceptable is no progress and no plan. The priority queue for renegotiation should be:

  1. Critical ICT third-party providers (designated or anticipated designations)
  2. Any provider whose failure could directly disrupt regulated services
  3. Cloud infrastructure providers for production workloads
  4. Providers with access to confidential customer data

Incident Reporting Under the Third-Party Lens

DORA’s major ICT incident reporting requirements (Article 19) require financial entities to notify their competent authority of major incidents within defined timelines. What many CISOs have under-planned is the triangular notification requirement when a third-party is involved:

  • The financial entity must report the incident to its regulator
  • The contract with the ICT provider must require the provider to notify the financial entity of incidents that affect the financial entity’s services within the provider’s required notification window
  • If the provider is a CTPP under DORA oversight, there are parallel ESA notification obligations

The contractual notification timeline required under DORA Article 30(2)(f) is that ICT third parties must notify the financial entity “without undue delay” of incidents that may affect the financial entity’s ICT services. CISOs should ensure that vendor contracts specify this timeline explicitly (ideally 24 hours for significant incidents) and that there is a process to receive and triage such notifications.

What Supervisors Are Looking At

Based on early supervisory engagement and EBA Q&A guidance, the following areas are generating scrutiny:

ICT register completeness. Supervisors are asking financial entities to walk through their ICT register and explain the methodology for identifying and classifying providers. Gaps — particularly where material dependencies exist but are not in the register (e.g., embedded software components, third-party data feeds) — are findings.

Concentration risk documentation. For firms heavily dependent on the hyperscalers (AWS, Azure, GCP), supervisors expect to see a documented cloud concentration risk assessment and a transition capability (not necessarily a tested multi-cloud deployment, but a credible plan and evidence that the cost of migration has been assessed).

Exercise and testing. DORA requires digital operational resilience testing, including advanced testing (TLPT — Threat-Led Penetration Testing) for significant entities. Supervisors are verifying that firms have conducted resilience testing and that the test scenarios include third-party failure modes.

CTPP exit plans. For providers the firm anticipates will be designated as CTPPs (or for major cloud providers that may be designated), supervisors want to see documented exit strategies. These need to be realistic — acknowledging lock-in where it exists while documenting the path to transferability.

Practical Priorities for Q3-Q4 2026

Finalise the ICT register. If the register is incomplete, prioritise completing it using a business service mapping approach: start with regulated services, identify the ICT systems that underpin them, and trace the dependencies to providers. This is more efficient than trying to enumerate all vendors from procurement records.

Accelerate critical contract renegotiation. Use the DORA Article 30 checklist as the negotiating template. Where a major provider refuses to accept audit rights, document the refusal and escalate internally — this creates a record and may support a substitution decision.

Conduct a concentration risk assessment. If your firm uses a single cloud provider for more than 50% of production workloads, document this explicitly in the operational resilience framework with a mitigation plan. The mitigation does not have to be multi-cloud deployment — it may be a transition playbook and a tested backup operational mode.

Ensure ICT incident notifications from third parties are operational. Test that your major critical providers actually have a working process to notify you of incidents affecting your services. This is separate from their general breach notification procedures and may require a specific contact arrangement.

DORA’s third-party requirements are more onerous than firms initially anticipated because they require changing the contractual and operational relationship with vendors — not just documenting what you’re already doing. CISOs who own the DORA programme should be escalating the contractual renegotiation workload to legal and procurement as a shared regulatory obligation, not a security team problem alone.