DORA Compliance for FinTech SaaS: What ICT Third-Party Providers Must Ship by End of 2026

The Digital Operational Resilience Act went live across the EU in January 2025. By now, every bank, insurance firm, and investment platform subject to DORA has started sending questionnaires to their software vendors — and many of those vendors have discovered they are significantly underprepared. DORA compliance for FinTech SaaS is no longer a future obligation. It is a present commercial reality: financial institutions that cannot satisfy their supervisors about the resilience of their ICT third-party providers are terminating contracts and blocking new deals.

If you sell SaaS into EU financial services and you have not yet mapped your DORA obligations, this post gives you the concrete engineering deliverables. You do not need a compliance team to get this right. You need to understand what banks are actually asking for and build the features that answer those questions.

What DORA Means for SaaS Vendors Specifically

DORA applies directly to financial institutions. But Article 28 requires those institutions to flow down contractual and audit rights to their ICT third-party service providers — which includes virtually every SaaS product that processes data on behalf of a regulated entity. Whether you provide a payment gateway, a KYC API, a document management system, or a data analytics platform, if your product touches a bank's operational systems you are in scope.

The obligations that land on your product break into four categories: incident reporting infrastructure, threat-led penetration testing readiness, register-of-information exports, and exit plan documentation. Each one requires engineering work, not just policy documents.

Incident Classification and the 4-Hour Problem

DORA sets a hard 4-hour window for financial institutions to report major ICT incidents to their national competent authority. Your SaaS product is part of their incident timeline. If your service goes down, degrades, or is compromised, your customers need structured information from you — fast — so they can meet their own reporting deadlines.

What banks are asking for in their DORA questionnaires:

• Does your platform emit structured incident notifications with severity classification, estimated recovery time, and affected functionality scope?
• Do you maintain a classification taxonomy that maps to DORA's major/significant/minor incident tiers?
• Is the notification delivered to a designated security contact within 30 minutes of internal declaration, with updates at defined intervals until resolution?

The engineering required here is real but not exotic. You need an incident classification framework built into your engineering runbook — a decision tree that maps observable platform events (API error rate, database replication lag, authentication failure rate) to DORA severity tiers. You need an internal communications channel that feeds an external status page and a direct email/webhook channel to each financial institution customer. And you need documentation showing that your engineering team rehearses this process.

If your current incident management is informal Slack threads and ad-hoc email, that needs to change before an enterprise bank will sign a contract.

TLPT Readiness: Threat-Led Penetration Testing

DORA mandates Threat-Led Penetration Testing (TLPT) for significant financial entities, and those entities are contractually required to ensure their critical ICT third-party providers participate when scoped into a test. TLPT is not a standard penetration test — it is a red-team exercise based on current threat intelligence, conducted by accredited testers, using production systems.

You are unlikely to be pulled into a full TLPT engagement unless you are a critical provider to a major institution. But every bank's vendor questionnaire asks whether you are TLPT-ready, meaning: can you give a red team controlled access to production-equivalent infrastructure without disrupting other customers, and can you receive their findings under NDA and remediate within a documented timeframe?

What you need to build or document:

• A staging or shadow environment that mirrors production architecture closely enough to be useful for a penetration test
• An NDA and test scoping process that your legal and engineering teams can execute in under two weeks
• A vulnerability remediation SLA that specifies timelines by severity (critical, high, medium), and evidence that you have met those SLAs historically
• A designated point of contact for security testing engagements

The environment isolation piece is the most significant engineering investment here, particularly if you run a multi-tenant SaaS where a test against one tenant's data could have lateral movement implications for others. If that is your architecture, the answer is either a dedicated single-tenant test environment or a tenant isolation audit that you can present to demonstrate the blast radius is contained.

Register of Information: What Your Customers Have to File

DORA requires financial entities to maintain a comprehensive Register of Information covering all ICT third-party contracts. The European Supervisory Authorities have published specific data templates — the Register must capture contract start and end dates, criticality classification, data categories processed, sub-processor chains, and termination provisions.

Your customers will be coming to you to help them fill this out. If you make that process difficult or slow, you become a compliance liability. If you make it straightforward, you become a preferred vendor.

What good looks like: a dedicated DORA documentation pack that you maintain and version. This typically includes a completed Register of Information template (pre-filled with your fields), a list of your own sub-processors and their locations, your Business Continuity Plan summary, and your data processing agreement. Some vendors expose this via a Trust Center; others deliver it as a PDF on request. Either works, but it needs to exist and be current.

