DORA for SaaS Vendors: What Your Financial-Services Customers Will Ask For

Since 17 January 2025, banks, insurers, and payment providers have been asking their SaaS and ICT vendors for two things above all: structured details for their register of information under Article 28(3) DORA, and contractual clauses under Article 30 — covering everything from data locations and service levels to exit arrangements. The addressee of these obligations is the financial entity itself, not you; but it can only meet them if you, the vendor, supply the required details and evidence.

This article explains what sits behind the questionnaires and contract annexes your financial customers are sending — and which evidence artifacts you can deliver. It is guidance, not legal advice.

What is DORA — and since when does it apply?

DORA is the Digital Operational Resilience Act, formally Regulation (EU) 2022/2554 of 14 December 2022. As an EU regulation it applies directly in every member state — since 17 January 2025, as Germany’s financial supervisor BaFin confirms. There is no transition period: your financial customers have been in scope for over a year.

Who falls under DORA is listed in Article 2(1) across 21 categories — including credit institutions, payment institutions, e-money institutions, investment firms, crypto-asset service providers, insurance and reinsurance undertakings, insurance intermediaries, and occupational pension institutions. If your customers come from any of these categories, DORA matters to you — even though the regulation never mentions you by name.

In Germany, the FinmadiG (Financial Market Digitalisation Act, published 27 December 2024) aligned national laws such as the KWG and VAG with DORA; BaFin acts as the national reporting hub for ICT incidents in the financial sector.

Why are you receiving DORA requirements when you are not a financial entity?

Because DORA extends financial entities’ risk management across their entire ICT supply chain — and you are part of that chain. Two definitions make this unavoidable:

• An ICT third-party service provider is, under Article 3(19), simply “an undertaking providing ICT services” — deliberately broad, with no size or industry threshold.
• ICT services are, under Article 3(21), digital and data services provided through ICT systems on an ongoing basis. SaaS falls under that definition — a legal interpretation to confirm case by case, but rarely contested in practice.

An important framing point: you are not under direct DORA supervision. The only exception is designation as a “critical ICT third-party service provider” under Article 31 by the European Supervisory Authorities — which targets systemically relevant hyperscalers, not the typical SaaS vendor. But your financial customers must enter you into their register of information and agree the Article 30 clauses with you, because under Article 28(1)(a) they remain “at all times fully responsible” for complying with DORA. Proportionality is built in (Article 28(1)(b)): the intensity of the requirements scales with the risk and criticality of the service.

You may recognise the pattern from other regulated verticals — healthcare software vendors get availability and security requirements passed down by their clinic customers in much the same way (see our healthcare page). Regulated customers don’t just buy features; they buy evidence.

What goes into the register of information — and which details does your customer need from you?

Under Article 28(3) DORA, financial entities maintain a register of information covering all contractual arrangements with ICT third-party service providers — not only the critical ones. The register distinguishes between contracts supporting critical or important functions and all others. At least yearly, financial entities report to their supervisor the number of new arrangements, the provider categories, and the type of contracts and services; on request, they must produce the complete register. Planned contracts for critical or important functions must even be notified to the supervisor in advance.

The register’s structure is not left to chance: Implementing Regulation (EU) 2024/2956 of 29 November 2024 sets standard templates. That is why the questionnaires from your financial customers look so uniform: who you are, what you deliver, where you process data, which subcontractors you use, which function your service supports.

What counts as a “critical or important function” is defined in Article 3(22): a function whose disruption would materially impair the financial entity’s financial performance, soundness, or business continuity, or its compliance with its authorisation conditions. Your customer makes that classification itself — before signing the contract (Article 28(4)(a)). You cannot control it, but you should know which bucket you landed in, because it decides which clauses appear in your contract.

Which contractual clauses does Article 30 require — and what does the criticality classification change?

Article 30 carries the official title “Key contractual provisions”. Paragraph 1 requires that the rights and obligations be set out in writing in one complete contract, including service level agreements. From there, the article splits into two tiers:

Tier	Applies to	Core content
Article 30(2) (points a–i)	all ICT contracts	service description + subcontracting conditions; locations of service provision and data processing incl. storage, with advance notice of changes; availability, integrity, confidentiality; data return on insolvency or termination in an accessible format; service level descriptions; incident assistance at no extra or pre-agreed cost; cooperation with authorities; termination rights; security training participation
Article 30(3) (points a–f)	additionally for critical or important functions	full SLAs with precise quantitative and qualitative performance targets for effective monitoring; notice periods + provider reporting duties (incl. developments that could affect performance); tested contingency plans and ICT security measures; participation in threat-led penetration testing (Articles 26/27); unrestricted audit and inspection rights for the financial entity and the supervisor; exit strategies with a mandatory transition period

Once more, plainly: you are not the one who “must comply with Article 30” — your financial customers must agree these clauses with you. The practical question for you: can you back the commitments your customer needs on paper with credible artifacts? Vendors who can cut vendor reviews from weeks to days.

Which evidence can you actually deliver? The mapping table

Here is the translation from contractual requirement to evidence artifact — the material you can proactively place in your customer’s due-diligence folder:

Your financial customer’s requirement (register of information / Article 30 contract)	Evidence artifact you deliver
Data location and processing sites (Art. 30(2)(b))	Documented hosting location (region/country, datacenter) + complete sub-processor list with jurisdictions — the EU Jurisdiction Database maps both for 50+ SaaS tools
Service levels and availability (Art. 30(2)(c), (e) / 30(3)(a))	Continuous availability report with uptime history — measured numbers, the basis for the “effective monitoring” paragraph 3(a) demands
Assistance with ICT incidents (Art. 30(2)(f))	Complete incident history with timestamps (start, detection, resolution) + a public status page as a transparent communication channel
Provider reporting obligations (Art. 30(3)(b))	Automatic incident notifications (email, webhook, status page subscriptions) that reach your customer without manual steps
Data protection / processing agreement (Art. 28 GDPR, alongside Art. 30(2)(c))	A DPA under Article 28 GDPR, available as an instant download rather than after a sales call
Exit and data return (Art. 30(2)(d) / 30(3)(f))	Documented data export in an easily accessible format + a described offboarding process with a transition period

The common thread: almost every row demands ongoing, timestamped evidence rather than one-off assurances. A PDF stating “99.9% targeted” does not answer paragraph 3(a) — a verifiable uptime history comes much closer.

The data-location row deserves extra attention: after Schrems II, your providers’ jurisdiction matters as much as your servers’ physical location — a topic we unpack in US CLOUD Act & SaaS monitoring. A stack running on US-operated services becomes a line item your customer has to explain in its register.

What happens during an ICT incident — and why does your customer need your data so fast?

Because your customer has deadlines of its own. Financial entities must report major ICT-related incidents to their authority (Article 19(1)) — in three stages: initial, intermediate, and final report (Article 19(4)) — and may also have to inform their clients (Article 19(3)). If the root cause sits in your service, your customer’s report depends on your information: when the disruption started, what was affected, when it was resolved.

That is exactly why “assistance with ICT incidents” (Article 30(2)(f)) and the provider’s reporting obligations (paragraph 3(b)) end up in the contract. A vendor that detects incidents automatically, documents them with timestamps, and communicates proactively makes its customer’s reporting chain workable.

What role does FoundersDeck play — and which role doesn’t it?

The boundary first: no monitoring tool makes you or your financial customer DORA-compliant. DORA compliance is an organisational achievement of the financial entity — governance, risk management, contracts, testing. What monitoring does is something else: it produces the evidence required in several rows of the table above.

FoundersDeck contributes three building blocks: continuous availability monitoring with uptime history (service-level evidence), automatic incident detection with a complete, timestamped incident history (evidence for incident assistance and reportability), and cookie-free status pages as a transparent communication channel. Add what matters for the data-location row: 100% German infrastructure (Netcup, Nuremberg), no US jurisdiction in the chain, and a DPA as an instant download. That way your monitoring stack never becomes a register entry your financial customer has to explain — a lens we apply to the whole category in our GDPR-compliant monitoring tools 2026 comparison.

Frequently Asked Questions

Does DORA apply directly to SaaS vendors?

No — the addressee of DORA’s obligations is the financial entity, not its vendor. Small and mid-sized SaaS providers face no direct DORA supervision; the only exception is designation as a “critical ICT third-party service provider” under Article 31 by the European Supervisory Authorities, which in practice targets systemically relevant hyperscalers. DORA still reaches you, though: your financial customers must record every ICT contract in their register of information (Article 28(3)) and agree the Article 30 clauses with you. Under Article 28(1)(a) the financial entity remains “at all times fully responsible” for DORA compliance — which is why it scrutinises its vendors so closely.

What is the DORA register of information?

Under Article 28(3) DORA, financial entities must maintain a register of information covering all contractual arrangements with ICT third-party service providers — not just the critical ones. The register distinguishes between contracts that support critical or important functions and all others. At least yearly, financial entities report to their supervisor the number of new arrangements, the provider categories, and the type of contracts and services; on request they must produce the full register. The standard templates are set by Implementing Regulation (EU) 2024/2956. For you as a vendor, that means your customer needs structured, register-ready details about the service, its locations, and your subcontractors.

Which contractual clauses does Article 30 DORA require?

Article 30, officially titled “Key contractual provisions”, requires that rights and obligations be set out in writing in one complete contract that includes service level agreements. For all ICT contracts, paragraph 2 mandates, among other things: a full service description including subcontracting conditions, the locations of service provision and data processing including storage, provisions on availability, integrity and confidentiality, data return on insolvency or termination, service level descriptions, assistance with ICT incidents, and termination rights. Where the service supports a critical or important function, paragraph 3 adds full SLAs with precise quantitative and qualitative performance targets, provider reporting obligations, contingency plans, participation in penetration testing, unrestricted audit and inspection rights, and exit strategies with a mandatory transition period.

Am I an ICT third-party service provider under DORA even as a small SaaS company?

Very likely, yes. Article 3(19) DORA deliberately defines an ICT third-party service provider broadly as “an undertaking providing ICT services” — with no size or industry threshold. ICT services are, under Article 3(21), digital and data services provided through ICT systems on an ongoing basis; SaaS falls under that definition (a legal interpretation to confirm case by case). Whether your service supports a “critical or important function” is not your call: the financial entity makes that assessment before signing (Article 28(4)(a)) — determining whether only the baseline clauses of Article 30(2) or also the stricter paragraph 3 requirements end up in your contract.

---

This article is intended as orientation, not legal advice. The authoritative texts are Regulation (EU) 2022/2554 (DORA), Implementing Regulation (EU) 2024/2956 on the register templates, and the BaFin DORA overview. Last reviewed: July 2026.