DORA Third-Party Risk Management: EU-Compliant Vendor Assessment Tools 2026

Post #4 in the sota.io EU DORA Compliance Tools Series

Every major financial sector breach of the last decade ran through a third-party vendor. SWIFT messaging systems compromised via a Bangladeshi bank's IT contractor. Capital One's data exposed through a misconfigured AWS service. TSB's catastrophic migration failure built on outsourced core banking software. The European legislator studied this pattern carefully before writing Articles 28–44 of DORA.

The result is the most demanding third-party ICT risk management framework ever enacted in financial services regulation. DORA doesn't just require you to assess your vendors — it designates the most critical ones as Critical Third-Party Providers (CTPPs), subjects them to direct ESA oversight, and holds your board personally accountable for every contractual arrangement you have with them.

The tools financial institutions were using for vendor risk management before DORA were built for a different world: questionnaire-based assessments, annual reviews, and checkbox compliance. DORA requires continuous monitoring, real-time contractual enforcement, and regulatory reporting in machine-readable format. Most US-built VRM platforms aren't designed for this. And all of them have a CLOUD Act problem.

What DORA Articles 28–44 Actually Require

Article 28: General Principles for ICT Third-Party Risk

Article 28 establishes that financial entities must manage ICT third-party risk "as an integral part of ICT risk within their ICT risk management framework." This isn't a separate compliance exercise — it's embedded in the same governance structure as internal ICT risk.

The key obligations:

• Documented strategy for ICT third-party risk management, reviewed annually and after each major ICT-related incident
• Register of Information (the "ICT vendor register") maintained for all contractual arrangements — submitted to the competent authority on request or regularly if mandated
• Pre-contractual assessment before engaging any new ICT vendor: risk analysis, due diligence, concentration risk evaluation
• Ongoing monitoring throughout the relationship, not just at contract signature

Article 28(2) specifically calls out concentration risk: if your entire payment processing runs through one US cloud provider, that's a DORA risk — even if that individual contract is well-managed.

Article 29: Key Principles for Managing ICT Third-Party Risk

Article 29 introduces proportionality: a tier-1 bank that outsources its core banking to a single vendor faces different requirements than an investment firm using cloud storage for backups.

The risk-proportional framework requires assessment of:

• Substitutability: How quickly could you replace this vendor if they failed? Could you replace AWS within 12 months?
• Criticality: Does this vendor process personal data, support critical functions, or handle payment flows?
• Systemic importance: Would your vendor failure cascade to the broader financial system?

The exit strategy requirement is new for most institutions. Article 29 mandates a documented exit strategy for each critical ICT arrangement — not a theoretical exercise, but a tested plan including data portability procedures, transition timelines, and alternative provider identification.

Article 30: Key Contractual Provisions

This is where most financial institutions will need to renegotiate existing vendor contracts. Article 30 specifies mandatory clauses for all ICT arrangements supporting critical or important functions.

Mandatory contractual provisions:

• Full description of services with specific service levels (SLAs must be DORA-measurable, not vague)
• Data location clauses: where data is processed, stored, and backed up — with requirements to notify of any changes
• Accessibility and recoverability: vendor must provide financial entity access to their premises for audit; must support business continuity
• Cooperation with competent authorities: vendor must cooperate with regulators on supervision, including providing data and access
• Termination rights: financial entity must have rights to terminate without excessive penalty when vendor fails DORA requirements
• Subcontracting visibility: vendor must disclose material subcontracting arrangements; change notifications are mandatory
• Audit rights: financial entity (or designated third party) must be able to conduct audits of the ICT vendor

The audit rights clause alone will trigger renegotiations with hyperscale cloud providers. AWS, Azure, and Google Cloud's standard terms don't include the on-premises audit access DORA requires. Their shared responsibility model and SOC2 reports are not DORA-equivalent substitutes.

Articles 31–44: Critical Third-Party Provider (CTPP) Designation

This is the most consequential innovation in DORA's third-party framework. The Joint Committee of ESAs (EBA, ESMA, EIOPA) can designate specific ICT vendors as Critical Third-Party Providers subject to direct EU regulatory oversight.

Designation criteria (Article 31):

• Number of financial entities using the provider's services
• Substitutability: how difficult would it be to replace the provider?
• Systemic relevance: would failure affect financial stability?
• Degree of interdependency between financial entities using the same provider

The ESAs publish the CTPP list. As of early 2026, the methodology is established and the first designations are expected. AWS, Microsoft Azure, and Google Cloud are virtually certain to be designated CTPPs given their concentration across European financial services.

What CTPP status means for vendors:

