DORA quietly turned your third-party providers into your own regulatory exposure. If your core banking platform runs on a vendor you don't control, the regulator no longer cares. You are accountable for their resilience, their security controls, and their ability to recover when they fail.
Most fintech CTOs I talk to understand this in the abstract. Far fewer have done the work to operationalise it. Article 28 of the Digital Operational Resilience Act is not a procurement checklist item. It is a live obligation that runs for the entire duration of every ICT contract you hold — and as of January 2025, it applies to any financial entity operating in the EU.
What Article 28 Actually Requires
The regulation is unusually prescriptive for EU law. It does not say "manage third-party risk appropriately." It specifies what your contracts must contain, what your register must look like, and what your exit strategy must cover.
The core obligations break into four operational areas.
A complete, current ICT third-party register. Not a list of vendors — a register of ICT services, including whether each service supports a critical or important function, the date of the last assessment, and the concentration risk category. The EBA/ESMA/EIOPA joint regulatory technical standards specify the columns. If you haven't mapped your vendor landscape to those columns, you don't yet have a DORA-compliant register.
Mandatory contractual clauses. Every ICT contract supporting a critical or important function must include: audit rights (yours, not just the regulator's), subcontractor disclosure, incident notification timelines, performance SLAs tied to your DORA obligations, and provisions for termination and data return on exit. Existing contracts signed before January 2025 must be remediated by January 2026 — a deadline that is closer than it looks when your legal team quotes four to six weeks per contract for renegotiation.
Concentration risk assessment. You must assess whether your dependency on a single provider — or a small group of providers — creates systemic risk to your operations. This is where cloud hyperscaler dependency gets expensive. If Azure, AWS, or GCP hosts your critical functions and goes down, your DORA filing must explain how you survive that. Multi-region architecture is table stakes. Multi-provider planning is increasingly expected.
Exit strategies for critical providers. Not a theoretical plan. A documented, tested exit strategy that demonstrates your organisation can migrate a critical function away from a provider within a defined timeframe without unacceptable disruption to services. Most fintechs have never modelled this for their core providers.
The Register Problem
The register is where most teams get stuck first, because doing it properly requires resolving a question most engineering organisations avoid: what actually constitutes a "critical or important function"?
The regulation defers this to the financial entity — which sounds like flexibility but is actually a trap. If you define your critical functions too narrowly to reduce your register scope, you're exposed in a supervisory review. If you define them too broadly, you own audit obligations on fifty vendors instead of fifteen.
The definition problem regulators will probe
Your definition of 'critical or important function' will be the first thing a supervisory authority reviews. If it conveniently excludes your payment processor, your KYC provider, and your cloud infrastructure — but includes only your core ledger — expect questions. Regulators are not naive about scope minimisation. Your definition needs to be defensible, documented, and applied consistently.
Here is a working classification approach I use with clients:
| Provider Category | Criticality Test | Typical DORA Classification |
|---|---|---|
| Core banking / ledger platform | Failure halts revenue-generating transactions | Critical |
| Payment rails (SEPA, card schemes) | Failure stops customer payment execution | Critical |
| KYC / AML / identity verification | Failure triggers regulatory breach risk | Important |
| Cloud infrastructure (primary region) | Failure affects availability of critical systems | Critical |
| Cloud infrastructure (secondary/DR) | Failure degrades but doesn't halt operations | Important |
| Internal developer tooling (CI/CD, source control) | Failure delays but doesn't halt service | Important or excluded |
| SaaS productivity tools (email, collaboration) | No direct impact on financial services delivery | Typically excluded |
| Data analytics / BI platforms | Indirect impact on business functions | Context-dependent |
Getting this classification right is not a one-hour workshop. It requires a session with operations, compliance, and engineering together — because the business function perspective and the technology dependency perspective produce different answers when done separately.
The Contract Remediation Timeline Is Brutal
The legal requirement to remediate pre-2025 ICT contracts by January 2026 sounds manageable until you count your contracts and factor in your legal team's capacity.
A typical fintech with 30–50 material ICT relationships needs to:
- Identify which contracts require remediation (not all do — only those supporting critical or important functions)
- Conduct a gap analysis against the Article 28 mandatory clauses for each
- Negotiate amendments with each vendor — some of whom will push back on audit rights clauses
- Execute and archive the amendments
Four to six weeks per contract negotiation is optimistic if the vendor is a hyperscaler or a platform with standard-form contracts. AWS, Microsoft, and Stripe have DORA addenda that cover some requirements. None of them give you unconditional audit rights — instead they offer third-party audit reports (SOC 2, ISO 27001) as a substitute. Whether that substitution satisfies your obligations depends on your regulator, your function classification, and what specific controls you need assurance on.
The vendors who are genuinely difficult are mid-tier SaaS providers who have not prepared DORA-compliant addenda. Those negotiations can run three to four months. Start them now.
Prioritise by criticality, not by contract renewal date
The natural instinct is to address DORA contract remediation at renewal time to avoid renegotiation costs. That approach will leave you non-compliant through most of 2025. Prioritise by function criticality instead. Remediate your three to five most critical providers first, regardless of contract dates. Those are the ones where a regulatory gap creates the most exposure.
Subcontractor Disclosure and the Fourth-Party Problem
Article 28 requires your vendors to disclose their own ICT subcontractors — the fourth parties in your dependency chain. This sounds academic until you realise that your core banking vendor might run on AWS, their KYC module might use a third-party API, and their disaster recovery might sit in a data centre you've never heard of.
Fourth-party risk is not new, but DORA makes your responsibility for it explicit. You must know the material subcontractors of your critical ICT providers, assess concentration risk across that chain, and maintain records of those dependencies.
Most vendors will provide a subcontractor list. Getting it updated annually, and getting notification of material changes within a contractually-required timeframe, requires you to negotiate those terms explicitly. Default SaaS terms don't include them.
Exit Strategies: The Test Nobody Passes
The exit strategy obligation is the one that exposes the most architectural debt. DORA requires that you can exit a critical ICT provider and maintain business continuity. The question is not whether you can migrate in theory — it is whether you have:
- Documented the dependencies well enough to know what a migration involves
- Estimated the time, cost, and resource requirements of migration
- Identified alternative providers or in-house alternatives
- Tested at least the critical path elements of the migration process
Most fintechs have not done this for their core banking platform, their payment infrastructure, or their primary cloud provider. The migration of a core banking system typically takes 18–36 months and costs seven to eight figures. That is not an exit strategy — it is an exit aspiration.
The pragmatic answer for most organisations is a tiered exit strategy: immediate actions that reduce dependency (e.g., extracting and owning your data in a portable format), medium-term actions that create migration optionality (e.g., API abstraction layers, portable data models), and long-term investments that enable actual migration if required.
| Exit Tier | Timeframe | What It Covers | Typical Effort |
|---|---|---|---|
| Data sovereignty | Immediate | Own your data outside the vendor's walls; exportable formats | 2–4 weeks |
| Operational runbooks | 1–3 months | Document every dependency; map critical path to alternative | 4–8 weeks |
| Parallel capability | 3–12 months | Test alternative providers on non-critical workloads | Varies |
| Full migration readiness | 12–36 months | Validated ability to operate without the primary vendor | Major programme |
You are not required to be at tier four for every provider. You are required to demonstrate that you have a credible, documented strategy and that you understand your own dependencies well enough to execute it.
What the Supervisory Review Actually Looks Like
The national competent authorities — BaFin in Germany, DNB in the Netherlands, the FCA in the UK for firms under UK DORA equivalents — are conducting supervisory reviews that focus on three things in the first wave: the ICT third-party register, evidence of contract remediation progress, and incident reporting processes.
They are not expecting perfection. They are expecting evidence of a structured programme with documented progress. The firms that are most exposed are those who have done nothing — no register, no gap analysis, no remediation timeline. The firms that are best positioned have a documented programme, can show what they've completed, and can articulate what remains and when.
That posture requires someone senior enough to own it across legal, engineering, and compliance — and experienced enough in both the regulatory language and the technical architecture to translate between them.
The Operational Model That Works
DORA third-party risk is not a legal project or a technology project. It is a joint programme that requires legal (contract remediation), engineering (architecture dependency mapping, exit strategy modelling), security (vendor security assessment), and compliance (register maintenance, regulatory reporting) to work from the same source of truth.
The register is the single source of truth. It drives the contract remediation priority. It informs the concentration risk assessment. It populates the regulatory template when supervisors ask. If your register lives in a spreadsheet owned by one person in compliance, you have a fragility problem that DORA itself would flag.
The four functions feed into and draw from a shared register:
The firms I've seen manage DORA third-party risk well have a vendor governance framework that was mostly in place before DORA. The ones struggling are those treating it as a new compliance obligation to document rather than an operational reality to manage.
If you're working through DORA third-party obligations and need someone who can translate between the regulatory text and your actual architecture, let's talk. I work with fintech and financial services CTOs on exactly this — from register design to contract negotiation strategy to board-level reporting. Book a 30-minute discovery call and let's scope what your programme actually needs.