Learn
If you work in compliance at an EU financial entity, you already know that the Digital Operational Resilience Act (DORA) went beyond what anyone expected for ICT third-party risk management. Articles 28 through 44 of Regulation (EU) 2022/2554 don’t merely suggest that financial institutions track their ICT vendors. They mandate a structured, reportable register of every ICT service arrangement, complete with mandatory contractual clauses, sub-outsourcing chain visibility, concentration risk analysis, and exit strategies - all subject to direct supervisory oversight.
This is not generic vendor management. DORA’s TPRM requirements are architecturally specific: they prescribe what data your register must contain, which contractual provisions are non-negotiable, and how supervisory authorities will assess your compliance. The ESAs’ Regulatory Technical Standards (RTS) under Article 28(9) add further granularity, defining the exact information elements financial entities must maintain.
Whether you’re building your DORA ICT third-party risk register from scratch or remediating an existing vendor inventory, this guide walks you through every requirement, every data field, and every operational challenge you’ll face. We’ve worked with compliance teams at banks, insurers, and investment firms across the EU - and the patterns of struggle (and success) are remarkably consistent.
📜
Chapter V Overview
What DORA Actually Requires for ICT Third-Party Risk
DORA dedicates an entire chapter - Chapter V, Articles 28 through 44 - to ICT third-party risk. This is not a single article with broad principles. It is a prescriptive, multi-layered regime that imposes obligations at every stage of the ICT service lifecycle: pre-contractual due diligence, contract negotiation, ongoing monitoring, and exit planning.
The scope is deliberately wide. DORA applies to all ICT services provided by third parties, not just outsourcing arrangements. Cloud infrastructure, SaaS platforms, managed security services, data analytics providers, payment processing systems, network connectivity - if a third party delivers ICT services that your financial entity relies on, it falls within scope.
Key Regulatory Architecture
DORA’s third-party risk framework has three pillars: (1) the register - a structured inventory of all ICT third-party arrangements (Art. 28(3)); (2) contractual requirements - mandatory clauses that must appear in every ICT service agreement (Art. 30); and (3) the oversight framework - direct ESA supervision of critical ICT third-party service providers (Arts. 31-44). Financial entities are responsible for pillars 1 and 2. Pillar 3 is the supervisory authorities’ domain, but your register data feeds directly into their oversight decisions.
Article 28(3) is unambiguous: financial entities shall maintain and update a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers. This register must be available to competent authorities upon request, and entities must report it to the ESAs at least annually. The register is not a “nice to have” - it is the primary supervisory artifact for DORA TPRM compliance.
The ESA draft RTS under Article 28(9) further specifies the register’s data structure. Financial entities must capture, at a minimum:
| Data Category | Required Elements | Reference |
|---|---|---|
| Provider identification | Legal name, LEI/BIC, registered address, parent company, country of incorporation | Art. 28(3), RTS Annex |
| Service description | Nature and scope of ICT services, service type classification, functions supported | Art. 28(3), RTS Annex |
| Criticality assessment | Whether the service supports critical or important functions, rationale for classification | Art. 28(1)(a) |
| Contractual details | Contract start/end dates, renewal terms, termination notice periods, governing law | Art. 28(3), Art. 30 |
| Data processing | Data locations, processing jurisdictions, data sensitivity classification | Art. 28(8), Art. 30(2)(b) |
| Sub-outsourcing | Subcontractor details, chain depth, critical subcontractor identification | Art. 29(2), Art. 30(2)(a) |
| Business function mapping | Which business functions each provider supports, single/multi-provider dependencies | Art. 28(1)(b) |
| Risk assessment | Risk rating, last assessment date, identified risks, residual risk level | Art. 28(4) |
This is not an aspirational list. Supervisory authorities will request this register, verify its completeness, and use it to identify systemic concentration risks across the sector. If your register cannot produce these fields on demand, you have a compliance gap.
📝
Article 30 Deep Dive
The 14+ Mandatory Contract Clauses You Cannot Omit
Article 30 is the most operationally consequential provision in DORA’s third-party risk chapter. It mandates specific contractual clauses that must appear in every ICT service agreement. For arrangements supporting critical or important functions, the requirements are even more stringent. This is not a matter of “best practice” - contracts lacking these clauses will trigger supervisory findings.
Here are the mandatory provisions, with practical commentary on what supervisors actually look for:
| # | Mandatory Clause | What It Must Include | Supervisor Focus |
|---|---|---|---|
| 1 | Service level descriptions | Quantitative and qualitative performance targets, specific SLA metrics, measurement methodology | Are SLAs measurable? Not vague “best efforts” language |
| 2 | Data locations & processing | Where data is stored, processed, and backed up; any cross-border transfers; applicable data protection law | Geographic specificity - “EU” is often insufficient; they want country-level |
| 3 | Business continuity provisions | Provider’s BCM obligations, RTOs, RPOs, disaster recovery commitments, testing frequency | Alignment with your own DORA testing programme |
| 4 | Right to audit & access | Unrestricted audit rights for you and your competent authority; on-site inspection provisions; access to relevant documentation | Contractual obstacles to audit are a red flag; “upon reasonable notice” must not mean “never” |
| 5 | Termination rights & transition | Clear termination triggers, minimum notice periods, transition assistance obligations, data return/deletion | Can you actually exit? Transition plans must be tested, not theoretical |
| 6 | Sub-outsourcing approval | Prior approval or notification rights for subcontracting, right to object, full chain visibility | Can you identify every link in the chain? Are approval rights real or pro forma? |
| 7 | Security requirements | Minimum security standards, certifications (ISO 27001, SOC 2), vulnerability management, access controls | Generic “industry standard” clauses are insufficient; supervisors want specifics |
| 8 | Incident notification obligations | Timeframes for incident reporting, severity classification, root cause analysis provision, cooperation duties | Must align with DORA’s own incident reporting timelines (Art. 19) |
| 9 | Cooperation with authorities | Provider obligation to cooperate with competent authorities and resolution authorities upon request | Provider cannot refuse supervisory access; clause must be explicit |
| 10 | Performance monitoring | Reporting cadence, dashboards, right to benchmark, escalation procedures for SLA breaches | Are you actually monitoring, or just collecting dust on quarterly reports? |
| 11 | Data portability & interoperability | Data export formats, API availability, migration support, no proprietary lock-in | Can you retrieve your data in a usable format if you need to move? |
| 12 | TLPT participation | Obligation to participate in threat-led penetration testing where required by competent authority | Critical function providers cannot opt out of TLPT programmes |
| 13 | Intellectual property & confidentiality | IP ownership clarity, confidentiality obligations, data sovereignty provisions | Who owns the data? What happens to it post-termination? |
| 14 | Change management | Notification of material changes to service, infrastructure, or personnel; approval requirements for changes affecting critical functions | Unannounced infrastructure changes to critical services are a supervisory concern |
Practical Reality Check
Most financial entities we work with discover that 40-60% of their existing ICT contracts are missing at least three of these mandatory clauses. The most commonly absent: sub-outsourcing approval rights, TLPT participation obligations, and specific data location commitments. Contract remediation is typically a 6-12 month programme - start early, prioritize critical function providers, and maintain a clause-by-clause compliance tracker for each arrangement.
📌
Step-by-Step Process
Building Your ICT Provider Register
Building a DORA-compliant ICT provider register is not a single afternoon’s work. It is a structured programme that touches procurement, IT, business lines, legal, and compliance. Here is the process that works, broken into five discrete phases:
Step 1: Inventory All ICT Service Providers
DORA’s scope extends beyond traditional “vendors.” You must capture every entity that provides ICT services to your organization, including cloud providers, SaaS platforms, managed service providers, data feeds, telecommunications, hardware maintenance, and consultants with system access. Start with procurement records, accounts payable data, software asset inventories, and IT department knowledge. Cross-reference against your network and access control logs to catch shadow IT.
Common pitfall: Teams miss intra-group ICT providers (parent company shared services) and free-tier SaaS tools used by individual business lines. Both are in scope.
Step 2: Map Providers to Business Functions
For each ICT service provider, determine which business functions they support. DORA distinguishes between critical or important functions (CIFs) and non-critical functions, and the distinction drives your contractual obligations. A function is critical or important if its disruption would materially impair the entity’s financial performance, continuity, or compliance with regulatory obligations.
This mapping must be bidirectional: for each provider, list supported functions; for each critical function, list all providers. This reveals single points of failure and concentration risks that are invisible in a flat vendor list.
Step 3: Document Contractual Arrangements
For each provider, record the full contractual arrangement: contract reference, start and end dates, renewal terms, governing law, and critically, the clause-by-clause status against Article 30’s mandatory provisions. Build a compliance matrix that tracks which clauses are present, absent, or partially addressed in each contract.
For critical function providers, Article 30(2) imposes additional requirements including specific exit plans, performance monitoring clauses, and enhanced audit rights. Your tracking must distinguish between the baseline obligations (Art. 30(1)) and the elevated requirements for CIF arrangements.
Step 4: Track Sub-Outsourcing Chains
For each provider, identify whether they subcontract any part of the ICT service, who those subcontractors are, where they operate, and whether the subcontracted portion involves critical or important functions. This is one of DORA’s most operationally challenging requirements and deserves its own section (below). At minimum, your register must capture: subcontractor identity, the service element subcontracted, the subcontractor’s jurisdiction, and your contractual approval rights over the subcontracting arrangement.
Step 5: Assess Concentration Risk
Concentration risk analysis is mandatory under Article 29(1). You must assess whether your ICT third-party arrangements create undue dependency on individual providers, specific geographies, or particular technology stacks. This is not a one-time exercise - it must be reviewed whenever arrangements change and at least annually. Details on how to perform this analysis follow in the next section.
“The register is not a static document. It is a living operational tool that must be updated in real time as contracts change, providers are onboarded or offboarded, and services evolve. Supervisory authorities expect to see a register that reflects your current state, not your state at last year’s annual review.”
- ESA guidance on DORA implementation
📈
Risk Analysis
Concentration Risk: The Hidden Compliance Killer
Concentration risk under DORA is not merely about having “too many eggs in one basket.” It is a multi-dimensional analysis that supervisory authorities take extremely seriously - because systemic concentration in ICT services is one of the primary threats DORA was designed to address.
Article 29(1) requires financial entities to assess, at least annually, whether their ICT third-party arrangements pose concentration risks. The ESA draft RTS provides further guidance on the dimensions that must be considered:
Provider Concentration
Do multiple critical functions depend on the same provider? If your core banking, payments, and regulatory reporting all run on a single cloud provider, a disruption to that provider could simultaneously disable all three. Map provider dependency across functions and flag single-provider dependencies for critical function pairs.
Geographic Concentration
Are your ICT services concentrated in a single jurisdiction or region? Consider data centre locations, processing centres, and support teams. A natural disaster, political instability, or regulatory change in that jurisdiction could cascade across your operations. DORA explicitly flags geographic concentration as a risk factor.
Technology Stack Concentration
Even if you use multiple providers, do they all rely on the same underlying technology? Three different SaaS vendors all running on AWS still represent AWS concentration risk. Your analysis must look through providers to their infrastructure dependencies, particularly for critical functions.
Substitutability Assessment
For each critical provider, assess how difficult and how long it would take to switch. Proprietary data formats, deep integration dependencies, regulatory approval requirements for new providers, and migration complexity all factor in. Low substitutability combined with high criticality equals high concentration risk.
How to Calculate It
Build a concentration risk matrix with three axes: criticality of functions supported (high/medium/low), dependency depth (number of critical functions relying on this provider), and substitutability (high/medium/low difficulty to replace). Providers scoring high on criticality, high on dependency depth, and low on substitutability are your highest concentration risks. Document the rationale for each rating and maintain exit strategies for all high-concentration providers - DORA Article 28(8) makes this explicit.
🔗
Chain Visibility
Sub-Outsourcing Chain Tracking: Your Provider’s Providers
DORA Article 29(2) imposes one of the regulation’s most operationally difficult requirements: financial entities must maintain visibility into the sub-outsourcing chain of their ICT service providers. When your cloud provider subcontracts data centre operations, or your SaaS vendor uses a third-party authentication service, those downstream arrangements are within the scope of your risk management obligations.
Article 30(2)(a) specifically requires contracts supporting critical or important functions to include provisions on sub-outsourcing - including the right to approve or object to subcontractors, notification requirements for changes, and the ability to terminate if sub-outsourcing materially changes the risk profile.
In practice, this means your register must capture:
| Sub-Outsourcing Data Point | Why It Matters |
|---|---|
| Subcontractor identity & LEI | Enables supervisory authorities to identify systemic dependencies across the sector |
| Service element subcontracted | Determines whether the subcontracted portion involves critical functions |
| Jurisdiction of subcontractor | Flags geographic concentration and potential data sovereignty issues |
| Chain depth (levels) | Deeper chains mean longer blast radius and harder recovery; supervisors flag chains >2 levels |
| Your approval rights | Confirms you have contractual ability to object to subcontractors |
| Last notification/change date | Shows whether your sub-outsourcing data is current or stale |
“The biggest operational challenge in sub-outsourcing chain tracking is getting the data in the first place. Many ICT providers consider their subcontractor relationships commercially sensitive. Your leverage is your contract: if it includes the mandatory Article 30 clauses on sub-outsourcing, you have the right to demand this information. If it doesn’t, add it during the next renewal - and flag the contract as non-compliant until you do.”
Large cloud providers like AWS, Microsoft Azure, and Google Cloud have started publishing sub-processor lists and data processing locations in response to DORA demand, but these are usually presented as web pages that change without notice. You need a process to monitor these pages, capture changes, and assess their impact on your risk profile.
⚠️
Supervisory Findings
Common TPRM Gaps: What Supervisors Find vs. What They Expect
Based on early supervisory reviews and industry consultations, here are the most common DORA TPRM gaps - and what supervisory authorities actually expect to see:
| What Supervisors Find | What They Expect |
|---|---|
| Spreadsheet-based vendor lists with inconsistent fields | Structured register conforming to ESA RTS data model, exportable in standard format |
| No distinction between critical and non-critical providers | Documented criticality assessment for every provider with rationale |
| Contracts missing 3-5 mandatory Article 30 clauses | Clause-by-clause compliance tracker with remediation timeline for gaps |
| No sub-outsourcing data whatsoever | Sub-outsourcing chain documentation at least two levels deep for CIF providers |
| Concentration risk “considered” but not formally assessed | Multi-dimensional concentration risk matrix reviewed annually |
| Exit plans written as one-page policy statements | Operational exit plans with timelines, resource estimates, tested procedures |
| Business function mapping limited to “IT systems” | Provider-to-function and function-to-provider bidirectional mapping |
| Risk assessments performed at onboarding only | Regular risk reassessment cycle with trigger-based reviews for material changes |
| Register updated annually (if at all) | Real-time maintenance with change log and audit trail |
The Bottom Line
Supervisory authorities are not evaluating whether you have a vendor list. They are evaluating whether you have a structured, current, actionable register that demonstrates you understand your ICT third-party dependencies, have assessed the risks, secured appropriate contractual protections, and can exit arrangements when necessary. The gap between most entities’ current state and DORA’s requirements is significant - but bridgeable with the right tooling and approach.
🚪
Operational Resilience
Exit Strategies and Ongoing Register Management
DORA Article 28(8) mandates that financial entities maintain exit strategies for ICT third-party service arrangements supporting critical or important functions. These are not theoretical documents filed and forgotten. Supervisors expect exit plans that have been validated through tabletop exercises or actual dry runs, with realistic timelines and resource estimates.
An effective exit plan must address:
Data Migration
How will data be extracted from the provider? In what format? How long will migration take? What is the data integrity verification process? Contracts must guarantee data portability in standard, non-proprietary formats.
Alternative Providers
Have you identified at least one alternative provider for each critical function? Have you pre-qualified them? DORA expects that switching is operationally feasible, not just theoretically possible.
Transition Timeline
Realistic estimates for the full transition: procurement, configuration, data migration, testing, parallel running, and cutover. For complex arrangements, this could be 12-18 months. Your exit plan must reflect this reality, not aspirational timelines.
Continuity During Transition
How will the business function continue operating during the transition period? Contractual provisions for continued service during transition, even after termination notice, are essential. The exit plan must not create its own operational disruption.
Beyond exit planning, ongoing register management requires defined processes for:
Trigger-based updates: Contract renewals, provider changes (M&A, restructuring), service scope changes, incident occurrences, and sub-outsourcing changes should all trigger register reviews.
Annual comprehensive review: At least once per year, the entire register should be reviewed for accuracy, completeness, and alignment with the current operational landscape. This review should feed into the entity’s annual DORA reporting to the competent authority.
Supervisory reporting: Under Article 28(3), the register must be reported to the ESAs. Your register’s data structure must be exportable in the format prescribed by the ESA implementing technical standards (ITS). Building this export capability retroactively is painful - design for it from the start.
⚡
Purpose-Built Tooling
How Venvera Automates DORA TPRM
Everything described above - the structured register, contractual clause tracking, sub-outsourcing chains, concentration risk analysis, exit plan management - can be managed in spreadsheets. But spreadsheets don’t scale, don’t enforce data integrity, can’t calculate concentration risk automatically, and won’t pass supervisory scrutiny when an authority asks for an export in ESA ITS format at 48 hours’ notice.
Venvera was built specifically for DORA compliance, including the full Chapter V TPRM regime. Here is what it provides out of the box:
📚
ICT Provider Register
Structured register conforming to the ESA RTS data model. Every field supervisors expect is built in: provider identification, LEI, service descriptions, criticality classifications, contract details, and risk assessments. Exportable in the ESA ITS reporting format.
📋
Contractual Clause Tracking
Article 30 compliance matrix for every contractual arrangement. Track each mandatory clause as present, absent, or partially addressed. Automated alerts for contracts missing critical clauses. Remediation workflow with deadline tracking and owner assignment.
📈
Concentration Risk Dashboard
Automated concentration risk scoring across four dimensions: provider, geographic, technology stack, and substitutability. Visual heatmaps showing dependency clusters. Alerts when new arrangements increase concentration risk beyond defined thresholds.
🔗
Sub-Outsourcing Mapping
Visual chain mapping showing each provider’s subcontractors, their jurisdictions, and the service elements subcontracted. Chain depth tracking with alerts for chains exceeding two levels. Approval workflow for subcontractor changes with full audit trail.
🚪
Exit Plan Management
Structured exit plans for each critical function provider with data migration checklists, alternative provider registers, transition timelines, and testing records. Automated reminders for annual exit plan reviews and updates.
📁
Business Function Mapping
Bidirectional mapping between ICT providers and business functions. Criticality classification with documented rationale. Single-point-of-failure detection that flags critical functions with only one provider. Gap analysis for functions without adequate backup arrangements.
📊
ESA Reporting Export
One-click export of your entire register in the format prescribed by the ESA implementing technical standards. No last-minute scramble to restructure data when your competent authority requests the register. Validation checks flag incomplete records before export.
🔔
Change Management & Audit Trail
Every change to the register is logged with timestamp, user, and before/after values. Contract renewal reminders, criticality reassessment triggers, and sub-outsourcing change alerts. Full audit trail demonstrating to supervisors that your register is actively maintained.
Why Purpose-Built Matters
Generic GRC tools treat DORA TPRM as a checkbox exercise - a vendor list with some extra fields. Venvera was designed around the actual regulatory data model: the ESA RTS register structure, Article 30’s mandatory clauses, concentration risk dimensions, and sub-outsourcing chain depth. The difference shows up when a supervisor asks for your register: purpose-built tooling produces a compliant export in seconds, while generic tools require weeks of manual data transformation.
Disclaimer: This article provides general guidance on DORA ICT third-party risk management requirements. It does not constitute legal or regulatory advice. Financial entities should consult with their legal advisors and competent authorities regarding specific compliance obligations under Regulation (EU) 2022/2554.