• Subject to oversight by a Lead Overseer (one of EBA, ESMA, or EIOPA)
• Required to provide all information requested by the Lead Overseer
• Subject to inspections, including on-premises visits
• Required to remediate risks identified by the Lead Overseer
• Potential CTPP-specific contractual requirements flowing down to financial entity contracts

What CTPP designation means for financial entities using designated vendors:

• Your contracts with CTPPs must include all Article 30 provisions
• You must report your CTPP relationships to your competent authority
• Your exit strategy for CTPPs must be regularly tested (not just documented)
• Your concentration risk assessment must specifically address CTPP reliance

The Registry of Information: DORA's Vendor Database Mandate

Article 28(3) requires financial entities to maintain a Register of Information for all ICT contractual arrangements. The EBA has published technical standards specifying the exact data fields required — there are over 130 fields per arrangement covering:

• Contract identifiers and dates
• Provider details (LEI code, registration, jurisdiction)
• Service descriptions (standardized service type codes)
• Data location (country, data center level)
• Criticality assessment (critical/important function: yes/no with rationale)
• Subcontractor chain (all material subcontractors, their jurisdictions)
• Business continuity provisions (RTO/RPO commitments in minutes)
• Audit provisions (type of audit rights, frequency)
• Concentration risk indicators

The Registry must be submitted to the competent authority "at least yearly" for significant financial entities, and immediately on request for all entities. It must be machine-readable in the EBA-specified format.

This is operationally significant: most existing vendor management systems don't capture data at this granularity, in this format. The US-built GRC and VRM tools that dominated financial services VRM before DORA were built for narrative risk assessments, not machine-readable regulatory submissions.

DORA Threat-Led Penetration Testing (TLPT) for Third Parties

Articles 26–27 cover TLPT, but third-party involvement in TLPT is substantial. Under Article 26(6), financial entities performing TLPT must include "all ICT systems and processes that support critical or important functions, including those outsourced to or contracted from ICT third-party service providers."

This means:

• Your cloud providers must allow your TLPT testers access to their infrastructure (to the extent it hosts your critical functions)
• Your core banking software vendor must participate in red team exercises targeting your production environment
• Results are shared with the competent authority

For EU-hosted infrastructure, TLPT is straightforward. For US-based cloud providers, negotiating TLPT access rights under Article 26 will require specific contractual amendments — and the hyperscalers' current TLPT policies vary significantly.

US Vendor Risk Management Tools: DORA Compliance Scorecard

The ServiceNow VRM Problem

ServiceNow is the dominant GRC platform in large financial institutions — most Tier 1 banks are already running it. The VRM module supports vendor assessments, contract tracking, and audit management. But:

EBA Registry Format: ServiceNow doesn't natively export in the EBA technical standard format. Custom integrations can generate the required fields, but require professional services and ongoing maintenance as the EBA standard evolves.

CTPP Monitoring: No native concept of regulatory CTPP status. You'd need a custom field and manual tracking process.

Data Residency: ServiceNow offers EU data centers, but the default configuration routes telemetry, updates, and support access through US infrastructure. ServiceNow Government (FedRAMP) exists, but there's no equivalent "DORA-compliant" configuration.

CLOUD Act: ServiceNow Inc. is a Delaware corporation. All ServiceNow data, including your vendor registry data, is potentially accessible to US federal law enforcement under the CLOUD Act regardless of which data center it sits in.

The Vanta Gap

Vanta became the dominant automated compliance platform for cloud-native companies through its SOC2 and ISO 27001 automation. It has added vendor risk features, but:

• Built for SaaS vendor assessment of tech companies — not financial sector ICT third-party risk
• No concept of DORA criticality assessment, Registry of Information, or CTPP tracking
• No EBA format support
• Primary data residence is in the US

Vanta is appropriate for a tech startup managing vendor questionnaires. It's not a DORA third-party risk management tool for a bank.

Archer's Partial Case

Archer (owned by RSA Security) has the deepest financial services VRM functionality of any US-origin platform. It handles complex risk frameworks, supports custom scoring models, and has some EBA-adjacent reporting. But RSA Security's ownership structure (private equity, US-based operations) creates the same CLOUD Act exposure as other US platforms.

Archer's implementation complexity is also substantial — typical financial institution deployments take 12–18 months and require dedicated implementation partners.

EU-Native DORA Third-Party Risk Management Tools

Riskonnect (EU Entity / Hybrid)

Riskonnect is headquartered in the US but operates a separate EU entity with EU-based data processing for its European financial services clients. The platform supports:

• Third-party risk assessment with configurable regulatory frameworks
• Contract lifecycle management including Art. 30 mandatory clause tracking
• Audit management with documented evidence chains
• Regulatory reporting templates (including EBA-adjacent formats)
• Concentration risk dashboards with visual dependency mapping

DORA Coverage: 19/25 — strong on contract management and audit, needs configuration for EBA Registry exact format

