DORA ICT Third-Party Risk: Contracting, Exit Strategies, and Oversight

Introduction to Pillar 4: ICT Third-Party Risk Management

Pillar 4 of DORA (Articles 28-44) addresses one of the most significant sources of operational risk in modern financial services: dependence on ICT third-party service providers. From cloud infrastructure and core banking platforms to payment processing and cybersecurity services, financial entities rely extensively on external ICT providers for critical operations.

DORA transforms how financial entities must manage this dependency. It moves beyond the traditional outsourcing guidelines that have governed third-party risk for over a decade, introducing mandatory contract clauses, concentration risk requirements, exit strategy obligations, the Register of Information, and — most innovatively — a direct EU-level oversight framework for Critical ICT Third-Party Service Providers (CTPPs).

This guide provides a comprehensive walkthrough of Pillar 4 requirements: from the strategic third-party risk management framework through pre-contractual due diligence, mandatory contract provisions, ongoing management, and exit planning. We include a practical contract clause checklist and guidance on the Register of Information and CTPP oversight framework.

Third-Party Risk Management Strategy

Article 28(2) requires financial entities to adopt a strategy on ICT third-party risk as part of the ICT risk management framework. This is a management body-approved, board-level strategic document.

Strategy Components

• Risk appetite: Define the entity's appetite for ICT third-party risk, including acceptable concentration levels and dependency thresholds
• Sourcing policy: Guidelines for when to use ICT third-party services versus in-house capability, considering criticality, control, and substitutability
• Due diligence requirements: Minimum standards for pre-contractual and ongoing due diligence based on service criticality
• Contractual standards: Minimum contractual requirements aligned with Article 30 and entity-specific needs
• Monitoring approach: How the entity will monitor provider performance, risk posture, and compliance on an ongoing basis
• Exit planning: Approach to maintaining exit readiness for critical and important ICT services
• Concentration risk management: How the entity will assess, monitor, and mitigate concentration risk across its ICT provider ecosystem

Management Body Oversight

The management body must:

• Approve the ICT third-party risk strategy and any material updates
• Receive regular reporting on third-party risk posture, concentration risk, and key provider performance
• Approve the use of ICT services supporting critical or important functions
• Be informed of any significant third-party incidents or service disruptions
• Review and approve the Register of Information at least annually

Pre-Contractual Due Diligence

Before entering into any ICT third-party arrangement, financial entities must conduct due diligence proportionate to the criticality of the services to be provided.

Due Diligence for Critical or Important Functions

For ICT services supporting critical or important functions, due diligence must be comprehensive:

• Financial stability: Assess the provider's financial health, longevity, and risk of insolvency
• Technical capability: Evaluate the provider's technical infrastructure, security posture, and service delivery capability
• Security assessment: Review the provider's information security policies, certifications (ISO 27001, SOC 2), and incident history
• Business continuity: Assess the provider's BCP/DR capabilities and testing practices
• Regulatory compliance: Verify the provider's ability to comply with DORA contractual requirements, including audit rights and data location
• Concentration assessment: Evaluate whether engaging the provider would create or increase concentration risk
• Sub-outsourcing: Understand the provider's sub-outsourcing arrangements and their impact on service delivery
• Exit feasibility: Assess the feasibility of transitioning away from the provider, including data portability and alternative providers

Due Diligence for Non-Critical Services

For ICT services not supporting critical or important functions, due diligence can be proportionately lighter but must still cover:

• Basic financial and operational assessment
• Security baseline evaluation
• Contractual compliance with DORA minimum requirements
• Data protection and processing location

Mandatory Contract Clauses (Article 30)

Article 30 is one of DORA's most operationally impactful provisions. It mandates specific clauses that must be present in all ICT third-party service contracts, with additional requirements for contracts supporting critical or important functions.

Clauses Required for All ICT Contracts

