DORA, fintech vendor risk and ICT outsourcing

The Digital Operational Resilience Act (DORA) sets EU requirements for how in-scope financial entities manage information and communication technology (ICT) risk, handle incidents, test resilience and govern their ICT third parties. For fintech teams the key question is whether you face DORA directly, as an in-scope entity, or contractually, as a vendor to one. Either way, DORA does not let a regulated entity outsource away its responsibility. This article separates those two forms of exposure.

Legal and regulatory status was reviewed on 7 July 2026.

Who DORA applies to

DORA has applied since 17 January 2025 and sets requirements for a defined set of financial entities, alongside provisions reaching their ICT third-party service providers 1. Whether a given firm is an in-scope financial entity is a specific analysis. Do not assume every fintech is directly subject to every DORA requirement — some firms are in scope directly, while others encounter DORA mainly through contracts with in-scope customers. Establish which case applies to you before scoping work.

Direct and contractual exposure

There are two distinct ways DORA reaches a business. Direct exposure applies when the firm is itself an in-scope financial entity and must meet DORA’s obligations. Contractual exposure applies when the firm is an ICT vendor to an in-scope entity and inherits obligations through the contract and its customer’s compliance needs. The requirements you actually carry differ between these positions, so name yours before planning.

ICT risk-management framework

In-scope entities are expected to maintain an ICT risk-management framework covering identification, protection, detection, response and recovery 1. The framework is meant to be proportionate and embedded in the business, not a document that sits on a shelf. Vendors are frequently asked to evidence how they support each of these functions for their customers.

Governance

DORA places responsibility for ICT risk with the management body of the in-scope entity 1. Governance cannot be delegated to a vendor. The board or equivalent is expected to understand and oversee ICT risk, which is one concrete way DORA prevents responsibility from disappearing into outsourcing.

Incident classification and reporting

DORA requires in-scope entities to detect, classify and, for major incidents, report ICT-related incidents on defined terms 1. Vendors typically must support this by notifying customers promptly and providing the information they need to meet reporting duties. Agree notification timelines and content in the contract, because the customer’s clock depends on your inputs.

Resilience testing

DORA expects a programme of digital operational resilience testing appropriate to the entity, which for some entities includes more advanced testing 1. Vendors may be drawn into their customers’ testing and should understand what participation is expected. Define testing cooperation up front rather than negotiating it during an exercise.

Third-party ICT risk

A central theme of DORA is managing risk from ICT third-party service providers across the relationship lifecycle — before, during and on exit 1. In-scope entities must understand and control this dependency. As a vendor, expect deeper diligence; as an in-scope entity, expect to perform it. The fintech provider due diligence and RFP approach aligns closely with these expectations.

Contract requirements (high level)

DORA sets expectations for what ICT contracts with in-scope entities should address, at a high level covering matters such as service descriptions, data handling, access, cooperation and termination 1. Specific clauses depend on the service and its criticality. Vendors serving financial entities should expect contracts to reflect these expectations rather than generic terms.

Register of information

In-scope entities are expected to maintain a register of information on their contractual arrangements for ICT services 1. Vendors are commonly asked for the data that populates it — entity details, service descriptions and subcontracting information. Being able to supply this cleanly is part of being an easy-to-diligence vendor.

Subcontracting

Where a vendor relies on its own subcontractors, that chain becomes part of the customer’s ICT risk picture 1. Disclose subcontractors used for the service, how they are managed, and how changes are communicated. Undisclosed subcontracting is a common source of concentration and resilience surprises.

Concentration risk

DORA draws attention to concentration risk — heavy reliance on a single ICT provider or on providers that are themselves widely relied upon 1. Map where you, or your customers, are concentrated, and consider what a single provider’s failure would mean. Concentration is a resilience issue even when each individual provider looks sound.

Exit strategies

In-scope entities are expected to have exit strategies for ICT arrangements, particularly critical ones 1. Plan how you would move off a provider, over what period, with what data, and with what fallback. Vendors should support orderly exit rather than resist it. Negotiate exit terms before go-live, as with any critical dependency.

Business continuity

DORA expects business-continuity and recovery arrangements appropriate to the entity 1. Understand recovery objectives, backup arrangements and how continuity is tested. Vendors should be able to explain how their continuity arrangements support their customers’ obligations, not just their own uptime.