Limitation: US parent company = CLOUD Act exposure, even with EU entity. Transfer impact assessment required.

IBM OpenPages (EU GovCloud)

IBM OpenPages deployed on IBM Cloud Frankfurt (EU-sovereign configuration) is the strongest enterprise option for financial institutions requiring full data sovereignty.

DORA capabilities:

• Pre-built DORA regulatory control framework (updated January 2026)
• Third-party risk module with criticality assessment (critical/important function mapping)
• Registry of Information builder with EBA field mapping (not yet in exact EBA format, but closest of any commercial platform)
• CTPP designation tracking (added 2025)
• Contract management with Art. 30 clause tracking
• Audit planning and execution management
• Concentration risk heat maps with multi-tier vendor mapping

IBM Cloud Frankfurt: European data center with EU-sovereign configuration — data doesn't leave Frankfurt. IBM Germany is an EU legal entity for data processing purposes.

Score: 21/25 — strongest DORA-native functionality of any commercial platform. EBA Registry format requires additional configuration.

Limitation: IBM implementation cost is substantial. Not viable for smaller financial entities.

Diligent (UK/NL Operations)

Diligent has repositioned from board management software to a GRC platform with strong third-party risk capabilities. Its EU operations are centered in Amsterdam (NL), with EU data residency for European clients.

• Strong on vendor assessment workflows and evidence collection
• Board-level risk reporting (useful for DORA board accountability requirements)
• Contract tracking with configurable clause monitoring
• Limited on EBA Registry format — needs custom configuration

Score: 16/25 — good for board governance layer, limited on technical DORA specifics

Protecht (EU-available)

Protecht is an Australian-origin risk management platform that has expanded to EU financial services, offering EU data residency through AWS Frankfurt (shared responsibility model applies).

Score: 14/25 — workable for SME financial entities, not recommended for CTPP-exposed institutions

Open-Source / Self-Hosted Option: ERAMBA

ERAMBA is an open-source GRC framework (PHP/MySQL) used by financial institutions in several EU countries. Deployed self-hosted on EU infrastructure, it provides:

• Vendor risk management modules with configurable assessment frameworks
• Contract management
• Audit management
• No CLOUD Act risk (your infrastructure, your data)
• No vendor lock-in

Score: 18/25 — strong sovereignty posture, requires technical implementation resources. 100+ EU financial institutions (mostly cooperative banks, credit unions) run ERAMBA in production.

The "Registry of Information" Technical Implementation Problem

The EBA's Implementing Technical Standards (ITS) for the Registry of Information are specific. The required submission format includes:

130+ mandatory fields per ICT arrangement including:

• ICT_PROV_LEI — the Legal Entity Identifier of the ICT provider (not all vendors have LEIs)
• SERV_TYPE_CODE — standardized service type from a closed EBA codelist
• DATA_STORAGE_LOC_CTRY — ISO country codes for all data storage locations (not "EU" — specific countries)
• SUB_OUTSRC_CHAIN — complete subcontracting chain to the 3rd tier
• EXIT_PLAN_EXISTS — binary flag plus document reference
• BCP_RTO_MIN — recovery time objective in minutes (many contracts specify this in hours/days)

Most financial institutions' current vendor inventories don't capture data at this granularity. The implementation challenge isn't just the software — it's the data collection exercise:

1. LEI acquisition: Many smaller vendors don't have LEIs and must register for one
2. Data location specificity: Vendors must disclose data storage at country level (AWS "EU" is not sufficient — is it Dublin, Frankfurt, or Stockholm?)
3. Subcontractor chain visibility: Tier-1 vendors must disclose their material subcontractors; those subcontractors must then be added to your registry
4. RTO/RPO in minutes: Standard vendor contracts specify these in hours — requires renegotiation or clarification letters

Practical Implementation: The EU-Sovereign DORA VRM Stack

For financial institutions requiring full DORA compliance with EU data sovereignty:

Tier 1: Large Banks / Significant Financial Entities

IBM OpenPages (Frankfurt) — Core DORA VRM platform
├── DORA control framework (pre-built)
├── Registry of Information management
├── CTPP designation tracking
├── Art. 30 contract clause monitoring
└── Audit management

Wazuh (EU-deployed) — ICT security monitoring for vendor connections
├── Vendor network traffic monitoring
├── Anomaly detection for third-party connections
└── Evidence for Art. 28 ongoing monitoring requirement

ERAMBA (self-hosted EU) — Complementary GRC for smaller arrangements
└── Long-tail vendor assessment (non-critical arrangements)

Tier 2: Mid-Size Financial Entities / Fintechs

ERAMBA (self-hosted, EU data center) — Primary VRM
├── Vendor assessment workflows
├── Contract management
├── Audit tracking
└── Risk scoring (configurable for DORA criticality)

