Contract GuideEU

EU DORA Third-Party Risk + Contract Clauses

Make ICT third-party risk a controlled system: policy, due diligence, clauses, monitoring, and exit plans.

Grounded in Article 28-30, RTS 2024/1773 contract RTS, and subcontracting RTS 2025/532.

Back to main artifact Review sources

Author

Sorena AI

Published

Feb 23, 2026

Updated

Feb 23, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Feb 23, 2026

Updated Feb 23, 2026

Overview

DORA's third-party requirements are designed to stop "outsourcing the risk". Your compliance posture depends on whether you can prove (1) you selected the provider with risk-based due diligence, (2) your contract gives you real audit and access rights, (3) you continuously monitor performance and security, (4) you understand the subcontracting chain for critical or important functions, and (5) you can execute a credible exit without breaking critical services.

Section 1

What DORA expects (plain language)

DORA requires a strategic, management-body-owned approach to ICT third-party risk, plus operational controls for contracting, monitoring, and exit.

Think of this as a "contract + evidence" program: the contract must enable supervision-grade access, and your operations must continuously generate auditable proof.

An ICT third-party risk strategy and policy covering planning, due diligence, approvals, monitoring, and exit (Article 28 + RTS 2024/1773).
Contractual clauses that are written, enforceable, and aligned to risk for ICT services supporting critical or important functions (RTS 2024/1773).
Subcontracting governance and assessment for chains supporting critical or important functions (RTS 2025/532).
A register of information that supervisors can request in full or in part (Article 28).

Section 2

Article 28 - Strategy + governance for ICT third-party risk

Article 28 anchors the program: governance, strategy, and the requirement to maintain a register of information on contractual arrangements for ICT services.

Treat the strategy as an operating model: roles, decisions, thresholds, and evidence, not a PDF that nobody can follow.

Define what "critical or important functions" mean in your service catalog and architecture (used to trigger stricter contract controls).
Set approval gates: when legal/security/outsourcing committee sign-off is mandatory (new provider, material change, critical service).
Define concentration risk indicators (provider, region, technology stack) and the escalation path when risk grows.
Connect the strategy to the register of information: if it's not in the register, assume it will be invisible to supervisors.

Section 3

RTS 2024/1773 - Due diligence you can defend

RTS 2024/1773 operationalizes how financial entities should plan contractual arrangements and assess provider suitability before contracting.

Design due diligence so you can show traceability: requirement -> evidence -> risk decision -> contract clause -> monitoring control.

Business reputation + financial and operational resilience of the provider (risk-based assessment).
Security posture and internal controls (policies, governance, technical safeguards, business continuity).
Human and technical resources to deliver critical services sustainably (including key subcontractors).
Document the "why this provider" decision and the compensating controls when gaps remain.

Section 4

Contract clause library (what to include for critical/important functions)

For ICT services supporting critical or important functions, your contract must not be a generic SaaS agreement.

Build a clause library aligned to DORA and RTS 2024/1773, then map each clause to: risk scenario, metric, evidence, and exit plan dependency.

Audit and access rights: your right (and supervisors'/appointed auditors' right) to inspect, access information, and execute audits in a risk-based manner (RTS 2024/1773).
Monitoring + reporting: periodic service delivery reports, incident reports, security reports, and business continuity testing evidence (RTS 2024/1773).
Security + resilience requirements: confidentiality, integrity, availability, authenticity of data; change management and secure operations.
Location and data-processing transparency: where services run, where data is stored/processed, and how changes are notified.
Incident notification obligations: notification triggers, timelines, and what information is provided to support DORA reporting (align with Articles 17-19).
Exit and termination: realistic exit plan, triggers, and operational feasibility with a planned implementation schedule (RTS 2024/1773).

Section 5

Audits in the cloud era (how to comply without "on-site audit theatre")

RTS 2024/1773 anticipates real constraints: financial entities can use certifications and third-party audit reports, but must not rely on them blindly over time.

Treat assurance as layered: baseline independent audits + scoped deep dives + pooled audits + your own testing in high-risk areas.

Assurance coverage mapping: ensure audit reports/certifications cover the systems and key controls you rely on (RTS 2024/1773).
Recency and scope governance: verify reports aren't obsolete and that future audit scopes include your key controls.
Contractual right to request scope changes and to perform individual and pooled audits within reasonable frequency (RTS 2024/1773).
Evidence: keep the assurance register (what you reviewed, findings, remediation commitments, and closure proof).

Section 6

Subcontracting controls - RTS 2025/532 (stop hidden supply-chain risk)

Subcontracting can create long supply chains that undermine operational resilience. RTS 2025/532 specifies elements to assess when subcontracting ICT services supporting critical or important functions.

Implement subcontracting governance as part of vendor management: visibility, approval, monitoring, and exit readiness.