The sub-processor question deserves particular attention. If you use AWS, Azure, or GCP as infrastructure, that is straightforward to document. If you use third-party enrichment services, fraud APIs, or AI inference providers that touch customer data, each one needs to appear in your sub-processor list with country of processing and contractual basis. If you have not audited your own supply chain from this angle, now is the time.

Exit Plan Engineering

This is the part most SaaS vendors get wrong because it feels counterintuitive: your customers' DORA compliance requires them to have a credible plan for terminating their contract with you and migrating to an alternative — without operational disruption. You need to actively support that plan, not because you want to lose customers, but because financial institutions are contractually required to demonstrate it is feasible.

What a DORA-ready exit plan requires from your side:

• A data export capability that can produce a complete, machine-readable export of all customer data within a defined timeframe (typically 30 days)
• Documentation of all proprietary data formats and how they map to open standards
• A transition assistance commitment — a documented period during which you will support a customer migrating away, including API access during wind-down
• A knowledge transfer package: API documentation, data dictionaries, integration specifications

The practical engineering implication is that if your SaaS uses opaque internal data models, or if bulk export is not currently a supported feature, you need to build it. Banks are increasingly refusing to sign contracts with vendors who cannot produce a credible exit plan. This is not a threat; it is a procurement criterion.

Where to Start If You Are Behind

If you are reading this as a product owner or CTO of a FinTech SaaS that sells to EU financial institutions and you have not started this work, the honest answer is that you are behind — but not catastrophically so if you start now.

The sequence that produces the fastest meaningful progress:

First, produce a Register of Information pack. This is mostly documentation work and gives you an immediately useful artefact you can hand to enterprise prospects. Second, implement structured incident notifications. This requires engineering but has a clear scope and a quick delivery cycle. Third, audit your sub-processor chain and update your data processing agreements. Third, build the data export capability if it does not exist. Fourth, create the exit plan documentation.

Threat-led penetration testing readiness is important but has the longest lead time and lowest immediate commercial impact — prioritise it after the others.

The Business Case Is Straightforward

Every financial institution subject to DORA is auditing their ICT third-party providers. Those audits have procurement consequences. Vendors who can demonstrate operational resilience are winning contracts that non-compliant vendors are losing. If you are in the FinTech space in Europe, DORA compliance is not a cost — it is a market access requirement.

The engineering work involved is real but tractable. For most mid-size SaaS products, the full implementation — incident infrastructure, documentation pack, export capability, exit plan — is a three-to-six-month project with a focused team.

If your product is in scope and you want an honest assessment of where you stand and what the implementation path looks like, the starting point is a structured technical review. You can reach the Wolf-Tech team at hello@wolf-tech.io or book a discovery call at wolf-tech.io. We have worked through DORA implementation with FinTech SaaS products ranging from seed-stage startups to Series B platforms, and we can give you a clear picture of your gap and a realistic timeline to close it.

Frequently Asked Questions

Does DORA apply to SaaS vendors that are not themselves financial institutions?

DORA applies directly to financial entities regulated under EU law. However, Article 28 requires those entities to include DORA-aligned contractual provisions in their agreements with ICT third-party providers — including SaaS vendors. In practice, if you sell to EU banks or investment firms, you will face DORA-derived requirements through your contracts regardless of your own regulatory status.

What is the difference between a major and significant ICT incident under DORA?

The European Supervisory Authorities published classification criteria based on the number of customers affected, the duration of the disruption, the geographic spread, and the economic impact. A major incident triggers the 4-hour initial report and 72-hour detailed report timeline. Significant incidents have a lighter reporting regime. Your platform needs an incident classification process that can make this determination reliably and quickly.

Are non-EU SaaS vendors subject to DORA?

Yes, if they provide services to EU-regulated financial entities. DORA has no carve-out for vendors based outside the EU. A US-based SaaS providing services to a German bank is subject to the same contractual DORA obligations as a Berlin-based vendor.

What does a DORA audit by a financial institution actually look like?

Most commonly it takes the form of a detailed questionnaire (often based on a standardised template) followed by an evidence review. For critical ICT providers, on-site audits are possible. The questionnaire typically covers your business continuity plan, incident management process, security testing practices, sub-processor chain, and exit plan. Having prepared documentation dramatically reduces the time these audits take.