• Service level descriptions: Clear, detailed descriptions of all ICT services, including service levels and performance targets
• Data processing: Provisions on data processing, including processing locations, data security measures, and data access restrictions
• Availability targets: Quantitative availability, reliability, and performance targets for services
• Incident notification: Obligation for the provider to notify the financial entity of ICT-related incidents without undue delay
• Cooperation with authorities: Provider cooperation with the financial entity's competent authority during supervisory activities
• Termination rights: Clear termination rights and conditions for the financial entity

Additional Clauses for Critical or Important Functions

Contracts for services supporting critical or important functions must additionally include:

• Full service level descriptions: Detailed quantitative and qualitative service levels with remedies for non-performance
• Audit and inspection rights: Unrestricted rights of access, inspection, and audit by the financial entity, its competent authority, and any appointed third party
• Data location: Specific identification of processing and storage locations, including any change notification obligations
• Business continuity: Provider's business continuity arrangements, including testing obligations and recovery commitments
• Sub-outsourcing provisions: Conditions and notification requirements for sub-outsourcing, including the entity's right to object
• Exit assistance: Provider's obligations to assist with transition, including adequate transition period, data migration support, and continued service during transition
• Participation in testing: Provider's obligation to participate in the entity's digital operational resilience testing programme, including TLPT where applicable
• Security measures: Specification of security measures the provider must implement and maintain

Contract Clause Checklist

Use the following checklist when reviewing or negotiating ICT third-party contracts under DORA:

Sub-Outsourcing Management

ICT service providers often rely on their own sub-contractors (sub-outsourcing). DORA requires financial entities to manage this chain of dependency.

Contractual Sub-Outsourcing Provisions

• Notification: The provider must notify the financial entity of any planned sub-outsourcing or changes to existing sub-outsourcing before implementation
• Objection rights: For critical or important functions, the financial entity must have the right to object to sub-outsourcing that may impair service delivery or security
• Pass-through obligations: Key contractual obligations (security, audit rights, data protection) must be passed through to sub-contractors
• Monitoring: The financial entity must have visibility into the sub-outsourcing chain and the ability to monitor material sub-contractors
• Accountability: The primary provider remains fully accountable for the service, regardless of sub-outsourcing arrangements

Practical Challenges

Sub-outsourcing management is one of the most challenging areas of DORA implementation. Common challenges include:

• Large cloud and SaaS providers may resist entity-specific sub-outsourcing notification obligations
• Multi-tier sub-outsourcing chains are difficult to map and monitor
• Sub-contractor audit rights may conflict with provider confidentiality obligations to their own suppliers
• Rapid changes in cloud service delivery models make sub-outsourcing arrangements dynamic

Concentration Risk Assessment

Article 29 requires financial entities to identify and assess concentration risk in their ICT third-party arrangements. Concentration risk arises when the entity (or the financial sector broadly) is excessively dependent on a single or small number of ICT providers.

Concentration Risk Factors

• Provider concentration: How many critical or important functions depend on a single provider?
• Service concentration: Are multiple critical services (e.g., cloud, security, payments) provided by the same entity or group?
• Geographic concentration: Are ICT services concentrated in specific locations or jurisdictions?
• Technology concentration: Is the entity dependent on a single technology platform with limited alternatives?
• Sectoral concentration: Are many financial entities in the same sector dependent on the same provider?

Concentration Risk Mitigation

• Develop and maintain a multi-vendor strategy where feasible for critical services
• Assess alternative providers for each critical ICT service
• Avoid single points of failure in the ICT supply chain
• Implement portability and interoperability requirements in contracts
• Maintain exit readiness to migrate away from concentrated providers if needed
• Report concentration risk assessment to the management body

Supervisory Reporting

Financial entities must be prepared to provide concentration risk analysis to competent authorities. The Register of Information (RoI) supports this by providing a comprehensive view of all ICT third-party arrangements, enabling supervisory analysis of concentration at entity, sector, and system-wide levels.

Exit Strategies and Transition Plans

