The Digital Operational Resilience Act came into force across the European Union on 17 January 2025. A year on, the dust has settled enough to see how it has actually changed the way banks, insurers, investment firms, and crypto-asset service providers do security due diligence on their software vendors. The short version: due diligence is no longer a one-off questionnaire at procurement. It is a continuous, contract-bound, regulator-visible process — and SaaS vendors that sell into European financial services have had to adapt their security review motion accordingly.
If you are a CTO at a SaaS company that signs deals with EU banks, or a security lead at a financial institution navigating the new rules, this is what 2026 actually looks like under DORA.
Key takeaways:
- DORA applies to almost every financial entity in the EU and indirectly to every “ICT third-party service provider” that supplies them, regardless of where the vendor is based
- Vendor due diligence is now formalised in regulation rather than handled as an internal procurement preference, with mandatory contract clauses and ongoing monitoring requirements
- Security questionnaires sent by European financial firms have grown longer, more prescriptive, and now ask for evidence rather than attestations
- “Critical ICT third-party service providers” face a designation regime that gives EU regulators direct oversight authority — including the right to conduct on-site inspections
- Vendors that prepare with a structured response library, mapped controls, and proactive evidence packs are signing DORA-affected contracts in days; vendors that do not are losing deals to procurement timelines that now run six to twelve weeks
What DORA actually changed
Before DORA, vendor security due diligence in European financial services was governed by a patchwork of guidelines: the EBA Guidelines on Outsourcing Arrangements, the EIOPA guidelines for insurers, ESMA guidance for investment firms, and a long list of national supervisory expectations. The bar was uneven. A small fintech in Lithuania might do a checklist questionnaire. A tier-one French bank might do a six-month onsite review. The same vendor could go through wildly different processes depending on which financial firm was buying.
DORA replaced that patchwork with a single regulation that applies directly across all 27 EU member states. The five pillars — ICT risk management, incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing — give financial entities a common framework. Chapter V on third-party risk is the chapter that has reshaped vendor due diligence specifically.
The practical effect is that every “ICT third-party service provider” — which includes virtually any SaaS company providing software to a financial firm — now sits inside a regulated due diligence regime. The financial entity is the one on the hook with the regulator, but the obligations flow through to the vendor through contracts, questionnaires, evidence requests, and ongoing oversight.
How security questionnaires have changed in 2026
The single most visible change for SaaS vendors is the security questionnaire itself. We have seen three patterns emerge consistently across the financial customers our users work with.
Questionnaires are longer and more prescriptive
Pre-DORA, a typical financial services questionnaire ran 100 to 200 questions and leaned heavily on yes/no attestations. Post-DORA questionnaires regularly run 300 to 600 questions and ask for specific evidence: SOC 2 reports, ISO 27001 certificates, penetration test summaries, BC/DR test results, sub-processor lists, encryption key management documentation, and named individuals accountable for each ICT risk domain.
“We used to get one questionnaire per deal. Now we get a questionnaire, an evidence pack request, a contract addendum review, and a six-month follow-up baked into the procurement timeline from day one.”
The new questions are also more prescriptive. Where a 2024 questionnaire might have asked “do you have a business continuity plan?”, a 2026 DORA-aligned questionnaire asks for the recovery time objective for each in-scope service, the date of the last full restoration test, the name of the executive accountable for BC, and a copy of the most recent BIA. Generic answers no longer pass.
Evidence is mandatory, not optional
Article 28 of DORA requires financial entities to maintain a “register of information” on all contractual arrangements with ICT third-party providers. That register has to be machine-readable and reportable to the regulator. To populate it, financial firms ask vendors for structured evidence: SOC 2 type 2 reports, penetration test letters, sub-processor lists with locations and data flows, certifications with valid expiry dates, and named incident contacts.
A vendor that responds with “we follow industry best practices” is not just being weak on the questionnaire — they are failing to give the financial firm what the firm needs to comply with the regulation. Those vendors get filtered out at the due diligence stage.
Contract terms come pre-loaded
DORA Articles 28 and 30 set out mandatory contractual provisions for ICT service contracts, with even stricter requirements for contracts supporting “critical or important functions”. As a result, financial firms now arrive at the contracting stage with a pre-built DORA addendum that they expect the vendor to accept with minimal redlines. Common provisions include:
- Detailed description of the services, data, and locations of processing
- Service levels with quantitative targets
- Vendor obligations to assist with incident reporting under the DORA 24-hour/72-hour/one-month timeline
- Audit and inspection rights, including for the financial entity, its auditors, and the competent regulator
- Termination rights triggered by regulatory action against the vendor
- Exit plans and assistance obligations
- Sub-contracting controls, including prior notification and consent for sub-processors supporting critical or important functions
Vendors that try to negotiate these clauses out tend to learn quickly that the financial entity does not have the option to remove them. They are not the customer’s preference; they are the customer’s obligation.
The “critical ICT third-party service provider” designation
The most novel piece of DORA is the designation regime in Articles 31 to 44. The European Supervisory Authorities — EBA, EIOPA, and ESMA, sitting together as the ESAs — can designate ICT third-party service providers as “critical” when they are systemically important to the EU financial sector. Once designated, the provider falls under the direct oversight of a Lead Overseer, which is one of the ESAs.
The Lead Overseer can:
- Request information about the provider’s ICT risk management, security, business continuity, and incident response
- Conduct general investigations and on-site inspections
- Issue recommendations on operational resilience that the provider is expected to follow
- Impose periodic penalty payments for non-compliance with information requests or inspections
- Coordinate cross-border supervisory activity through joint oversight teams
The first critical designations landed in 2025. The list is short — the largest cloud providers, payment networks, and core banking system vendors — but the implications cascade across the supply chain. If you are a SaaS vendor that runs on AWS, Azure, or GCP, your customer’s questionnaire is going to ask you specifically how your business continuity plan handles a degradation event at a designated critical third party, and how you would migrate workloads in a regulator-mandated exit scenario.
Most SaaS vendors will never be designated critical themselves. But almost all of them will be in scope of a customer’s DORA-driven supply chain assessment.
What financial firms are doing differently in 2026
A year into DORA, the financial firms we see have settled into three observable practices that vendors need to plan around.
A pre-procurement gating step
Many financial firms have added a gating step before they will issue a full security questionnaire. A short pre-questionnaire — typically 20 to 40 questions — screens out vendors that obviously do not meet baseline DORA expectations. Vendors that fail the gate are dropped before they get to a full review. Vendors that pass are invited into the full procurement process.
The questions on the gate are predictable: do you hold SOC 2 type 2 or ISO 27001, do you have a designated incident contact in the EU or named representative, can you accept DORA contract clauses without material redlines, do you publish a sub-processor list, do you support the customer’s audit rights. A “no” on any of these typically ends the conversation.
A formal annual reassessment
DORA expects ongoing monitoring of ICT third parties, not point-in-time review. Most financial firms have built that into an annual reassessment programme. The reassessment is a lighter questionnaire than the initial one — focused on changes, incidents, certification renewals, and any material changes to the service or sub-processors — but it is a real cycle of work that vendors should expect every twelve months for every active financial customer.
Vendors that maintain a current evidence pack and a current sub-processor list handle the reassessment in days. Vendors that have to rebuild the evidence from scratch each year burn weeks of engineering time and risk missing reassessment deadlines that can trigger contract review.
Concentration risk and exit planning
Articles 28(2) and 28(7) of DORA require financial firms to assess concentration risk — the risk of becoming over-reliant on a single provider — and to maintain documented exit strategies for services supporting critical or important functions. This shows up in vendor questionnaires as questions about portability, data export formats, transition assistance commitments, and the existence of viable alternatives in the market.
Vendors that have invested in standards-based interfaces, exportable data formats, and documented migration assistance offer a stronger answer than vendors that effectively lock the customer in. Lock-in used to be a commercial moat; under DORA it is increasingly a procurement liability.
What SaaS vendors should do in 2026
If you sell into European financial services, the questions you should be asking yourself in 2026 are different from the questions you were asking yourself in 2024.
Map your evidence to DORA categories. The DORA implementing regulations and the ESAs’ Regulatory Technical Standards specify the categories of information that financial firms need to collect. Map your existing security and compliance evidence — SOC 2 controls, ISO 27001 statements of applicability, penetration test reports, BCP/DR documentation — to those categories. When a customer asks for evidence, you should be able to hand over a single pack rather than scrambling to find documents.
Maintain a current sub-processor list with locations and data flows. This is now table stakes. The list should include the entity name, country, services provided, type of data accessed, and the basis on which they are engaged. Update it every quarter, publish it on your trust portal, and notify customers of material changes in line with your contract terms.
Build a DORA contract addendum you can sign. Reading every customer’s DORA addendum from scratch eats legal cycles you do not have. Build your own version aligned to Articles 28 and 30, mark which clauses you will accept and which you will negotiate, and offer it proactively. Customers will redline it, but you will save weeks of back-and-forth.
Invest in a structured response library. With questionnaires now reaching 600 questions and reassessment running every year, treating each questionnaire as a bespoke writing exercise is no longer viable. A canonical response library — with reviewed, approved, and dated answers — is the difference between a one-week response cycle and a six-week one. (This is exactly the problem ResponseHub was built to solve, and DORA has accelerated demand for it considerably.)
Identify your “critical or important function” exposure. If your software supports a customer’s critical or important function — payments, trading, core banking, claims handling — you will face stricter contract terms and more intensive due diligence. Know where you sit in the customer’s value chain so you can answer the right questions about RTO, RPO, and exit planning without having to ask.
The bottom line
DORA has not invented vendor due diligence. European banks were doing serious security reviews of their vendors long before January 2025. What DORA has done is standardise the practice, raise the floor, and put a regulator behind it. The financial firm on the other side of your sales process no longer has the discretion to take your word for it. They need evidence, they need contract protections, and they need ongoing assurance — because if they cannot demonstrate that to their regulator, they have a compliance failure that is far more expensive than any procurement delay.
For SaaS vendors, the trajectory is clear. The companies that have invested in structured evidence, prepared contract terms, and continuous response infrastructure are closing DORA-affected deals on familiar timelines. The companies still treating each questionnaire as a fire drill are watching procurement cycles stretch from weeks to months and losing competitive bids to vendors that look more operationally mature — not because they have better security, but because they can prove it faster.
DORA is not going away. The smart move in 2026 is to stop treating it as a one-off compliance burden and start treating it as a permanent feature of selling software into European financial services.