Riskonnect (EU entity) — If budget exists for commercial support
└── Enhanced reporting and regulatory submission support

Custom EBA Registry exporter (Python/PostgreSQL)
└── Generates EBA ITS format from existing vendor data

Tier 3: Smaller Credit Institutions / Payment Institutions

LibreOffice Calc / PostgreSQL (EU VPS, self-hosted)
├── Manual Registry of Information (EBA CSV template)
└── Adequate for entities with <20 ICT arrangements

ERAMBA (hosted, EU provider)
└── Structured vendor assessment workflow

The CTPP Concentration Risk Problem No Tool Can Solve

Every DORA vendor risk tool faces the same fundamental problem: the three largest cloud providers (AWS, Azure, Google Cloud) are all CLOUD Act-exposed US entities, and all three are virtually certain to be designated CTPPs.

The Registry of Information will make concentration risk visible. The EBA already has informal estimates suggesting that European banking is critically dependent on two or three hyperscale cloud providers. DORA doesn't prohibit this concentration — but it requires explicit risk acceptance at board level, documented exit strategies, and tested multi-cloud or on-premise fallback capabilities.

The tool question is secondary. The strategy question is primary: Can your institution recover critical functions within 4 hours without its primary cloud provider?

If the answer is no, DORA Article 29's exit strategy requirement isn't a documentation exercise — it's a capability gap that no VRM software can resolve.

DORA Third-Party Risk Management Timeline

2025 (DORA Application Date — January 17)

• Full DORA application from January 17, 2025
• Registry of Information submissions begin (on-request basis)
• All new ICT contracts must include Art. 30 provisions
• Existing contracts: 12-month grace period for critical arrangements

2026 (Current)

• CTPP designation list expected Q1-Q2 2026 — ESA methodology published, designations imminent
• First annual Registry submissions (for entities required to submit annually)
• TLPT programs for Tier 1 financial entities: first test cycles completing
• Competent authorities issuing first supervisory findings on third-party risk management

2026-2027 (Maturation)

• CTPP Lead Overseer oversight operational — direct ESA engagement with designated providers
• Financial entities with CTPPs receiving supervisory requirements to remediate CTPP-related gaps
• Exit strategy tests expected (first formal TLPT cycles for CTPPs)

What to Prioritize Now

1. Complete your Registry of Information — even in spreadsheet form. Competent authorities can request it at any time.
2. Identify your critical and important functions — Art. 30 mandatory clauses apply to ICT arrangements supporting these functions.
3. Audit your contracts against Art. 30 requirements — particularly data location, audit rights, and exit provisions.
4. Build your CTPP shortlist — identify which of your vendors are likely to be designated and prioritize those relationships.
5. Start exit strategy documentation for your most critical ICT arrangements.

Choosing a DORA VRM Tool: Decision Framework

Does your institution have >100 ICT arrangements?
├── YES → Commercial platform required (IBM OpenPages or Riskonnect EU)
│         Start implementation now — 12+ month timeline
└── NO → ERAMBA (self-hosted) covers this scope

Do you have CTPP-designated (or likely-to-be-designated) providers?
├── YES → CTPP tracking capability is mandatory in your tool
│         IBM OpenPages has this built-in
└── NO → Concentration risk monitoring still required

Do you require full EU data sovereignty?
├── YES → IBM OpenPages (Frankfurt) or ERAMBA (self-hosted EU)
│         Avoid US-origin platforms with CLOUD Act exposure
└── PARTIAL → Riskonnect EU entity (transfer impact assessment required)

Is your institution a smaller credit institution or payment institution?
├── YES → ERAMBA + EBA Registry spreadsheet template
│         Proportionality principle applies
└── NO → Full platform implementation required

Conclusion: Third-Party Risk Is Now Existential

DORA's third-party risk framework is not a compliance checkbox. The CTPP designation mechanism creates direct regulatory oversight of the vendors your institution depends on. The Registry of Information creates transparency about your vendor dependencies that didn't exist before. The exit strategy requirement forces genuine resilience planning.

For financial institutions still running their VRM on questionnaire-based US platforms or spreadsheets, the current supervisory environment creates material risk. Competent authorities are requesting Registries. CTPP designations are imminent. The contractual renegotiations with Article 30 requirements take 12–18 months for large portfolios.

The tools exist. The implementation path exists. The question is whether your institution is treating DORA third-party risk as the operational risk event it represents — or filing it under "compliance."

This is Post #4 in sota.io's EU DORA Compliance Tools Series. Previous posts covered DORA Overview, ICT Risk Management Tools, and Incident Reporting Requirements. Post #5 will cover the complete DORA compliance stack for financial services.