DORA mandates that financial entities develop and maintain exit strategies for all ICT third-party arrangements supporting critical or important functions. This is not a theoretical exercise — exit strategies must be practical, tested, and ready for execution.

Exit Strategy Requirements

• Transition plan: Documented plan for migrating to an alternative provider or bringing the service in-house, including timelines, resources, and milestones
• Data portability: Defined approach for extracting and migrating data, including formats, methods, and validation procedures
• Alternative arrangements: Identified alternative providers or in-house capabilities for each critical service
• Transition period: Contractually defined adequate transition period during which the outgoing provider continues to deliver services
• Testing: Periodic testing or validation of exit strategies to ensure they remain feasible
• Communication plan: Defined approach for communicating with stakeholders (clients, regulators, staff) during transition

Exit Strategy Triggers

Exit strategies should be activated or considered when:

• The provider's performance consistently fails to meet contractual service levels
• The provider experiences a significant security incident affecting the entity
• The provider's financial stability deteriorates materially
• Concentration risk becomes unacceptable
• The competent authority directs the entity to reduce dependency on a specific provider
• The provider is designated as CTPP and the Lead Overseer identifies material risks
• The contract reaches natural expiry and strategic review favours change

Exit Strategy Review

Exit strategies must be reviewed at least annually and updated to reflect changes in the market, available alternatives, and the entity's own ICT landscape. Reviews should verify that alternative providers remain viable, data portability approaches are still feasible, and transition timelines are realistic.

Register of Information (RoI)

Article 28(3) requires financial entities to maintain a Register of Information that records all ICT third-party service arrangements. The RoI is a key supervisory tool and must be available to competent authorities upon request.

RoI Content Requirements

The ITS on the Register of Information specifies the data fields. Key elements include:

• Identification of the ICT third-party service provider (name, LEI, jurisdiction)
• Description of ICT services provided
• Whether the services support critical or important functions
• Contract details (start date, end date, renewal terms)
• Data processing locations
• Sub-outsourcing arrangements
• Assessment of substitutability
• Date of most recent due diligence assessment
• Contract value (where applicable)

RoI Maintenance

• The RoI must be maintained at entity level
• For groups, it may also be maintained at sub-consolidated and consolidated level
• It must be updated promptly when new arrangements are entered, existing ones are changed, or arrangements are terminated
• It must be reviewed at least annually for completeness and accuracy
• It must be in a format that can be provided to competent authorities upon request

Supervisory Use

Competent authorities use the RoI to:

• Monitor individual entity third-party risk
• Identify concentration risk across the financial sector
• Inform CTPP designation decisions
• Support supervisory stress testing of ICT supply chain resilience
• Facilitate cross-border supervisory cooperation

CTPP Oversight Framework

Articles 31-44 establish the EU-level oversight framework for Critical ICT Third-Party Service Providers (CTPPs). This is one of DORA's most innovative provisions, creating direct regulatory engagement with ICT providers for the first time.

Oversight Structure

• Joint Committee: The ESAs' Joint Committee coordinates CTPP designation and oversight activities
• Lead Overseer: One of the three ESAs (EBA, EIOPA, or ESMA) is designated as Lead Overseer for each CTPP based on the financial sub-sector most dependent on the provider
• Joint Examination Team: Multi-disciplinary team supporting the Lead Overseer in conducting oversight activities
• Oversight Forum: Advisory body supporting coordination between the ESAs, competent authorities, and other relevant stakeholders

Oversight Powers

The Lead Overseer has broad powers over designated CTPPs:

• Information requests: Request any information or documentation needed for oversight
• General investigations: Conduct investigations into the CTPP's operations, risk management, and security
• On-site inspections: Conduct inspections at the CTPP's premises, including data centres and operational sites
• Recommendations: Issue recommendations on ICT risk management, security, incident reporting, testing, and sub-outsourcing
• Compliance monitoring: Request reports from the CTPP on compliance with recommendations