Data location and access

Where data is stored and processed, and who can access it, are recurring diligence points 1. Be clear about data locations, access controls and how customers or authorities can exercise access rights. Ambiguity here slows diligence and raises risk questions.

Audit and inspection

DORA contemplates audit and inspection rights over ICT arrangements 1. Vendors serving in-scope entities should expect audit and access rights in contracts and be prepared to accommodate them. Clarify scope, frequency and process so audits are workable rather than disruptive.

Critical ICT third-party oversight

DORA introduces an oversight framework for certain critical ICT third-party providers 1. Whether a provider is designated as critical is determined under the framework, not self-declared. If you might fall in scope, understand what oversight could entail; if you rely on such providers, factor the designation into your risk picture.

Provider due diligence

Treat DORA-aligned diligence as part of normal provider selection: assess ICT risk management, incident handling, testing, subcontracting, concentration, continuity and exit for each provider 1. Document the assessment. This diligence dovetails with resilience planning for core-banking and banking providers and with the modernise-core-banking-and-ledger-infrastructure stack.

What DORA does not outsource

DORA does not make outsourcing responsibility disappear. The regulated financial entity remains responsible for its obligations even when it relies on ICT third parties 1. Using a vendor can shift work, but not accountability. Build your arrangements so that responsibility is clear and evidenced, not assumed to have moved.

Direct versus contractual exposure

Dimension	Direct exposure (in-scope entity)	Contractual exposure (ICT vendor)
Basis	You are an in-scope financial entity	You serve an in-scope entity
Primary duties	DORA obligations apply to you	Support customer’s DORA compliance
Governance	Management body owns ICT risk	Support customer governance/reporting
Incidents	Detect, classify, report as required	Notify and inform customers promptly
Contracts/register	Maintain register, meet contract terms	Provide data, accept relevant terms
Responsibility	Remains with you	Does not transfer from the customer to you

Implementation checklist

• Whether you have direct or contractual exposure is established
• ICT risk-management framework functions are documented (identify, protect, detect, respond, recover)
• Governance ownership of ICT risk is assigned to the management body
• Incident classification and reporting/notification timelines are defined
• Resilience-testing expectations and cooperation are agreed
• Third-party ICT risk is assessed across the lifecycle
• Contracts address service, data, access, cooperation and termination
• Register-of-information data is maintained or supplied
• Subcontracting chains are disclosed and managed
• Concentration risk is mapped
• Exit strategies and continuity arrangements are documented

Questions to ask providers

• Are you an in-scope entity, an ICT vendor, or both, for DORA purposes?
• How is your ICT risk-management framework structured across the five functions?
• How and how quickly will you notify us of ICT incidents?
• How do you support resilience testing and audit or inspection rights?
• Which subcontractors support this service, and how are changes communicated?
• What data can you provide for our register of information?
• Where is data stored and processed, and who can access it?
• What are your continuity arrangements and our exit path?

Common failure modes

• Assuming every fintech is directly subject to every DORA requirement 1.
• Treating a vendor relationship as transferring responsibility away from the regulated entity.
• Leaving governance of ICT risk unassigned or delegated to the vendor.
• Agreeing incident notification terms too late to meet reporting clocks.
• Overlooking subcontracting chains and concentration risk.
• Signing without exit strategies or continuity arrangements for critical services.

What this does not cover

This article does not determine whether your firm is an in-scope entity, whether a provider is a critical ICT third party, or whether any arrangement meets DORA. Those are fact-specific and legal questions. It is not legal, regulatory or compliance advice, and specific conclusions require qualified analysis.

FAQ

When did DORA start to apply?

DORA has applied since 17 January 2025 1.

Does DORA apply directly to my fintech?

Not necessarily. Some firms are in scope directly; others encounter DORA contractually as ICT vendors to in-scope entities. Establish which applies to you before scoping work 1.

Can I outsource DORA responsibility to a provider?

No. DORA does not make outsourcing responsibility disappear; the regulated financial entity remains responsible for its obligations 1.

What does DORA require around ICT third parties?

It requires managing ICT third-party risk across the lifecycle, including contracts, a register of information, subcontracting, concentration risk and exit strategies 1.

What is the register of information?

It is a record in-scope entities are expected to maintain about their ICT contractual arrangements; vendors are often asked to supply data that populates it 1.