Identify which subcontractors "effectively underpin" the ICT service supporting the critical/important function and track them in your register of information (ITS/Article 28 context).
Assess subcontracting changes as material changes: risk review, control impact, and exit dependency review.
Ensure flow-down obligations: audit/access, security controls, incident notification, and continuity requirements apply through the chain.
Monitor concentration risk at subcontractor level (region, platform, identity/monitoring stack) and define escalation triggers.

Section 7

What the 18 November 2025 critical-provider designations mean for vendor governance

The first published list of designated critical ICT third-party providers turned DORA oversight from a future framework into an active supervisory regime.

For financial entities, that changes the quality bar for provider inventories, contract mapping, monitoring cadence, and exit planning around major cloud and ICT dependencies.

Track whether a key provider or provider group appears on the designated CTPP list and reflect that in your risk register, board reporting, and contract governance.
Reconcile provider identifiers across contracts, RoI exports, assurance reports, and incident dependencies so oversight questions can be answered quickly.
If a designated provider underpins critical or important functions, test whether your exit and concentration-risk assumptions are still credible.

Section 8

Oversight of critical ICT providers (what changes when a provider is "critical")

DORA establishes an EU oversight framework for ICT third-party providers designated as critical. This influences what supervisors expect your contracts and evidence to support.

Prepare for increased transparency and request-response speed: you may need to provide register extracts and contract evidence quickly.

Current implementation fact: the ESAs published the first list of designated critical ICT third-party providers on 18 November 2025, so this oversight layer is now live rather than hypothetical.
Be ready to provide your register of information (full or sections) and related supervision information on request (Article 28).
Track whether key providers are designated as critical and adjust monitoring cadence and escalation accordingly.
For critical providers, note that the oversight framework includes powers and potential penalty payments for non-cooperation at provider level (DORA oversight provisions).

Section 9

Exit strategy playbook (what "credible exit" means)

A DORA exit plan is not "we can cancel anytime". It's the ability to transition or replace the service without unacceptable disruption, even under stress.

Design exits as engineering + procurement deliverables: data portability, infrastructure portability, and operational runbooks.

Define exit triggers: chronic SLA failures, security posture deterioration, regulatory constraints, concentration risk escalation.
Build a transition architecture: target state, migration plan, parallel run where feasible, rollback plan, and cutover criteria.
Contract for the exit: assistance obligations, data return/deletion, transition support, and access to logs/evidence for post-exit investigations.
Test exits: tabletop exercises for critical providers and "minimum viable migration" drills for key datasets and identities.

Section 10

Evidence pack checklist (what to have ready for supervisors)

Third-party risk programs fail audits when evidence is fragmented across procurement, security, and engineering systems.

Build a single evidence index that points to systems-of-record, not static attachments.

Management-body approved ICT third-party risk strategy and policy (Article 28 + RTS 2024/1773).
Due diligence pack for each critical/important service: evaluation, risk decision, compensating controls, and approvals.
Signed contract with DORA clause mapping (audit/access, monitoring, incident notice, BCP/DR testing, exit).
Subcontracting assessment record (RTS 2025/532) and subcontractor inventory for underpinning services.
Register-of-information export aligned to ITS 2024/2956 with relational keys and data quality checks.

Recommended next step

Keep EU DORA Third-Party Risk + Contract Clauses in one governed evidence system

SSOT can take EU DORA Third-Party Risk + Contract Clauses from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Evidence system

Open SSOT for EU DORA Third-Party Risk + Contract Clauses

Start from EU DORA Third-Party Risk + Contract Clauses and keep documents, evidence, and control records in one governed system.

Explore next step

Talk to Sorena

Talk through EU DORA

Review your current process, evidence gaps, and next steps for EU DORA Third-Party Risk + Contract Clauses.

Explore next step

Primary sources

References and citations

Commission Delegated Regulation (EU) 2024/1502 - Designation criteria for critical ICT third-party providers (RTS)

eur-lex.europa.eu

Referenced sections

Criteria for when ICT third-party providers may be designated as critical under DORA oversight.

Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements for ICT services supporting critical or important functions (RTS)

eur-lex.europa.eu

Referenced sections

RTS on due diligence, monitoring, audit/access rights, use of certifications/audit reports, and exit planning in contractual arrangements.

Commission Delegated Regulation (EU) 2025/532 - Subcontracting elements assessment for critical/important ICT services (RTS)

eur-lex.europa.eu

Referenced sections

RTS specifying elements to determine and assess when subcontracting ICT services supporting critical or important functions.

ESMA news - ESAs designate critical ICT third-party providers under DORA

esma.europa.eu

Referenced sections

Official announcement of critical ICT provider designations; useful for monitoring and updating critical provider status in third-party risk programs.

Regulation (EU) 2022/2554 (DORA) - Official Journal

eur-lex.europa.eu

Referenced sections

ICT third-party risk strategy, register of information, oversight framework, and cooperation provisions (including linkages to NIS2 cooperation structures).

Related guides