CTPP Obligations

Once designated as a CTPP, the provider must:

• Cooperate fully with the Lead Overseer and Joint Examination Team
• Provide requested information and documentation within specified timelines
• Facilitate on-site inspections and investigations
• Address recommendations issued by the Lead Overseer
• Report on compliance with recommendations
• Third-country CTPPs must establish an EU subsidiary within 12 months of designation

Impact on Financial Entities

The CTPP oversight framework does not reduce the financial entity's own obligations. Entities must still:

• Conduct their own due diligence and ongoing monitoring of CTPPs
• Maintain contractual compliance with Article 30
• Manage concentration risk related to CTPP dependency
• Maintain exit strategies for CTPP services
• Consider Lead Overseer recommendations in their own risk assessments

Implementation Approach

Implementing DORA Pillar 4 requires a systematic approach across multiple organisational functions.

Phase 1: Inventory and Assessment (Weeks 1-6)

• Complete inventory of all ICT third-party service providers
• Classify providers by criticality of supported functions
• Populate or update the Register of Information
• Assess contract compliance with Article 30 for all existing agreements
• Identify contracts requiring amendment or renegotiation

Phase 2: Strategy and Governance (Weeks 4-10)

• Develop or update the ICT third-party risk management strategy
• Establish management body reporting on third-party risk
• Conduct initial concentration risk assessment
• Define due diligence requirements by service criticality tier

Phase 3: Contract Remediation (Weeks 8-24)

• Prioritise contract amendments based on criticality and gap severity
• Negotiate and execute contract amendments with critical and important providers
• Update standard contract templates for new engagements
• Address sub-outsourcing provisions and audit rights

Phase 4: Exit Planning and Ongoing Management (Weeks 16-30)

• Develop exit strategies for all critical and important function providers
• Identify alternative providers for each critical service
• Implement ongoing monitoring programme
• Establish annual review cycle for RoI, concentration risk, and exit strategies

Contract remediation is often the longest and most resource-intensive aspect of Pillar 4 compliance. Many large ICT providers resist entity-specific contract amendments. Start early, prioritise by criticality, and leverage regulatory leverage — providers have strong commercial incentives to enable their clients' DORA compliance.

Frequently Asked Questions

What are the mandatory DORA contract clauses under Article 30?

Article 30 mandates specific contract provisions including clear service level descriptions, data processing locations, audit and inspection rights, incident notification obligations, business continuity guarantees, termination rights, exit provisions with transition periods, sub-outsourcing conditions, and cooperation obligations with competent authorities. Contracts for critical or important functions have additional requirements.

What is the DORA Register of Information?

The Register of Information (RoI) is a comprehensive record of all ICT third-party service arrangements that financial entities must maintain under Article 28(3). It must include details of all ICT services, providers, criticality classification, contract details, data locations, and sub-outsourcing. It must be available to competent authorities upon request and can be maintained at entity, sub-consolidated, and consolidated group levels.

What is concentration risk under DORA?

DORA concentration risk refers to excessive dependence on a single or small number of ICT third-party service providers. Article 29 requires financial entities to assess and manage concentration risk by considering the number of entities relying on the same provider, the criticality of functions supported, substitutability, and geographic concentration. A multi-vendor strategy should be considered for critical services.

What exit strategies does DORA require?

DORA requires exit strategies for all ICT third-party arrangements supporting critical or important functions. Exit strategies must include transition plans with timelines, data portability and migration provisions, identification of alternative providers, contractually defined transition periods, testing of exit procedures, and stakeholder communication plans. Exit strategies must be reviewed annually.

How does DORA handle sub-outsourcing?

DORA requires that contracts include provisions for sub-outsourcing. For critical or important functions, the financial entity must have the right to object to sub-outsourcing that may impair service delivery or security. Contracts must require notification before new sub-outsourcing, pass-through of key obligations to sub-contractors, and the primary provider remains fully accountable regardless of sub-outsourcing.