An operational guide for SaaS and cloud vendors responding to DORA-driven requirements from EU financial-sector customers.
DORA is a regulation, and it reaches suppliers directly
The Digital Operational Resilience Act (Regulation EU 2022/2554) has applied since 17 January 2025. Unlike NIS2, it is a regulation — directly applicable across the EU with no national transposition, so the rules are the same in every member state.
It governs financial entities: banks, insurers, investment firms, payment institutions, crypto-asset service providers and more. But the part that matters commercially to technology companies is that DORA explicitly extends to ICT third-party service providers — which includes most SaaS and cloud vendors selling into financial services.
Two very different ways you can be affected
| Contractual route (most vendors) | Direct oversight route (a handful) | |
|---|---|---|
| Who | Any ICT provider serving EU financial entities | Providers formally designated Critical ICT Third-Party Providers (CTPPs) |
| How obligations arrive | Through your customers' contracts | Directly from the European Supervisory Authorities |
| What it involves | Mandatory contract clauses, audit rights, exit support, incident cooperation | Annual risk assessments, on-site inspections, mandatory reporting, potential recommendations |
| Scale | Thousands of vendors | 19 designated in the first list published November 2025 |
The first CTPP list includes the names you would expect — Amazon Web Services, Google Cloud, Microsoft, Oracle, SAP and Deutsche Telekom among them. If you are not on that list, your DORA exposure is entirely contractual, and that is still substantial.
What your financial-services customers must now demand
Articles 28–30 set out what has to be in the contract. Your customers cannot negotiate these away — they are regulatory obligations, which is why procurement conversations have got noticeably less flexible.
Expect every contract to require:
- Full description of services, including whether the function is "critical or important"
- Locations where services are provided and data is processed and stored, plus notice of changes
- Data protection provisions — availability, authenticity, integrity, confidentiality
- Access, inspection and audit rights for the customer, their auditors and the competent authority. Unrestricted, not "reasonable endeavours"
- Assistance during ICT incidents, at no additional cost or at a pre-agreed cost
- Participation in the customer's threat-led penetration testing (TLPT) where relevant
- Exit strategies — a transition period, support during exit, and no disruption to the customer's ability to comply
- Termination rights for specified circumstances including regulatory breach
- Service level agreements with precise quantitative targets
- Sub-outsourcing conditions, including notice and rights to object
The register of information — why your customers keep asking for data
Article 28(3) requires every financial entity to maintain a register of all ICT contractual arrangements and submit it annually to their competent authority by 31 March.
The register demands specific fields from you: legal entity identifier, service description, whether it supports a critical or important function, contract dates, country of data processing and storage, and — this catches vendors out — the full sub-outsourcing chain.
That last point means you need to be able to name your own critical sub-processors and their locations, on demand, in a structured format. Vendors that cannot produce this cleanly create real friction in renewals.
Supervisors have signalled enforcement of persistent register deficiencies from the 2026 supervisory cycle onward, so this is moving from a paperwork exercise to a genuine control.
Incident reporting flows back to you
Financial entities have strict incident classification and reporting duties for major ICT-related incidents. Since many incidents originate with or involve suppliers, your contracts will require you to notify and assist promptly — often within timeframes far shorter than a typical support SLA.
Practical implication: your incident communication process needs a financial-services path that triggers fast, provides technical detail suitable for a regulatory filing, and does not wait for a full post-incident review.
What to do if you sell into EU financial services
- Establish whether you support "critical or important functions" for any customer. This drives how heavy the obligations are.
- Pre-build a DORA contract addendum. Vendors who arrive with compliant clauses ready close deals faster than those negotiating from a standard MSA.
- Map and document your sub-processors — legal entities, services, countries. Publish it and keep it current.
- Get your data location story precise. "EU region" is no longer sufficient; they need processing and storage locations, and change notification.
- Build the register-of-information data pack as a standard artefact you can hand over, not a bespoke response each time.
- Rehearse the exit plan. Exit support is a contractual requirement and customers increasingly test that it is real.
- Prepare for audits. Some customers will exercise audit rights; pooled audits and third-party attestations (SOC 2, ISO 27001) reduce but do not eliminate this.
The commercial opportunity
DORA is genuinely burdensome, but it advantages prepared vendors. Financial entities are actively consolidating suppliers who cannot meet the requirements. A vendor with a ready addendum, clean sub-processor register, precise data-location documentation and a tested exit plan wins business from competitors who treat each request as a fire drill.
Frequently asked questions
We are a small SaaS vendor — does DORA really reach us?
Not directly, but through your customers, yes. Size is not the trigger; serving an EU financial entity is. Small vendors often face the same contract clauses as large ones.
Are UK vendors affected?
DORA applies to EU financial entities. UK vendors serving those entities are affected contractually. The UK has its own parallel regime for critical third parties, so many vendors end up managing both.
Does SOC 2 or ISO 27001 satisfy DORA?
They help substantially with the evidence burden and can reduce audit frequency, but neither replaces the specific contractual provisions, register data or exit requirements.